Prep main for 9.1 (#4555)

* Prep for Release 9.1

* Update Patch Version

* Update Patch version

* Update Patch version

rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml

@@ -1,10 +1,8 @@
 [metadata]
 creation_date = "2020/12/21"
 integration = ["endpoint", "windows", "system"]
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
-min_stack_version = "8.14.0"
 maturity = "production"
-updated_date = "2025/02/21"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -27,6 +25,41 @@ language = "eql"
 license = "Elastic License v2"
 max_signals = 33
 name = "Potential Cookies Theft via Browser Debugging"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Cookies Theft via Browser Debugging
+
+Chromium-based browsers support debugging features that allow developers to inspect and modify web applications. Adversaries can exploit these features to access session cookies, enabling unauthorized access to web services. The detection rule identifies suspicious browser processes using debugging arguments, which may indicate cookie theft attempts, by monitoring specific process names and arguments across different operating systems.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of suspicious debugging arguments such as "--remote-debugging-port=*", "--remote-debugging-targets=*", or "--remote-debugging-pipe=*". Check if these arguments were used in conjunction with "--user-data-dir=*" and ensure "--remote-debugging-port=0" is not present.
+- Identify the user account associated with the suspicious browser process to determine if it aligns with expected behavior or if it might be compromised.
+- Investigate the source IP address and network activity associated with the process to identify any unusual or unauthorized access patterns.
+- Check for any recent changes or anomalies in the user's account activity, such as unexpected logins or access to sensitive applications.
+- Correlate the event with other security alerts or logs to identify if this activity is part of a broader attack pattern or campaign.
+- If possible, capture and analyze the network traffic associated with the process to detect any data exfiltration attempts or communication with known malicious IP addresses.
+
+### False positive analysis
+
+- Development and testing activities may trigger the rule when developers use debugging features for legitimate purposes. To manage this, create exceptions for known developer machines or user accounts frequently involved in web application development.
+- Automated testing frameworks that utilize browser debugging for testing web applications can also cause false positives. Identify and exclude processes initiated by these frameworks by specifying their unique process names or user accounts.
+- Browser extensions or tools that rely on debugging ports for functionality might be flagged. Review and whitelist these extensions or tools if they are verified as safe and necessary for business operations.
+- Remote support or troubleshooting sessions using debugging features can be mistaken for suspicious activity. Implement a policy to log and review such sessions, allowing exceptions for recognized support tools or personnel.
+- Continuous integration/continuous deployment (CI/CD) pipelines that involve browser automation may inadvertently match the rule criteria. Exclude these processes by identifying and filtering based on the CI/CD system's user accounts or process identifiers.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious browser processes identified with debugging arguments to stop potential cookie theft in progress.
+- Conduct a thorough review of access logs for the affected web applications or services to identify any unauthorized access attempts using stolen cookies.
+- Invalidate all active sessions for the affected user accounts and force a re-authentication to ensure that any stolen session cookies are rendered useless.
+- Implement stricter browser security policies, such as disabling remote debugging features in production environments, to prevent similar exploitation in the future.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised.
+- Enhance monitoring and alerting for similar suspicious browser activities by refining detection rules and incorporating additional threat intelligence."""
 references = [
     "https://github.com/defaultnamehere/cookie_crimes",
     "https://embracethered.com/blog/posts/2020/cookie-crimes-on-mirosoft-edge/",
@@ -66,41 +99,6 @@ process where event.type in ("start", "process_started", "info") and
                    "--remote-debugging-pipe=*") and
    process.args : "--user-data-dir=*" and not process.args:"--remote-debugging-port=0"
 '''
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Cookies Theft via Browser Debugging
-
-Chromium-based browsers support debugging features that allow developers to inspect and modify web applications. Adversaries can exploit these features to access session cookies, enabling unauthorized access to web services. The detection rule identifies suspicious browser processes using debugging arguments, which may indicate cookie theft attempts, by monitoring specific process names and arguments across different operating systems.
-
-### Possible investigation steps
-
-- Review the process details to confirm the presence of suspicious debugging arguments such as "--remote-debugging-port=*", "--remote-debugging-targets=*", or "--remote-debugging-pipe=*". Check if these arguments were used in conjunction with "--user-data-dir=*" and ensure "--remote-debugging-port=0" is not present.
-- Identify the user account associated with the suspicious browser process to determine if it aligns with expected behavior or if it might be compromised.
-- Investigate the source IP address and network activity associated with the process to identify any unusual or unauthorized access patterns.
-- Check for any recent changes or anomalies in the user's account activity, such as unexpected logins or access to sensitive applications.
-- Correlate the event with other security alerts or logs to identify if this activity is part of a broader attack pattern or campaign.
-- If possible, capture and analyze the network traffic associated with the process to detect any data exfiltration attempts or communication with known malicious IP addresses.
-
-### False positive analysis
-
-- Development and testing activities may trigger the rule when developers use debugging features for legitimate purposes. To manage this, create exceptions for known developer machines or user accounts frequently involved in web application development.
-- Automated testing frameworks that utilize browser debugging for testing web applications can also cause false positives. Identify and exclude processes initiated by these frameworks by specifying their unique process names or user accounts.
-- Browser extensions or tools that rely on debugging ports for functionality might be flagged. Review and whitelist these extensions or tools if they are verified as safe and necessary for business operations.
-- Remote support or troubleshooting sessions using debugging features can be mistaken for suspicious activity. Implement a policy to log and review such sessions, allowing exceptions for recognized support tools or personnel.
-- Continuous integration/continuous deployment (CI/CD) pipelines that involve browser automation may inadvertently match the rule criteria. Exclude these processes by identifying and filtering based on the CI/CD system's user accounts or process identifiers.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Terminate any suspicious browser processes identified with debugging arguments to stop potential cookie theft in progress.
-- Conduct a thorough review of access logs for the affected web applications or services to identify any unauthorized access attempts using stolen cookies.
-- Invalidate all active sessions for the affected user accounts and force a re-authentication to ensure that any stolen session cookies are rendered useless.
-- Implement stricter browser security policies, such as disabling remote debugging features in production environments, to prevent similar exploitation in the future.
-- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised.
-- Enhance monitoring and alerting for similar suspicious browser activities by refining detection rules and incorporating additional threat intelligence."""
 
 
 [[rule.threat]]

rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/11/03"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -17,39 +15,6 @@ index = ["auditbeat-*", "winlogbeat-*", "logs-endpoint.events.*", "logs-windows.
 language = "eql"
 license = "Elastic License v2"
 name = "WebServer Access Logs Deleted"
-risk_score = 47
-rule_id = "665e7a4f-c58e-4fc6-bc83-87a7572670ac"
-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
-"""
-severity = "medium"
-tags = [
-    "Domain: Endpoint",
-    "OS: Linux",
-    "OS: Windows",
-    "OS: macOS",
-    "Use Case: Threat Detection",
-    "Tactic: Defense Evasion",
-    "Data Source: Elastic Defend",
-    "Data Source: Sysmon",
-    "Resources: Investigation Guide",
-]
-timestamp_override = "event.ingested"
-type = "eql"
-
-query = '''
-file where event.type == "deletion" and
-  file.path : ("C:\\inetpub\\logs\\LogFiles\\*.log",
-               "/var/log/apache*/access.log",
-               "/etc/httpd/logs/access_log",
-               "/var/log/httpd/access_log",
-               "/var/www/*/logs/access.log")
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -84,6 +49,39 @@ Web server access logs are crucial for monitoring and analyzing web traffic, pro
 - Review and tighten access controls and permissions on log files to ensure only authorized personnel can modify or delete them.
 - Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
 - Document the incident, including all actions taken, and update incident response plans to improve future detection and response capabilities."""
+risk_score = 47
+rule_id = "665e7a4f-c58e-4fc6-bc83-87a7572670ac"
+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
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "OS: Windows",
+    "OS: macOS",
+    "Use Case: Threat Detection",
+    "Tactic: Defense Evasion",
+    "Data Source: Elastic Defend",
+    "Data Source: Sysmon",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+file where event.type == "deletion" and
+  file.path : ("C:\\inetpub\\logs\\LogFiles\\*.log",
+               "/var/log/apache*/access.log",
+               "/etc/httpd/logs/access_log",
+               "/var/log/httpd/access_log",
+               "/var/www/*/logs/access.log")
+'''
 
 
 [[rule.threat]]

rules/cross-platform/impact_hosts_file_modified.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/07/07"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/09/19"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 anomaly_threshold = 75
@@ -20,6 +18,40 @@ interval = "15m"
 license = "Elastic License v2"
 machine_learning_job_id = "problem_child_rare_process_by_host"
 name = "Unusual Process Spawned by a Host"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Process Spawned by a Host
+
+The detection rule leverages machine learning to identify atypical processes on Windows systems, focusing on those that deviate from normal behavior. Adversaries often exploit legitimate system tools, known as LOLbins, to evade detection. This rule uses the ProblemChild ML model to flag processes that are both statistically unusual and potentially malicious, enhancing detection of stealthy attacks that bypass traditional methods.
+
+### Possible investigation steps
+
+- Review the process details flagged by the ProblemChild ML model, including the process name, path, and command line arguments, to understand its nature and potential purpose.
+- Check the parent process of the flagged process to determine if it was spawned by a legitimate application or a known LOLbin, which might indicate a Living off the Land attack.
+- Investigate the host's historical activity to assess whether this process or similar ones have been executed previously, focusing on any patterns of unusual behavior.
+- Correlate the process activity with user logins and network connections to identify any suspicious user behavior or external communications that coincide with the process execution.
+- Examine the system's security logs for any related alerts or anomalies around the time the process was detected, which might provide additional context or evidence of malicious activity.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger false positives if they involve unusual processes or tools not commonly used on the host. Users can create exceptions for these known tasks to prevent unnecessary alerts.
+- Software updates or installations can spawn processes that are atypical but benign. Identifying and excluding these processes during known maintenance windows can reduce false positives.
+- Custom scripts or automation tools that mimic LOLbins behavior might be flagged. Users should document and whitelist these scripts if they are verified as safe and necessary for operations.
+- Legitimate third-party applications that use system binaries in uncommon ways may be misclassified. Regularly review and update the list of approved applications to ensure they are not mistakenly flagged.
+- Temporary spikes in unusual processes due to legitimate business activities, such as end-of-quarter reporting, can be managed by adjusting the detection thresholds or temporarily disabling the rule during these periods.
+
+### Response and remediation
+
+- Isolate the affected host from the network to prevent further spread or communication with potential command and control servers.
+- Terminate the suspicious process identified by the ProblemChild ML model to halt any ongoing malicious activity.
+- Conduct a thorough review of the process's parent and child processes to identify any additional malicious activity or persistence mechanisms.
+- Remove any identified LOLbins or unauthorized tools used by the adversary from the system to prevent further exploitation.
+- Restore the affected system from a known good backup if any system integrity issues are detected.
+- Update endpoint protection and monitoring tools to ensure they can detect similar threats in the future, focusing on the specific techniques used in this incident.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 references = [
     "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
     "https://docs.elastic.co/en/integrations/problemchild",
@@ -58,40 +90,6 @@ tags = [
     "Resources: Investigation Guide",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Process Spawned by a Host
-
-The detection rule leverages machine learning to identify atypical processes on Windows systems, focusing on those that deviate from normal behavior. Adversaries often exploit legitimate system tools, known as LOLbins, to evade detection. This rule uses the ProblemChild ML model to flag processes that are both statistically unusual and potentially malicious, enhancing detection of stealthy attacks that bypass traditional methods.
-
-### Possible investigation steps
-
-- Review the process details flagged by the ProblemChild ML model, including the process name, path, and command line arguments, to understand its nature and potential purpose.
-- Check the parent process of the flagged process to determine if it was spawned by a legitimate application or a known LOLbin, which might indicate a Living off the Land attack.
-- Investigate the host's historical activity to assess whether this process or similar ones have been executed previously, focusing on any patterns of unusual behavior.
-- Correlate the process activity with user logins and network connections to identify any suspicious user behavior or external communications that coincide with the process execution.
-- Examine the system's security logs for any related alerts or anomalies around the time the process was detected, which might provide additional context or evidence of malicious activity.
-
-### False positive analysis
-
-- Routine administrative tasks may trigger false positives if they involve unusual processes or tools not commonly used on the host. Users can create exceptions for these known tasks to prevent unnecessary alerts.
-- Software updates or installations can spawn processes that are atypical but benign. Identifying and excluding these processes during known maintenance windows can reduce false positives.
-- Custom scripts or automation tools that mimic LOLbins behavior might be flagged. Users should document and whitelist these scripts if they are verified as safe and necessary for operations.
-- Legitimate third-party applications that use system binaries in uncommon ways may be misclassified. Regularly review and update the list of approved applications to ensure they are not mistakenly flagged.
-- Temporary spikes in unusual processes due to legitimate business activities, such as end-of-quarter reporting, can be managed by adjusting the detection thresholds or temporarily disabling the rule during these periods.
-
-### Response and remediation
-
-- Isolate the affected host from the network to prevent further spread or communication with potential command and control servers.
-- Terminate the suspicious process identified by the ProblemChild ML model to halt any ongoing malicious activity.
-- Conduct a thorough review of the process's parent and child processes to identify any additional malicious activity or persistence mechanisms.
-- Remove any identified LOLbins or unauthorized tools used by the adversary from the system to prevent further exploitation.
-- Restore the affected system from a known good backup if any system integrity issues are detected.
-- Update endpoint protection and monitoring tools to ensure they can detect similar threats in the future, focusing on the specific techniques used in this incident.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]

rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 anomaly_threshold = 75
@@ -20,6 +18,42 @@ interval = "15m"
 license = "Elastic License v2"
 machine_learning_job_id = "problem_child_rare_process_by_parent"
 name = "Unusual Process Spawned by a Parent Process"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Process Spawned by a Parent Process
+
+In Windows environments, processes are often spawned by parent processes to perform legitimate tasks. However, adversaries can exploit this by using legitimate tools, known as LOLbins, to execute malicious activities stealthily. The detection rule leverages machine learning to identify anomalies in process creation patterns, flagging processes that deviate from typical behavior, thus uncovering potential threats that evade traditional detection methods.
+
+### Possible investigation steps
+
+- Review the parent process and child process names to determine if they are known legitimate applications or if they are commonly associated with LOLbins or other malicious activities.
+- Check the process creation time and correlate it with any known user activity or scheduled tasks to identify if the process execution aligns with expected behavior.
+- Investigate the command line arguments used by the suspicious process to identify any unusual or potentially malicious commands or scripts being executed.
+- Analyze the network activity associated with the process to detect any suspicious outbound connections or data exfiltration attempts.
+- Examine the file path and hash of the executable to verify its legitimacy and check against known malware databases or threat intelligence sources.
+- Review any recent changes to the system, such as software installations or updates, that might explain the unusual process behavior.
+- Consult endpoint detection and response (EDR) logs or other security tools to gather additional context and evidence related to the process and its activities.
+
+### False positive analysis
+
+- Legitimate administrative tools like PowerShell or command prompt may be flagged when used for routine tasks. Users can create exceptions for these tools when executed by known and trusted parent processes.
+- Software updates or installations often spawn processes that might appear unusual. Exclude these processes by identifying their typical parent-child relationships during updates.
+- Custom scripts or automation tools used within the organization might trigger alerts. Document these scripts and their expected behavior to create exceptions for them.
+- Frequent use of remote management tools can lead to false positives. Ensure these tools are whitelisted when used by authorized personnel.
+- Regularly review and update the list of exceptions to accommodate changes in legitimate process behaviors over time.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.
+- Terminate the suspicious process identified by the alert to stop any ongoing malicious actions.
+- Conduct a thorough analysis of the process and its parent to understand the scope of the compromise and identify any additional malicious activities or files.
+- Remove any malicious files or artifacts associated with the process from the system to ensure complete remediation.
+- Restore the system from a known good backup if the integrity of the system is compromised beyond repair.
+- Update and patch the system to close any vulnerabilities that may have been exploited by the adversary.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 references = [
     "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
     "https://docs.elastic.co/en/integrations/problemchild",
@@ -58,42 +92,6 @@ tags = [
     "Resources: Investigation Guide",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Process Spawned by a Parent Process
-
-In Windows environments, processes are often spawned by parent processes to perform legitimate tasks. However, adversaries can exploit this by using legitimate tools, known as LOLbins, to execute malicious activities stealthily. The detection rule leverages machine learning to identify anomalies in process creation patterns, flagging processes that deviate from typical behavior, thus uncovering potential threats that evade traditional detection methods.
-
-### Possible investigation steps
-
-- Review the parent process and child process names to determine if they are known legitimate applications or if they are commonly associated with LOLbins or other malicious activities.
-- Check the process creation time and correlate it with any known user activity or scheduled tasks to identify if the process execution aligns with expected behavior.
-- Investigate the command line arguments used by the suspicious process to identify any unusual or potentially malicious commands or scripts being executed.
-- Analyze the network activity associated with the process to detect any suspicious outbound connections or data exfiltration attempts.
-- Examine the file path and hash of the executable to verify its legitimacy and check against known malware databases or threat intelligence sources.
-- Review any recent changes to the system, such as software installations or updates, that might explain the unusual process behavior.
-- Consult endpoint detection and response (EDR) logs or other security tools to gather additional context and evidence related to the process and its activities.
-
-### False positive analysis
-
-- Legitimate administrative tools like PowerShell or command prompt may be flagged when used for routine tasks. Users can create exceptions for these tools when executed by known and trusted parent processes.
-- Software updates or installations often spawn processes that might appear unusual. Exclude these processes by identifying their typical parent-child relationships during updates.
-- Custom scripts or automation tools used within the organization might trigger alerts. Document these scripts and their expected behavior to create exceptions for them.
-- Frequent use of remote management tools can lead to false positives. Ensure these tools are whitelisted when used by authorized personnel.
-- Regularly review and update the list of exceptions to accommodate changes in legitimate process behaviors over time.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.
-- Terminate the suspicious process identified by the alert to stop any ongoing malicious actions.
-- Conduct a thorough analysis of the process and its parent to understand the scope of the compromise and identify any additional malicious activities or files.
-- Remove any malicious files or artifacts associated with the process from the system to ensure complete remediation.
-- Restore the system from a known good backup if the integrity of the system is compromised beyond repair.
-- Update and patch the system to close any vulnerabilities that may have been exploited by the adversary.
-- 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.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]

rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 anomaly_threshold = 75
@@ -21,6 +19,41 @@ interval = "15m"
 license = "Elastic License v2"
 machine_learning_job_id = "problem_child_rare_process_by_user"
 name = "Unusual Process Spawned by a User"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Process Spawned by a User
+
+The detection of unusual processes spawned by users leverages machine learning to identify anomalies in user behavior and process execution. Adversaries often exploit legitimate tools, known as LOLbins, to evade detection. This rule uses both supervised and unsupervised ML models to flag processes that deviate from typical user activity, indicating potential misuse or masquerading tactics.
+
+### Possible investigation steps
+
+- Review the user context associated with the alert to determine if the user has a history of spawning unusual processes or if this is an isolated incident.
+- Examine the specific process flagged by the alert, including its command line arguments, parent process, and any associated network activity, to identify potential indicators of compromise.
+- Check for the presence of known LOLbins or other legitimate tools that may have been exploited, as indicated by the alert's focus on defense evasion tactics.
+- Investigate any recent changes in the user's behavior or system configuration that could explain the anomaly, such as software updates or new application installations.
+- Correlate the alert with other security events or logs from the same timeframe to identify any related suspicious activities or patterns.
+- Assess the risk score and severity level in the context of the organization's threat landscape to prioritize the response and determine if further action is needed.
+
+### False positive analysis
+
+- Legitimate administrative tools may trigger false positives if they are used in atypical contexts. Users should review the context of the process execution and, if deemed safe, add these tools to an exception list to prevent future alerts.
+- Scheduled tasks or scripts that run infrequently might be flagged as unusual. Verify the legitimacy of these tasks and consider excluding them if they are part of regular maintenance or updates.
+- Software updates or installations can spawn processes that appear anomalous. Confirm the source and purpose of these updates, and if they are routine, create exceptions for these specific processes.
+- Developers or IT personnel using command-line tools for legitimate purposes may trigger alerts. Evaluate the necessity of these tools in their workflow and whitelist them if they are consistently used in a non-malicious manner.
+- New or infrequently used applications might be flagged due to lack of historical data. Assess the application's legitimacy and, if appropriate, add it to a list of known safe applications to reduce false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Terminate the suspicious process identified by the alert to halt any ongoing malicious activity.
+- Conduct a thorough review of the user's recent activity and access logs to identify any unauthorized actions or data access.
+- Reset the credentials of the affected user account to prevent further unauthorized access, ensuring that strong, unique passwords are used.
+- Scan the system for additional indicators of compromise, such as other unusual processes or modifications to system files, and remove any identified threats.
+- Restore the system from a known good backup if any critical system files or configurations have been altered.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 references = [
     "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
     "https://docs.elastic.co/en/integrations/problemchild",
@@ -59,41 +92,6 @@ tags = [
     "Resources: Investigation Guide",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Process Spawned by a User
-
-The detection of unusual processes spawned by users leverages machine learning to identify anomalies in user behavior and process execution. Adversaries often exploit legitimate tools, known as LOLbins, to evade detection. This rule uses both supervised and unsupervised ML models to flag processes that deviate from typical user activity, indicating potential misuse or masquerading tactics.
-
-### Possible investigation steps
-
-- Review the user context associated with the alert to determine if the user has a history of spawning unusual processes or if this is an isolated incident.
-- Examine the specific process flagged by the alert, including its command line arguments, parent process, and any associated network activity, to identify potential indicators of compromise.
-- Check for the presence of known LOLbins or other legitimate tools that may have been exploited, as indicated by the alert's focus on defense evasion tactics.
-- Investigate any recent changes in the user's behavior or system configuration that could explain the anomaly, such as software updates or new application installations.
-- Correlate the alert with other security events or logs from the same timeframe to identify any related suspicious activities or patterns.
-- Assess the risk score and severity level in the context of the organization's threat landscape to prioritize the response and determine if further action is needed.
-
-### False positive analysis
-
-- Legitimate administrative tools may trigger false positives if they are used in atypical contexts. Users should review the context of the process execution and, if deemed safe, add these tools to an exception list to prevent future alerts.
-- Scheduled tasks or scripts that run infrequently might be flagged as unusual. Verify the legitimacy of these tasks and consider excluding them if they are part of regular maintenance or updates.
-- Software updates or installations can spawn processes that appear anomalous. Confirm the source and purpose of these updates, and if they are routine, create exceptions for these specific processes.
-- Developers or IT personnel using command-line tools for legitimate purposes may trigger alerts. Evaluate the necessity of these tools in their workflow and whitelist them if they are consistently used in a non-malicious manner.
-- New or infrequently used applications might be flagged due to lack of historical data. Assess the application's legitimacy and, if appropriate, add it to a list of known safe applications to reduce false positives.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
-- Terminate the suspicious process identified by the alert to halt any ongoing malicious activity.
-- Conduct a thorough review of the user's recent activity and access logs to identify any unauthorized actions or data access.
-- Reset the credentials of the affected user account to prevent further unauthorized access, ensuring that strong, unique passwords are used.
-- Scan the system for additional indicators of compromise, such as other unusual processes or modifications to system files, and remove any identified threats.
-- Restore the system from a known good backup if any critical system files or configurations have been altered.
-- 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.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]

rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -18,6 +16,41 @@ index = ["endgame-*", "logs-endpoint.events.process-*", "winlogbeat-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Machine Learning Detected a Suspicious Windows Event with a High Malicious Probability Score"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Machine Learning Detected a Suspicious Windows Event with a High Malicious Probability Score
+
+The detection leverages a machine learning model, ProblemChild, to identify potentially malicious Windows processes by analyzing patterns and assigning a high probability score to suspicious activities. Adversaries may exploit legitimate processes to evade detection, often using techniques like masquerading. This rule flags high-risk events by focusing on processes with a high malicious probability score or those identified by a blocklist, excluding known benign activities.
+
+### Possible investigation steps
+
+- Review the process details flagged by the ProblemChild model, focusing on those with a prediction probability greater than 0.98 or identified by the blocklist.
+- Examine the command-line arguments of the suspicious process to identify any unusual or unexpected patterns, excluding those matching known benign patterns like "*C:\\\\WINDOWS\\\\temp\\\\nessus_*.txt*" or "*C:\\\\WINDOWS\\\\temp\\\\nessus_*.tmp*".
+- Check the parent process of the flagged event to determine if it is a legitimate process or if it has been potentially compromised.
+- Investigate the user account associated with the process to assess if it has been involved in any other suspicious activities or if it has elevated privileges that could be exploited.
+- Correlate the event with other security alerts or logs to identify any related activities or patterns that could indicate a broader attack campaign.
+- Consult threat intelligence sources to determine if the process or its associated indicators are linked to known malicious activities or threat actors.
+
+### False positive analysis
+
+- Nessus scan files in the Windows temp directory may trigger false positives due to their temporary nature and frequent legitimate use. Users can mitigate this by adding exceptions for file paths like C:\\WINDOWS\\temp\\nessus_*.txt and C:\\WINDOWS\\temp\\nessus_*.tmp.
+- Legitimate software updates or installations might be flagged if they mimic known malicious patterns. Users should review the process details and whitelist trusted software update processes.
+- System administration tools that perform actions similar to those used in attacks could be misidentified. Users should verify the legitimacy of these tools and exclude them from the rule if they are part of regular administrative tasks.
+- Custom scripts or automation tools that are not widely recognized might be flagged. Users should ensure these scripts are secure and add them to an allowlist if they are part of routine operations.
+- Frequent false positives from specific processes can be managed by adjusting the threshold of the machine learning model or refining the blocklist to better distinguish between benign and malicious activities.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Terminate the suspicious process identified by the ProblemChild model to halt any ongoing malicious actions.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats.
+- Review and analyze the process execution history and associated files to understand the scope of the compromise and identify any persistence mechanisms.
+- Restore any altered or deleted files from backups, ensuring that the backup is clean and free from malware.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring and logging for similar processes and activities to detect and respond to future attempts at masquerading or defense evasion."""
 references = [
     "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
     "https://docs.elastic.co/en/integrations/problemchild",
@@ -63,41 +96,6 @@ query = '''
 process where ((problemchild.prediction == 1 and problemchild.prediction_probability > 0.98) or
 blocklist_label == 1) and not process.args : ("*C:\\WINDOWS\\temp\\nessus_*.txt*", "*C:\\WINDOWS\\temp\\nessus_*.tmp*")
 '''
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Machine Learning Detected a Suspicious Windows Event with a High Malicious Probability Score
-
-The detection leverages a machine learning model, ProblemChild, to identify potentially malicious Windows processes by analyzing patterns and assigning a high probability score to suspicious activities. Adversaries may exploit legitimate processes to evade detection, often using techniques like masquerading. This rule flags high-risk events by focusing on processes with a high malicious probability score or those identified by a blocklist, excluding known benign activities.
-
-### Possible investigation steps
-
-- Review the process details flagged by the ProblemChild model, focusing on those with a prediction probability greater than 0.98 or identified by the blocklist.
-- Examine the command-line arguments of the suspicious process to identify any unusual or unexpected patterns, excluding those matching known benign patterns like "*C:\\\\WINDOWS\\\\temp\\\\nessus_*.txt*" or "*C:\\\\WINDOWS\\\\temp\\\\nessus_*.tmp*".
-- Check the parent process of the flagged event to determine if it is a legitimate process or if it has been potentially compromised.
-- Investigate the user account associated with the process to assess if it has been involved in any other suspicious activities or if it has elevated privileges that could be exploited.
-- Correlate the event with other security alerts or logs to identify any related activities or patterns that could indicate a broader attack campaign.
-- Consult threat intelligence sources to determine if the process or its associated indicators are linked to known malicious activities or threat actors.
-
-### False positive analysis
-
-- Nessus scan files in the Windows temp directory may trigger false positives due to their temporary nature and frequent legitimate use. Users can mitigate this by adding exceptions for file paths like C:\\WINDOWS\\temp\\nessus_*.txt and C:\\WINDOWS\\temp\\nessus_*.tmp.
-- Legitimate software updates or installations might be flagged if they mimic known malicious patterns. Users should review the process details and whitelist trusted software update processes.
-- System administration tools that perform actions similar to those used in attacks could be misidentified. Users should verify the legitimacy of these tools and exclude them from the rule if they are part of regular administrative tasks.
-- Custom scripts or automation tools that are not widely recognized might be flagged. Users should ensure these scripts are secure and add them to an allowlist if they are part of routine operations.
-- Frequent false positives from specific processes can be managed by adjusting the threshold of the machine learning model or refining the blocklist to better distinguish between benign and malicious activities.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Terminate the suspicious process identified by the ProblemChild model to halt any ongoing malicious actions.
-- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats.
-- Review and analyze the process execution history and associated files to understand the scope of the compromise and identify any persistence mechanisms.
-- Restore any altered or deleted files from backups, ensuring that the backup is clean and free from malware.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
-- Implement enhanced monitoring and logging for similar processes and activities to detect and respond to future attempts at masquerading or defense evasion."""
 
 
 [[rule.threat]]

rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml

@@ -2,26 +2,59 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/03/19"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 anomaly_threshold = 75
 author = ["Elastic"]
 description = """
 A machine learning job combination has identified a host with one or more suspicious Windows processes that exhibit
-unusually high malicious probability scores.These process(es) have been classified as malicious in several ways. The process(es)
-were predicted to be malicious by the ProblemChild supervised ML model. If the anomaly contains a cluster of suspicious
-processes, each process has the same host name, and the aggregate score of the event cluster was calculated to be
-unusually high by an unsupervised ML model. Such a cluster often contains suspicious or malicious activity, possibly
-involving LOLbins, that may be resistant to detection using conventional search rules.
+unusually high malicious probability scores.These process(es) have been classified as malicious in several ways. The
+process(es) were predicted to be malicious by the ProblemChild supervised ML model. If the anomaly contains a cluster of
+suspicious processes, each process has the same host name, and the aggregate score of the event cluster was calculated
+to be unusually high by an unsupervised ML model. Such a cluster often contains suspicious or malicious activity,
+possibly involving LOLbins, that may be resistant to detection using conventional search rules.
 """
 from = "now-45m"
 interval = "15m"
 license = "Elastic License v2"
 machine_learning_job_id = "problem_child_high_sum_by_host"
 name = "Host Detected with Suspicious Windows Process(es)"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Host Detected with Suspicious Windows Process(es)
+
+The detection leverages machine learning to identify clusters of Windows processes with high malicious probability scores. Adversaries exploit legitimate tools, known as LOLbins, to evade detection. This rule uses both supervised and unsupervised ML models to flag unusual process clusters on a single host, indicating potential masquerading tactics for defense evasion.
+
+### Possible investigation steps
+
+- Review the host name associated with the suspicious process cluster to determine if it is a critical asset or has a history of similar alerts.
+- Examine the specific processes flagged by the ProblemChild supervised ML model to identify any known LOLbins or unusual command-line arguments that may indicate masquerading.
+- Check the timeline of the process execution to see if it coincides with any known scheduled tasks or user activity that could explain the anomaly.
+- Investigate the parent-child relationship of the processes to identify any unexpected or unauthorized process spawning patterns.
+- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activity.
+- Assess the network activity associated with the host during the time of the alert to detect any potential data exfiltration or communication with known malicious IP addresses.
+
+### False positive analysis
+
+- Legitimate administrative tools like PowerShell or Windows Management Instrumentation (WMI) may be flagged as suspicious due to their dual-use nature. Users can create exceptions for these tools when used by trusted administrators or during scheduled maintenance.
+- Automated scripts or scheduled tasks that perform routine system checks or updates might trigger alerts. Review these processes and whitelist them if they are verified as part of regular operations.
+- Software updates or installations that involve multiple processes spawning in a short time frame can be mistaken for malicious clusters. Ensure that these activities are documented and create exceptions for known update processes.
+- Development or testing environments where new or experimental software is frequently executed may generate false positives. Consider excluding these environments from monitoring or adjusting the sensitivity of the rule for these specific hosts.
+- Frequent use of remote desktop or remote management tools by IT staff can appear suspicious. Implement user-based exceptions for known IT personnel to reduce unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected host immediately to prevent further spread of potential malicious activity. Disconnect it from the network to contain the threat.
+- Terminate the suspicious processes identified by the alert. Use task management tools or scripts to ensure all instances of the processes are stopped.
+- Conduct a thorough review of the host's system logs and process history to identify any additional indicators of compromise or related malicious activity.
+- Restore the host from a known good backup if available, ensuring that the backup is free from any signs of compromise.
+- Update and patch the host's operating system and all installed software to close any vulnerabilities that may have been exploited.
+- Implement application whitelisting to prevent unauthorized or suspicious processes from executing in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional hosts are affected."""
 references = [
     "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
     "https://docs.elastic.co/en/integrations/problemchild",
@@ -58,41 +91,6 @@ tags = [
     "Resources: Investigation Guide",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Host Detected with Suspicious Windows Process(es)
-
-The detection leverages machine learning to identify clusters of Windows processes with high malicious probability scores. Adversaries exploit legitimate tools, known as LOLbins, to evade detection. This rule uses both supervised and unsupervised ML models to flag unusual process clusters on a single host, indicating potential masquerading tactics for defense evasion.
-
-### Possible investigation steps
-
-- Review the host name associated with the suspicious process cluster to determine if it is a critical asset or has a history of similar alerts.
-- Examine the specific processes flagged by the ProblemChild supervised ML model to identify any known LOLbins or unusual command-line arguments that may indicate masquerading.
-- Check the timeline of the process execution to see if it coincides with any known scheduled tasks or user activity that could explain the anomaly.
-- Investigate the parent-child relationship of the processes to identify any unexpected or unauthorized process spawning patterns.
-- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activity.
-- Assess the network activity associated with the host during the time of the alert to detect any potential data exfiltration or communication with known malicious IP addresses.
-
-### False positive analysis
-
-- Legitimate administrative tools like PowerShell or Windows Management Instrumentation (WMI) may be flagged as suspicious due to their dual-use nature. Users can create exceptions for these tools when used by trusted administrators or during scheduled maintenance.
-- Automated scripts or scheduled tasks that perform routine system checks or updates might trigger alerts. Review these processes and whitelist them if they are verified as part of regular operations.
-- Software updates or installations that involve multiple processes spawning in a short time frame can be mistaken for malicious clusters. Ensure that these activities are documented and create exceptions for known update processes.
-- Development or testing environments where new or experimental software is frequently executed may generate false positives. Consider excluding these environments from monitoring or adjusting the sensitivity of the rule for these specific hosts.
-- Frequent use of remote desktop or remote management tools by IT staff can appear suspicious. Implement user-based exceptions for known IT personnel to reduce unnecessary alerts.
-
-### Response and remediation
-
-- Isolate the affected host immediately to prevent further spread of potential malicious activity. Disconnect it from the network to contain the threat.
-- Terminate the suspicious processes identified by the alert. Use task management tools or scripts to ensure all instances of the processes are stopped.
-- Conduct a thorough review of the host's system logs and process history to identify any additional indicators of compromise or related malicious activity.
-- Restore the host from a known good backup if available, ensuring that the backup is free from any signs of compromise.
-- Update and patch the host's operating system and all installed software to close any vulnerabilities that may have been exploited.
-- Implement application whitelisting to prevent unauthorized or suspicious processes from executing in the future.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional hosts are affected."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]

rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml

@@ -2,26 +2,59 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/03/19"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 anomaly_threshold = 75
 author = ["Elastic"]
 description = """
-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.
+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.
 """
 from = "now-45m"
 interval = "15m"
 license = "Elastic License v2"
 machine_learning_job_id = "problem_child_high_sum_by_parent"
 name = "Parent Process Detected with Suspicious Windows Process(es)"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Parent Process Detected with Suspicious Windows Process(es)
+
+In Windows environments, processes are often spawned by parent processes, forming a hierarchy. Adversaries exploit this by using legitimate processes to launch malicious ones, often leveraging Living off the Land Binaries (LOLBins) to evade detection. The detection rule employs machine learning to identify clusters of processes with high malicious probability, focusing on those sharing a common parent process. This approach helps uncover stealthy attacks that traditional methods might miss, enhancing defense against tactics like masquerading.
+
+### Possible investigation steps
+
+- Review the parent process name associated with the suspicious process cluster to identify if it is a known legitimate process or a potential masquerading attempt.
+- Examine the command line arguments and execution context of the suspicious processes to identify any use of LOLBins or unusual patterns that could indicate malicious activity.
+- Check the process creation timestamps and correlate them with any known events or user activities to determine if the process execution aligns with expected behavior.
+- Investigate the network activity of the suspicious processes to identify any unusual outbound connections or data exfiltration attempts.
+- Analyze the user account context under which the suspicious processes were executed to determine if there is any indication of compromised credentials or privilege escalation.
+- Cross-reference the detected processes with threat intelligence sources to identify any known indicators of compromise or related threat actor activity.
+
+### False positive analysis
+
+- Legitimate administrative tools may trigger false positives if they frequently spawn processes that resemble malicious activity. Users can create exceptions for known safe tools by whitelisting their parent process names.
+- Software updates or installations often generate clusters of processes that might be flagged as suspicious. Users should monitor these activities and exclude them if they are verified as legitimate.
+- Automated scripts or batch jobs that run regularly and spawn multiple processes can be mistaken for malicious clusters. Identifying these scripts and excluding their parent processes can reduce false positives.
+- Security software or monitoring tools that perform regular scans or updates might mimic malicious behavior. Users should ensure these tools are recognized and excluded from the rule's scope.
+- Custom business applications that are not widely recognized might be flagged. Users should document and exclude these applications if they are confirmed to be safe and necessary for operations.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any ongoing malicious activity.
+- Terminate the suspicious processes identified by the alert to stop any malicious actions they may be performing.
+- Conduct a thorough review of the parent process and its associated binaries to ensure they have not been tampered with or replaced by malicious versions.
+- Restore any affected files or system components from a known good backup to ensure system integrity and functionality.
+- Update and patch the system to close any vulnerabilities that may have been exploited by the adversary, focusing on those related to LOLBins and masquerading techniques.
+- Monitor the system and network for any signs of re-infection or related suspicious activity, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 references = [
     "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
     "https://docs.elastic.co/en/integrations/problemchild",
@@ -60,41 +93,6 @@ tags = [
     "Resources: Investigation Guide",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Parent Process Detected with Suspicious Windows Process(es)
-
-In Windows environments, processes are often spawned by parent processes, forming a hierarchy. Adversaries exploit this by using legitimate processes to launch malicious ones, often leveraging Living off the Land Binaries (LOLBins) to evade detection. The detection rule employs machine learning to identify clusters of processes with high malicious probability, focusing on those sharing a common parent process. This approach helps uncover stealthy attacks that traditional methods might miss, enhancing defense against tactics like masquerading.
-
-### Possible investigation steps
-
-- Review the parent process name associated with the suspicious process cluster to identify if it is a known legitimate process or a potential masquerading attempt.
-- Examine the command line arguments and execution context of the suspicious processes to identify any use of LOLBins or unusual patterns that could indicate malicious activity.
-- Check the process creation timestamps and correlate them with any known events or user activities to determine if the process execution aligns with expected behavior.
-- Investigate the network activity of the suspicious processes to identify any unusual outbound connections or data exfiltration attempts.
-- Analyze the user account context under which the suspicious processes were executed to determine if there is any indication of compromised credentials or privilege escalation.
-- Cross-reference the detected processes with threat intelligence sources to identify any known indicators of compromise or related threat actor activity.
-
-### False positive analysis
-
-- Legitimate administrative tools may trigger false positives if they frequently spawn processes that resemble malicious activity. Users can create exceptions for known safe tools by whitelisting their parent process names.
-- Software updates or installations often generate clusters of processes that might be flagged as suspicious. Users should monitor these activities and exclude them if they are verified as legitimate.
-- Automated scripts or batch jobs that run regularly and spawn multiple processes can be mistaken for malicious clusters. Identifying these scripts and excluding their parent processes can reduce false positives.
-- Security software or monitoring tools that perform regular scans or updates might mimic malicious behavior. Users should ensure these tools are recognized and excluded from the rule's scope.
-- Custom business applications that are not widely recognized might be flagged. Users should document and exclude these applications if they are confirmed to be safe and necessary for operations.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any ongoing malicious activity.
-- Terminate the suspicious processes identified by the alert to stop any malicious actions they may be performing.
-- Conduct a thorough review of the parent process and its associated binaries to ensure they have not been tampered with or replaced by malicious versions.
-- Restore any affected files or system components from a known good backup to ensure system integrity and functionality.
-- Update and patch the system to close any vulnerabilities that may have been exploited by the adversary, focusing on those related to LOLBins and masquerading techniques.
-- Monitor the system and network for any signs of re-infection or related suspicious activity, using enhanced logging and alerting mechanisms.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]

rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml

@@ -2,26 +2,59 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/03/19"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 anomaly_threshold = 75
 author = ["Elastic"]
 description = """
 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.
+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.
 """
 from = "now-45m"
 interval = "15m"
 license = "Elastic License v2"
 machine_learning_job_id = "problem_child_high_sum_by_user"
 name = "User Detected with Suspicious Windows Process(es)"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 User Detected with Suspicious Windows Process(es)
+
+The detection leverages machine learning to identify clusters of Windows processes with high malicious probability, often linked to tactics like masquerading. Adversaries exploit legitimate tools (LOLBins) to evade detection. This rule uses both supervised and unsupervised ML models to flag unusual process clusters, focusing on user-associated anomalies to uncover potential threats.
+
+### Possible investigation steps
+
+- Review the list of processes flagged by the alert to identify any known legitimate applications or tools that might have been misclassified.
+- Investigate the user account associated with the suspicious process cluster to determine if there is any history of unusual activity or if the account has been compromised.
+- Examine the parent-child relationship of the processes to understand the execution chain and identify any potential masquerading attempts or use of LOLBins.
+- Check for any recent changes or updates to the system that might explain the unusual process behavior, such as software installations or updates.
+- Correlate the detected processes with any known indicators of compromise (IOCs) or threat intelligence feeds to assess if they are linked to known malicious activity.
+- Analyze the network activity associated with the processes to identify any suspicious outbound connections or data exfiltration attempts.
+
+### False positive analysis
+
+- Legitimate administrative tools like PowerShell or Windows Management Instrumentation (WMI) may trigger false positives due to their frequent use in system management. Users can create exceptions for these tools when used by trusted administrators.
+- Software updates or installations often involve processes that mimic suspicious behavior. Exclude these processes by identifying and whitelisting update-related activities from known software vendors.
+- Automated scripts or scheduled tasks that perform routine maintenance can be misclassified as malicious. Review and whitelist these tasks if they are part of regular system operations.
+- Development environments may spawn multiple processes that resemble malicious clusters. Developers should document and exclude these processes when they are part of legitimate development activities.
+- Security software or monitoring tools might generate process clusters that appear suspicious. Ensure these tools are recognized and excluded from analysis to prevent false alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Terminate the suspicious processes identified by the alert to halt any ongoing malicious actions.
+- Conduct a thorough review of the affected user's account for any unauthorized access or changes, and reset credentials if necessary.
+- Analyze the use of any identified LOLBins to determine if they were used maliciously and restrict their execution through application whitelisting or policy adjustments.
+- Collect and preserve relevant logs and forensic data from the affected system for further analysis and to aid in understanding the scope of the incident.
+- Escalate the incident to the security operations center (SOC) or incident response team for a deeper investigation and to determine if additional systems are compromised.
+- Implement enhanced monitoring and detection rules to identify similar patterns of behavior in the future, focusing on the specific tactics and techniques used in this incident."""
 references = [
     "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
     "https://docs.elastic.co/en/integrations/problemchild",
@@ -60,41 +93,6 @@ tags = [
     "Resources: Investigation Guide",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 User Detected with Suspicious Windows Process(es)
-
-The detection leverages machine learning to identify clusters of Windows processes with high malicious probability, often linked to tactics like masquerading. Adversaries exploit legitimate tools (LOLBins) to evade detection. This rule uses both supervised and unsupervised ML models to flag unusual process clusters, focusing on user-associated anomalies to uncover potential threats.
-
-### Possible investigation steps
-
-- Review the list of processes flagged by the alert to identify any known legitimate applications or tools that might have been misclassified.
-- Investigate the user account associated with the suspicious process cluster to determine if there is any history of unusual activity or if the account has been compromised.
-- Examine the parent-child relationship of the processes to understand the execution chain and identify any potential masquerading attempts or use of LOLBins.
-- Check for any recent changes or updates to the system that might explain the unusual process behavior, such as software installations or updates.
-- Correlate the detected processes with any known indicators of compromise (IOCs) or threat intelligence feeds to assess if they are linked to known malicious activity.
-- Analyze the network activity associated with the processes to identify any suspicious outbound connections or data exfiltration attempts.
-
-### False positive analysis
-
-- Legitimate administrative tools like PowerShell or Windows Management Instrumentation (WMI) may trigger false positives due to their frequent use in system management. Users can create exceptions for these tools when used by trusted administrators.
-- Software updates or installations often involve processes that mimic suspicious behavior. Exclude these processes by identifying and whitelisting update-related activities from known software vendors.
-- Automated scripts or scheduled tasks that perform routine maintenance can be misclassified as malicious. Review and whitelist these tasks if they are part of regular system operations.
-- Development environments may spawn multiple processes that resemble malicious clusters. Developers should document and exclude these processes when they are part of legitimate development activities.
-- Security software or monitoring tools might generate process clusters that appear suspicious. Ensure these tools are recognized and excluded from analysis to prevent false alerts.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Terminate the suspicious processes identified by the alert to halt any ongoing malicious actions.
-- Conduct a thorough review of the affected user's account for any unauthorized access or changes, and reset credentials if necessary.
-- Analyze the use of any identified LOLBins to determine if they were used maliciously and restrict their execution through application whitelisting or policy adjustments.
-- Collect and preserve relevant logs and forensic data from the affected system for further analysis and to aid in understanding the scope of the incident.
-- Escalate the incident to the security operations center (SOC) or incident response team for a deeper investigation and to determine if additional systems are compromised.
-- Implement enhanced monitoring and detection rules to identify similar patterns of behavior in the future, focusing on the specific tactics and techniques used in this incident."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]

rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 anomaly_threshold = 50
@@ -24,6 +22,42 @@ interval = "15m"
 license = "Elastic License v2"
 machine_learning_job_id = ["v3_windows_rare_metadata_process"]
 name = "Unusual Windows Process Calling the Metadata Service"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Windows Process Calling the Metadata Service
+
+In cloud environments, the metadata service provides essential instance information, including credentials and configuration data. Adversaries may exploit this by using atypical Windows processes to access the service, aiming to extract sensitive information. The detection rule leverages machine learning to identify anomalies in process behavior, flagging potential credential access attempts by unusual processes.
+
+### Possible investigation steps
+
+- Review the process name and command line arguments associated with the alert to identify any unusual or suspicious activity.
+- Check the parent process of the flagged process to understand the context of how it was initiated and assess if it aligns with expected behavior.
+- Investigate the user account under which the process was executed to determine if it has legitimate access to the metadata service or if it has been compromised.
+- Analyze network logs to identify any outbound connections to the metadata service from the flagged process, noting any unusual patterns or destinations.
+- Cross-reference the process and user activity with recent changes or deployments in the environment to rule out false positives related to legitimate administrative actions.
+- Consult threat intelligence sources to see if the process or command line arguments have been associated with known malicious activity or campaigns.
+
+### False positive analysis
+
+- Routine system updates or maintenance scripts may trigger the rule. Review the process details and verify if they align with scheduled maintenance activities. If confirmed, consider adding these processes to an exception list.
+- Legitimate software or security tools that access the metadata service for configuration purposes might be flagged. Identify these tools and create exceptions for their known processes to prevent future alerts.
+- Automated backup or monitoring solutions that interact with the metadata service could be misidentified as threats. Validate these processes and exclude them if they are part of authorized operations.
+- Custom scripts developed in-house for cloud management tasks may access the metadata service. Ensure these scripts are documented and, if safe, add them to the list of exceptions to reduce false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate the unusual process accessing the metadata service to stop any ongoing credential harvesting attempts.
+- Conduct a thorough review of the system's event logs and process history to identify any additional indicators of compromise or related malicious activity.
+- Change all credentials that may have been exposed or accessed through the metadata service to mitigate the risk of unauthorized access.
+- Implement network segmentation to limit access to the metadata service, ensuring only authorized processes and users can interact with it.
+- Escalate the incident to the security operations center (SOC) for further analysis and to determine if the threat is part of a larger attack campaign.
+- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar anomalous process behaviors in the future."""
+risk_score = 21
+rule_id = "abae61a8-c560-4dbd-acca-1e1438bff36b"
 setup = """## Setup
 
 This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
@@ -68,8 +102,6 @@ The Windows integration allows you to monitor the Windows OS, services, applicat
 - Click “Save and Continue”.
 - For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).
 """
-risk_score = 21
-rule_id = "abae61a8-c560-4dbd-acca-1e1438bff36b"
 severity = "low"
 tags = [
     "Domain: Endpoint",
@@ -81,40 +113,6 @@ tags = [
     "Resources: Investigation Guide",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Windows Process Calling the Metadata Service
-
-In cloud environments, the metadata service provides essential instance information, including credentials and configuration data. Adversaries may exploit this by using atypical Windows processes to access the service, aiming to extract sensitive information. The detection rule leverages machine learning to identify anomalies in process behavior, flagging potential credential access attempts by unusual processes.
-
-### Possible investigation steps
-
-- Review the process name and command line arguments associated with the alert to identify any unusual or suspicious activity.
-- Check the parent process of the flagged process to understand the context of how it was initiated and assess if it aligns with expected behavior.
-- Investigate the user account under which the process was executed to determine if it has legitimate access to the metadata service or if it has been compromised.
-- Analyze network logs to identify any outbound connections to the metadata service from the flagged process, noting any unusual patterns or destinations.
-- Cross-reference the process and user activity with recent changes or deployments in the environment to rule out false positives related to legitimate administrative actions.
-- Consult threat intelligence sources to see if the process or command line arguments have been associated with known malicious activity or campaigns.
-
-### False positive analysis
-
-- Routine system updates or maintenance scripts may trigger the rule. Review the process details and verify if they align with scheduled maintenance activities. If confirmed, consider adding these processes to an exception list.
-- Legitimate software or security tools that access the metadata service for configuration purposes might be flagged. Identify these tools and create exceptions for their known processes to prevent future alerts.
-- Automated backup or monitoring solutions that interact with the metadata service could be misidentified as threats. Validate these processes and exclude them if they are part of authorized operations.
-- Custom scripts developed in-house for cloud management tasks may access the metadata service. Ensure these scripts are documented and, if safe, add them to the list of exceptions to reduce false positives.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Terminate the unusual process accessing the metadata service to stop any ongoing credential harvesting attempts.
-- Conduct a thorough review of the system's event logs and process history to identify any additional indicators of compromise or related malicious activity.
-- Change all credentials that may have been exposed or accessed through the metadata service to mitigate the risk of unauthorized access.
-- Implement network segmentation to limit access to the metadata service, ensuring only authorized processes and users can interact with it.
-- Escalate the incident to the security operations center (SOC) for further analysis and to determine if the threat is part of a larger attack campaign.
-- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar anomalous process behaviors in the future."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]

rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 anomaly_threshold = 75
@@ -24,6 +22,44 @@ interval = "15m"
 license = "Elastic License v2"
 machine_learning_job_id = ["v3_windows_rare_metadata_user"]
 name = "Unusual Windows User Calling the Metadata Service"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Windows User Calling the Metadata Service
+
+Cloud platforms provide a metadata service that allows instances to access configuration data, including credentials. Adversaries may exploit this by using compromised Windows accounts to query the service, aiming to harvest sensitive information. The detection rule leverages machine learning to identify atypical access patterns by Windows users, flagging potential credential access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific Windows user account involved in the unusual access to the metadata service.
+- Check the timestamp of the access attempt to correlate with any known scheduled tasks or legitimate user activities.
+- Investigate the source IP address and device from which the metadata service was accessed to determine if it aligns with expected user behavior or known assets.
+- Examine recent login and access logs for the identified user account to detect any other suspicious activities or anomalies.
+- Assess whether there have been any recent changes to the user's permissions or roles that could explain the access attempt.
+- Look for any other alerts or incidents involving the same user account or device to identify potential patterns of malicious behavior.
+- Consult with the user or their manager to verify if the access was legitimate or if the account may have been compromised.
+
+### False positive analysis
+
+- Routine administrative tasks by IT personnel may trigger alerts. Review access logs to confirm legitimate administrative actions and consider whitelisting specific user accounts or IP addresses.
+- Automated scripts or scheduled tasks that query the metadata service for configuration updates can be mistaken for suspicious activity. Identify these scripts and exclude them from the rule by adding them to an exception list.
+- Cloud management tools that regularly access the metadata service for monitoring or configuration purposes might be flagged. Verify these tools and create exceptions for their known access patterns.
+- Instances where legitimate software updates or patch management processes access the metadata service should be reviewed. Document these processes and exclude them from triggering alerts.
+- Temporary access by third-party vendors or consultants may appear unusual. Ensure their access is documented and create temporary exceptions during their engagement period.
+
+### Response and remediation
+
+- Immediately isolate the affected Windows system from the network to prevent further unauthorized access to the metadata service.
+- Revoke any potentially compromised credentials identified during the investigation and issue new credentials to affected users.
+- Conduct a thorough review of access logs to identify any unauthorized data access or exfiltration attempts from the metadata service.
+- Implement additional monitoring on the affected system and similar systems to detect any further anomalous access attempts.
+- Escalate the incident to the security operations center (SOC) for a deeper investigation into potential lateral movement or other compromised systems.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Review and enhance access controls and permissions for the metadata service to ensure only authorized users can access sensitive information."""
+risk_score = 21
+rule_id = "df197323-72a8-46a9-a08e-3f5b04a4a97a"
 setup = """## Setup
 
 This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
@@ -68,8 +104,6 @@ The Windows integration allows you to monitor the Windows OS, services, applicat
 - Click “Save and Continue”.
 - For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).
 """
-risk_score = 21
-rule_id = "df197323-72a8-46a9-a08e-3f5b04a4a97a"
 severity = "low"
 tags = [
     "Domain: Endpoint",
@@ -81,42 +115,6 @@ tags = [
     "Resources: Investigation Guide",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Windows User Calling the Metadata Service
-
-Cloud platforms provide a metadata service that allows instances to access configuration data, including credentials. Adversaries may exploit this by using compromised Windows accounts to query the service, aiming to harvest sensitive information. The detection rule leverages machine learning to identify atypical access patterns by Windows users, flagging potential credential access attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific Windows user account involved in the unusual access to the metadata service.
-- Check the timestamp of the access attempt to correlate with any known scheduled tasks or legitimate user activities.
-- Investigate the source IP address and device from which the metadata service was accessed to determine if it aligns with expected user behavior or known assets.
-- Examine recent login and access logs for the identified user account to detect any other suspicious activities or anomalies.
-- Assess whether there have been any recent changes to the user's permissions or roles that could explain the access attempt.
-- Look for any other alerts or incidents involving the same user account or device to identify potential patterns of malicious behavior.
-- Consult with the user or their manager to verify if the access was legitimate or if the account may have been compromised.
-
-### False positive analysis
-
-- Routine administrative tasks by IT personnel may trigger alerts. Review access logs to confirm legitimate administrative actions and consider whitelisting specific user accounts or IP addresses.
-- Automated scripts or scheduled tasks that query the metadata service for configuration updates can be mistaken for suspicious activity. Identify these scripts and exclude them from the rule by adding them to an exception list.
-- Cloud management tools that regularly access the metadata service for monitoring or configuration purposes might be flagged. Verify these tools and create exceptions for their known access patterns.
-- Instances where legitimate software updates or patch management processes access the metadata service should be reviewed. Document these processes and exclude them from triggering alerts.
-- Temporary access by third-party vendors or consultants may appear unusual. Ensure their access is documented and create temporary exceptions during their engagement period.
-
-### Response and remediation
-
-- Immediately isolate the affected Windows system from the network to prevent further unauthorized access to the metadata service.
-- Revoke any potentially compromised credentials identified during the investigation and issue new credentials to affected users.
-- Conduct a thorough review of access logs to identify any unauthorized data access or exfiltration attempts from the metadata service.
-- Implement additional monitoring on the affected system and similar systems to detect any further anomalous access attempts.
-- Escalate the incident to the security operations center (SOC) for a deeper investigation into potential lateral movement or other compromised systems.
-- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
-- Review and enhance access controls and permissions for the metadata service to ensure only authorized users can access sensitive information."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]

rules/ml/execution_ml_windows_anomalous_script.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 anomaly_threshold = 50
@@ -24,6 +22,47 @@ interval = "15m"
 license = "Elastic License v2"
 machine_learning_job_id = ["v3_windows_anomalous_script"]
 name = "Suspicious Powershell Script"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Powershell Script
+
+PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries often exploit its capabilities to execute malicious scripts, leveraging obfuscation to evade detection. The 'Suspicious Powershell Script' detection rule employs machine learning to identify unusual script characteristics, such as obfuscation, indicating potential threats. By analyzing these anomalies, the rule aids in early threat detection and mitigation.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific PowerShell script or command that triggered the detection, focusing on any obfuscated elements.
+- Examine the source endpoint and user account associated with the alert to determine if the activity aligns with expected behavior or if it appears suspicious.
+- Check the execution history on the affected endpoint for any other unusual or unauthorized PowerShell commands or scripts executed around the same time.
+- Investigate the network activity from the source endpoint to identify any connections to known malicious IP addresses or domains.
+- Correlate the alert with other security events or logs, such as antivirus alerts or firewall logs, to gather additional context and assess the potential impact.
+- Consult threat intelligence sources to determine if the detected script or its components are associated with known malware or attack campaigns.
+
+### False positive analysis
+
+- Legitimate administrative scripts may trigger the rule due to obfuscation techniques used for efficiency or security. Review the script's purpose and source to determine its legitimacy.
+- Automated deployment tools often use PowerShell scripts that appear obfuscated. Identify and whitelist these tools to prevent unnecessary alerts.
+- Security software updates might use obfuscated scripts for protection against tampering. Verify the update source and add exceptions for known trusted vendors.
+- Custom scripts developed in-house for specific tasks may use obfuscation for intellectual property protection. Document and exclude these scripts after confirming their safety.
+- Regularly review and update the list of exceptions to ensure that only verified non-threatening scripts are excluded, maintaining the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.
+- Terminate any suspicious PowerShell processes identified on the affected system to halt the execution of potentially harmful scripts.
+- Conduct a thorough review of the PowerShell script logs and execution history on the affected system to identify any unauthorized or malicious commands executed.
+- Restore the affected system from a known good backup if any malicious activity is confirmed, ensuring that the backup is free from compromise.
+- Update and patch the affected system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Implement enhanced monitoring for PowerShell activity across the network, focusing on detecting obfuscation and unusual script characteristics.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
+references = [
+    "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
+    "https://www.elastic.co/security-labs/detecting-living-off-the-land-attacks-with-new-elastic-integration",
+]
+risk_score = 21
+rule_id = "1781d055-5c66-4adf-9d60-fc0fa58337b6"
 setup = """## Setup
 
 This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
@@ -68,12 +107,6 @@ The Windows integration allows you to monitor the Windows OS, services, applicat
 - Click “Save and Continue”.
 - For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).
 """
-references = [
-    "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
-    "https://www.elastic.co/security-labs/detecting-living-off-the-land-attacks-with-new-elastic-integration",
-]
-risk_score = 21
-rule_id = "1781d055-5c66-4adf-9d60-fc0fa58337b6"
 severity = "low"
 tags = [
     "Domain: Endpoint",
@@ -85,41 +118,6 @@ tags = [
     "Resources: Investigation Guide",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Powershell Script
-
-PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries often exploit its capabilities to execute malicious scripts, leveraging obfuscation to evade detection. The 'Suspicious Powershell Script' detection rule employs machine learning to identify unusual script characteristics, such as obfuscation, indicating potential threats. By analyzing these anomalies, the rule aids in early threat detection and mitigation.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific PowerShell script or command that triggered the detection, focusing on any obfuscated elements.
-- Examine the source endpoint and user account associated with the alert to determine if the activity aligns with expected behavior or if it appears suspicious.
-- Check the execution history on the affected endpoint for any other unusual or unauthorized PowerShell commands or scripts executed around the same time.
-- Investigate the network activity from the source endpoint to identify any connections to known malicious IP addresses or domains.
-- Correlate the alert with other security events or logs, such as antivirus alerts or firewall logs, to gather additional context and assess the potential impact.
-- Consult threat intelligence sources to determine if the detected script or its components are associated with known malware or attack campaigns.
-
-### False positive analysis
-
-- Legitimate administrative scripts may trigger the rule due to obfuscation techniques used for efficiency or security. Review the script's purpose and source to determine its legitimacy.
-- Automated deployment tools often use PowerShell scripts that appear obfuscated. Identify and whitelist these tools to prevent unnecessary alerts.
-- Security software updates might use obfuscated scripts for protection against tampering. Verify the update source and add exceptions for known trusted vendors.
-- Custom scripts developed in-house for specific tasks may use obfuscation for intellectual property protection. Document and exclude these scripts after confirming their safety.
-- Regularly review and update the list of exceptions to ensure that only verified non-threatening scripts are excluded, maintaining the effectiveness of the detection rule.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.
-- Terminate any suspicious PowerShell processes identified on the affected system to halt the execution of potentially harmful scripts.
-- Conduct a thorough review of the PowerShell script logs and execution history on the affected system to identify any unauthorized or malicious commands executed.
-- Restore the affected system from a known good backup if any malicious activity is confirmed, ensuring that the backup is free from compromise.
-- Update and patch the affected system to the latest security standards to close any vulnerabilities that may have been exploited.
-- Implement enhanced monitoring for PowerShell activity across the network, focusing on detecting obfuscation and unusual script characteristics.
-- 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.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]

rules/ml/initial_access_ml_windows_anomalous_user_name.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/17"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 anomaly_threshold = 50
@@ -30,6 +28,17 @@ interval = "15m"
 license = "Elastic License v2"
 machine_learning_job_id = ["v3_windows_anomalous_user_name"]
 name = "Unusual Windows Username"
+note = """## Triage and analysis
+
+### Investigating Unusual Windows Username
+Detection alerts from this rule indicate activity for a Windows user name that is rare and unusual. Here are some possible avenues of investigation:
+- Consider the user as identified by the username field. Is this program part of an expected workflow for the user who ran this program on this host? Could this be related to occasional troubleshooting or support activity?
+- Examine the history of user activity. If this user only manifested recently, it might be a service account for a new software package. If it has a consistent cadence (for example if it runs monthly or quarterly), it might be part of a monthly or quarterly business process.
+- Examine the process arguments, title and working directory. These may provide indications as to the source of the program or the nature of the tasks that the user is performing.
+- Consider the same for the parent process. If the parent process is a legitimate system utility or service, this could be related to software updates or system management. If the parent process is something user-facing like an Office application, this process could be more suspicious."""
+references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
+risk_score = 21
+rule_id = "1781d055-5c66-4adf-9c59-fc0fa58336a5"
 setup = """## Setup
 
 This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
@@ -74,17 +83,6 @@ The Windows integration allows you to monitor the Windows OS, services, applicat
 - Click “Save and Continue”.
 - For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).
 """
-note = """## Triage and analysis
-
-### Investigating Unusual Windows Username
-Detection alerts from this rule indicate activity for a Windows user name that is rare and unusual. Here are some possible avenues of investigation:
-- Consider the user as identified by the username field. Is this program part of an expected workflow for the user who ran this program on this host? Could this be related to occasional troubleshooting or support activity?
-- Examine the history of user activity. If this user only manifested recently, it might be a service account for a new software package. If it has a consistent cadence (for example if it runs monthly or quarterly), it might be part of a monthly or quarterly business process.
-- Examine the process arguments, title and working directory. These may provide indications as to the source of the program or the nature of the tasks that the user is performing.
-- Consider the same for the parent process. If the parent process is a legitimate system utility or service, this could be related to software updates or system management. If the parent process is something user-facing like an Office application, this process could be more suspicious."""
-references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
-risk_score = 21
-rule_id = "1781d055-5c66-4adf-9c59-fc0fa58336a5"
 severity = "low"
 tags = [
     "Domain: Endpoint",

rules/ml/initial_access_ml_windows_rare_user_type10_remote_login.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/17"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 anomaly_threshold = 50
@@ -25,6 +23,15 @@ interval = "15m"
 license = "Elastic License v2"
 machine_learning_job_id = ["v3_windows_rare_user_type10_remote_login"]
 name = "Unusual Windows Remote User"
+note = """## Triage and analysis
+
+### Investigating Unusual Windows Remote User
+Detection alerts from this rule indicate activity for a rare and unusual Windows RDP (remote desktop) user. Here are some possible avenues of investigation:
+- Consider the user as identified by the username field. Is the user part of a group who normally logs into Windows hosts using RDP (remote desktop protocol)? Is this logon activity part of an expected workflow for the user?
+- Consider the source of the login. If the source is remote, could this be related to occasional troubleshooting or support activity by a vendor or an employee working remotely?"""
+references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
+risk_score = 21
+rule_id = "1781d055-5c66-4adf-9e93-fc0fa69550c9"
 setup = """## Setup
 
 This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
@@ -69,15 +76,6 @@ The Windows integration allows you to monitor the Windows OS, services, applicat
 - Click “Save and Continue”.
 - For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).
 """
-note = """## Triage and analysis
-
-### Investigating Unusual Windows Remote User
-Detection alerts from this rule indicate activity for a rare and unusual Windows RDP (remote desktop) user. Here are some possible avenues of investigation:
-- Consider the user as identified by the username field. Is the user part of a group who normally logs into Windows hosts using RDP (remote desktop protocol)? Is this logon activity part of an expected workflow for the user?
-- Consider the source of the login. If the source is remote, could this be related to occasional troubleshooting or support activity by a vendor or an employee working remotely?"""
-references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
-risk_score = 21
-rule_id = "1781d055-5c66-4adf-9e93-fc0fa69550c9"
 severity = "low"
 tags = [
     "Domain: Endpoint",

rules/ml/ml_windows_anomalous_network_activity.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/17"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 anomaly_threshold = 50
@@ -22,6 +20,20 @@ interval = "15m"
 license = "Elastic License v2"
 machine_learning_job_id = ["v3_windows_anomalous_network_activity"]
 name = "Unusual Windows Network Activity"
+note = """## Triage and analysis
+
+### Investigating Unusual Windows Network Activity
+Detection alerts from this rule indicate the presence of network activity from a Windows process for which network activity is very unusual.  Here are some possible avenues of investigation:
+- Consider the IP addresses, protocol and ports. Are these used by normal but infrequent network workflows? Are they expected or unexpected?
+- If the destination IP address is remote or external, does it associate with an expected domain, organization or geography? Note: avoid interacting directly with suspected malicious IP addresses.
+- Consider the user as identified by the username field. Is this network activity part of an expected workflow for the user who ran the program?
+- Examine the history of execution. If this process only manifested recently, it might be part of a new software package. If it has a consistent cadence (for example if it runs monthly or quarterly), it might be part of a monthly or quarterly business process.
+- Examine the process arguments, title and working directory. These may provide indications as to the source of the program or the nature of the tasks it is performing.
+- Consider the same for the parent process. If the parent process is a legitimate system utility or service, this could be related to software updates or system management. If the parent process is something user-facing like an Office application, this process could be more suspicious.
+- If you have file hash values in the event data, and you suspect malware, you can optionally run a search for the file hash to see if the file is identified as malware by anti-malware tools."""
+references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
+risk_score = 21
+rule_id = "ba342eb2-583c-439f-b04d-1fdd7c1417cc"
 setup = """## Setup
 
 This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
@@ -66,20 +78,6 @@ The Windows integration allows you to monitor the Windows OS, services, applicat
 - Click “Save and Continue”.
 - For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).
 """
-note = """## Triage and analysis
-
-### Investigating Unusual Windows Network Activity
-Detection alerts from this rule indicate the presence of network activity from a Windows process for which network activity is very unusual.  Here are some possible avenues of investigation:
-- Consider the IP addresses, protocol and ports. Are these used by normal but infrequent network workflows? Are they expected or unexpected?
-- If the destination IP address is remote or external, does it associate with an expected domain, organization or geography? Note: avoid interacting directly with suspected malicious IP addresses.
-- Consider the user as identified by the username field. Is this network activity part of an expected workflow for the user who ran the program?
-- Examine the history of execution. If this process only manifested recently, it might be part of a new software package. If it has a consistent cadence (for example if it runs monthly or quarterly), it might be part of a monthly or quarterly business process.
-- Examine the process arguments, title and working directory. These may provide indications as to the source of the program or the nature of the tasks it is performing.
-- Consider the same for the parent process. If the parent process is a legitimate system utility or service, this could be related to software updates or system management. If the parent process is something user-facing like an Office application, this process could be more suspicious.
-- If you have file hash values in the event data, and you suspect malware, you can optionally run a search for the file hash to see if the file is identified as malware by anti-malware tools."""
-references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
-risk_score = 21
-rule_id = "ba342eb2-583c-439f-b04d-1fdd7c1417cc"
 severity = "low"
 tags = [
     "Domain: Endpoint",

rules/ml/persistence_ml_rare_process_by_host_windows.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/02/03"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]
@@ -51,50 +49,6 @@ interval = "15m"
 license = "Elastic License v2"
 machine_learning_job_id = ["v3_rare_process_by_host_windows"]
 name = "Unusual Process For a Windows Host"
-setup = """## Setup
-
-This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
-- Elastic Defend
-- Windows
-
-### Anomaly Detection Setup
-
-Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).
-
-### 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 [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
-
-#### The following steps should be executed in order to add the Elastic Defend integration to your system:
-- Go to the Kibana home page and click "Add integrations".
-- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
-- Click "Add Elastic Defend".
-- Configure the integration name and optionally add a description.
-- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
-- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
-- 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 [helper guide](https://www.elastic.co/guide/en/fleet/current/agent-policy.html).
-- 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 [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
-
-### Windows Integration Setup
-The Windows integration allows you to monitor the Windows OS, services, applications, and more.
-
-#### The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:
-- Go to the Kibana home page and click “Add integrations”.
-- In the query bar, search for “Windows” and select the integration to see more details about it.
-- Click “Add Windows”.
-- Configure the integration name and optionally add a description.
-- Review optional and advanced settings accordingly.
-- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable.
-- Click “Save and Continue”.
-- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).
-"""
 note = """## Triage and analysis
 
 ###  Investigating Unusual Process For a Windows Host
@@ -159,6 +113,50 @@ This rule uses a machine learning job to detect a Windows process that is rare a
 references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
 risk_score = 21
 rule_id = "6d448b96-c922-4adb-b51c-b767f1ea5b76"
+setup = """## Setup
+
+This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
+- Elastic Defend
+- Windows
+
+### Anomaly Detection Setup
+
+Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).
+
+### 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 [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+
+#### The following steps should be executed in order to add the Elastic Defend integration to your system:
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
+- 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 [helper guide](https://www.elastic.co/guide/en/fleet/current/agent-policy.html).
+- 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 [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+
+### Windows Integration Setup
+The Windows integration allows you to monitor the Windows OS, services, applications, and more.
+
+#### The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:
+- Go to the Kibana home page and click “Add integrations”.
+- In the query bar, search for “Windows” and select the integration to see more details about it.
+- Click “Add Windows”.
+- Configure the integration name and optionally add a description.
+- Review optional and advanced settings accordingly.
+- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable.
+- Click “Save and Continue”.
+- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).
+"""
 severity = "low"
 tags = [
     "Domain: Endpoint",

rules/ml/persistence_ml_windows_anomalous_path_activity.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 anomaly_threshold = 50
@@ -27,6 +25,44 @@ interval = "15m"
 license = "Elastic License v2"
 machine_learning_job_id = ["v3_windows_anomalous_path_activity"]
 name = "Unusual Windows Path Activity"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Windows Path Activity
+
+In corporate Windows environments, software is typically managed centrally, making execution from user or temporary directories uncommon. Adversaries exploit this by running malware from these atypical paths, bypassing standard security measures. The 'Unusual Windows Path Activity' detection rule leverages machine learning to identify such anomalies, flagging potential persistence or execution tactics used by attackers.
+
+### Possible investigation steps
+
+- Review the process name and path to determine if it is a known legitimate application or a suspicious executable.
+- Check the parent process to understand how the process was initiated and if it correlates with expected user behavior or known software installations.
+- Investigate the user account associated with the process execution to verify if the activity aligns with their typical usage patterns or if it appears anomalous.
+- Examine the file hash of the executable to see if it matches known malware signatures or if it has been flagged by any threat intelligence sources.
+- Look into recent file modifications or creations in the directory from which the process was executed to identify any additional suspicious files or scripts.
+- Analyze network connections initiated by the process to detect any unusual or unauthorized external communications.
+
+### False positive analysis
+
+- Software updates or installations by IT staff can trigger alerts when executed from temporary directories. To manage this, create exceptions for known IT processes or scripts that are regularly used for legitimate software deployment.
+- Some legitimate applications may temporarily execute components from user directories during updates or initial setup. Identify these applications and add them to an allowlist to prevent unnecessary alerts.
+- Developers or power users might run scripts or applications from non-standard directories for testing purposes. Establish a policy to document and approve such activities, and configure exceptions for these known cases.
+- Automated tasks or scripts that are scheduled to run from user directories can be mistaken for malicious activity. Review and document these tasks, then configure the detection rule to exclude them from triggering alerts.
+- Security tools or monitoring software might execute diagnostic or remediation scripts from temporary paths. Verify these activities and add them to an exception list to avoid false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malware and unauthorized access.
+- Terminate any suspicious processes identified as running from atypical directories to halt malicious activity.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious files.
+- Review and restore any modified system processes or configurations to their original state to ensure system integrity.
+- Collect and preserve relevant logs and evidence for further analysis and potential escalation to the incident response team.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat persists or if there is evidence of broader compromise.
+- Implement application whitelisting to prevent unauthorized execution of software from user or temporary directories in the future."""
+references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
+risk_score = 21
+rule_id = "445a342e-03fb-42d0-8656-0367eb2dead5"
 setup = """## Setup
 
 This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
@@ -71,9 +107,6 @@ The Windows integration allows you to monitor the Windows OS, services, applicat
 - Click “Save and Continue”.
 - For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).
 """
-references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
-risk_score = 21
-rule_id = "445a342e-03fb-42d0-8656-0367eb2dead5"
 severity = "low"
 tags = [
     "Domain: Endpoint",
@@ -86,41 +119,6 @@ tags = [
     "Resources: Investigation Guide",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Windows Path Activity
-
-In corporate Windows environments, software is typically managed centrally, making execution from user or temporary directories uncommon. Adversaries exploit this by running malware from these atypical paths, bypassing standard security measures. The 'Unusual Windows Path Activity' detection rule leverages machine learning to identify such anomalies, flagging potential persistence or execution tactics used by attackers.
-
-### Possible investigation steps
-
-- Review the process name and path to determine if it is a known legitimate application or a suspicious executable.
-- Check the parent process to understand how the process was initiated and if it correlates with expected user behavior or known software installations.
-- Investigate the user account associated with the process execution to verify if the activity aligns with their typical usage patterns or if it appears anomalous.
-- Examine the file hash of the executable to see if it matches known malware signatures or if it has been flagged by any threat intelligence sources.
-- Look into recent file modifications or creations in the directory from which the process was executed to identify any additional suspicious files or scripts.
-- Analyze network connections initiated by the process to detect any unusual or unauthorized external communications.
-
-### False positive analysis
-
-- Software updates or installations by IT staff can trigger alerts when executed from temporary directories. To manage this, create exceptions for known IT processes or scripts that are regularly used for legitimate software deployment.
-- Some legitimate applications may temporarily execute components from user directories during updates or initial setup. Identify these applications and add them to an allowlist to prevent unnecessary alerts.
-- Developers or power users might run scripts or applications from non-standard directories for testing purposes. Establish a policy to document and approve such activities, and configure exceptions for these known cases.
-- Automated tasks or scripts that are scheduled to run from user directories can be mistaken for malicious activity. Review and document these tasks, then configure the detection rule to exclude them from triggering alerts.
-- Security tools or monitoring software might execute diagnostic or remediation scripts from temporary paths. Verify these activities and add them to an exception list to avoid false positives.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malware and unauthorized access.
-- Terminate any suspicious processes identified as running from atypical directories to halt malicious activity.
-- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious files.
-- Review and restore any modified system processes or configurations to their original state to ensure system integrity.
-- Collect and preserve relevant logs and evidence for further analysis and potential escalation to the incident response team.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat persists or if there is evidence of broader compromise.
-- Implement application whitelisting to prevent unauthorized execution of software from user or temporary directories in the future."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]

rules/ml/persistence_ml_windows_anomalous_process_all_hosts.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/02/03"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]
@@ -51,50 +49,6 @@ interval = "15m"
 license = "Elastic License v2"
 machine_learning_job_id = ["v3_windows_anomalous_process_all_hosts"]
 name = "Anomalous Process For a Windows Population"
-setup = """## Setup
-
-This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
-- Elastic Defend
-- Windows
-
-### Anomaly Detection Setup
-
-Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).
-
-### 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 [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
-
-#### The following steps should be executed in order to add the Elastic Defend integration to your system:
-- Go to the Kibana home page and click "Add integrations".
-- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
-- Click "Add Elastic Defend".
-- Configure the integration name and optionally add a description.
-- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
-- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
-- 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 [helper guide](https://www.elastic.co/guide/en/fleet/current/agent-policy.html).
-- 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 [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
-
-### Windows Integration Setup
-The Windows integration allows you to monitor the Windows OS, services, applications, and more.
-
-#### The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:
-- Go to the Kibana home page and click “Add integrations”.
-- In the query bar, search for “Windows” and select the integration to see more details about it.
-- Click “Add Windows”.
-- Configure the integration name and optionally add a description.
-- Review optional and advanced settings accordingly.
-- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable.
-- Click “Save and Continue”.
-- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).
-"""
 note = """## Triage and analysis
 
 ###  Investigating Anomalous Process For a Windows Population
@@ -159,6 +113,50 @@ This rule uses a machine learning job to detect a Windows process that is rare a
 references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
 risk_score = 21
 rule_id = "6e40d56f-5c0e-4ac6-aece-bee96645b172"
+setup = """## Setup
+
+This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
+- Elastic Defend
+- Windows
+
+### Anomaly Detection Setup
+
+Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).
+
+### 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 [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+
+#### The following steps should be executed in order to add the Elastic Defend integration to your system:
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
+- 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 [helper guide](https://www.elastic.co/guide/en/fleet/current/agent-policy.html).
+- 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 [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+
+### Windows Integration Setup
+The Windows integration allows you to monitor the Windows OS, services, applications, and more.
+
+#### The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:
+- Go to the Kibana home page and click “Add integrations”.
+- In the query bar, search for “Windows” and select the integration to see more details about it.
+- Click “Add Windows”.
+- Configure the integration name and optionally add a description.
+- Review optional and advanced settings accordingly.
+- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable.
+- Click “Save and Continue”.
+- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).
+"""
 severity = "low"
 tags = [
     "Domain: Endpoint",

rules/ml/persistence_ml_windows_anomalous_process_creation.toml

@@ -1,10 +1,8 @@
 [metadata]
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
-min_stack_version = "8.14.0"
 maturity = "production"
-updated_date = "2025/02/03"
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]
@@ -54,50 +52,6 @@ interval = "15m"
 license = "Elastic License v2"
 machine_learning_job_id = ["v3_windows_anomalous_process_creation"]
 name = "Anomalous Windows Process Creation"
-setup = """## Setup
-
-This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
-- Elastic Defend
-- Windows
-
-### Anomaly Detection Setup
-
-Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).
-
-### 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 [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
-
-#### The following steps should be executed in order to add the Elastic Defend integration to your system:
-- Go to the Kibana home page and click "Add integrations".
-- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
-- Click "Add Elastic Defend".
-- Configure the integration name and optionally add a description.
-- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
-- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
-- 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 [helper guide](https://www.elastic.co/guide/en/fleet/current/agent-policy.html).
-- 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 [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
-
-### Windows Integration Setup
-The Windows integration allows you to monitor the Windows OS, services, applications, and more.
-
-#### The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:
-- Go to the Kibana home page and click “Add integrations”.
-- In the query bar, search for “Windows” and select the integration to see more details about it.
-- Click “Add Windows”.
-- Configure the integration name and optionally add a description.
-- Review optional and advanced settings accordingly.
-- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable.
-- Click “Save and Continue”.
-- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).
-"""
 note = """## Triage and analysis
 
 ###  Investigating Anomalous Windows Process Creation
@@ -162,6 +116,50 @@ This rule uses a machine learning job to detect an anomalous Windows process wit
 references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
 risk_score = 21
 rule_id = "0b29cab4-dbbd-4a3f-9e8e-1287c7c11ae5"
+setup = """## Setup
+
+This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
+- Elastic Defend
+- Windows
+
+### Anomaly Detection Setup
+
+Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).
+
+### 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 [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+
+#### The following steps should be executed in order to add the Elastic Defend integration to your system:
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
+- 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 [helper guide](https://www.elastic.co/guide/en/fleet/current/agent-policy.html).
+- 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 [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+
+### Windows Integration Setup
+The Windows integration allows you to monitor the Windows OS, services, applications, and more.
+
+#### The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:
+- Go to the Kibana home page and click “Add integrations”.
+- In the query bar, search for “Windows” and select the integration to see more details about it.
+- Click “Add Windows”.
+- Configure the integration name and optionally add a description.
+- Review optional and advanced settings accordingly.
+- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable.
+- Click “Save and Continue”.
+- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).
+"""
 severity = "low"
 tags = [
     "Domain: Endpoint",

rules/ml/persistence_ml_windows_anomalous_service.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 anomaly_threshold = 50
@@ -25,6 +23,44 @@ interval = "15m"
 license = "Elastic License v2"
 machine_learning_job_id = ["v3_windows_anomalous_service"]
 name = "Unusual Windows Service"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Windows Service
+
+Windows services are crucial for running background processes and applications. Adversaries exploit this by creating or modifying services to maintain persistence or execute unauthorized actions. The 'Unusual Windows Service' detection rule leverages machine learning to identify atypical services, flagging potential threats by comparing against known service patterns, thus aiding in early threat detection and response.
+
+### Possible investigation steps
+
+- Review the details of the detected unusual Windows service, including the service name, path, and any associated executables, to determine if it aligns with known legitimate services or appears suspicious.
+- Check the creation and modification timestamps of the service to identify if it was recently added or altered, which could indicate unauthorized activity.
+- Investigate the user account under which the service is running to assess if it has the necessary permissions and if the account has been compromised or misused.
+- Cross-reference the service with known threat intelligence databases to see if it matches any known malware or persistence mechanisms.
+- Analyze the network activity and connections associated with the service to identify any unusual or unauthorized communication patterns.
+- Examine the host's event logs for any related entries that could provide additional context or evidence of malicious activity, such as failed login attempts or privilege escalation events.
+
+### False positive analysis
+
+- Legitimate software installations or updates may create new services that are flagged as unusual. Users should verify the source and purpose of the service before excluding it.
+- Custom in-house applications often run unique services that can trigger alerts. Document these services and create exceptions to prevent future false positives.
+- IT administrative tools might install services for management purposes. Confirm these tools are authorized and add them to an exception list if they are frequently flagged.
+- Temporary services used for troubleshooting or testing can be mistaken for threats. Ensure these are removed after use or excluded if they are part of regular operations.
+- Scheduled tasks that create services for specific operations might be flagged. Review these tasks and exclude them if they are part of normal business processes.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent potential lateral movement or data exfiltration by the unauthorized service.
+- Terminate the unusual Windows service identified by the alert to stop any ongoing malicious activity.
+- Conduct a thorough analysis of the service's executable and associated files to determine if they are malicious. Use endpoint detection and response (EDR) tools to assist in this analysis.
+- Remove any malicious files or executables associated with the service from the system to ensure complete eradication of the threat.
+- Restore the affected system from a known good backup if the service has caused significant changes or damage to the system.
+- Monitor the system and network for any signs of re-infection or similar unusual service activity, 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 need for broader organizational response measures."""
+references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
+risk_score = 21
+rule_id = "1781d055-5c66-4adf-9c71-fc0fa58338c7"
 setup = """## Setup
 
 This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
@@ -69,9 +105,6 @@ The Windows integration allows you to monitor the Windows OS, services, applicat
 - Click “Save and Continue”.
 - For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).
 """
-references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
-risk_score = 21
-rule_id = "1781d055-5c66-4adf-9c71-fc0fa58338c7"
 severity = "low"
 tags = [
     "Domain: Endpoint",
@@ -83,41 +116,6 @@ tags = [
     "Resources: Investigation Guide",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Windows Service
-
-Windows services are crucial for running background processes and applications. Adversaries exploit this by creating or modifying services to maintain persistence or execute unauthorized actions. The 'Unusual Windows Service' detection rule leverages machine learning to identify atypical services, flagging potential threats by comparing against known service patterns, thus aiding in early threat detection and response.
-
-### Possible investigation steps
-
-- Review the details of the detected unusual Windows service, including the service name, path, and any associated executables, to determine if it aligns with known legitimate services or appears suspicious.
-- Check the creation and modification timestamps of the service to identify if it was recently added or altered, which could indicate unauthorized activity.
-- Investigate the user account under which the service is running to assess if it has the necessary permissions and if the account has been compromised or misused.
-- Cross-reference the service with known threat intelligence databases to see if it matches any known malware or persistence mechanisms.
-- Analyze the network activity and connections associated with the service to identify any unusual or unauthorized communication patterns.
-- Examine the host's event logs for any related entries that could provide additional context or evidence of malicious activity, such as failed login attempts or privilege escalation events.
-
-### False positive analysis
-
-- Legitimate software installations or updates may create new services that are flagged as unusual. Users should verify the source and purpose of the service before excluding it.
-- Custom in-house applications often run unique services that can trigger alerts. Document these services and create exceptions to prevent future false positives.
-- IT administrative tools might install services for management purposes. Confirm these tools are authorized and add them to an exception list if they are frequently flagged.
-- Temporary services used for troubleshooting or testing can be mistaken for threats. Ensure these are removed after use or excluded if they are part of regular operations.
-- Scheduled tasks that create services for specific operations might be flagged. Review these tasks and exclude them if they are part of normal business processes.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent potential lateral movement or data exfiltration by the unauthorized service.
-- Terminate the unusual Windows service identified by the alert to stop any ongoing malicious activity.
-- Conduct a thorough analysis of the service's executable and associated files to determine if they are malicious. Use endpoint detection and response (EDR) tools to assist in this analysis.
-- Remove any malicious files or executables associated with the service from the system to ensure complete eradication of the threat.
-- Restore the affected system from a known good backup if the service has caused significant changes or damage to the system.
-- Monitor the system and network for any signs of re-infection or similar unusual service activity, 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 need for broader organizational response measures."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]

rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 anomaly_threshold = 50
@@ -25,6 +23,44 @@ interval = "15m"
 license = "Elastic License v2"
 machine_learning_job_id = ["v3_windows_rare_user_runas_event"]
 name = "Unusual Windows User Privilege Elevation Activity"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Windows User Privilege Elevation Activity
+
+In Windows environments, privilege elevation tools like 'runas' allow users to execute programs with different user credentials, typically used by administrators. Adversaries exploit this to gain elevated access, often indicating account compromise. The detection rule leverages machine learning to identify atypical usage patterns of such tools, flagging potential unauthorized privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the specific user account involved in the alert to determine if it is a regular user or an administrator, as privilege elevation is more common among administrators.
+- Check the timestamp of the alert to correlate with any known scheduled tasks or administrative activities that might explain the use of privilege elevation tools.
+- Investigate the source IP address and device from which the privilege elevation attempt was made to verify if it aligns with the user's typical access patterns.
+- Examine recent login activity for the user account to identify any unusual or unauthorized access attempts that could indicate account compromise.
+- Look for any other security alerts or logs related to the same user or device around the time of the alert to gather additional context on potential malicious activity.
+- Assess whether there have been any recent changes to user permissions or group memberships that could have facilitated the privilege elevation.
+
+### False positive analysis
+
+- Regular administrative tasks by domain or network administrators can trigger false positives. To manage this, create exceptions for known administrator accounts frequently using the runas command.
+- Scheduled tasks or scripts that require privilege elevation might be flagged. Identify and exclude these tasks from monitoring if they are verified as safe and necessary for operations.
+- Software updates or installations that require elevated privileges can also cause alerts. Maintain a list of approved software and update processes to exclude them from triggering the rule.
+- Training or testing environments where privilege elevation is part of routine operations may generate false positives. Exclude these environments from the rule's scope to prevent unnecessary alerts.
+- Third-party applications that use privilege elevation for legitimate purposes should be reviewed and, if deemed safe, added to an exception list to avoid repeated false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Revoke any elevated privileges granted to the compromised account and reset its password to prevent further misuse.
+- Conduct a thorough review of recent activity logs for the affected account to identify any unauthorized actions or data access.
+- Notify the security team and relevant stakeholders about the incident for awareness and potential escalation.
+- Restore any altered or compromised system configurations to their original state using backups or system snapshots.
+- Implement additional monitoring on the affected system and account to detect any further suspicious activity.
+- Review and update access controls and privilege management policies to minimize the risk of similar incidents in the future."""
+references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
+risk_score = 21
+rule_id = "1781d055-5c66-4adf-9d82-fc0fa58449c8"
 setup = """## Setup
 
 This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
@@ -69,9 +105,6 @@ The Windows integration allows you to monitor the Windows OS, services, applicat
 - Click “Save and Continue”.
 - For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).
 """
-references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
-risk_score = 21
-rule_id = "1781d055-5c66-4adf-9d82-fc0fa58449c8"
 severity = "low"
 tags = [
     "Domain: Endpoint",
@@ -83,41 +116,6 @@ tags = [
     "Resources: Investigation Guide",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Windows User Privilege Elevation Activity
-
-In Windows environments, privilege elevation tools like 'runas' allow users to execute programs with different user credentials, typically used by administrators. Adversaries exploit this to gain elevated access, often indicating account compromise. The detection rule leverages machine learning to identify atypical usage patterns of such tools, flagging potential unauthorized privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the specific user account involved in the alert to determine if it is a regular user or an administrator, as privilege elevation is more common among administrators.
-- Check the timestamp of the alert to correlate with any known scheduled tasks or administrative activities that might explain the use of privilege elevation tools.
-- Investigate the source IP address and device from which the privilege elevation attempt was made to verify if it aligns with the user's typical access patterns.
-- Examine recent login activity for the user account to identify any unusual or unauthorized access attempts that could indicate account compromise.
-- Look for any other security alerts or logs related to the same user or device around the time of the alert to gather additional context on potential malicious activity.
-- Assess whether there have been any recent changes to user permissions or group memberships that could have facilitated the privilege elevation.
-
-### False positive analysis
-
-- Regular administrative tasks by domain or network administrators can trigger false positives. To manage this, create exceptions for known administrator accounts frequently using the runas command.
-- Scheduled tasks or scripts that require privilege elevation might be flagged. Identify and exclude these tasks from monitoring if they are verified as safe and necessary for operations.
-- Software updates or installations that require elevated privileges can also cause alerts. Maintain a list of approved software and update processes to exclude them from triggering the rule.
-- Training or testing environments where privilege elevation is part of routine operations may generate false positives. Exclude these environments from the rule's scope to prevent unnecessary alerts.
-- Third-party applications that use privilege elevation for legitimate purposes should be reviewed and, if deemed safe, added to an exception list to avoid repeated false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Revoke any elevated privileges granted to the compromised account and reset its password to prevent further misuse.
-- Conduct a thorough review of recent activity logs for the affected account to identify any unauthorized actions or data access.
-- Notify the security team and relevant stakeholders about the incident for awareness and potential escalation.
-- Restore any altered or compromised system configurations to their original state using backups or system snapshots.
-- Implement additional monitoring on the affected system and account to detect any further suspicious activity.
-- Review and update access controls and privilege management policies to minimize the risk of similar incidents in the future."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 

rules/windows/collection_email_powershell_exchange_mailbox.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/12/15"
 integration = ["endpoint", "windows", "system", "sentinel_one_cloud_funnel", "m365_defender", "crowdstrike"]
 maturity = "production"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
-min_stack_version = "8.14.0"
-updated_date = "2025/02/21"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/windows/collection_mailbox_export_winlog.toml

@@ -2,14 +2,13 @@
 creation_date = "2023/01/11"
 integration = ["windows"]
 maturity = "production"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
-min_stack_version = "8.14.0"
-updated_date = "2024/10/28"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies the use of the Exchange PowerShell cmdlet, New-MailBoxExportRequest, to export the contents of a primary mailbox or archive to a .pst file. Adversaries may target user email to collect sensitive information.
+Identifies the use of the Exchange PowerShell cmdlet, New-MailBoxExportRequest, to export the contents of a primary
+mailbox or archive to a .pst file. Adversaries may target user email to collect sensitive information.
 """
 false_positives = ["Legitimate exchange system administration activity."]
 from = "now-9m"
@@ -63,7 +62,14 @@ references = [
 risk_score = 47
 rule_id = "54a81f68-5f2a-421e-8eed-f888278bb712"
 severity = "medium"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Collection", "Resources: Investigation Guide", "Data Source: PowerShell Logs"]
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Collection",
+    "Resources: Investigation Guide",
+    "Data Source: PowerShell Logs",
+]
 timestamp_override = "event.ingested"
 type = "query"
 
@@ -72,27 +78,28 @@ event.category:process and host.os.type:windows and
   powershell.file.script_block_text : "New-MailboxExportRequest"
 '''
 
+
 [[rule.filters]]
+
 [rule.filters.meta]
 negate = true
 [rule.filters.query.wildcard."file.path"]
-"case_insensitive" = true
-"value" = "?:\\\\Users\\\\*\\\\AppData\\\\Roaming\\\\Microsoft\\\\Exchange\\\\RemotePowerShell\\\\*"
-
+case_insensitive = true
+value = "?:\\\\Users\\\\*\\\\AppData\\\\Roaming\\\\Microsoft\\\\Exchange\\\\RemotePowerShell\\\\*"
 [[rule.filters]]
+
 [rule.filters.meta]
 negate = true
 [rule.filters.query.wildcard."file.path"]
-"case_insensitive" = true
-"value" = "?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Temp\\\\tmp_????????.???\\\\tmp_????????.???.ps?1"
-
+case_insensitive = true
+value = "?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Temp\\\\tmp_????????.???\\\\tmp_????????.???.ps?1"
 [[rule.filters]]
+
 [rule.filters.meta]
 negate = true
 [rule.filters.query.wildcard."file.path"]
-"case_insensitive" = true
-"value" = "?:\\\\Windows\\\\TEMP\\\\tmp_????????.???\\\\tmp_????????.???.ps?1"
-
+case_insensitive = true
+value = "?:\\\\Windows\\\\TEMP\\\\tmp_????????.???\\\\tmp_????????.???.ps?1"
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
@@ -104,7 +111,6 @@ reference = "https://attack.mitre.org/techniques/T1005/"
 id = "T1114"
 name = "Email Collection"
 reference = "https://attack.mitre.org/techniques/T1114/"
-
 [[rule.threat.technique.subtechnique]]
 id = "T1114.001"
 name = "Local Email Collection"
@@ -116,7 +122,9 @@ name = "Remote Email Collection"
 reference = "https://attack.mitre.org/techniques/T1114/002/"
 
 
+
 [rule.threat.tactic]
 id = "TA0009"
 name = "Collection"
 reference = "https://attack.mitre.org/tactics/TA0009/"
+

rules/windows/collection_posh_audio_capture.toml

@@ -2,9 +2,7 @@
 creation_date = "2021/10/19"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/windows/collection_posh_clipboard_capture.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/01/12"
 integration = ["windows"]
 maturity = "production"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
-min_stack_version = "8.14.0"
-updated_date = "2024/10/28"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -80,7 +78,14 @@ reg add "hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLo
 ```
 """
 severity = "medium"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Collection", "Data Source: PowerShell Logs", "Resources: Investigation Guide"]
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Collection",
+    "Data Source: PowerShell Logs",
+    "Resources: Investigation Guide",
+]
 timestamp_override = "event.ingested"
 type = "query"
 
@@ -105,27 +110,28 @@ event.category:process and host.os.type:windows and
   )
 '''
 
+
 [[rule.filters]]
+
 [rule.filters.meta]
 negate = true
 [rule.filters.query.wildcard."file.path"]
-"case_insensitive" = true
-"value" = "?:\\\\program?files\\\\powershell\\\\?\\\\Modules\\\\*.psd1"
-
+case_insensitive = true
+value = "?:\\\\program?files\\\\powershell\\\\?\\\\Modules\\\\*.psd1"
 [[rule.filters]]
+
 [rule.filters.meta]
 negate = true
 [rule.filters.query.wildcard."file.path"]
-"case_insensitive" = true
-"value" = "?:\\\\Windows\\\\system32\\\\WindowsPowerShell\\\\v1.0\\\\Modules\\\\*.psd1"
-
+case_insensitive = true
+value = "?:\\\\Windows\\\\system32\\\\WindowsPowerShell\\\\v1.0\\\\Modules\\\\*.psd1"
 [[rule.filters]]
+
 [rule.filters.meta]
 negate = true
 [rule.filters.query.wildcard."file.path"]
-"case_insensitive" = true
-"value" = "?:\\\\Program?Files\\\\WindowsPowerShell\\\\Modules\\\\*.ps?1"
-
+case_insensitive = true
+value = "?:\\\\Program?Files\\\\WindowsPowerShell\\\\Modules\\\\*.ps?1"
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]

rules/windows/collection_posh_keylogger.toml

@@ -2,9 +2,7 @@
 creation_date = "2021/10/15"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/windows/collection_posh_mailbox.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/01/11"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/windows/collection_posh_screen_grabber.toml

@@ -2,9 +2,7 @@
 creation_date = "2021/10/19"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/windows/collection_posh_webcam_video_capture.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/07/18"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -17,6 +15,40 @@ index = ["winlogbeat-*", "logs-windows.powershell*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "PowerShell Script with Webcam Video Capture Capabilities"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 PowerShell Script with Webcam Video Capture Capabilities
+
+PowerShell, a powerful scripting language in Windows, can interface with system components like webcams for legitimate tasks such as video conferencing. However, adversaries exploit this by crafting scripts to covertly record video, infringing on privacy. The detection rule identifies suspicious script patterns and API calls linked to webcam access, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the PowerShell script block text associated with the alert to identify any suspicious patterns or API calls, such as "NewFrameEventHandler" or "VideoCaptureDevice".
+- Check the process execution details, including the parent process, to determine how the PowerShell script was initiated and if it was part of a legitimate application or task.
+- Investigate the user account under which the PowerShell script was executed to assess if the account has a history of suspicious activity or if it has been compromised.
+- Examine the host's recent activity logs for any other unusual behavior or alerts that might correlate with the webcam access attempt, such as unauthorized access attempts or data exfiltration.
+- Verify if the host has any legitimate applications that might use webcam access, and cross-reference with the script's behavior to rule out false positives.
+
+### False positive analysis
+
+- Legitimate video conferencing applications may trigger the detection rule due to their use of similar API calls and script patterns. Users can create exceptions for known and trusted applications by whitelisting their process names or script signatures.
+- Security testing tools that simulate webcam access for vulnerability assessments might be flagged. To handle this, users should exclude these tools from monitoring during scheduled testing periods.
+- System diagnostics or maintenance scripts that access webcam components for hardware checks can be mistaken for malicious activity. Users should document and exclude these scripts if they are part of routine system operations.
+- Educational or training software that uses webcam access for interactive sessions may be incorrectly identified. Users can mitigate this by adding these applications to an allowlist after verifying their legitimacy.
+- Custom scripts developed in-house for specific business needs that involve webcam access should be reviewed and, if deemed safe, excluded from the detection rule to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious PowerShell processes identified by the detection rule to stop ongoing webcam recording activities.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious scripts or software.
+- Review and revoke any unauthorized access permissions or credentials that may have been compromised during the incident.
+- Restore the system from a known good backup if any critical system files or configurations have been altered by the malicious script.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced monitoring and logging for PowerShell activities across the network to detect and respond to similar threats more effectively in the future."""
 references = [
     "https://github.com/EmpireProject/Empire/blob/master/lib/modules/powershell/collection/WebcamRecorder.py",
 ]
@@ -68,40 +100,6 @@ event.category:process and host.os.type:windows and
     )
   )
 '''
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 PowerShell Script with Webcam Video Capture Capabilities
-
-PowerShell, a powerful scripting language in Windows, can interface with system components like webcams for legitimate tasks such as video conferencing. However, adversaries exploit this by crafting scripts to covertly record video, infringing on privacy. The detection rule identifies suspicious script patterns and API calls linked to webcam access, flagging potential misuse for further investigation.
-
-### Possible investigation steps
-
-- Review the PowerShell script block text associated with the alert to identify any suspicious patterns or API calls, such as "NewFrameEventHandler" or "VideoCaptureDevice".
-- Check the process execution details, including the parent process, to determine how the PowerShell script was initiated and if it was part of a legitimate application or task.
-- Investigate the user account under which the PowerShell script was executed to assess if the account has a history of suspicious activity or if it has been compromised.
-- Examine the host's recent activity logs for any other unusual behavior or alerts that might correlate with the webcam access attempt, such as unauthorized access attempts or data exfiltration.
-- Verify if the host has any legitimate applications that might use webcam access, and cross-reference with the script's behavior to rule out false positives.
-
-### False positive analysis
-
-- Legitimate video conferencing applications may trigger the detection rule due to their use of similar API calls and script patterns. Users can create exceptions for known and trusted applications by whitelisting their process names or script signatures.
-- Security testing tools that simulate webcam access for vulnerability assessments might be flagged. To handle this, users should exclude these tools from monitoring during scheduled testing periods.
-- System diagnostics or maintenance scripts that access webcam components for hardware checks can be mistaken for malicious activity. Users should document and exclude these scripts if they are part of routine system operations.
-- Educational or training software that uses webcam access for interactive sessions may be incorrectly identified. Users can mitigate this by adding these applications to an allowlist after verifying their legitimacy.
-- Custom scripts developed in-house for specific business needs that involve webcam access should be reviewed and, if deemed safe, excluded from the detection rule to prevent unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Terminate any suspicious PowerShell processes identified by the detection rule to stop ongoing webcam recording activities.
-- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious scripts or software.
-- Review and revoke any unauthorized access permissions or credentials that may have been compromised during the incident.
-- Restore the system from a known good backup if any critical system files or configurations have been altered by the malicious script.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced monitoring and logging for PowerShell activities across the network to detect and respond to similar threats more effectively in the future."""
 
 
 [[rule.threat]]

rules/windows/collection_winrar_encryption.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/12/04"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/11/02"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -14,12 +12,12 @@ preparation for exfiltration.
 """
 from = "now-9m"
 index = [
-  "logs-endpoint.events.process-*",
-  "winlogbeat-*",
-  "logs-windows.sysmon_operational-*",
-  "endgame-*",
-  "logs-m365_defender.event-*",
-  "logs-sentinel_one_cloud_funnel.*"
+    "logs-endpoint.events.process-*",
+    "winlogbeat-*",
+    "logs-windows.sysmon_operational-*",
+    "endgame-*",
+    "logs-m365_defender.event-*",
+    "logs-sentinel_one_cloud_funnel.*",
 ]
 language = "eql"
 license = "Elastic License v2"
@@ -81,7 +79,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
-    "Data Source: SentinelOne"
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"

rules/windows/command_and_control_certreq_postdata.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/01/13"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]

rules/windows/command_and_control_dns_tunneling_nslookup.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/11/11"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/windows/command_and_control_encrypted_channel_freesslcert.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/11/04"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -17,6 +15,40 @@ index = ["winlogbeat-*", "logs-endpoint.events.network-*", "logs-windows.sysmon_
 language = "eql"
 license = "Elastic License v2"
 name = "Connection to Commonly Abused Free SSL Certificate Providers"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Connection to Commonly Abused Free SSL Certificate Providers
+
+Free SSL certificates, like those from Let's Encrypt, enable secure web traffic encryption. Adversaries exploit these to mask malicious command and control (C2) communications. The detection rule identifies unusual Windows processes accessing domains with such certificates, excluding common false positives, to flag potential misuse of encrypted channels for C2 activities.
+
+### Possible investigation steps
+
+- Review the process executable path to confirm if it is a native Windows process and assess the legitimacy of its network activity. Focus on paths like "C:\\Windows\\System32\\*.exe" and "C:\\Windows\\SysWOW64\\*.exe".
+- Investigate the specific domain accessed by the process, such as those ending in "*.letsencrypt.org" or "*.sslforfree.com", to determine if it is associated with known malicious activity or if it is a legitimate service.
+- Check the process name against the list of excluded false positives, ensuring it is not "svchost.exe", "MicrosoftEdge*.exe", or "msedge.exe", which are common and typically benign.
+- Analyze the network traffic associated with the process to identify any unusual patterns or anomalies that could indicate command and control activity.
+- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activities.
+
+### False positive analysis
+
+- Windows system processes like svchost.exe and MicrosoftEdge.exe are common false positives due to their legitimate network activities. These can be excluded from the detection rule to reduce noise.
+- Regularly update the list of excluded processes to include any new system processes that are verified to have legitimate reasons for accessing domains with free SSL certificates.
+- Monitor and analyze network traffic patterns to identify any additional processes that consistently generate false positives, and consider adding them to the exclusion list if they are deemed non-threatening.
+- Use process whitelisting to allow known safe applications that frequently access these domains, ensuring they do not trigger alerts unnecessarily.
+- Implement a review process to periodically reassess the exclusion list, ensuring it remains relevant and does not inadvertently allow malicious activities to go undetected.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious communication and potential lateral movement.
+- Terminate any suspicious processes identified in the alert that are not typically associated with network activity, such as those running from unusual paths or with unexpected network connections.
+- Conduct a thorough review of the system's recent activity logs to identify any unauthorized changes or additional indicators of compromise.
+- Remove any malicious files or executables found on the system, ensuring that all remnants of the threat are eradicated.
+- Restore the system from a known good backup if any critical system files or configurations have been altered.
+- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 risk_score = 21
 rule_id = "e3cf38fa-d5b8-46cc-87f9-4a7513e4281d"
 setup = """## Setup
@@ -56,40 +88,6 @@ network where host.os.type == "windows" and network.protocol == "dns" and
   /* Insert noisy false positives here */
   not process.name : ("svchost.exe", "MicrosoftEdge*.exe", "msedge.exe")
 '''
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Connection to Commonly Abused Free SSL Certificate Providers
-
-Free SSL certificates, like those from Let's Encrypt, enable secure web traffic encryption. Adversaries exploit these to mask malicious command and control (C2) communications. The detection rule identifies unusual Windows processes accessing domains with such certificates, excluding common false positives, to flag potential misuse of encrypted channels for C2 activities.
-
-### Possible investigation steps
-
-- Review the process executable path to confirm if it is a native Windows process and assess the legitimacy of its network activity. Focus on paths like "C:\\Windows\\System32\\*.exe" and "C:\\Windows\\SysWOW64\\*.exe".
-- Investigate the specific domain accessed by the process, such as those ending in "*.letsencrypt.org" or "*.sslforfree.com", to determine if it is associated with known malicious activity or if it is a legitimate service.
-- Check the process name against the list of excluded false positives, ensuring it is not "svchost.exe", "MicrosoftEdge*.exe", or "msedge.exe", which are common and typically benign.
-- Analyze the network traffic associated with the process to identify any unusual patterns or anomalies that could indicate command and control activity.
-- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activities.
-
-### False positive analysis
-
-- Windows system processes like svchost.exe and MicrosoftEdge.exe are common false positives due to their legitimate network activities. These can be excluded from the detection rule to reduce noise.
-- Regularly update the list of excluded processes to include any new system processes that are verified to have legitimate reasons for accessing domains with free SSL certificates.
-- Monitor and analyze network traffic patterns to identify any additional processes that consistently generate false positives, and consider adding them to the exclusion list if they are deemed non-threatening.
-- Use process whitelisting to allow known safe applications that frequently access these domains, ensuring they do not trigger alerts unnecessarily.
-- Implement a review process to periodically reassess the exclusion list, ensuring it remains relevant and does not inadvertently allow malicious activities to go undetected.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further malicious communication and potential lateral movement.
-- Terminate any suspicious processes identified in the alert that are not typically associated with network activity, such as those running from unusual paths or with unexpected network connections.
-- Conduct a thorough review of the system's recent activity logs to identify any unauthorized changes or additional indicators of compromise.
-- Remove any malicious files or executables found on the system, ensuring that all remnants of the threat are eradicated.
-- Restore the system from a known good backup if any critical system files or configurations have been altered.
-- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]

rules/windows/command_and_control_headless_browser.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/05/10"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/windows/command_and_control_new_terms_commonly_abused_rat_execution.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/04/03"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/windows/command_and_control_outlook_home_page.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/08/01"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -13,43 +11,17 @@ Identifies modifications in registry keys associated with abuse of the Outlook H
 control or persistence.
 """
 from = "now-9m"
-index = ["winlogbeat-*", "logs-endpoint.events.registry-*", "logs-windows.sysmon_operational-*", "endgame-*", "logs-m365_defender.event-*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "winlogbeat-*",
+    "logs-endpoint.events.registry-*",
+    "logs-windows.sysmon_operational-*",
+    "endgame-*",
+    "logs-m365_defender.event-*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Outlook Home Page Registry Modification"
-references = [
-    "https://cloud.google.com/blog/topics/threat-intelligence/breaking-the-rules-tough-outlook-for-home-page-attacks/",
-    "https://github.com/trustedsec/specula"
-]
-risk_score = 47
-rule_id = "ac5a2759-5c34-440a-b0c4-51fe674611d6"
-severity = "medium"
-tags = [
-    "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",
-]
-timestamp_override = "event.ingested"
-type = "eql"
-
-query = '''
-registry where host.os.type == "windows" and event.action != "deletion" and registry.value : "URL" and
-    registry.path : (
-        "HKCU\\*\\SOFTWARE\\Microsoft\\Office\\*\\Outlook\\Webview\\Inbox\\URL",
-        "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Office\\*\\Outlook\\Webview\\Inbox\\URL",
-        "HKU\\*\\SOFTWARE\\Microsoft\\Office\\*\\Outlook\\Webview\\Inbox\\URL",
-        "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Office\\*\\Outlook\\Webview\\Inbox\\URL",
-        "USER\\*\\SOFTWARE\\Microsoft\\Office\\*\\Outlook\\Webview\\Inbox\\URL"
-    ) and registry.data.strings : "*http*"
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -84,6 +56,39 @@ The Outlook Home Page feature allows users to set a webpage as the default view
 - Review and analyze network logs to identify any outbound connections to suspicious domains or IP addresses, and block these at the firewall.
 - Escalate the incident to the security operations center (SOC) for further investigation and to determine if other systems are affected.
 - Implement additional monitoring on the affected system and similar endpoints to detect any recurrence of the threat, focusing on registry changes and network activity."""
+references = [
+    "https://cloud.google.com/blog/topics/threat-intelligence/breaking-the-rules-tough-outlook-for-home-page-attacks/",
+    "https://github.com/trustedsec/specula",
+]
+risk_score = 47
+rule_id = "ac5a2759-5c34-440a-b0c4-51fe674611d6"
+severity = "medium"
+tags = [
+    "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",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+registry where host.os.type == "windows" and event.action != "deletion" and registry.value : "URL" and
+    registry.path : (
+        "HKCU\\*\\SOFTWARE\\Microsoft\\Office\\*\\Outlook\\Webview\\Inbox\\URL",
+        "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Office\\*\\Outlook\\Webview\\Inbox\\URL",
+        "HKU\\*\\SOFTWARE\\Microsoft\\Office\\*\\Outlook\\Webview\\Inbox\\URL",
+        "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Office\\*\\Outlook\\Webview\\Inbox\\URL",
+        "USER\\*\\SOFTWARE\\Microsoft\\Office\\*\\Outlook\\Webview\\Inbox\\URL"
+    ) and registry.data.strings : "*http*"
+'''
 
 
 [[rule.threat]]
@@ -93,7 +98,6 @@ framework = "MITRE ATT&CK"
 id = "TA0011"
 name = "Command and Control"
 reference = "https://attack.mitre.org/tactics/TA0011/"
-
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]

rules/windows/command_and_control_port_forwarding_added_registry.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/11/25"
 integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defender"]
 maturity = "production"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
-min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -13,7 +11,14 @@ Identifies the creation of a new port forwarding rule. An adversary may abuse th
 segmentation restrictions.
 """
 from = "now-9m"
-index = ["winlogbeat-*", "logs-endpoint.events.registry-*", "logs-windows.sysmon_operational-*", "endgame-*", "logs-sentinel_one_cloud_funnel.*", "logs-m365_defender.event-*"]
+index = [
+    "winlogbeat-*",
+    "logs-endpoint.events.registry-*",
+    "logs-windows.sysmon_operational-*",
+    "endgame-*",
+    "logs-sentinel_one_cloud_funnel.*",
+    "logs-m365_defender.event-*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Port Forwarding Rule Addition"
@@ -101,7 +106,6 @@ reference = "https://attack.mitre.org/techniques/T1572/"
 id = "TA0011"
 name = "Command and Control"
 reference = "https://attack.mitre.org/tactics/TA0011/"
-
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
@@ -109,6 +113,7 @@ id = "T1112"
 name = "Modify Registry"
 reference = "https://attack.mitre.org/techniques/T1112/"
 
+
 [rule.threat.tactic]
 id = "TA0005"
 name = "Defense Evasion"

rules/windows/command_and_control_rdp_tunnel_plink.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/10/14"
 integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defender", "system", "crowdstrike"]
 maturity = "production"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
-min_stack_version = "8.14.0"
-updated_date = "2025/02/21"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -103,7 +101,6 @@ reference = "https://attack.mitre.org/techniques/T1572/"
 id = "TA0011"
 name = "Command and Control"
 reference = "https://attack.mitre.org/tactics/TA0011/"
-
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
@@ -121,3 +118,4 @@ reference = "https://attack.mitre.org/techniques/T1021/004/"
 id = "TA0008"
 name = "Lateral Movement"
 reference = "https://attack.mitre.org/tactics/TA0008/"
+

rules/windows/command_and_control_remote_file_copy_desktopimgdownldr.toml

@@ -2,11 +2,40 @@
 creation_date = "2020/09/03"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [transform]
+[[transform.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"
+
+[[transform.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"
+
+[[transform.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" }
+  ]
+]
+
 [[transform.osquery]]
 label = "Osquery - Retrieve DNS Cache"
 query = "SELECT * FROM dns_cache"
@@ -31,37 +60,6 @@ services.path FROM services JOIN authenticode ON services.path = authenticode.pa
 authenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'
 """
 
-[[transform.investigate]]
-label = "Alerts associated with the user in the last 48h"
-relativeFrom = "now-48h/h"
-relativeTo = "now"
-providers = [
-    [
-        {field = "event.kind", excluded = false, queryType = "phrase", value = "signal", valueType = "string"},
-        {field = "user.id", excluded = false, queryType = "phrase", value = "{{user.id}}", valueType = "string"}
-    ]
-]
-
-[[transform.investigate]]
-label = "Alerts associated with the host in the last 48h"
-relativeFrom = "now-48h/h"
-relativeTo = "now"
-providers = [
-    [
-        {field = "event.kind", excluded = false, queryType = "phrase", value = "signal", valueType = "string"},
-        {field = "host.name", excluded = false, queryType = "phrase", value = "{{host.name}}", valueType = "string"},
-    ]
-]
-
-[[transform.investigate]]
-label = "Investigate the Subject Process Network Events"
-providers = [
-    [
-        {field = "process.entity_id", excluded = false, queryType = "phrase", value = "{{process.entity_id}}", valueType = "string"},
-        {field = "event.category", excluded = false, queryType = "phrase", value = "network", valueType = "string"}
-    ]
-]
-
 
 [rule]
 author = ["Elastic"]

rules/windows/command_and_control_remote_file_copy_mpcmdrun.toml

@@ -2,11 +2,40 @@
 creation_date = "2020/09/03"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [transform]
+[[transform.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"
+
+[[transform.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"
+
+[[transform.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" }
+  ]
+]
+
 [[transform.osquery]]
 label = "Osquery - Retrieve DNS Cache"
 query = "SELECT * FROM dns_cache"
@@ -31,37 +60,6 @@ services.path FROM services JOIN authenticode ON services.path = authenticode.pa
 authenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'
 """
 
-[[transform.investigate]]
-label = "Alerts associated with the user in the last 48h"
-relativeFrom = "now-48h/h"
-relativeTo = "now"
-providers = [
-    [
-        {field = "event.kind", excluded = false, queryType = "phrase", value = "signal", valueType = "string"},
-        {field = "user.id", excluded = false, queryType = "phrase", value = "{{user.id}}", valueType = "string"}
-    ]
-]
-
-[[transform.investigate]]
-label = "Alerts associated with the host in the last 48h"
-relativeFrom = "now-48h/h"
-relativeTo = "now"
-providers = [
-    [
-        {field = "event.kind", excluded = false, queryType = "phrase", value = "signal", valueType = "string"},
-        {field = "host.name", excluded = false, queryType = "phrase", value = "{{host.name}}", valueType = "string"}
-    ]
-]
-
-[[transform.investigate]]
-label = "Investigate the Subject Process Network Events"
-providers = [
-    [
-        {field = "process.entity_id", excluded = false, queryType = "phrase", value = "{{process.entity_id}}", valueType = "string"},
-        {field = "event.category", excluded = false, queryType = "phrase", value = "network", valueType = "string"}
-    ]
-]
-
 
 [rule]
 author = ["Elastic"]

rules/windows/command_and_control_remote_file_copy_scripts.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/11/29"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/02/03"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]

rules/windows/command_and_control_screenconnect_childproc.toml

@@ -2,15 +2,13 @@
 creation_date = "2024/03/27"
 integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defender", "system", "crowdstrike"]
 maturity = "production"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
-min_stack_version = "8.14.0"
-updated_date = "2025/02/21"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies suspicious processes being spawned by the ScreenConnect client processes. This activity may indicate execution
-abusing unauthorized access to the ScreenConnect remote access software.
+Identifies suspicious processes being spawned by the ScreenConnect client processes. This activity may indicate
+execution abusing unauthorized access to the ScreenConnect remote access software.
 """
 from = "now-9m"
 index = [
@@ -26,7 +24,44 @@ index = [
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious ScreenConnect Client Child Process"
-references = ["https://www.huntress.com/blog/slashandgrab-screen-connect-post-exploitation-in-the-wild-cve-2024-1709-cve-2024-1708"]
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 ScreenConnect Client Child Process
+
+ScreenConnect, a remote access tool, facilitates legitimate remote support but can be exploited by adversaries to execute unauthorized commands. Malicious actors may spawn processes like PowerShell or cmd.exe via ScreenConnect to perform harmful activities. The detection rule identifies such suspicious child processes, focusing on unusual arguments and process names, indicating potential abuse of remote access capabilities.
+
+### Possible investigation steps
+
+- Review the parent process name to confirm it is one of the ScreenConnect client processes listed in the query, such as ScreenConnect.ClientService.exe or ScreenConnect.WindowsClient.exe, to verify the source of the suspicious activity.
+- Examine the child process name and arguments, such as powershell.exe with encoded commands or cmd.exe with /c, to identify potentially malicious actions or commands being executed.
+- Check the network activity associated with the suspicious process, especially if the process arguments include network-related terms like *http* or *downloadstring*, to determine if there is any unauthorized data exfiltration or command and control communication.
+- Investigate the user account under which the suspicious process was executed to assess if the account has been compromised or is being misused.
+- Correlate the event with other security alerts or logs from data sources like Elastic Defend or Microsoft Defender for Endpoint to gather additional context and identify any related malicious activities.
+- Review the system's recent activity and changes, such as new scheduled tasks or services created by schtasks.exe or sc.exe, to identify any persistence mechanisms that may have been established by the attacker.
+
+### False positive analysis
+
+- Legitimate IT support activities using ScreenConnect may trigger the rule when executing scripts or commands for maintenance. To manage this, identify and whitelist specific IT support accounts or IP addresses that regularly perform these actions.
+- Automated scripts or scheduled tasks that use ScreenConnect for routine operations might be flagged. Review and document these scripts, then create exceptions for known benign processes and arguments.
+- Software updates or installations initiated through ScreenConnect can appear suspicious. Maintain a list of approved software and update processes, and exclude these from the rule.
+- Internal security tools or monitoring solutions that leverage ScreenConnect for legitimate purposes may be detected. Verify these tools and add them to an exclusion list to prevent false positives.
+- Training sessions or demonstrations using ScreenConnect to showcase command-line tools could be misinterpreted as threats. Ensure these sessions are logged and recognized as non-threatening, and adjust the rule to accommodate these scenarios.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
+- Terminate any suspicious processes identified in the alert, such as PowerShell, cmd.exe, or other flagged executables, to halt any ongoing malicious activity.
+- Review and revoke any unauthorized user accounts or privileges that may have been created or modified using tools like net.exe or schtasks.exe.
+- Conduct a thorough scan of the affected system using endpoint protection tools to identify and remove any malware or unauthorized software installed by the attacker.
+- Restore the system from a known good backup if any critical system files or configurations have been altered or compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring and logging for ScreenConnect and other remote access tools to detect similar activities in the future, ensuring that alerts are promptly reviewed and acted upon."""
+references = [
+    "https://www.huntress.com/blog/slashandgrab-screen-connect-post-exploitation-in-the-wild-cve-2024-1709-cve-2024-1708",
+]
 risk_score = 47
 rule_id = "78de1aeb-5225-4067-b8cc-f4a1de8a8546"
 severity = "medium"
@@ -68,41 +103,6 @@ process where host.os.type == "windows" and event.type == "start" and
                    "ssh.exe", "scp.exe", "wevtutil.exe", "wget.exe", "wmic.exe")
    )
 '''
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 ScreenConnect Client Child Process
-
-ScreenConnect, a remote access tool, facilitates legitimate remote support but can be exploited by adversaries to execute unauthorized commands. Malicious actors may spawn processes like PowerShell or cmd.exe via ScreenConnect to perform harmful activities. The detection rule identifies such suspicious child processes, focusing on unusual arguments and process names, indicating potential abuse of remote access capabilities.
-
-### Possible investigation steps
-
-- Review the parent process name to confirm it is one of the ScreenConnect client processes listed in the query, such as ScreenConnect.ClientService.exe or ScreenConnect.WindowsClient.exe, to verify the source of the suspicious activity.
-- Examine the child process name and arguments, such as powershell.exe with encoded commands or cmd.exe with /c, to identify potentially malicious actions or commands being executed.
-- Check the network activity associated with the suspicious process, especially if the process arguments include network-related terms like *http* or *downloadstring*, to determine if there is any unauthorized data exfiltration or command and control communication.
-- Investigate the user account under which the suspicious process was executed to assess if the account has been compromised or is being misused.
-- Correlate the event with other security alerts or logs from data sources like Elastic Defend or Microsoft Defender for Endpoint to gather additional context and identify any related malicious activities.
-- Review the system's recent activity and changes, such as new scheduled tasks or services created by schtasks.exe or sc.exe, to identify any persistence mechanisms that may have been established by the attacker.
-
-### False positive analysis
-
-- Legitimate IT support activities using ScreenConnect may trigger the rule when executing scripts or commands for maintenance. To manage this, identify and whitelist specific IT support accounts or IP addresses that regularly perform these actions.
-- Automated scripts or scheduled tasks that use ScreenConnect for routine operations might be flagged. Review and document these scripts, then create exceptions for known benign processes and arguments.
-- Software updates or installations initiated through ScreenConnect can appear suspicious. Maintain a list of approved software and update processes, and exclude these from the rule.
-- Internal security tools or monitoring solutions that leverage ScreenConnect for legitimate purposes may be detected. Verify these tools and add them to an exclusion list to prevent false positives.
-- Training sessions or demonstrations using ScreenConnect to showcase command-line tools could be misinterpreted as threats. Ensure these sessions are logged and recognized as non-threatening, and adjust the rule to accommodate these scenarios.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
-- Terminate any suspicious processes identified in the alert, such as PowerShell, cmd.exe, or other flagged executables, to halt any ongoing malicious activity.
-- Review and revoke any unauthorized user accounts or privileges that may have been created or modified using tools like net.exe or schtasks.exe.
-- Conduct a thorough scan of the affected system using endpoint protection tools to identify and remove any malware or unauthorized software installed by the attacker.
-- Restore the system from a known good backup if any critical system files or configurations have been altered or compromised.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
-- Implement enhanced monitoring and logging for ScreenConnect and other remote access tools to detect similar activities in the future, ensuring that alerts are promptly reviewed and acted upon."""
 
 
 [[rule.threat]]

rules/windows/command_and_control_tool_transfer_via_curl.toml

@@ -2,14 +2,13 @@
 creation_date = "2025/02/03"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/02/22"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies Curl for Windows making an HTTP request. Adversaries could abuse Curl to download files or upload data to a remote URL.
+Identifies Curl for Windows making an HTTP request. Adversaries could abuse Curl to download files or upload data to a
+remote URL.
 """
 from = "now-9m"
 index = [
@@ -118,4 +117,5 @@ reference = "https://attack.mitre.org/techniques/T1105/"
 [rule.threat.tactic]
 id = "TA0011"
 name = "Command and Control"
-reference = "https://attack.mitre.org/tactics/TA0011/"
+reference = "https://attack.mitre.org/tactics/TA0011/"
+

rules/windows/command_and_control_tunnel_vscode.toml

@@ -2,15 +2,13 @@
 creation_date = "2024/09/09"
 integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defender", "system", "crowdstrike"]
 maturity = "production"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
-min_stack_version = "8.14.0"
-updated_date = "2025/02/21"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
-Detects the execution of the VScode portable binary with the tunnel command line option indicating an
-attempt to establish a remote tunnel session to Github or a remote VScode instance.
+Detects the execution of the VScode portable binary with the tunnel command line option indicating an attempt to
+establish a remote tunnel session to Github or a remote VScode instance.
 """
 from = "now-9m"
 index = [
@@ -26,35 +24,6 @@ index = [
 language = "eql"
 license = "Elastic License v2"
 name = "Attempt to Establish VScode Remote Tunnel"
-references = [
-    "https://badoption.eu/blog/2023/01/31/code_c2.html",
-    "https://code.visualstudio.com/docs/remote/tunnels"
-]
-risk_score = 47
-rule_id = "0b96dfd8-5b8c-4485-9a1c-69ff7839786a"
-severity = "medium"
-tags = [
-    "Domain: Endpoint",
-    "OS: Windows",
-    "Use Case: Threat Detection",
-    "Tactic: Command and Control",
-    "Data Source: Elastic Endgame",
-    "Data Source: Elastic Defend",
-    "Data Source: Sysmon",
-    "Data Source: SentinelOne",
-    "Data Source: Microsoft Defender for Endpoint",
-    "Data Source: Windows Security Event Logs",
-    "Data Source: Crowdstrike",
-    "Resources: Investigation Guide",
-]
-timestamp_override = "event.ingested"
-type = "eql"
-
-query = '''
-process where host.os.type == "windows" and event.type == "start" and
-  process.args : "tunnel" and (process.args : "--accept-server-license-terms" or process.name : "code*.exe") and
-  not (process.name == "code-tunnel.exe" and process.args == "status" and process.parent.name == "Code.exe")
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -90,6 +59,35 @@ Visual Studio Code (VScode) offers a remote tunnel feature enabling developers t
 - Restore the system from a known good backup if any unauthorized changes or malware are detected.
 - Implement network segmentation to limit the ability of similar threats to spread across the environment.
 - Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
+references = [
+    "https://badoption.eu/blog/2023/01/31/code_c2.html",
+    "https://code.visualstudio.com/docs/remote/tunnels",
+]
+risk_score = 47
+rule_id = "0b96dfd8-5b8c-4485-9a1c-69ff7839786a"
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Command and Control",
+    "Data Source: Elastic Endgame",
+    "Data Source: Elastic Defend",
+    "Data Source: Sysmon",
+    "Data Source: SentinelOne",
+    "Data Source: Microsoft Defender for Endpoint",
+    "Data Source: Windows Security Event Logs",
+    "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "windows" and event.type == "start" and
+  process.args : "tunnel" and (process.args : "--accept-server-license-terms" or process.name : "code*.exe") and
+  not (process.name == "code-tunnel.exe" and process.args == "status" and process.parent.name == "Code.exe")
+'''
 
 
 [[rule.threat]]

rules/windows/credential_access_adidns_wildcard.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/03/26"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -21,6 +19,41 @@ index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential ADIDNS Poisoning via Wildcard Record Creation"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 ADIDNS Poisoning via Wildcard Record Creation
+
+Active Directory Integrated DNS (ADIDNS) is crucial for maintaining domain consistency by storing DNS zones as AD objects. However, its default permissions allow authenticated users to create DNS records, which adversaries can exploit by adding wildcard records. This enables them to redirect traffic and perform Man-in-the-Middle attacks. The detection rule identifies such abuse by monitoring specific directory service changes indicative of wildcard record creation.
+
+### 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.
+- Examine the ObjectDN field in the event data to identify the specific DNS zone where the wildcard record was created, ensuring it starts with "DC=*," to confirm the wildcard nature.
+- Check the user account associated with the event to determine if it is a legitimate account or potentially compromised, focusing on any unusual or unauthorized activity.
+- Investigate recent changes in the DNS zone to identify any other suspicious modifications or patterns that could indicate further malicious activity.
+- Correlate the event with network traffic logs to detect any unusual or redirected traffic patterns that could suggest a Man-in-the-Middle attack.
+- 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
+
+- Routine administrative changes to DNS records by IT staff can trigger alerts. To manage this, create exceptions for known administrative accounts or specific ObjectDN patterns that correspond to legitimate changes.
+- Automated systems or scripts that update DNS records as part of regular maintenance may cause false positives. Identify these systems and exclude their activity from triggering alerts by filtering based on their unique identifiers or event sources.
+- Software installations or updates that modify DNS settings might be flagged. Monitor and document these activities, and consider excluding them if they are part of a recognized and secure process.
+- Changes made by trusted third-party services that integrate with ADIDNS could be misinterpreted as threats. Verify these services and whitelist their actions to prevent unnecessary alerts.
+- Temporary testing environments that mimic production settings might generate alerts. Ensure these environments are clearly documented and excluded from monitoring if they are known to perform non-threatening wildcard record creations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or data exfiltration.
+- Revoke any potentially compromised credentials associated with the affected system or user accounts involved in the alert.
+- Conduct a thorough review of DNS records in the affected zone to identify and remove any unauthorized wildcard entries.
+- Implement stricter access controls on DNS record creation, limiting permissions to only necessary administrative accounts.
+- 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.
+- Update detection mechanisms to include additional indicators of compromise related to ADIDNS abuse, enhancing future threat detection capabilities."""
 references = [
     "https://www.netspi.com/blog/technical/network-penetration-testing/exploiting-adidns/",
     "https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications/adidns-spoofing",
@@ -67,41 +100,6 @@ query = '''
 any where host.os.type == "windows" and event.code == "5137" and
     startsWith(winlog.event_data.ObjectDN, "DC=*,")
 '''
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 ADIDNS Poisoning via Wildcard Record Creation
-
-Active Directory Integrated DNS (ADIDNS) is crucial for maintaining domain consistency by storing DNS zones as AD objects. However, its default permissions allow authenticated users to create DNS records, which adversaries can exploit by adding wildcard records. This enables them to redirect traffic and perform Man-in-the-Middle attacks. The detection rule identifies such abuse by monitoring specific directory service changes indicative of wildcard record creation.
-
-### 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.
-- Examine the ObjectDN field in the event data to identify the specific DNS zone where the wildcard record was created, ensuring it starts with "DC=*," to confirm the wildcard nature.
-- Check the user account associated with the event to determine if it is a legitimate account or potentially compromised, focusing on any unusual or unauthorized activity.
-- Investigate recent changes in the DNS zone to identify any other suspicious modifications or patterns that could indicate further malicious activity.
-- Correlate the event with network traffic logs to detect any unusual or redirected traffic patterns that could suggest a Man-in-the-Middle attack.
-- 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
-
-- Routine administrative changes to DNS records by IT staff can trigger alerts. To manage this, create exceptions for known administrative accounts or specific ObjectDN patterns that correspond to legitimate changes.
-- Automated systems or scripts that update DNS records as part of regular maintenance may cause false positives. Identify these systems and exclude their activity from triggering alerts by filtering based on their unique identifiers or event sources.
-- Software installations or updates that modify DNS settings might be flagged. Monitor and document these activities, and consider excluding them if they are part of a recognized and secure process.
-- Changes made by trusted third-party services that integrate with ADIDNS could be misinterpreted as threats. Verify these services and whitelist their actions to prevent unnecessary alerts.
-- Temporary testing environments that mimic production settings might generate alerts. Ensure these environments are clearly documented and excluded from monitoring if they are known to perform non-threatening wildcard record creations.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation or data exfiltration.
-- Revoke any potentially compromised credentials associated with the affected system or user accounts involved in the alert.
-- Conduct a thorough review of DNS records in the affected zone to identify and remove any unauthorized wildcard entries.
-- Implement stricter access controls on DNS record creation, limiting permissions to only necessary administrative accounts.
-- 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.
-- Update detection mechanisms to include additional indicators of compromise related to ADIDNS abuse, enhancing future threat detection capabilities."""
 
 
 [[rule.threat]]

rules/windows/credential_access_adidns_wpad_record.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/06/03"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -18,6 +16,41 @@ index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential WPAD Spoofing via DNS Record Creation"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 WPAD Spoofing via DNS Record Creation
+
+Web Proxy Auto-Discovery (WPAD) helps devices automatically detect proxy settings, crucial for network efficiency. However, attackers can exploit WPAD by creating malicious DNS records, tricking systems into using rogue proxies for data interception. The detection rule identifies suspicious DNS record changes, specifically targeting WPAD entries, to flag potential spoofing attempts, aiding in early threat detection and mitigation.
+
+### Possible investigation steps
+
+- Review the event logs for the specific event code "5137" to identify the creation or modification of the "wpad" DNS record. Focus on the details provided in the winlog.event_data.ObjectDN field to confirm the presence of "DC=wpad,*".
+- Check the Active Directory change history to determine who made the changes to the DNS records and whether these changes were authorized.
+- Investigate the user account associated with the directory service change event to assess if it has been compromised or if there are any signs of unauthorized access.
+- Analyze network traffic to and from the "wpad" DNS record to identify any suspicious activity or connections to rogue proxy servers.
+- Verify the configuration of the Global Query Block List (GQBL) to ensure it has not been disabled or altered, which could allow unauthorized WPAD entries.
+- Cross-reference the alert with other security logs and alerts to identify any related suspicious activities or patterns that could indicate a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate network changes may trigger alerts if a new WPAD DNS record is created intentionally for network configuration. Verify with network administrators if such changes were planned.
+- Automated scripts or software updates that modify DNS records can cause false positives. Review the source of the change and consider excluding known benign scripts or update processes.
+- Test environments often simulate DNS changes, including WPAD entries, for development purposes. Exclude these environments from monitoring if they are known to generate non-threatening alerts.
+- Some organizations may have legacy systems that rely on WPAD configurations. Document these systems and create exceptions for their DNS changes to avoid unnecessary alerts.
+- Regular audits of the Global Query Block List settings can help identify and exclude expected changes, reducing false positives related to WPAD record creation.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further data interception or lateral movement by the rogue proxy.
+- Verify and restore the integrity of the DNS records by removing any unauthorized "wpad" entries and re-enabling the Global Query Block List (GQBL) if it was disabled.
+- Conduct a thorough review of Active Directory logs to identify any unauthorized changes or suspicious activities related to directory service modifications.
+- Reset credentials for any accounts that may have been compromised or accessed during the incident to prevent unauthorized access.
+- Implement network segmentation to limit the exposure of critical systems to potential WPAD spoofing attacks.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems or data were affected.
+- Update and enhance monitoring rules to detect similar WPAD spoofing attempts in the future, ensuring timely alerts and responses."""
 references = [
     "https://www.thehacker.recipes/ad/movement/mitm-and-coerced-authentications/wpad-spoofing#through-adidns-spoofing",
     "https://cube0x0.github.io/Pocing-Beyond-DA/",
@@ -63,41 +96,6 @@ type = "eql"
 query = '''
 any where host.os.type == "windows" and event.code == "5137" and winlog.event_data.ObjectDN : "DC=wpad,*"
 '''
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 WPAD Spoofing via DNS Record Creation
-
-Web Proxy Auto-Discovery (WPAD) helps devices automatically detect proxy settings, crucial for network efficiency. However, attackers can exploit WPAD by creating malicious DNS records, tricking systems into using rogue proxies for data interception. The detection rule identifies suspicious DNS record changes, specifically targeting WPAD entries, to flag potential spoofing attempts, aiding in early threat detection and mitigation.
-
-### Possible investigation steps
-
-- Review the event logs for the specific event code "5137" to identify the creation or modification of the "wpad" DNS record. Focus on the details provided in the winlog.event_data.ObjectDN field to confirm the presence of "DC=wpad,*".
-- Check the Active Directory change history to determine who made the changes to the DNS records and whether these changes were authorized.
-- Investigate the user account associated with the directory service change event to assess if it has been compromised or if there are any signs of unauthorized access.
-- Analyze network traffic to and from the "wpad" DNS record to identify any suspicious activity or connections to rogue proxy servers.
-- Verify the configuration of the Global Query Block List (GQBL) to ensure it has not been disabled or altered, which could allow unauthorized WPAD entries.
-- Cross-reference the alert with other security logs and alerts to identify any related suspicious activities or patterns that could indicate a broader attack campaign.
-
-### False positive analysis
-
-- Legitimate network changes may trigger alerts if a new WPAD DNS record is created intentionally for network configuration. Verify with network administrators if such changes were planned.
-- Automated scripts or software updates that modify DNS records can cause false positives. Review the source of the change and consider excluding known benign scripts or update processes.
-- Test environments often simulate DNS changes, including WPAD entries, for development purposes. Exclude these environments from monitoring if they are known to generate non-threatening alerts.
-- Some organizations may have legacy systems that rely on WPAD configurations. Document these systems and create exceptions for their DNS changes to avoid unnecessary alerts.
-- Regular audits of the Global Query Block List settings can help identify and exclude expected changes, reducing false positives related to WPAD record creation.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further data interception or lateral movement by the rogue proxy.
-- Verify and restore the integrity of the DNS records by removing any unauthorized "wpad" entries and re-enabling the Global Query Block List (GQBL) if it was disabled.
-- Conduct a thorough review of Active Directory logs to identify any unauthorized changes or suspicious activities related to directory service modifications.
-- Reset credentials for any accounts that may have been compromised or accessed during the incident to prevent unauthorized access.
-- Implement network segmentation to limit the exposure of critical systems to potential WPAD spoofing attacks.
-- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems or data were affected.
-- Update and enhance monitoring rules to detect similar WPAD spoofing attempts in the future, ensuring timely alerts and responses."""
 
 
 [[rule.threat]]

rules/windows/credential_access_bruteforce_admin_account.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/08/29"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]

rules/windows/credential_access_bruteforce_multiple_logon_failure_followed_by_success.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/08/29"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]

rules/windows/credential_access_bruteforce_multiple_logon_failure_same_srcip.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/08/29"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]

rules/windows/credential_access_cmdline_dump_tool.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/11/24"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "system"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/windows/credential_access_copy_ntds_sam_volshadowcp_cmdline.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/11/24"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]

rules/windows/credential_access_credential_dumping_msbuild.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/02/03"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]

rules/windows/credential_access_dcsync_newterm_subjectuser.toml

@@ -2,9 +2,7 @@
 creation_date = "2022/12/19"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/windows/credential_access_dcsync_replication_rights.toml

@@ -2,9 +2,7 @@
 creation_date = "2022/02/08"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/windows/credential_access_dcsync_user_backdoor.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/07/10"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -75,12 +73,21 @@ references = [
     "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"
+    "https://learn.microsoft.com/en-us/windows/win32/adschema/r-ds-replication-get-changes-in-filtered-set",
 ]
 risk_score = 47
 rule_id = "f8822053-a5d2-46db-8c96-d460b12c36ac"
 severity = "medium"
-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"]
+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",
+]
 timestamp_override = "event.ingested"
 type = "query"
 
@@ -96,22 +103,22 @@ event.code:"5136" and
   )
 '''
 
+
 [[rule.threat]]
 framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1003"
+name = "OS Credential Dumping"
+reference = "https://attack.mitre.org/techniques/T1003/"
+[[rule.threat.technique.subtechnique]]
+id = "T1003.006"
+name = "DCSync"
+reference = "https://attack.mitre.org/techniques/T1003/006/"
 
-  [[rule.threat.technique]]
-  id = "T1003"
-  reference = "https://attack.mitre.org/techniques/T1003/"
-  name = "OS Credential Dumping"
-
-    [[rule.threat.technique.subtechnique]]
-    id = "T1003.006"
-    reference = "https://attack.mitre.org/techniques/T1003/006/"
-    name = "DCSync"
 
 
 [rule.threat.tactic]
 id = "TA0006"
-reference = "https://attack.mitre.org/tactics/TA0006/"
 name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
 

rules/windows/credential_access_disable_kerberos_preauth.toml

@@ -2,9 +2,7 @@
 creation_date = "2022/01/24"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/windows/credential_access_dnsnode_creation.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/03/26"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -21,6 +19,41 @@ index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Creation of a DNS-Named Record"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Creation of a DNS-Named Record
+
+Active Directory Integrated DNS (ADIDNS) is crucial for maintaining domain consistency by storing DNS zones as AD objects. However, its default permissions can be exploited by attackers to create DNS records for spoofing attacks, targeting services like WPAD. The detection rule identifies such abuse by monitoring specific Windows events related to DNS record creation, filtering out legitimate system accounts to highlight potential threats.
+
+### Possible investigation steps
+
+- Review the event logs for event code 5137 to identify the specific DNS-named record that was created and the associated timestamp.
+- Examine the winlog.event_data.SubjectUserName field to determine the user account that initiated the DNS record creation, ensuring it is not a system account.
+- Investigate the context around the winlog.event_data.ObjectClass field to confirm the object class is "dnsNode" and assess if the DNS record creation aligns with expected administrative activities.
+- Check for any recent LLMNR/NBT-NS requests or network traffic that might indicate an attempt to exploit the newly created DNS record for spoofing purposes.
+- Correlate the alert with other security events or logs to identify any patterns or anomalies that might suggest malicious intent or unauthorized access attempts.
+- Assess the risk and impact of the DNS record creation by determining if it targets critical services like WPAD or other sensitive systems within the network.
+
+### False positive analysis
+
+- Legitimate administrative actions may trigger the rule when DNS records are created or modified by IT staff. To manage this, create exceptions for known administrative accounts that regularly perform these tasks.
+- Automated system processes or scripts that update DNS records can also cause false positives. Identify these processes and exclude their associated accounts from the rule to prevent unnecessary alerts.
+- Service accounts used by legitimate applications to dynamically update DNS records might be flagged. Review these accounts and add them to an exception list if they are verified as non-threatening.
+- Temporary network changes or testing environments where DNS records are frequently modified can lead to false positives. Consider excluding these environments or specific IP ranges from the rule to reduce noise.
+- Regularly review and update the exception list to ensure it reflects current network and administrative practices, minimizing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious DNS record creation and potential spoofing attacks.
+- Review and remove any unauthorized DNS records created by non-system accounts, focusing on those targeting services like WPAD.
+- Reset credentials for any accounts that were potentially compromised or used in the attack to prevent further unauthorized access.
+- Implement stricter access controls on DNS record creation within Active Directory to limit permissions to only necessary and trusted accounts.
+- Monitor for any further suspicious DNS record creation events, particularly those involving non-system accounts, to detect and respond to potential follow-up attacks.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or services were affected.
+- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures to prevent similar incidents in the future."""
 references = [
     "https://www.netspi.com/blog/technical/network-penetration-testing/adidns-revisited/",
     "https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications/wpad-spoofing",
@@ -67,41 +100,6 @@ query = '''
 any where host.os.type == "windows" and event.code == "5137" and winlog.event_data.ObjectClass == "dnsNode" and
     not winlog.event_data.SubjectUserName : "*$"
 '''
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Creation of a DNS-Named Record
-
-Active Directory Integrated DNS (ADIDNS) is crucial for maintaining domain consistency by storing DNS zones as AD objects. However, its default permissions can be exploited by attackers to create DNS records for spoofing attacks, targeting services like WPAD. The detection rule identifies such abuse by monitoring specific Windows events related to DNS record creation, filtering out legitimate system accounts to highlight potential threats.
-
-### Possible investigation steps
-
-- Review the event logs for event code 5137 to identify the specific DNS-named record that was created and the associated timestamp.
-- Examine the winlog.event_data.SubjectUserName field to determine the user account that initiated the DNS record creation, ensuring it is not a system account.
-- Investigate the context around the winlog.event_data.ObjectClass field to confirm the object class is "dnsNode" and assess if the DNS record creation aligns with expected administrative activities.
-- Check for any recent LLMNR/NBT-NS requests or network traffic that might indicate an attempt to exploit the newly created DNS record for spoofing purposes.
-- Correlate the alert with other security events or logs to identify any patterns or anomalies that might suggest malicious intent or unauthorized access attempts.
-- Assess the risk and impact of the DNS record creation by determining if it targets critical services like WPAD or other sensitive systems within the network.
-
-### False positive analysis
-
-- Legitimate administrative actions may trigger the rule when DNS records are created or modified by IT staff. To manage this, create exceptions for known administrative accounts that regularly perform these tasks.
-- Automated system processes or scripts that update DNS records can also cause false positives. Identify these processes and exclude their associated accounts from the rule to prevent unnecessary alerts.
-- Service accounts used by legitimate applications to dynamically update DNS records might be flagged. Review these accounts and add them to an exception list if they are verified as non-threatening.
-- Temporary network changes or testing environments where DNS records are frequently modified can lead to false positives. Consider excluding these environments or specific IP ranges from the rule to reduce noise.
-- Regularly review and update the exception list to ensure it reflects current network and administrative practices, minimizing the risk of overlooking genuine threats.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious DNS record creation and potential spoofing attacks.
-- Review and remove any unauthorized DNS records created by non-system accounts, focusing on those targeting services like WPAD.
-- Reset credentials for any accounts that were potentially compromised or used in the attack to prevent further unauthorized access.
-- Implement stricter access controls on DNS record creation within Active Directory to limit permissions to only necessary and trusted accounts.
-- Monitor for any further suspicious DNS record creation events, particularly those involving non-system accounts, to detect and respond to potential follow-up attacks.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or services were affected.
-- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures to prevent similar incidents in the future."""
 
 
 [[rule.threat]]

rules/windows/credential_access_dollar_account_relay.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/07/24"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -18,39 +16,6 @@ index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Relay Attack against a Domain Controller"
-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/",
-]
-risk_score = 21
-rule_id = "263481c8-1e9b-492e-912d-d1760707f810"
-severity = "low"
-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",
-]
-timestamp_override = "event.ingested"
-type = "eql"
-
-query = '''
-authentication where host.os.type == "windows" and event.code in ("4624", "4625") and endswith~(user.name, "$") and
-    winlog.event_data.AuthenticationPackageName : "NTLM" and winlog.logon.type : "network" and
-
-    /* Filter for a machine account that matches the hostname */
-    startswith~(host.name, substring(user.name, 0, -1)) and
-
-    /* Verify if the Source IP belongs to the host */
-    not endswith(string(source.ip), string(host.ip)) and
-    source.ip != null and source.ip != "::1" and source.ip != "127.0.0.1"
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -86,6 +51,39 @@ Domain Controllers (DCs) are critical in managing authentication within Windows
 - 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.
 - Deploy additional monitoring and detection mechanisms to identify similar relay attack patterns in the future, enhancing the detection capabilities for NTLM relay attacks.
 - Conduct a post-incident review to identify any gaps in security controls and update policies or procedures to prevent recurrence, ensuring lessons learned are applied to improve overall security posture."""
+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/",
+]
+risk_score = 21
+rule_id = "263481c8-1e9b-492e-912d-d1760707f810"
+severity = "low"
+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",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+authentication where host.os.type == "windows" and event.code in ("4624", "4625") and endswith~(user.name, "$") and
+    winlog.event_data.AuthenticationPackageName : "NTLM" and winlog.logon.type : "network" and
+
+    /* Filter for a machine account that matches the hostname */
+    startswith~(host.name, substring(user.name, 0, -1)) and
+
+    /* Verify if the Source IP belongs to the host */
+    not endswith(string(source.ip), string(host.ip)) and
+    source.ip != null and source.ip != "::1" and source.ip != "127.0.0.1"
+'''
 
 
 [[rule.threat]]
@@ -105,6 +103,7 @@ name = "LLMNR/NBT-NS Poisoning and SMB Relay"
 reference = "https://attack.mitre.org/techniques/T1557/001/"
 
 
+
 [rule.threat.tactic]
 id = "TA0006"
 name = "Credential Access"

rules/windows/credential_access_domain_backup_dpapi_private_keys.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/08/13"
 integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defender", "crowdstrike"]
 maturity = "production"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
-min_stack_version = "8.14.0"
-updated_date = "2025/01/15"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -13,7 +11,15 @@ Identifies the creation or modification of Domain Backup private keys. Adversari
 (DPAPI) domain backup key from a Domain Controller (DC) to be able to decrypt any domain user master key file.
 """
 from = "now-9m"
-index = ["winlogbeat-*", "logs-endpoint.events.file-*", "logs-windows.sysmon_operational-*", "endgame-*", "logs-sentinel_one_cloud_funnel.*", "logs-m365_defender.event-*", "logs-crowdstrike.fdr*"]
+index = [
+    "winlogbeat-*",
+    "logs-endpoint.events.file-*",
+    "logs-windows.sysmon_operational-*",
+    "endgame-*",
+    "logs-sentinel_one_cloud_funnel.*",
+    "logs-m365_defender.event-*",
+    "logs-crowdstrike.fdr*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Creation or Modification of Domain Backup DPAPI private key"
@@ -28,7 +34,19 @@ references = [
 risk_score = 73
 rule_id = "b83a7e96-2eb3-4edf-8346-427b6858d3bd"
 severity = "high"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Credential Access", "Data Source: Elastic Endgame", "Data Source: Elastic Defend", "Data Source: Sysmon", "Data Source: SentinelOne", "Data Source: Microsoft Defender for Endpoint", "Data Source: Crowdstrike", "Resources: Investigation Guide"]
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Data Source: Elastic Endgame",
+    "Data Source: Elastic Defend",
+    "Data Source: Sysmon",
+    "Data Source: SentinelOne",
+    "Data Source: Microsoft Defender for Endpoint",
+    "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
+]
 timestamp_override = "event.ingested"
 type = "eql"
 

rules/windows/credential_access_dump_registry_hives.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/11/23"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/windows/credential_access_generic_localdumps.toml

@@ -2,9 +2,7 @@
 creation_date = "2022/08/28"
 integration = ["endpoint", "windows", "m365_defender"]
 maturity = "production"
-updated_date = "2025/01/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -16,41 +14,16 @@ the credentials present on the system without having to bring malware to the sys
 default, and applications must create their registry subkeys to hold settings that enable them to collect dumps.
 """
 from = "now-9m"
-index = ["winlogbeat-*", "logs-endpoint.events.registry-*", "logs-windows.sysmon_operational-*", "endgame-*", "logs-m365_defender.event-*"]
+index = [
+    "winlogbeat-*",
+    "logs-endpoint.events.registry-*",
+    "logs-windows.sysmon_operational-*",
+    "endgame-*",
+    "logs-m365_defender.event-*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Full User-Mode Dumps Enabled System-Wide"
-references = [
-    "https://docs.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps",
-    "https://github.com/deepinstinct/Lsass-Shtinkering",
-    "https://media.defcon.org/DEF%20CON%2030/DEF%20CON%2030%20presentations/Asaf%20Gilboa%20-%20LSASS%20Shtinkering%20Abusing%20Windows%20Error%20Reporting%20to%20Dump%20LSASS.pdf",
-]
-risk_score = 47
-rule_id = "220be143-5c67-4fdb-b6ce-dd6826d024fd"
-severity = "medium"
-tags = [
-    "Domain: Endpoint",
-    "OS: Windows",
-    "Use Case: Threat Detection",
-    "Tactic: Credential Access",
-    "Data Source: Elastic Defend",
-    "Data Source: Elastic Endgame",
-    "Data Source: Sysmon",
-    "Data Source: Microsoft Defender for Endpoint",
-    "Resources: Investigation Guide",
-]
-timestamp_override = "event.ingested"
-type = "eql"
-
-query = '''
-registry where host.os.type == "windows" and
-    registry.path : (
-        "HKLM\\SOFTWARE\\Microsoft\\Windows\\Windows Error Reporting\\LocalDumps\\DumpType",
-        "\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows\\Windows Error Reporting\\LocalDumps\\DumpType"
-    ) and
-    registry.data.strings : ("2", "0x00000002") and
-    not (process.executable : "?:\\Windows\\system32\\svchost.exe" and user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20"))
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -85,6 +58,37 @@ Full user-mode dumps are a diagnostic feature in Windows that captures detailed
 - Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
 - Implement enhanced monitoring and alerting for similar registry changes across the network to detect and respond to future attempts promptly.
 - Review and update endpoint protection configurations to ensure they are capable of detecting and blocking similar credential dumping techniques."""
+references = [
+    "https://docs.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps",
+    "https://github.com/deepinstinct/Lsass-Shtinkering",
+    "https://media.defcon.org/DEF%20CON%2030/DEF%20CON%2030%20presentations/Asaf%20Gilboa%20-%20LSASS%20Shtinkering%20Abusing%20Windows%20Error%20Reporting%20to%20Dump%20LSASS.pdf",
+]
+risk_score = 47
+rule_id = "220be143-5c67-4fdb-b6ce-dd6826d024fd"
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Data Source: Elastic Defend",
+    "Data Source: Elastic Endgame",
+    "Data Source: Sysmon",
+    "Data Source: Microsoft Defender for Endpoint",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+registry where host.os.type == "windows" and
+    registry.path : (
+        "HKLM\\SOFTWARE\\Microsoft\\Windows\\Windows Error Reporting\\LocalDumps\\DumpType",
+        "\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows\\Windows Error Reporting\\LocalDumps\\DumpType"
+    ) and
+    registry.data.strings : ("2", "0x00000002") and
+    not (process.executable : "?:\\Windows\\system32\\svchost.exe" and user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20"))
+'''
 
 
 [[rule.threat]]

rules/windows/credential_access_iis_connectionstrings_dumping.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -29,35 +27,6 @@ language = "eql"
 license = "Elastic License v2"
 max_signals = 33
 name = "Microsoft IIS Connection Strings Decryption"
-references = [
-    "https://blog.netspi.com/decrypting-iis-passwords-to-break-out-of-the-dmz-part-1/",
-    "https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/greenbug-espionage-telco-south-asia",
-]
-risk_score = 73
-rule_id = "c25e9c87-95e1-4368-bfab-9fd34cf867ec"
-severity = "high"
-tags = [
-    "Domain: Endpoint",
-    "OS: Windows",
-    "Use Case: Threat Detection",
-    "Tactic: Credential Access",
-    "Data Source: Elastic Endgame",
-    "Data Source: Elastic Defend",
-    "Data Source: Windows Security Event Logs",
-    "Data Source: Microsoft Defender for Endpoint",
-    "Data Source: Sysmon",
-    "Data Source: SentinelOne",
-    "Data Source: Crowdstrike",
-    "Resources: Investigation Guide",
-]
-timestamp_override = "event.ingested"
-type = "eql"
-
-query = '''
-process where host.os.type == "windows" and event.type == "start" and
-  (process.name : "aspnet_regiis.exe" or ?process.pe.original_file_name == "aspnet_regiis.exe") and
-  process.args : "connectionStrings" and process.args : "-pdf"
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -93,6 +62,35 @@ Microsoft IIS often stores sensitive connection strings in encrypted form to sec
 - Restore the IIS server from a known good backup taken before the compromise, ensuring that any webshells or malicious scripts are removed.
 - Implement enhanced monitoring and alerting for any future unauthorized use of aspnet_regiis.exe, focusing on the specific arguments used in the detection query.
 - Escalate the incident to the security operations center (SOC) or relevant incident response team for further investigation and to assess the broader impact on the organization."""
+references = [
+    "https://blog.netspi.com/decrypting-iis-passwords-to-break-out-of-the-dmz-part-1/",
+    "https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/greenbug-espionage-telco-south-asia",
+]
+risk_score = 73
+rule_id = "c25e9c87-95e1-4368-bfab-9fd34cf867ec"
+severity = "high"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Data Source: Elastic Endgame",
+    "Data Source: Elastic Defend",
+    "Data Source: Windows Security Event Logs",
+    "Data Source: Microsoft Defender for Endpoint",
+    "Data Source: Sysmon",
+    "Data Source: SentinelOne",
+    "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "windows" and event.type == "start" and
+  (process.name : "aspnet_regiis.exe" or ?process.pe.original_file_name == "aspnet_regiis.exe") and
+  process.args : "connectionStrings" and process.args : "-pdf"
+'''
 
 
 [[rule.threat]]

rules/windows/credential_access_imageload_azureadconnectauthsvc.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/10/14"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/02/14"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic", "Matteo Potito Giorgio"]
@@ -17,43 +15,6 @@ index = ["winlogbeat-*", "logs-endpoint.events.library-*", "logs-windows.sysmon_
 language = "eql"
 license = "Elastic License v2"
 name = "Untrusted DLL Loaded by Azure AD Sync Service"
-references = [
-"https://blog.xpnsec.com/azuread-connect-for-redteam/",
-"https://medium.com/@breakingmhet/detect-azure-pass-through-authentication-abuse-azure-hybrid-environments-ed4274784252",
-"https://learn.microsoft.com/en-us/azure/active-directory/hybrid/tshoot-connect-pass-through-authentication"
-]
-risk_score = 73
-rule_id = "f909075d-afc7-42d7-b399-600b94352fd9"
-severity = "high"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Credential Access", "Data Source: Elastic Defend", "Data Source: Sysmon", "Resources: Investigation Guide"]
-timestamp_override = "event.ingested"
-type = "eql"
-
-query = '''
-any where host.os.type == "windows" and process.name : "AzureADConnectAuthenticationAgentService.exe" and
-(
- (event.category == "library" and event.action == "load") or
- (event.category == "process" and event.action : "Image loaded*")
-) and
-
-not (?dll.code_signature.trusted == true or file.code_signature.status == "Valid") and not
-
-  (
-   /* Elastic defend DLL path */
-   ?dll.path :
-         ("?:\\Windows\\assembly\\NativeImages*",
-          "?:\\Windows\\Microsoft.NET\\*",
-          "?:\\Windows\\WinSxS\\*",
-          "?:\\Windows\\System32\\DriverStore\\FileRepository\\*") or
-
-   /* Sysmon DLL path is mapped to file.path */
-   file.path :
-         ("?:\\Windows\\assembly\\NativeImages*",
-          "?:\\Windows\\Microsoft.NET\\*",
-          "?:\\Windows\\WinSxS\\*",
-          "?:\\Windows\\System32\\DriverStore\\FileRepository\\*")
-  )
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -89,6 +50,51 @@ Azure AD Sync Service facilitates identity synchronization between on-premises d
 - Change all credentials that may have been exposed or compromised, focusing on those related to Azure AD and on-premises directory services.
 - Implement application whitelisting to prevent unauthorized DLLs from being loaded by critical processes like Azure AD Sync.
 - Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected."""
+references = [
+    "https://blog.xpnsec.com/azuread-connect-for-redteam/",
+    "https://medium.com/@breakingmhet/detect-azure-pass-through-authentication-abuse-azure-hybrid-environments-ed4274784252",
+    "https://learn.microsoft.com/en-us/azure/active-directory/hybrid/tshoot-connect-pass-through-authentication",
+]
+risk_score = 73
+rule_id = "f909075d-afc7-42d7-b399-600b94352fd9"
+severity = "high"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Data Source: Elastic Defend",
+    "Data Source: Sysmon",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+any where host.os.type == "windows" and process.name : "AzureADConnectAuthenticationAgentService.exe" and
+(
+ (event.category == "library" and event.action == "load") or
+ (event.category == "process" and event.action : "Image loaded*")
+) and
+
+not (?dll.code_signature.trusted == true or file.code_signature.status == "Valid") and not
+
+  (
+   /* Elastic defend DLL path */
+   ?dll.path :
+         ("?:\\Windows\\assembly\\NativeImages*",
+          "?:\\Windows\\Microsoft.NET\\*",
+          "?:\\Windows\\WinSxS\\*",
+          "?:\\Windows\\System32\\DriverStore\\FileRepository\\*") or
+
+   /* Sysmon DLL path is mapped to file.path */
+   file.path :
+         ("?:\\Windows\\assembly\\NativeImages*",
+          "?:\\Windows\\Microsoft.NET\\*",
+          "?:\\Windows\\WinSxS\\*",
+          "?:\\Windows\\System32\\DriverStore\\FileRepository\\*")
+  )
+'''
 
 
 [[rule.threat]]
@@ -103,3 +109,4 @@ reference = "https://attack.mitre.org/techniques/T1003/"
 id = "TA0006"
 name = "Credential Access"
 reference = "https://attack.mitre.org/tactics/TA0006/"
+

rules/windows/credential_access_kirbi_file.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defender", "crowdstrike"]
 maturity = "production"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
-min_stack_version = "8.14.0"
-updated_date = "2025/01/15"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -14,20 +12,18 @@ Kerberos ticket dump utilities, such as Mimikatz, and precedes attacks such as P
 attacker to impersonate users using Kerberos tickets.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.file-*", "logs-windows.sysmon_operational-*", "logs-sentinel_one_cloud_funnel.*", "logs-m365_defender.event-*", "winlogbeat-*", "endgame-*", "logs-crowdstrike.fdr*"]
+index = [
+    "logs-endpoint.events.file-*",
+    "logs-windows.sysmon_operational-*",
+    "logs-sentinel_one_cloud_funnel.*",
+    "logs-m365_defender.event-*",
+    "winlogbeat-*",
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Kirbi File Creation"
-risk_score = 73
-rule_id = "b8f8da2d-a9dc-48c0-90e4-955c0aa1259a"
-severity = "high"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Credential Access", "Data Source: Elastic Defend", "Data Source: Sysmon", "Data Source: SentinelOne", "Data Source: Microsoft Defender for Endpoint", "Data Source: Elastic Endgame", "Data Source: Crowdstrike", "Resources: Investigation Guide"]
-timestamp_override = "event.ingested"
-type = "eql"
-
-query = '''
-file where host.os.type == "windows" and event.type == "creation" and file.extension : "kirbi"
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -63,6 +59,28 @@ Kirbi files are associated with Kerberos, a network authentication protocol used
 - Revoke all active Kerberos tickets and force re-authentication for all users to ensure that any stolen tickets are rendered useless.
 - 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 enhanced monitoring and logging for Kerberos-related activities to detect and respond to similar threats more effectively in the future."""
+risk_score = 73
+rule_id = "b8f8da2d-a9dc-48c0-90e4-955c0aa1259a"
+severity = "high"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Data Source: Elastic Defend",
+    "Data Source: Sysmon",
+    "Data Source: SentinelOne",
+    "Data Source: Microsoft Defender for Endpoint",
+    "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+file where host.os.type == "windows" and event.type == "creation" and file.extension : "kirbi"
+'''
 
 
 [[rule.threat]]
@@ -78,7 +96,6 @@ name = "Steal or Forge Kerberos Tickets"
 reference = "https://attack.mitre.org/techniques/T1558/"
 
 
-
 [rule.threat.tactic]
 id = "TA0006"
 name = "Credential Access"

rules/windows/credential_access_ldap_attributes.toml

@@ -2,9 +2,7 @@
 creation_date = "2022/11/09"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -17,6 +15,41 @@ index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Access to a Sensitive LDAP Attribute"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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."""
 references = [
     "https://www.mandiant.com/resources/blog/apt29-windows-credential-roaming",
     "https://social.technet.microsoft.com/wiki/contents/articles/11483.windows-credential-roaming.aspx",
@@ -81,41 +114,6 @@ any where event.code == "4662" and
    */
   not winlog.event_data.AccessMask in ("0x0", "0x100")
 '''
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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."""
 
 
 [[rule.threat]]

rules/windows/credential_access_lsass_handle_via_malseclogon.toml

@@ -2,9 +2,7 @@
 creation_date = "2022/06/29"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -18,39 +16,6 @@ index = ["winlogbeat-*", "logs-windows.sysmon_operational-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious LSASS Access via MalSecLogon"
-references = ["https://splintercod3.blogspot.com/p/the-hidden-side-of-seclogon-part-3.html"]
-risk_score = 73
-rule_id = "7ba58110-ae13-439b-8192-357b0fcfa9d7"
-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
-"""
-severity = "high"
-tags = [
-    "Domain: Endpoint",
-    "OS: Windows",
-    "Use Case: Threat Detection",
-    "Tactic: Credential Access",
-    "Data Source: Sysmon",
-    "Resources: Investigation Guide",
-]
-timestamp_override = "event.ingested"
-type = "eql"
-
-query = '''
-process where host.os.type == "windows" and event.code == "10" and
-  winlog.event_data.TargetImage : "?:\\WINDOWS\\system32\\lsass.exe" and
-
-   /* seclogon service accessing lsass */
-  winlog.event_data.CallTrace : "*seclogon.dll*" and process.name : "svchost.exe" and
-
-   /* PROCESS_CREATE_PROCESS & PROCESS_DUP_HANDLE & PROCESS_QUERY_INFORMATION */
-  winlog.event_data.GrantedAccess == "0x14c0"
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -85,6 +50,39 @@ The Local Security Authority Subsystem Service (LSASS) is crucial for managing s
 - Collect and preserve relevant logs and forensic data from the affected system for further analysis and potential legal action.
 - 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.
 - Implement additional monitoring and alerting for similar suspicious activities involving LSASS and seclogon.dll to enhance detection capabilities."""
+references = ["https://splintercod3.blogspot.com/p/the-hidden-side-of-seclogon-part-3.html"]
+risk_score = 73
+rule_id = "7ba58110-ae13-439b-8192-357b0fcfa9d7"
+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
+"""
+severity = "high"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Data Source: Sysmon",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "windows" and event.code == "10" and
+  winlog.event_data.TargetImage : "?:\\WINDOWS\\system32\\lsass.exe" and
+
+   /* seclogon service accessing lsass */
+  winlog.event_data.CallTrace : "*seclogon.dll*" and process.name : "svchost.exe" and
+
+   /* PROCESS_CREATE_PROCESS & PROCESS_DUP_HANDLE & PROCESS_QUERY_INFORMATION */
+  winlog.event_data.GrantedAccess == "0x14c0"
+'''
 
 
 [[rule.threat]]

rules/windows/credential_access_lsass_memdump_file_created.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/11/24"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/02/03"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]
@@ -40,7 +38,14 @@ indicate a credential access attempt via trusted system utilities such as Task M
 (sqldumper.exe) or known pentesting tools such as Dumpert and AndrewSpecial.
 """
 from = "now-9m"
-index = ["winlogbeat-*", "logs-endpoint.events.file-*", "logs-windows.sysmon_operational-*", "endgame-*", "logs-m365_defender.event-*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "winlogbeat-*",
+    "logs-endpoint.events.file-*",
+    "logs-windows.sysmon_operational-*",
+    "endgame-*",
+    "logs-m365_defender.event-*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "LSASS Memory Dump Creation"

rules/windows/credential_access_lsass_memdump_handle_access.toml

@@ -2,9 +2,7 @@
 creation_date = "2022/02/16"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]

rules/windows/credential_access_mimikatz_memssp_default_logs.toml

@@ -2,15 +2,20 @@
 creation_date = "2020/08/31"
 integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defender"]
 maturity = "production"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
-min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = "Identifies the password log file from the default Mimikatz memssp module."
 from = "now-9m"
-index = ["winlogbeat-*", "logs-endpoint.events.file-*", "logs-windows.sysmon_operational-*", "endgame-*", "logs-sentinel_one_cloud_funnel.*", "logs-m365_defender.event-*"]
+index = [
+    "winlogbeat-*",
+    "logs-endpoint.events.file-*",
+    "logs-windows.sysmon_operational-*",
+    "endgame-*",
+    "logs-sentinel_one_cloud_funnel.*",
+    "logs-m365_defender.event-*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Mimikatz Memssp Log File Detected"

rules/windows/credential_access_mimikatz_powershell_module.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/17"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/windows/credential_access_mod_wdigest_security_provider.toml

@@ -2,9 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint", "windows", "m365_defender"]
 maturity = "production"
-updated_date = "2024/10/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -15,7 +13,13 @@ an endpoint. Once the UseLogonCredential value is modified, the adversary may at
 memory.
 """
 from = "now-9m"
-index = ["winlogbeat-*", "logs-endpoint.events.registry-*", "logs-windows.sysmon_operational-*", "endgame-*", "logs-m365_defender.event-*"]
+index = [
+    "winlogbeat-*",
+    "logs-endpoint.events.registry-*",
+    "logs-windows.sysmon_operational-*",
+    "endgame-*",
+    "logs-m365_defender.event-*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Modification of WDigest Security Provider"

rules/windows/credential_access_persistence_network_logon_provider_modification.toml

@@ -2,9 +2,7 @@
 creation_date = "2021/03/18"
 integration = ["endpoint", "m365_defender", "windows"]
 maturity = "production"
-updated_date = "2025/02/03"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]
@@ -41,7 +39,13 @@ during user logon.
 """
 false_positives = ["Authorized third party network logon providers."]
 from = "now-9m"
-index = ["logs-endpoint.events.registry-*", "endgame-*", "logs-windows.sysmon_operational-*", "winlogbeat-*", "logs-m365_defender.event-*"]
+index = [
+    "logs-endpoint.events.registry-*",
+    "endgame-*",
+    "logs-windows.sysmon_operational-*",
+    "winlogbeat-*",
+    "logs-m365_defender.event-*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Network Logon Provider Registry Modification"

rules/windows/credential_access_posh_invoke_ninjacopy.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/01/23"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/windows/credential_access_posh_kerb_ticket_dump.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/07/26"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/windows/credential_access_posh_minidump.toml

@@ -2,9 +2,7 @@
 creation_date = "2021/10/05"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/windows/credential_access_posh_relay_tools.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/03/27"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/10"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -17,6 +15,41 @@ index = ["winlogbeat-*", "logs-windows.powershell*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Potential PowerShell Pass-the-Hash/Relay Script"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Potential PowerShell Pass-the-Hash/Relay Script
+
+PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell to perform pass-the-hash attacks, where they use stolen hashed credentials to authenticate without knowing the actual password. The detection rule identifies scripts attempting to execute such attacks by monitoring for specific NTLM negotiation patterns and hex sequences indicative of credential relay activities, while excluding legitimate system processes.
+
+### Possible investigation steps
+
+- Review the PowerShell script block text associated with the alert to identify any suspicious patterns or hex sequences, such as "NTLMSSPNegotiate" or specific hex values like "4E544C4D53535000".
+- Check the process execution details, including the parent process and command line arguments, to determine if the script was executed by a legitimate user or process.
+- Investigate the source and destination IP addresses involved in the NTLM negotiation to identify any unusual or unauthorized network activity.
+- Examine the user account associated with the process to verify if it has been compromised or if there are any signs of unauthorized access.
+- Correlate the alert with other security events or logs, such as Windows Event Logs or network traffic logs, to gather additional context and identify potential lateral movement or further compromise.
+- Assess the file directory from which the script was executed, ensuring it is not a known safe location like "C:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Downloads", which is excluded in the query.
+
+### False positive analysis
+
+- Legitimate system processes may occasionally trigger the rule if they perform operations that mimic NTLM negotiation patterns. To manage this, users can create exceptions for specific processes known to be safe by excluding their file paths or hashes.
+- Security tools or network monitoring solutions that perform NTLM authentication checks might generate false positives. Users should identify these tools and exclude their associated scripts or directories from the detection rule.
+- Automated scripts for system administration that involve NTLM authentication could be flagged. Review these scripts and, if verified as safe, add them to an exclusion list based on their directory or script block text.
+- PowerShell scripts used for legitimate penetration testing or security assessments may trigger alerts. Ensure these activities are documented and exclude the relevant scripts or directories during the testing period.
+- Regular updates or patches from Microsoft might include scripts that temporarily match the detection criteria. Monitor updates and adjust exclusions as necessary to prevent false positives from these legitimate updates.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further credential relay or unauthorized access.
+- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing malicious activities.
+- Conduct a thorough review of recent authentication logs and network traffic from the isolated system to identify any lateral movement or additional compromised accounts.
+- Reset passwords for any accounts suspected to be compromised, ensuring that new credentials are not reused or easily guessable.
+- Apply patches and updates to the affected system and any other vulnerable systems to mitigate known exploits used in pass-the-hash attacks.
+- Implement network segmentation to limit the spread of similar attacks in the future, focusing on restricting access to critical systems and sensitive data.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 references = [
     "https://github.com/Kevin-Robertson/Invoke-TheHash/blob/master/Invoke-WMIExec.ps1",
     "https://github.com/Kevin-Robertson/Invoke-TheHash/blob/master/Invoke-SMBExec.ps1",
@@ -68,41 +101,6 @@ event.category:process and host.os.type:windows and
   ) and
   not file.directory : "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Downloads"
 '''
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
-
-### Investigating Potential PowerShell Pass-the-Hash/Relay Script
-
-PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell to perform pass-the-hash attacks, where they use stolen hashed credentials to authenticate without knowing the actual password. The detection rule identifies scripts attempting to execute such attacks by monitoring for specific NTLM negotiation patterns and hex sequences indicative of credential relay activities, while excluding legitimate system processes.
-
-### Possible investigation steps
-
-- Review the PowerShell script block text associated with the alert to identify any suspicious patterns or hex sequences, such as "NTLMSSPNegotiate" or specific hex values like "4E544C4D53535000".
-- Check the process execution details, including the parent process and command line arguments, to determine if the script was executed by a legitimate user or process.
-- Investigate the source and destination IP addresses involved in the NTLM negotiation to identify any unusual or unauthorized network activity.
-- Examine the user account associated with the process to verify if it has been compromised or if there are any signs of unauthorized access.
-- Correlate the alert with other security events or logs, such as Windows Event Logs or network traffic logs, to gather additional context and identify potential lateral movement or further compromise.
-- Assess the file directory from which the script was executed, ensuring it is not a known safe location like "C:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Downloads", which is excluded in the query.
-
-### False positive analysis
-
-- Legitimate system processes may occasionally trigger the rule if they perform operations that mimic NTLM negotiation patterns. To manage this, users can create exceptions for specific processes known to be safe by excluding their file paths or hashes.
-- Security tools or network monitoring solutions that perform NTLM authentication checks might generate false positives. Users should identify these tools and exclude their associated scripts or directories from the detection rule.
-- Automated scripts for system administration that involve NTLM authentication could be flagged. Review these scripts and, if verified as safe, add them to an exclusion list based on their directory or script block text.
-- PowerShell scripts used for legitimate penetration testing or security assessments may trigger alerts. Ensure these activities are documented and exclude the relevant scripts or directories during the testing period.
-- Regular updates or patches from Microsoft might include scripts that temporarily match the detection criteria. Monitor updates and adjust exclusions as necessary to prevent false positives from these legitimate updates.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further credential relay or unauthorized access.
-- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing malicious activities.
-- Conduct a thorough review of recent authentication logs and network traffic from the isolated system to identify any lateral movement or additional compromised accounts.
-- Reset passwords for any accounts suspected to be compromised, ensuring that new credentials are not reused or easily guessable.
-- Apply patches and updates to the affected system and any other vulnerable systems to mitigate known exploits used in pass-the-hash attacks.
-- Implement network segmentation to limit the spread of similar attacks in the future, focusing on restricting access to critical systems and sensitive data.
-- 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.threat]]

rules/windows/credential_access_posh_request_ticket.toml

@@ -2,9 +2,7 @@
 creation_date = "2022/01/24"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/windows/credential_access_posh_veeam_sql.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/03/14"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -17,6 +15,40 @@ index = ["winlogbeat-*", "logs-windows.powershell*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "PowerShell Script with Veeam Credential Access Capabilities"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 PowerShell Script with Veeam Credential Access Capabilities
+
+PowerShell, a powerful scripting language in Windows environments, can be exploited by attackers to access and decrypt sensitive credentials, such as those stored by Veeam in MSSQL databases. Adversaries may leverage this to compromise backup data, facilitating ransomware attacks. The detection rule identifies suspicious script activity by monitoring specific database interactions and decryption attempts, flagging potential credential access threats.
+
+### Possible investigation steps
+
+- Review the PowerShell script block text associated with the alert to identify any references to "[dbo].[Credentials]" and "Veeam" or "VeeamBackup" to confirm potential credential access attempts.
+- Check the event logs for the specific host where the alert was triggered to gather additional context about the process execution, including the user account involved and the script's origin.
+- Investigate any recent changes or access to the MSSQL database containing Veeam credentials to determine if there were unauthorized access attempts or modifications.
+- Analyze the use of "ProtectedStorage]::GetLocalString" within the script to understand if it was used to decrypt or access sensitive information.
+- Correlate the alert with other security events or logs from the same host or network segment to identify any related suspicious activities or patterns that could indicate a broader attack.
+
+### False positive analysis
+
+- Routine administrative scripts that query MSSQL databases for maintenance purposes may trigger the rule. To manage this, identify and whitelist specific scripts or processes that are known to be safe and regularly executed by trusted administrators.
+- Scheduled tasks or automated backup verification processes that access Veeam credentials for legitimate reasons can be mistaken for malicious activity. Exclude these tasks by specifying their unique identifiers or execution paths in the monitoring system.
+- Security audits or compliance checks that involve accessing credential information for validation purposes might be flagged. Coordinate with the audit team to document these activities and create exceptions for their scripts.
+- Development or testing environments where PowerShell scripts are used to simulate credential access for testing purposes can generate false positives. Implement environment-specific exclusions to prevent these from being flagged in production monitoring.
+- Third-party monitoring tools that interact with Veeam credentials for health checks or performance monitoring may inadvertently trigger alerts. Work with the tool vendors to understand their access patterns and exclude them if they are verified as non-threatening.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing credential access attempts.
+- Change all Veeam-related credentials and any other potentially compromised credentials stored in the MSSQL database to prevent further unauthorized access.
+- Conduct a thorough review of backup integrity and ensure that no unauthorized modifications or deletions have occurred.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring for PowerShell activity and MSSQL database access to detect similar threats in the future.
+- Review and update access controls and permissions for Veeam and MSSQL databases to ensure they follow the principle of least privilege."""
 references = [
     "https://forums.veeam.com/veeam-backup-replication-f2/recover-esxi-password-in-veeam-t34630.html",
     "https://www.crowdstrike.com/blog/anatomy-of-alpha-spider-ransomware/",
@@ -63,40 +95,6 @@ event.category:process and host.os.type:windows and
     "ProtectedStorage]::GetLocalString"
   )
 '''
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 PowerShell Script with Veeam Credential Access Capabilities
-
-PowerShell, a powerful scripting language in Windows environments, can be exploited by attackers to access and decrypt sensitive credentials, such as those stored by Veeam in MSSQL databases. Adversaries may leverage this to compromise backup data, facilitating ransomware attacks. The detection rule identifies suspicious script activity by monitoring specific database interactions and decryption attempts, flagging potential credential access threats.
-
-### Possible investigation steps
-
-- Review the PowerShell script block text associated with the alert to identify any references to "[dbo].[Credentials]" and "Veeam" or "VeeamBackup" to confirm potential credential access attempts.
-- Check the event logs for the specific host where the alert was triggered to gather additional context about the process execution, including the user account involved and the script's origin.
-- Investigate any recent changes or access to the MSSQL database containing Veeam credentials to determine if there were unauthorized access attempts or modifications.
-- Analyze the use of "ProtectedStorage]::GetLocalString" within the script to understand if it was used to decrypt or access sensitive information.
-- Correlate the alert with other security events or logs from the same host or network segment to identify any related suspicious activities or patterns that could indicate a broader attack.
-
-### False positive analysis
-
-- Routine administrative scripts that query MSSQL databases for maintenance purposes may trigger the rule. To manage this, identify and whitelist specific scripts or processes that are known to be safe and regularly executed by trusted administrators.
-- Scheduled tasks or automated backup verification processes that access Veeam credentials for legitimate reasons can be mistaken for malicious activity. Exclude these tasks by specifying their unique identifiers or execution paths in the monitoring system.
-- Security audits or compliance checks that involve accessing credential information for validation purposes might be flagged. Coordinate with the audit team to document these activities and create exceptions for their scripts.
-- Development or testing environments where PowerShell scripts are used to simulate credential access for testing purposes can generate false positives. Implement environment-specific exclusions to prevent these from being flagged in production monitoring.
-- Third-party monitoring tools that interact with Veeam credentials for health checks or performance monitoring may inadvertently trigger alerts. Work with the tool vendors to understand their access patterns and exclude them if they are verified as non-threatening.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing credential access attempts.
-- Change all Veeam-related credentials and any other potentially compromised credentials stored in the MSSQL database to prevent further unauthorized access.
-- Conduct a thorough review of backup integrity and ensure that no unauthorized modifications or deletions have occurred.
-- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected.
-- Implement enhanced monitoring for PowerShell activity and MSSQL database access to detect similar threats in the future.
-- Review and update access controls and permissions for Veeam and MSSQL databases to ensure they follow the principle of least privilege."""
 
 
 [[rule.threat]]

rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml

@@ -2,9 +2,7 @@
 creation_date = "2021/09/27"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -17,38 +15,6 @@ index = ["winlogbeat-*", "logs-windows.sysmon_operational-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Credential Access via DuplicateHandle in LSASS"
-references = ["https://github.com/CCob/MirrorDump"]
-risk_score = 47
-rule_id = "02a4576a-7480-4284-9327-548a806b5e48"
-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
-"""
-severity = "medium"
-tags = [
-    "Domain: Endpoint",
-    "OS: Windows",
-    "Use Case: Threat Detection",
-    "Tactic: Credential Access",
-    "Data Source: Sysmon",
-    "Resources: Investigation Guide",
-]
-timestamp_override = "event.ingested"
-type = "eql"
-
-query = '''
-process where host.os.type == "windows" and event.code == "10" and
-
- /* LSASS requesting DuplicateHandle access right to another process */
- process.name : "lsass.exe" and winlog.event_data.GrantedAccess == "0x40" and
-
- /* call is coming from an unknown executable region */
- winlog.event_data.CallTrace : "*UNKNOWN*"
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -83,6 +49,38 @@ The Local Security Authority Subsystem Service (LSASS) is crucial for enforcing
 - Review and update endpoint protection configurations to ensure they are capable of detecting and blocking similar unauthorized access attempts in the future.
 - Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
 - Implement enhanced monitoring and logging for LSASS and related processes to detect any future attempts to exploit the DuplicateHandle function."""
+references = ["https://github.com/CCob/MirrorDump"]
+risk_score = 47
+rule_id = "02a4576a-7480-4284-9327-548a806b5e48"
+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
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Data Source: Sysmon",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "windows" and event.code == "10" and
+
+ /* LSASS requesting DuplicateHandle access right to another process */
+ process.name : "lsass.exe" and winlog.event_data.GrantedAccess == "0x40" and
+
+ /* call is coming from an unknown executable region */
+ winlog.event_data.CallTrace : "*UNKNOWN*"
+'''
 
 
 [[rule.threat]]

rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml

@@ -2,9 +2,7 @@
 creation_date = "2022/04/30"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -27,6 +25,41 @@ index = [
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Local NTLM Relay via HTTP"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Local NTLM Relay via HTTP
+
+NTLM, a suite of Microsoft security protocols, is often targeted by adversaries for credential theft. Attackers may exploit the Windows Printer Spooler service to coerce NTLM authentication over HTTP, potentially elevating privileges. The detection rule identifies suspicious rundll32.exe executions invoking WebDAV client DLLs with specific arguments, signaling attempts to access named pipes via HTTP, indicative of NTLM relay attacks.
+
+### Possible investigation steps
+
+- Review the process execution details for rundll32.exe, focusing on the specific arguments related to davclnt.dll and DavSetCookie, to confirm the presence of suspicious WebDAV client activity.
+- Investigate the network connections initiated by the rundll32.exe process to identify any HTTP requests targeting named pipes, such as those containing "/print/pipe/", "/pipe/spoolss", or "/pipe/srvsvc".
+- Check the system's event logs for any related authentication attempts or failures around the time of the alert to identify potential NTLM relay activity.
+- Analyze the history of the Windows Printer Spooler service on the affected host to determine if it has been recently manipulated or exploited.
+- Correlate the alert with other security events or alerts from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related suspicious activities or patterns.
+- Assess the user account associated with the NTLM authentication attempt to determine if it has been compromised or is being used in an unauthorized manner.
+
+### False positive analysis
+
+- Legitimate administrative tasks using rundll32.exe with WebDAV client DLLs may trigger the rule. Review the context of the execution, such as the user account and the timing, to determine if it aligns with expected administrative activities.
+- Automated software deployment or update processes might use similar rundll32.exe calls. Verify if the process is part of a scheduled or known deployment task and consider excluding these specific processes from the rule.
+- Some third-party applications may use WebDAV for legitimate purposes, which could mimic the behavior detected by the rule. Identify these applications and create exceptions for their known processes to prevent false alerts.
+- System maintenance scripts or tools that interact with network resources via HTTP might inadvertently match the rule's criteria. Ensure these scripts are documented and exclude them if they are verified as non-threatening.
+- Regularly review and update the exclusion list to accommodate changes in legitimate software behavior, ensuring that only verified false positives are excluded to maintain the rule's effectiveness.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious rundll32.exe processes identified in the alert to stop ongoing malicious activity.
+- Conduct a thorough review of the affected system's event logs and network traffic to identify any additional indicators of compromise or related malicious activity.
+- Reset credentials for any accounts that may have been exposed or compromised during the attack to prevent unauthorized access.
+- Apply the latest security patches and updates to the Windows Printer Spooler service and related components to mitigate known vulnerabilities.
+- Implement network segmentation to limit the exposure of critical services and reduce the risk of similar attacks 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."""
 references = [
     "https://github.com/med0x2e/NTLMRelay2Self",
     "https://github.com/topotam/PetitPotam",
@@ -63,41 +96,6 @@ process where host.os.type == "windows" and event.type == "start" and
   /* Access to named pipe via http */
   process.args : ("http*/print/pipe/*", "http*/pipe/spoolss", "http*/pipe/srvsvc")
 '''
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Local NTLM Relay via HTTP
-
-NTLM, a suite of Microsoft security protocols, is often targeted by adversaries for credential theft. Attackers may exploit the Windows Printer Spooler service to coerce NTLM authentication over HTTP, potentially elevating privileges. The detection rule identifies suspicious rundll32.exe executions invoking WebDAV client DLLs with specific arguments, signaling attempts to access named pipes via HTTP, indicative of NTLM relay attacks.
-
-### Possible investigation steps
-
-- Review the process execution details for rundll32.exe, focusing on the specific arguments related to davclnt.dll and DavSetCookie, to confirm the presence of suspicious WebDAV client activity.
-- Investigate the network connections initiated by the rundll32.exe process to identify any HTTP requests targeting named pipes, such as those containing "/print/pipe/", "/pipe/spoolss", or "/pipe/srvsvc".
-- Check the system's event logs for any related authentication attempts or failures around the time of the alert to identify potential NTLM relay activity.
-- Analyze the history of the Windows Printer Spooler service on the affected host to determine if it has been recently manipulated or exploited.
-- Correlate the alert with other security events or alerts from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related suspicious activities or patterns.
-- Assess the user account associated with the NTLM authentication attempt to determine if it has been compromised or is being used in an unauthorized manner.
-
-### False positive analysis
-
-- Legitimate administrative tasks using rundll32.exe with WebDAV client DLLs may trigger the rule. Review the context of the execution, such as the user account and the timing, to determine if it aligns with expected administrative activities.
-- Automated software deployment or update processes might use similar rundll32.exe calls. Verify if the process is part of a scheduled or known deployment task and consider excluding these specific processes from the rule.
-- Some third-party applications may use WebDAV for legitimate purposes, which could mimic the behavior detected by the rule. Identify these applications and create exceptions for their known processes to prevent false alerts.
-- System maintenance scripts or tools that interact with network resources via HTTP might inadvertently match the rule's criteria. Ensure these scripts are documented and exclude them if they are verified as non-threatening.
-- Regularly review and update the exclusion list to accommodate changes in legitimate software behavior, ensuring that only verified false positives are excluded to maintain the rule's effectiveness.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Terminate any suspicious rundll32.exe processes identified in the alert to stop ongoing malicious activity.
-- Conduct a thorough review of the affected system's event logs and network traffic to identify any additional indicators of compromise or related malicious activity.
-- Reset credentials for any accounts that may have been exposed or compromised during the attack to prevent unauthorized access.
-- Apply the latest security patches and updates to the Windows Printer Spooler service and related components to mitigate known vulnerabilities.
-- Implement network segmentation to limit the exposure of critical services and reduce the risk of similar attacks 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.threat]]

rules/windows/credential_access_saved_creds_vault_winlog.toml

@@ -2,9 +2,7 @@
 creation_date = "2022/08/30"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -18,38 +16,6 @@ index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Multiple Vault Web Credentials Read"
-references = [
-    "https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=5382",
-    "https://www.elastic.co/security-labs/detect-credential-access",
-]
-risk_score = 47
-rule_id = "44fc462c-1159-4fa8-b1b7-9b6296ab4f96"
-severity = "medium"
-tags = [
-    "Domain: Endpoint",
-    "OS: Windows",
-    "Use Case: Threat Detection",
-    "Tactic: Credential Access",
-    "Data Source: Windows Security Event Logs",
-    "Resources: Investigation Guide",
-]
-type = "eql"
-
-query = '''
-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
-  (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
-  (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/"]
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -85,6 +51,38 @@ Windows Credential Manager stores credentials for web logins, apps, and networks
 - 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."""
+references = [
+    "https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=5382",
+    "https://www.elastic.co/security-labs/detect-credential-access",
+]
+risk_score = 47
+rule_id = "44fc462c-1159-4fa8-b1b7-9b6296ab4f96"
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Data Source: Windows Security Event Logs",
+    "Resources: Investigation Guide",
+]
+type = "eql"
+
+query = '''
+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
+  (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
+  (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/"]
+'''
 
 
 [[rule.threat]]

rules/windows/credential_access_saved_creds_vaultcmd.toml

@@ -2,9 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "system", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -28,36 +26,6 @@ index = [
 language = "eql"
 license = "Elastic License v2"
 name = "Searching for Saved Credentials via VaultCmd"
-references = [
-    "https://medium.com/threatpunter/detecting-adversary-tradecraft-with-image-load-event-logging-and-eql-8de93338c16",
-    "https://web.archive.org/web/20201004080456/https://rastamouse.me/blog/rdp-jump-boxes/",
-    "https://www.elastic.co/security-labs/detect-credential-access",
-]
-risk_score = 47
-rule_id = "be8afaed-4bcd-4e0a-b5f9-5562003dde81"
-severity = "medium"
-tags = [
-    "Domain: Endpoint",
-    "OS: Windows",
-    "Use Case: Threat Detection",
-    "Tactic: Credential Access",
-    "Data Source: Elastic Endgame",
-    "Data Source: Elastic Defend",
-    "Data Source: Windows Security Event Logs",
-    "Data Source: Microsoft Defender for Endpoint",
-    "Data Source: Sysmon",
-    "Data Source: SentinelOne",
-    "Data Source: Crowdstrike",
-    "Resources: Investigation Guide",
-]
-timestamp_override = "event.ingested"
-type = "eql"
-
-query = '''
-process where host.os.type == "windows" and event.type == "start" and
-  (?process.pe.original_file_name:"vaultcmd.exe" or process.name:"vaultcmd.exe") and
-  process.args:"/list*"
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -92,6 +60,36 @@ Windows Credential Manager stores credentials for websites, applications, and ne
 - Implement enhanced monitoring on the affected system and similar endpoints for any further attempts to use VaultCmd.exe or other credential dumping tools.
 - Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the scope of the breach.
 - Review and update endpoint protection configurations to ensure that similar threats are detected and blocked in the future, leveraging threat intelligence and MITRE ATT&CK framework insights."""
+references = [
+    "https://medium.com/threatpunter/detecting-adversary-tradecraft-with-image-load-event-logging-and-eql-8de93338c16",
+    "https://web.archive.org/web/20201004080456/https://rastamouse.me/blog/rdp-jump-boxes/",
+    "https://www.elastic.co/security-labs/detect-credential-access",
+]
+risk_score = 47
+rule_id = "be8afaed-4bcd-4e0a-b5f9-5562003dde81"
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Data Source: Elastic Endgame",
+    "Data Source: Elastic Defend",
+    "Data Source: Windows Security Event Logs",
+    "Data Source: Microsoft Defender for Endpoint",
+    "Data Source: Sysmon",
+    "Data Source: SentinelOne",
+    "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "windows" and event.type == "start" and
+  (?process.pe.original_file_name:"vaultcmd.exe" or process.name:"vaultcmd.exe") and
+  process.args:"/list*"
+'''
 
 
 [[rule.threat]]

rules/windows/credential_access_seenabledelegationprivilege_assigned_to_user.toml

@@ -2,9 +2,7 @@
 creation_date = "2022/01/27"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/windows/credential_access_shadow_credentials.toml

@@ -2,9 +2,7 @@
 creation_date = "2022/01/26"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/windows/credential_access_spn_attribute_modified.toml

@@ -2,9 +2,7 @@
 creation_date = "2022/02/22"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/windows/credential_access_suspicious_comsvcs_imageload.toml

@@ -2,9 +2,7 @@
 creation_date = "2021/10/17"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/02/03"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]

rules/windows/credential_access_suspicious_lsass_access_generic.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/01/22"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -14,6 +12,41 @@ index = ["winlogbeat-*", "logs-windows.sysmon_operational-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious Lsass Process Access"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Lsass Process Access
+
+The Local Security Authority Subsystem Service (LSASS) is crucial for enforcing security policies and managing user logins in Windows environments. Adversaries often target LSASS to extract credentials, enabling unauthorized access. The detection rule identifies unusual access attempts to LSASS by filtering out legitimate processes and access patterns, focusing on anomalies that suggest credential dumping activities.
+
+### Possible investigation steps
+
+- Review the process details that triggered the alert, focusing on the process name and executable path to determine if it is a known legitimate application or potentially malicious.
+- Examine the GrantedAccess value in the event data to understand the level of access attempted on the LSASS process and compare it against typical access patterns.
+- Investigate the parent process of the suspicious process to identify how it was spawned and assess if it is part of a legitimate workflow or an anomaly.
+- Check the CallTrace field for any unusual or suspicious DLLs that might indicate malicious activity or exploitation attempts.
+- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns, such as network connections or file modifications.
+- Verify the host's security posture, including the status of antivirus or endpoint protection solutions, to ensure they are functioning correctly and have not been tampered with.
+
+### False positive analysis
+
+- Legitimate security tools like Sysinternals Process Explorer and Process Monitor can trigger false positives. Exclude these by adding their process names to the exception list.
+- Windows Defender and other antivirus software may access LSASS for legitimate scanning purposes. Exclude their executable paths from the detection rule to prevent false alerts.
+- System processes such as csrss.exe, lsm.exe, and wmiprvse.exe are known to access LSASS as part of normal operations. Ensure these are included in the process executable exceptions to avoid unnecessary alerts.
+- Software updates and installers, like those from Cisco AnyConnect or Oracle, may access LSASS during legitimate operations. Add these specific paths to the exclusion list to reduce false positives.
+- Custom enterprise applications that interact with LSASS for authentication purposes should be identified and their paths added to the exceptions to prevent disruption in monitoring.
+
+### Response and remediation
+
+- Isolate the affected system from the network immediately to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified in the alert that are attempting to access the LSASS process, ensuring that legitimate processes are not disrupted.
+- Conduct a memory dump analysis of the affected system to identify any malicious tools or scripts used for credential dumping, focusing on the LSASS process.
+- Change all potentially compromised credentials, especially those with administrative privileges, to prevent unauthorized access using stolen credentials.
+- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited by the adversary.
+- Monitor the network for any signs of further suspicious activity or attempts to access LSASS on other systems, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 references = ["https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1003.001/T1003.001.md"]
 risk_score = 47
 rule_id = "128468bf-cab1-4637-99ea-fdf3780a4609"
@@ -74,41 +107,6 @@ process where host.os.type == "windows" and event.code == "10" and
   ) and
   not winlog.event_data.CallTrace : ("*mpengine.dll*", "*appresolver.dll*", "*sysmain.dll*")
 '''
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Lsass Process Access
-
-The Local Security Authority Subsystem Service (LSASS) is crucial for enforcing security policies and managing user logins in Windows environments. Adversaries often target LSASS to extract credentials, enabling unauthorized access. The detection rule identifies unusual access attempts to LSASS by filtering out legitimate processes and access patterns, focusing on anomalies that suggest credential dumping activities.
-
-### Possible investigation steps
-
-- Review the process details that triggered the alert, focusing on the process name and executable path to determine if it is a known legitimate application or potentially malicious.
-- Examine the GrantedAccess value in the event data to understand the level of access attempted on the LSASS process and compare it against typical access patterns.
-- Investigate the parent process of the suspicious process to identify how it was spawned and assess if it is part of a legitimate workflow or an anomaly.
-- Check the CallTrace field for any unusual or suspicious DLLs that might indicate malicious activity or exploitation attempts.
-- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns, such as network connections or file modifications.
-- Verify the host's security posture, including the status of antivirus or endpoint protection solutions, to ensure they are functioning correctly and have not been tampered with.
-
-### False positive analysis
-
-- Legitimate security tools like Sysinternals Process Explorer and Process Monitor can trigger false positives. Exclude these by adding their process names to the exception list.
-- Windows Defender and other antivirus software may access LSASS for legitimate scanning purposes. Exclude their executable paths from the detection rule to prevent false alerts.
-- System processes such as csrss.exe, lsm.exe, and wmiprvse.exe are known to access LSASS as part of normal operations. Ensure these are included in the process executable exceptions to avoid unnecessary alerts.
-- Software updates and installers, like those from Cisco AnyConnect or Oracle, may access LSASS during legitimate operations. Add these specific paths to the exclusion list to reduce false positives.
-- Custom enterprise applications that interact with LSASS for authentication purposes should be identified and their paths added to the exceptions to prevent disruption in monitoring.
-
-### Response and remediation
-
-- Isolate the affected system from the network immediately to prevent further unauthorized access or lateral movement by the adversary.
-- Terminate any suspicious processes identified in the alert that are attempting to access the LSASS process, ensuring that legitimate processes are not disrupted.
-- Conduct a memory dump analysis of the affected system to identify any malicious tools or scripts used for credential dumping, focusing on the LSASS process.
-- Change all potentially compromised credentials, especially those with administrative privileges, to prevent unauthorized access using stolen credentials.
-- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited by the adversary.
-- Monitor the network for any signs of further suspicious activity or attempts to access LSASS on other systems, using enhanced logging and alerting mechanisms.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]

rules/windows/credential_access_suspicious_lsass_access_memdump.toml

@@ -2,9 +2,7 @@
 creation_date = "2021/10/07"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -17,6 +15,41 @@ index = ["winlogbeat-*", "logs-windows.sysmon_operational-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Credential Access via LSASS Memory Dump"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Credential Access via LSASS Memory Dump
+
+LSASS (Local Security Authority Subsystem Service) is crucial for managing Windows security policies and storing sensitive data like user credentials. Adversaries exploit this by using tools that leverage MiniDumpWriteDump from libraries like DBGHelp.dll to extract credentials. The detection rule identifies suspicious LSASS access by monitoring for these libraries in call traces, excluding legitimate crash handlers, thus flagging potential credential theft attempts.
+
+### Possible investigation steps
+
+- Review the process details associated with the alert, focusing on the process name, executable path, and parent process to determine if the process accessing LSASS is legitimate or suspicious.
+- Examine the call trace details to confirm the presence of DBGHelp.dll or DBGCore.dll, which are indicative of potential credential dumping attempts.
+- Check for any recent crash reports or legitimate use of WerFault.exe, WerFaultSecure.exe, or similar processes that might explain the LSASS access as a non-malicious event.
+- Investigate the user account context under which the suspicious process is running to assess if it aligns with expected behavior or if it indicates potential compromise.
+- Correlate the event with other security logs or alerts to identify any related suspicious activities, such as unauthorized access attempts or lateral movement within the network.
+- Assess the risk and impact by determining if any sensitive credentials could have been exposed, and consider isolating the affected system to prevent further compromise.
+
+### False positive analysis
+
+- Legitimate crash handlers like WerFault.exe may access LSASS during system crashes. To prevent these from being flagged, ensure that the rule excludes processes such as WerFault.exe, WerFaultSecure.exe, and their SysWOW64 counterparts.
+- Debugging tools used by developers or IT administrators might trigger this rule if they access LSASS for legitimate purposes. Consider creating exceptions for known and trusted debugging tools within your environment.
+- Security software or endpoint protection solutions may perform similar actions as part of their normal operations. Verify with your security vendor and exclude these processes if they are confirmed to be benign.
+- Automated system diagnostics or maintenance scripts that interact with LSASS for health checks could be misidentified. Review and whitelist these scripts if they are part of routine system management tasks.
+- Ensure that any custom or third-party applications that require access to LSASS for legitimate reasons are documented and excluded from the rule to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further credential access or lateral movement by the adversary.
+- Terminate any suspicious processes that are accessing the LSASS memory, especially those involving DBGHelp.dll or DBGCore.dll, to stop the credential dumping activity.
+- Conduct a thorough review of the affected system's security logs to identify any unauthorized access or changes, focusing on event code "10" and call traces involving LSASS.
+- Change passwords for all accounts that were active on the affected system, prioritizing high-privilege accounts, to mitigate the risk of compromised credentials being used.
+- Restore the affected system from a known good backup to ensure that any malicious changes or tools are removed.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected.
+- Implement enhanced monitoring and alerting for similar suspicious activities, focusing on LSASS access and the use of MiniDumpWriteDump, to improve detection and response capabilities."""
 references = [
     "https://www.ired.team/offensive-security/credential-access-and-credential-dumping/dump-credentials-from-lsass-process-without-mimikatz",
     "https://www.elastic.co/security-labs/detect-credential-access",
@@ -59,41 +92,6 @@ process where host.os.type == "windows" and event.code == "10" and
         "?:\\Windows\\System32\\WerFaultSecure.exe"
       )
 '''
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every 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 Credential Access via LSASS Memory Dump
-
-LSASS (Local Security Authority Subsystem Service) is crucial for managing Windows security policies and storing sensitive data like user credentials. Adversaries exploit this by using tools that leverage MiniDumpWriteDump from libraries like DBGHelp.dll to extract credentials. The detection rule identifies suspicious LSASS access by monitoring for these libraries in call traces, excluding legitimate crash handlers, thus flagging potential credential theft attempts.
-
-### Possible investigation steps
-
-- Review the process details associated with the alert, focusing on the process name, executable path, and parent process to determine if the process accessing LSASS is legitimate or suspicious.
-- Examine the call trace details to confirm the presence of DBGHelp.dll or DBGCore.dll, which are indicative of potential credential dumping attempts.
-- Check for any recent crash reports or legitimate use of WerFault.exe, WerFaultSecure.exe, or similar processes that might explain the LSASS access as a non-malicious event.
-- Investigate the user account context under which the suspicious process is running to assess if it aligns with expected behavior or if it indicates potential compromise.
-- Correlate the event with other security logs or alerts to identify any related suspicious activities, such as unauthorized access attempts or lateral movement within the network.
-- Assess the risk and impact by determining if any sensitive credentials could have been exposed, and consider isolating the affected system to prevent further compromise.
-
-### False positive analysis
-
-- Legitimate crash handlers like WerFault.exe may access LSASS during system crashes. To prevent these from being flagged, ensure that the rule excludes processes such as WerFault.exe, WerFaultSecure.exe, and their SysWOW64 counterparts.
-- Debugging tools used by developers or IT administrators might trigger this rule if they access LSASS for legitimate purposes. Consider creating exceptions for known and trusted debugging tools within your environment.
-- Security software or endpoint protection solutions may perform similar actions as part of their normal operations. Verify with your security vendor and exclude these processes if they are confirmed to be benign.
-- Automated system diagnostics or maintenance scripts that interact with LSASS for health checks could be misidentified. Review and whitelist these scripts if they are part of routine system management tasks.
-- Ensure that any custom or third-party applications that require access to LSASS for legitimate reasons are documented and excluded from the rule to avoid unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further credential access or lateral movement by the adversary.
-- Terminate any suspicious processes that are accessing the LSASS memory, especially those involving DBGHelp.dll or DBGCore.dll, to stop the credential dumping activity.
-- Conduct a thorough review of the affected system's security logs to identify any unauthorized access or changes, focusing on event code "10" and call traces involving LSASS.
-- Change passwords for all accounts that were active on the affected system, prioritizing high-privilege accounts, to mitigate the risk of compromised credentials being used.
-- Restore the affected system from a known good backup to ensure that any malicious changes or tools are removed.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected.
-- Implement enhanced monitoring and alerting for similar suspicious activities, focusing on LSASS access and the use of MiniDumpWriteDump, to improve detection and response capabilities."""
 
 
 [[rule.threat]]

rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml

@@ -2,9 +2,7 @@
 creation_date = "2021/10/14"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -18,35 +16,6 @@ index = ["winlogbeat-*", "logs-windows.sysmon_operational-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Potential LSASS Memory Dump via PssCaptureSnapShot"
-references = [
-    "https://www.matteomalvica.com/blog/2019/12/02/win-defender-atp-cred-bypass/",
-    "https://twitter.com/sbousseaden/status/1280619931516747777?lang=en",
-]
-risk_score = 73
-rule_id = "0f93cb9a-1931-48c2-8cd0-f173fd3e5283"
-setup = """## Setup
-
-This is meant to run only on datasources using Elastic Agent 7.14+ since versions prior to that will be missing the threshold
-rule cardinality feature.
-"""
-severity = "high"
-tags = [
-    "Domain: Endpoint",
-    "OS: Windows",
-    "Use Case: Threat Detection",
-    "Tactic: Credential Access",
-    "Data Source: Sysmon",
-    "Resources: Investigation Guide",
-]
-timestamp_override = "event.ingested"
-type = "threshold"
-
-query = '''
-event.category:process and host.os.type:windows and event.code:10 and
- winlog.event_data.TargetImage:("C:\\Windows\\system32\\lsass.exe" or
-                                 "c:\\Windows\\system32\\lsass.exe" or
-                                 "c:\\Windows\\System32\\lsass.exe")
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -81,6 +50,35 @@ PssCaptureSnapShot is a Windows feature used for capturing process snapshots, ai
 - Apply the latest security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
 - Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
 - Enhance monitoring and detection capabilities by ensuring that similar suspicious activities are logged and alerted on, using the specific query fields and threat indicators identified in this alert."""
+references = [
+    "https://www.matteomalvica.com/blog/2019/12/02/win-defender-atp-cred-bypass/",
+    "https://twitter.com/sbousseaden/status/1280619931516747777?lang=en",
+]
+risk_score = 73
+rule_id = "0f93cb9a-1931-48c2-8cd0-f173fd3e5283"
+setup = """## Setup
+
+This is meant to run only on datasources using Elastic Agent 7.14+ since versions prior to that will be missing the threshold
+rule cardinality feature.
+"""
+severity = "high"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Data Source: Sysmon",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "threshold"
+
+query = '''
+event.category:process and host.os.type:windows and event.code:10 and
+ winlog.event_data.TargetImage:("C:\\Windows\\system32\\lsass.exe" or
+                                 "c:\\Windows\\system32\\lsass.exe" or
+                                 "c:\\Windows\\System32\\lsass.exe")
+'''
 
 
 [[rule.threat]]

rules/windows/credential_access_suspicious_winreg_access_via_sebackup_priv.toml

@@ -2,9 +2,7 @@
 creation_date = "2022/02/16"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]

rules/windows/credential_access_symbolic_link_to_shadow_copy_created.toml

@@ -2,9 +2,7 @@
 creation_date = "2021/12/25"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic", "Austin Songer"]

rules/windows/credential_access_veeam_commands.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/03/14"
 integration = ["windows", "endpoint", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -27,36 +25,6 @@ index = [
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Veeam Credential Access Command"
-references = ["https://thedfirreport.com/2021/12/13/diavol-ransomware/"]
-risk_score = 47
-rule_id = "b661f86d-1c23-4ce7-a59e-2edbdba28247"
-severity = "medium"
-tags = [
-    "Domain: Endpoint",
-    "OS: Windows",
-    "Use Case: Threat Detection",
-    "Tactic: Defense Evasion",
-    "Tactic: Credential Access",
-    "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",
-]
-timestamp_override = "event.ingested"
-type = "eql"
-
-query = '''
-process where host.os.type == "windows" and event.type == "start" and
-  (
-    (process.name : "sqlcmd.exe" or ?process.pe.original_file_name : "sqlcmd.exe") or
-    process.args : ("Invoke-Sqlcmd", "Invoke-SqlExecute", "Invoke-DbaQuery", "Invoke-SqlQuery")
-  ) and
-  process.args : "*[VeeamBackup].[dbo].[Credentials]*"
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -92,6 +60,36 @@ Veeam credentials stored in MSSQL databases are crucial for managing backup oper
 - Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised.
 - Implement enhanced monitoring on systems storing Veeam credentials to detect similar suspicious activities in the future.
 - Review and update access controls and permissions for MSSQL databases to ensure only authorized personnel have access to Veeam credentials."""
+references = ["https://thedfirreport.com/2021/12/13/diavol-ransomware/"]
+risk_score = 47
+rule_id = "b661f86d-1c23-4ce7-a59e-2edbdba28247"
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Defense Evasion",
+    "Tactic: Credential Access",
+    "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",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "windows" and event.type == "start" and
+  (
+    (process.name : "sqlcmd.exe" or ?process.pe.original_file_name : "sqlcmd.exe") or
+    process.args : ("Invoke-Sqlcmd", "Invoke-SqlExecute", "Invoke-DbaQuery", "Invoke-SqlQuery")
+  ) and
+  process.args : "*[VeeamBackup].[dbo].[Credentials]*"
+'''
 
 
 [[rule.threat]]

rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml

@@ -2,9 +2,7 @@
 creation_date = "2021/11/27"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -17,30 +15,6 @@ index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential LSASS Clone Creation via PssCaptureSnapShot"
-references = [
-    "https://www.matteomalvica.com/blog/2019/12/02/win-defender-atp-cred-bypass/",
-    "https://medium.com/@Achilles8284/the-birth-of-a-process-part-2-97c6fb9c42a2",
-]
-risk_score = 73
-rule_id = "a16612dd-b30e-4d41-86a0-ebe70974ec00"
-severity = "high"
-tags = [
-    "Domain: Endpoint",
-    "OS: Windows",
-    "Use Case: Threat Detection",
-    "Tactic: Credential Access",
-    "Data Source: Sysmon",
-    "Data Source: Windows Security Event Logs",
-    "Resources: Investigation Guide",
-]
-timestamp_override = "event.ingested"
-type = "eql"
-
-query = '''
-process where host.os.type == "windows" and event.code:"4688" and
-  process.executable : "?:\\Windows\\System32\\lsass.exe" and
-  process.parent.executable : "?:\\Windows\\System32\\lsass.exe"
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -76,6 +50,30 @@ PssCaptureSnapShot is a Windows API used for creating snapshots of processes, of
 - Review and enhance endpoint security configurations to ensure that LSASS process memory is protected from unauthorized access, such as enabling Credential Guard if applicable.
 - Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
 - Implement additional monitoring and alerting for similar suspicious activities, focusing on process creation events involving LSASS, to improve early detection of future attempts."""
+references = [
+    "https://www.matteomalvica.com/blog/2019/12/02/win-defender-atp-cred-bypass/",
+    "https://medium.com/@Achilles8284/the-birth-of-a-process-part-2-97c6fb9c42a2",
+]
+risk_score = 73
+rule_id = "a16612dd-b30e-4d41-86a0-ebe70974ec00"
+severity = "high"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Data Source: Sysmon",
+    "Data Source: Windows Security Event Logs",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "windows" and event.code:"4688" and
+  process.executable : "?:\\Windows\\System32\\lsass.exe" and
+  process.parent.executable : "?:\\Windows\\System32\\lsass.exe"
+'''
 
 
 [[rule.threat]]

rules/windows/credential_access_wbadmin_ntds.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/06/05"
 integration = ["windows", "endpoint", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -27,34 +25,6 @@ index = [
 language = "eql"
 license = "Elastic License v2"
 name = "NTDS Dump via Wbadmin"
-references = [
-    "https://medium.com/r3d-buck3t/windows-privesc-with-sebackupprivilege-65d2cd1eb960"
-]
-risk_score = 47
-rule_id = "d93e61db-82d6-4095-99aa-714988118064"
-severity = "medium"
-tags = [
-    "Domain: Endpoint",
-    "OS: Windows",
-    "Use Case: Threat Detection",
-    "Tactic: Credential Access",
-    "Data Source: Elastic Endgame",
-    "Data Source: Elastic Defend",
-    "Data Source: Windows Security Event Logs",
-    "Data Source: Microsoft Defender for Endpoint",
-    "Data Source: Sysmon",
-    "Data Source: SentinelOne",
-    "Data Source: Crowdstrike",
-    "Resources: Investigation Guide",
-]
-timestamp_override = "event.ingested"
-type = "eql"
-
-query = '''
-process where host.os.type == "windows" and event.type == "start" and
-    (process.name : "wbadmin.exe" or ?process.pe.original_file_name : "wbadmin.exe") and
-     process.args : "recovery" and process.command_line : "*ntds.dit*"
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -89,6 +59,32 @@ Wbadmin is a Windows utility for backup and recovery, often used by administrato
 - Restore the NTDS.dit file from a known good backup if any unauthorized modifications are detected.
 - Implement enhanced monitoring and logging for wbadmin.exe usage across all domain controllers to detect future unauthorized access attempts.
 - Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network."""
+references = ["https://medium.com/r3d-buck3t/windows-privesc-with-sebackupprivilege-65d2cd1eb960"]
+risk_score = 47
+rule_id = "d93e61db-82d6-4095-99aa-714988118064"
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Data Source: Elastic Endgame",
+    "Data Source: Elastic Defend",
+    "Data Source: Windows Security Event Logs",
+    "Data Source: Microsoft Defender for Endpoint",
+    "Data Source: Sysmon",
+    "Data Source: SentinelOne",
+    "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "windows" and event.type == "start" and
+    (process.name : "wbadmin.exe" or ?process.pe.original_file_name : "wbadmin.exe") and
+     process.args : "recovery" and process.command_line : "*ntds.dit*"
+'''
 
 
 [[rule.threat]]
@@ -113,8 +109,6 @@ reference = "https://attack.mitre.org/techniques/T1003/003/"
 id = "TA0006"
 name = "Credential Access"
 reference = "https://attack.mitre.org/tactics/TA0006/"
-
-
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]

rules/windows/credential_access_wireless_creds_dumping.toml

@@ -2,9 +2,7 @@
 creation_date = "2022/11/01"
 integration = ["endpoint", "system", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]

rules/windows/defense_evasion_adding_the_hidden_file_attribute_with_via_attribexe.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]

rules/windows/defense_evasion_amsi_bypass_dllhijack.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/01/17"
 integration = ["windows", "endpoint", "sentinel_one_cloud_funnel", "m365_defender"]
 maturity = "production"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
-min_stack_version = "8.14.0"
-updated_date = "2025/02/03"
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]
@@ -39,7 +37,14 @@ Identifies the creation of the Antimalware Scan Interface (AMSI) DLL in an unusu
 attempt to bypass AMSI by loading a rogue AMSI module instead of the legit one.
 """
 from = "now-9m"
-index = ["winlogbeat-*", "logs-endpoint.events.file-*", "logs-windows.sysmon_operational-*", "endgame-*", "logs-sentinel_one_cloud_funnel.*", "logs-m365_defender.event-*"]
+index = [
+    "winlogbeat-*",
+    "logs-endpoint.events.file-*",
+    "logs-windows.sysmon_operational-*",
+    "endgame-*",
+    "logs-sentinel_one_cloud_funnel.*",
+    "logs-m365_defender.event-*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious Antimalware Scan Interface DLL"
@@ -105,7 +110,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
-    "Data Source: Microsoft Defender for Endpoint"
+    "Data Source: Microsoft Defender for Endpoint",
 ]
 timestamp_override = "event.ingested"
 type = "eql"

rules/windows/defense_evasion_amsi_bypass_powershell.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/01/17"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/02/21"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]

rules/windows/defense_evasion_amsienable_key_mod.toml

@@ -2,9 +2,7 @@
 creation_date = "2021/06/01"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
-min_stack_version = "8.14.0"
-min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -13,7 +11,14 @@ Identifies modifications of the AmsiEnable registry key to 0, which disables the
 adversary can modify this key to disable AMSI protections.
 """
 from = "now-9m"
-index = ["winlogbeat-*", "logs-endpoint.events.registry-*", "logs-windows.sysmon_operational-*", "endgame-*", "logs-m365_defender.event-*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "winlogbeat-*",
+    "logs-endpoint.events.registry-*",
+    "logs-windows.sysmon_operational-*",
+    "endgame-*",
+    "logs-m365_defender.event-*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Modification of AmsiEnable Registry Key"