[Detection Rules] Adding Documents for v8.19.29 Pre-Built Detection Rules

docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-alerts-in-different-att-ck-tactics-by-host.asciidoc

@@ -0,0 +1,143 @@
+[[prebuilt-rule-8-19-29-alerts-in-different-att-ck-tactics-by-host]]
+=== Alerts in Different ATT&CK Tactics by Host
+
+This rule correlates medium-or-higher severity alerts involving the same host from at least two distinct detection rules mapped to three or more ATT&CK tactics. Analysts can use this to prioritize triage and response, as this combination may indicate host compromise.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 1h
+
+*Searches indices from*: now-8h ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* Resources: Investigation Guide
+
+*Version*: 7
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Alerts in Different ATT&CK Tactics by Host*
+
+
+The rule identifies hosts with alerts across multiple ATT&CK tactics, which may indicate compromise. It helps analysts focus on high-risk hosts by correlating diverse alerts. The resulting alert is grouped, so the `Esql.*_values` fields summarize contributing alerts without preserving event order or relationships between values.
+
+
+*Possible investigation steps*
+
+
+- Review the alert details to identify the specific host involved and the different ATT&CK tactics that triggered the alerts.
+- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
+- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
+- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.
+- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
+- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.
+
+
+*False positive analysis*
+
+
+- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance.
+- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.
+- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.
+- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.
+- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.
+
+
+*Response and remediation*
+
+
+- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
+- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
+- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
+- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
+- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
+- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
+- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from .alerts-security.*  metadata _id
+
+// filter for medium-or-higher severity alerts, excluding threat_match, machine_learning, and deprecated rules.
+| where kibana.alert.risk_score > 21 and
+        kibana.alert.rule.name IS NOT NULL and kibana.alert.rule.rule_id IS NOT NULL and
+        host.id is not null and event.dataset is not null and
+        kibana.alert.rule.type not in ("threat_match", "machine_learning") and
+        // Exclude a deprecated rule whose alert name does not carry the standard prefix
+        kibana.alert.rule.name != "Potential PrintNightmare File Modification" and
+        not kibana.alert.rule.name like "Deprecated - *" and
+        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
+
+// extract unique counts and values by host.id
+| stats Esql.alerts_count = COUNT(*),
+        Esql.kibana_alert_rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),
+        Esql.kibana_alert_rule_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.rule_id),
+        Esql.event_module_values = VALUES(event.module),
+        Esql.host_name_values = VALUES(host.name),
+        Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name),
+        Esql.kibana_alert_rule_id_values = VALUES(kibana.alert.rule.rule_id),
+        Esql.threat_tactic_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.threat.tactic.id),
+        Esql.threat_tactic_name_values = VALUES(kibana.alert.rule.threat.tactic.name),
+        Esql.process_executable_values = VALUES(process.executable),
+        Esql.process_parent_executable_values = VALUES(process.parent.executable),
+        Esql.process_command_line_values = VALUES(process.command_line),
+        Esql.process_entity_id_distinct_count = COUNT_DISTINCT(process.entity_id) by host.id
+
+// filter for risky hosts with multiple distinct rules across multiple tactics
+// Distinct rule IDs prevent one rule mapped to multiple tactics from satisfying the correlation.
+| where Esql.kibana_alert_rule_name_distinct_count >= 2 and
+        Esql.kibana_alert_rule_id_distinct_count >= 2 and
+        Esql.threat_tactic_id_distinct_count >= 3
+
+// Populate the native host name for alert triage without changing the host.id correlation key.
+| eval host.name = MV_FIRST(Esql.host_name_values)
+
+// fields populated in the resulting alert
+| keep host.id,
+       host.name,
+       Esql.alerts_count,
+       Esql.kibana_alert_rule_name_distinct_count,
+       Esql.kibana_alert_rule_id_distinct_count,
+       Esql.process_entity_id_distinct_count,
+       Esql.event_module_values,
+       Esql.host_name_values,
+       Esql.kibana_alert_rule_name_values,
+       Esql.kibana_alert_rule_id_values,
+       Esql.threat_tactic_name_values,
+       Esql.process_executable_values,
+       Esql.process_parent_executable_values,
+       Esql.process_command_line_values
+
+----------------------------------

docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-batch-job-submitted-with-container-override-by-unusual-identity.asciidoc

@@ -0,0 +1,112 @@
+[[prebuilt-rule-8-19-29-aws-batch-job-submitted-with-container-override-by-unusual-identity]]
+=== AWS Batch Job Submitted with Container Override by Unusual Identity
+
+Detects the first time an AWS identity submits an AWS Batch job with a container command override ("containerOverrides.command"), indicating a runtime-modified execution environment. Command overrides allow the submitter to replace the default command of a job definition at submission time. This flexibility is commonly abused by adversaries to inject malicious commands or exfiltration logic into otherwise legitimate Batch compute environments without modifying the underlying job definition — making the malicious activity harder to detect through configuration review alone.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* logs-aws.cloudtrail-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html
+* https://docs.aws.amazon.com/batch/latest/APIReference/API_ContainerOverrides.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS Batch
+* Use Case: Threat Detection
+* Tactic: Execution
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating AWS Batch Job Submitted with Container Override by Unusual Identity*
+
+
+This rule fires when an identity submits a Batch job with a container command override and has not been observed doing so in the prior 7 days. Container overrides at submission time bypass job definition review — an adversary can inject a malicious command into an approved job definition without modifying it, making the change invisible to IaC drift detection or configuration compliance tools.
+
+
+*Possible investigation steps*
+
+
+- Identify the submitting principal (`aws.cloudtrail.user_identity.arn`) and determine whether they are expected to use AWS Batch with runtime overrides.
+- Review `aws.cloudtrail.request_parameters` to extract the overridden command in `containerOverrides.command` - this is the trigger. Also inspect any environment variables or resource requirements present. Look for shell commands, curl/wget calls, base64-encoded payloads, or references to external endpoints in the command override.
+- Identify the job queue and job definition used to understand the compute environment and IAM role the job will execute under.
+- Search for `DescribeJobs` events after the submission to track execution status and output.
+- Correlate with S3 `GetObject` or `PutObject` events from the Batch execution role during the job's execution window to identify data access or exfiltration.
+
+
+*False positive analysis*
+
+
+- ETL and data processing pipelines that parameterize job commands at submission time.
+- CI/CD systems that submit test jobs with dynamic parameters.
+
+
+*Response and remediation*
+
+
+- If unauthorized, cancel the job immediately using `TerminateJob`.
+- Review the Batch compute environment's IAM execution role for the scope of data access the job had.
+- Restrict `batch:SubmitJob` with `Condition` keys on `batch:Image` and job queue ARNs to prevent arbitrary container override submissions.
+
+
+==== Setup
+
+
+The AWS CloudTrail integration must be enabled and configured to collect Batch management events (`batch.amazonaws.com`).
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset: "aws.cloudtrail"
+    and event.provider: "batch.amazonaws.com"
+    and event.action: "SubmitJob"
+    and event.outcome: "success"
+    and aws.cloudtrail.request_parameters: (*containerOverrides* and *command*)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/