Update latest docs (#7110)

Author: tradebot-elastic

docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-agent-spoofing-mismatched-agent-id.asciidoc

@@ -0,0 +1,108 @@
+[[prebuilt-rule-8-19-10-agent-spoofing-mismatched-agent-id]]
+=== Agent Spoofing - Mismatched Agent ID
+
+Detects events that have a mismatch on the expected event agent ID. The status "agent_id_mismatch/mismatch" occurs when the expected agent ID associated with the API key does not match the actual agent ID in an event. This could indicate attempts to spoof events in order to masquerade actual activity to evade detection.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-*
+* metrics-*
+* traces-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Resources: Investigation Guide
+
+*Version*: 104
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Agent Spoofing - Mismatched Agent ID*
+
+
+In security environments, agent IDs uniquely identify software agents that report events. Adversaries may spoof these IDs to disguise unauthorized activities, evading detection systems. The detection rule identifies discrepancies between expected and actual agent IDs, flagging potential spoofing attempts. By monitoring for mismatches, it helps uncover efforts to masquerade malicious actions as legitimate.
+
+
+*Possible investigation steps*
+
+
+- Review the event logs to identify the specific events where the agent_id_status is marked as "agent_id_mismatch" or "mismatch" to understand the scope and frequency of the issue.
+- Correlate the mismatched agent IDs with the associated API keys to determine if there are any patterns or commonalities that could indicate a targeted spoofing attempt.
+- Investigate the source IP addresses and user accounts associated with the mismatched events to identify any unauthorized access or suspicious activity.
+- Check for any recent changes or anomalies in the configuration or deployment of agents that could explain the mismatches, such as updates or reassignments.
+- Analyze historical data to determine if similar mismatches have occurred in the past and whether they were resolved or linked to known issues or threats.
+- Consult with the IT or security team to verify if there are any legitimate reasons for the agent ID discrepancies, such as testing or maintenance activities.
+
+
+*False positive analysis*
+
+
+- Legitimate software updates or patches may temporarily cause agent ID mismatches. Users should verify if the mismatches coincide with scheduled updates and consider excluding these events if confirmed.
+- Network configuration changes, such as IP address reassignments, can lead to mismatches. Ensure that network changes are documented and correlate with the mismatched events before excluding them.
+- Virtual machine snapshots or clones might result in duplicate agent IDs. Users should track virtual machine activities and exclude events from known snapshot or cloning operations.
+- Load balancing or failover processes in high-availability environments can cause agent ID discrepancies. Review the infrastructure setup and exclude events that align with these processes.
+- Testing environments often simulate various agent activities, leading to mismatches. Clearly separate test environments from production in monitoring systems and exclude test-related events.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected systems to prevent further unauthorized access or data exfiltration. This can be done by disconnecting the system from the network or using network segmentation techniques.
+- Conduct a thorough review of the logs and events associated with the mismatched agent ID to identify any unauthorized changes or activities. Focus on the specific events flagged by the detection rule.
+- Revoke and reissue API keys associated with the compromised agent ID to prevent further misuse. Ensure that new keys are distributed securely and only to authorized personnel.
+- Implement additional monitoring on the affected systems and related network segments to detect any further attempts at agent ID spoofing or other suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat actor has compromised other parts of the network.
+- Review and update access controls and authentication mechanisms to ensure that only legitimate agents can report events. Consider implementing multi-factor authentication for added security.
+- Document the incident, including all actions taken, and conduct a post-incident review to identify any gaps in detection or response. Use this information to enhance future threat detection and response capabilities.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.agent_id_status:(agent_id_mismatch or mismatch) and not host.name:agentless-*
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Masquerading
+** ID: T1036
+** Reference URL: https://attack.mitre.org/techniques/T1036/

docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-bedrock-guardrails-detected-multiple-policy-violations-within-a-single-blocked-request.asciidoc

@@ -0,0 +1,147 @@
+[[prebuilt-rule-8-19-10-aws-bedrock-guardrails-detected-multiple-policy-violations-within-a-single-blocked-request]]
+=== AWS Bedrock Guardrails Detected Multiple Policy Violations Within a Single Blocked Request
+
+Identifies multiple violations of AWS Bedrock guardrails within a single request, resulting in a block action, increasing the likelihood of malicious intent. Multiple violations implies that a user may be intentionally attempting to cirvumvent security controls, access sensitive information, or possibly exploit a vulnerability in the system.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 10m
+
+*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html
+* https://atlas.mitre.org/techniques/AML.T0051
+* https://atlas.mitre.org/techniques/AML.T0054
+* https://www.elastic.co/security-labs/elastic-advances-llm-security
+
+*Tags*: 
+
+* Domain: LLM
+* Data Source: AWS Bedrock
+* Data Source: AWS S3
+* Resources: Investigation Guide
+* Use Case: Policy Violation
+* Mitre Atlas: T0051
+* Mitre Atlas: T0054
+
+*Version*: 7
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating AWS Bedrock Guardrails Detected Multiple Policy Violations Within a Single Blocked Request*
+
+
+Amazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications.
+
+It enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices.
+
+Through Guardrail, organizations can define "denied topics" to prevent the model from generating content on specific, undesired subjects,
+and they can establish thresholds for harmful content categories, including hate speech, violence, or offensive language.
+
+
+*Possible investigation steps*
+
+
+- Identify the user account and the user request that caused multiple policy violations and whether it should perform this kind of action.
+- Investigate the user activity that might indicate a potential brute force attack.
+- Investigate other alerts associated with the user account during the past 48 hours.
+- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?
+- Examine the account's prompts and responses in the last 24 hours.
+- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.
+
+
+*False positive analysis*
+
+
+- Verify the user account that caused multiple policy violations, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails.
+
+
+*Response and remediation*
+
+
+- Initiate the incident response process based on the outcome of the triage.
+- Disable or limit the account during the investigation and response.
+- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
+    - Identify the account role in the cloud environment.
+    - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.
+    - Identify any regulatory or legal ramifications related to this activity.
+- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:
+
+https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from logs-aws_bedrock.invocation-*
+
+// Expand multi-value policy action field
+| mv_expand gen_ai.policy.action
+
+// Filter for policy-blocked requests
+| where gen_ai.policy.action == "BLOCKED"
+
+// count number of policy matches per request (multi-valued)
+| eval Esql.ml_policy_violations_mv_count = mv_count(gen_ai.policy.name)
+
+// Filter for requests with more than one policy match
+| where Esql.ml_policy_violations_mv_count > 1
+
+// keep relevant fields
+| keep
+  gen_ai.policy.action,
+  Esql.ml_policy_violations_mv_count,
+  user.id,
+  gen_ai.request.model.id,
+  cloud.account.id
+
+// Aggregate requests with multiple violations
+| stats
+    Esql.ml_policy_violations_total_unique_requests_count = count(*)
+  by
+    Esql.ml_policy_violations_mv_count,
+    user.id,
+    gen_ai.request.model.id,
+    cloud.account.id
+
+// sort by number of unique requests
+| sort Esql.ml_policy_violations_total_unique_requests_count desc
+
+----------------------------------

docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-cli-command-with-custom-endpoint-url.asciidoc

@@ -0,0 +1,112 @@
+[[prebuilt-rule-8-19-10-aws-cli-command-with-custom-endpoint-url]]
+=== AWS CLI Command with Custom Endpoint URL
+
+Detects the use of the AWS CLI with the `--endpoint-url` argument, which allows users to specify a custom endpoint URL for AWS services. This can be leveraged by adversaries to redirect API requests to non-standard or malicious endpoints, potentially bypassing typical security controls and logging mechanisms. This behavior may indicate an attempt to interact with unauthorized or compromised infrastructure, exfiltrate data, or perform other malicious activities under the guise of legitimate AWS operations.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* logs-endpoint.events.process-*
+* logs-crowdstrike.fdr*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://sysdig.com/blog/scarleteel-2-0/
+
+*Tags*: 
+
+* Data Source: Elastic Defend
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Command and Control
+* Resources: Investigation Guide
+* Data Source: Crowdstrike
+
+*Version*: 5
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating AWS CLI Command with Custom Endpoint URL*
+
+
+The AWS CLI allows users to interact with AWS services via command-line, offering flexibility in managing cloud resources. The `--endpoint-url` option lets users specify alternative endpoints, which can be exploited by adversaries to reroute requests to malicious servers, bypassing security controls. The detection rule identifies such misuse by monitoring for the `--endpoint-url` argument in process logs, flagging potential unauthorized activities.
+
+
+*Possible investigation steps*
+
+
+- Review the process logs to identify the specific command line that triggered the alert, focusing on the presence of the --endpoint-url argument.
+- Investigate the custom endpoint URL specified in the command to determine if it is a known malicious or unauthorized domain.
+- Check the user account associated with the process to assess if it has a history of suspicious activity or if it has been compromised.
+- Analyze network logs to trace any outbound connections to the custom endpoint URL and evaluate the data being transmitted.
+- Correlate the event with other security alerts or logs to identify any patterns or additional indicators of compromise related to the same user or endpoint.
+- Verify if the AWS credentials used in the command have been exposed or misused in other contexts, potentially indicating credential theft or abuse.
+
+
+*False positive analysis*
+
+
+- Internal testing environments may use custom endpoint URLs for development purposes. To manage this, create exceptions for known internal IP addresses or domain names associated with these environments.
+- Organizations using AWS CLI with custom endpoints for legitimate third-party integrations might trigger this rule. Identify and whitelist these specific integrations by their endpoint URLs to prevent false positives.
+- Automated scripts or tools that interact with AWS services through custom endpoints for monitoring or backup purposes can be flagged. Review and document these scripts, then exclude them from detection by process name or specific endpoint URL.
+- Some organizations may use proxy servers that require custom endpoint URLs for AWS CLI operations. Verify these configurations and exclude the associated endpoint URLs from the detection rule.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Review process logs and network traffic to identify any data that may have been redirected to unauthorized endpoints and assess the extent of potential data exposure.
+- Revoke any AWS credentials or access keys used on the affected system to prevent further misuse and rotate them with new credentials.
+- Conduct a thorough investigation to determine if any other systems have been compromised or if similar unauthorized endpoint usage has occurred elsewhere in the network.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional containment or remediation actions are necessary.
+- Implement network-level controls to block known malicious endpoints and enhance monitoring for unusual AWS CLI usage patterns across the environment.
+- Update security policies and endpoint protection configurations to detect and alert on the use of custom endpoint URLs in AWS CLI commands, ensuring rapid response to future incidents.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+host.os.type: "linux" and event.category: "process" and process.name: "aws" and process.args:  "--endpoint-url"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Command and Control
+** ID: TA0011
+** Reference URL: https://attack.mitre.org/tactics/TA0011/
+* Technique:
+** Name: Web Service
+** ID: T1102
+** Reference URL: https://attack.mitre.org/techniques/T1102/