diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-aws-iam-administratoraccess-policy-attached-to-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-aws-iam-administratoraccess-policy-attached-to-group.asciidoc new file mode 100644 index 0000000000..475335f00d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-aws-iam-administratoraccess-policy-attached-to-group.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-9-aws-iam-administratoraccess-policy-attached-to-group]] +=== AWS IAM AdministratorAccess Policy Attached to Group + +An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to user groups the compromised user account belongs to. This rule looks for use of the IAM AttachGroupPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM user group. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachGroupPolicy.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*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS IAM AdministratorAccess Policy Attached to Group* + + +The AWS-managed `AdministratorAccess` policy grants full administrative privileges across all AWS services. +When attached to a group, all group members inherit this access, often unintentionally broadening the blast radius of a compromise. +Adversaries can exploit `iam:AttachGroupPolicy` permissions to escalate privileges or establish persistence by attaching this policy to an existing user group. + + +*Possible investigation steps* + + +- **Identify the affected group and calling principal.** + Review `aws.cloudtrail.user_identity.arn` (caller) and `aws.cloudtrail.request_parameters.groupName` (target group). + Validate whether this aligns with legitimate change management or automation workflows. + +- **Review group membership.** + Enumerate current members using `aws iam get-group`. + Determine whether unauthorized users could have gained administrative access as a result. + +- **Inspect CloudTrail details.** + Check `source.ip`, `user_agent.original`, and `source.geo` fields for anomalies. + Compare with historical operations by the same principal. + +- **Correlate related IAM activity.** + Search for adjacent events such as `AddUserToGroup`, `CreateUser`, or `AttachUserPolicy`. + These may indicate chained privilege escalation. + +- **Assess propagation of privileges.** + If the group has many members or is linked to cross-account roles, the impact may extend beyond a single user. + Document all affected identities for containment. + + +*False positive analysis* + + +- **Intentional access updates.** + Policy attachment may occur during legitimate administrative provisioning. Confirm via ticketing systems. +- **Automation or compliance tasks.** + Some environments use centralized scripts to attach AdministratorAccess temporarily. Validate through automation logs. + + +*Response and remediation* + + +**1. Immediate containment** +- Detach the policy from the affected group (`aws iam detach-group-policy`). +- Review and limit group membership. Temporarily remove non-essential users or disable access for impacted accounts. +- Rotate credentials for users who inherited admin privileges from the attachment. +- Enable MFA on all impacted accounts. + +**2. Evidence preservation** +- Export the triggering `AttachGroupPolicy` event and related CloudTrail entries ±30 minutes from the alert. +- Preserve AWS Config and GuardDuty records to support forensic analysis. + +**3. Scoping and investigation** +- Review additional IAM operations from the same caller (`CreateAccessKey`, `AttachRolePolicy`, `UpdateAssumeRolePolicy`). +- Identify whether new groups or roles were created shortly before or after the event. +- Check for subsequent API activity by newly privileged users (for example, S3, EC2, or IAM modifications). + +**4. Recovery and hardening** +- Reinforce least privilege, avoid assigning `AdministratorAccess` to groups. +- Use role-based access control with scoped permissions. +- Enable CloudTrail, GuardDuty, and Security Hub across all regions. +- Implement SCPs at the organization level to restrict direct `AdministratorAccess` attachments. + + +*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]. + + +==== Rule query + + +[source, js] +---------------------------------- +iam where event.dataset == "aws.cloudtrail" + and event.provider == "iam.amazonaws.com" + and event.action == "AttachGroupPolicy" + 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-9/prebuilt-rule-8-19-9-aws-iam-administratoraccess-policy-attached-to-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-aws-iam-administratoraccess-policy-attached-to-role.asciidoc new file mode 100644 index 0000000000..b03cb63a0e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-aws-iam-administratoraccess-policy-attached-to-role.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-9-aws-iam-administratoraccess-policy-attached-to-role]] +=== AWS IAM AdministratorAccess Policy Attached to Role + +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. + +*Rule type*: eql + +*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/APIReference/API_AttachRolePolicy.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*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS IAM AdministratorAccess Policy Attached to Role* + + +The `AdministratorAccess` managed policy grants unrestricted privileges. +When attached to a role, it can enable privilege escalation or persistence, especially if the role is assumable by other accounts or services. +This rule detects `AttachRolePolicy` events where the `policyName` is `AdministratorAccess`. + + +*Possible investigation steps* + + +- **Identify both identities.** + Determine the calling user or role (`aws.cloudtrail.user_identity.arn`) and the target role (`aws.cloudtrail.request_parameters.roleName`). + Validate whether this change aligns with intended administrative actions. + +- **Review the target role’s trust policy.** + Examine who can assume the role (`AssumeRolePolicyDocument`). + If the role is assumable by external accounts, this may indicate a potential persistence or lateral movement path. + +- **Review CloudTrail details.** + Check `source.ip`, `user_agent.original`, and `source.geo` fields for anomalies. + Compare with historical operations by the same principal. + +- **Correlate with adjacent IAM events.** + Look for `UpdateAssumeRolePolicy`, `CreateAccessKey`, or `PassRole` calls. + These often accompany privilege escalation activity. + +- **Inspect downstream activity.** + Query CloudTrail for recent `AssumeRole` calls for the target role — determine if the newly elevated permissions were used. + + +*False positive analysis* + + +- **Delegated role management.** + Cloud administrators may legitimately grant temporary AdministratorAccess for troubleshooting. Confirm through tickets or change logs. +- **Automation or service-linked roles.** + Some services attach policies automatically for setup; verify whether the target is a service-linked role. + + +*Response and remediation* + + +**1. Immediate containment** +- Detach the policy. Remove the `AdministratorAccess` policy from the target role. +- Restrict access. Temporarily revoke the caller’s IAM privileges until the legitimacy of the action is confirmed. +- Audit trust policies. Review the role’s trust relationships to ensure only approved principals can assume it. +- Rotate credentials for any principals who assumed the affected role during the period of elevated privileges. + +**2. Evidence preservation** +- Export the triggering `AttachRolePolicy` event and related CloudTrail entries ±30 minutes from the alert. +- Preserve AWS Config snapshots and GuardDuty findings for traceability. + +**3. Scoping and investigation** +- Identify if the elevated role was subsequently assumed. + Correlate by matching `aws.cloudtrail.eventName:AssumeRole` with the target role ARN. +- Search for other recent IAM policy attachments or modifications by the same actor or IP. + +**4. Recovery and hardening** +- Apply least privilege policies; limit who can attach or modify administrative policies. +- Enforce IAM Conditions such as `aws:PrincipalArn` or `aws:ResourceTag` to limit policy attachment scope. +- Enable CloudTrail, GuardDuty, and Security Hub across all regions. +- Implement SCPs at the organization level to restrict direct `AdministratorAccess` attachments. + + +*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]. + + +==== Rule query + + +[source, js] +---------------------------------- +iam where event.dataset == "aws.cloudtrail" + and event.provider == "iam.amazonaws.com" + and event.action == "AttachRolePolicy" + 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-9/prebuilt-rule-8-19-9-aws-iam-administratoraccess-policy-attached-to-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-aws-iam-administratoraccess-policy-attached-to-user.asciidoc new file mode 100644 index 0000000000..bd6d49567d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-aws-iam-administratoraccess-policy-attached-to-user.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-9-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*: 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/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*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS 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* + + +> Per AWS IR Playbooks, unauthorized administrative policy attachment represents a Privilege Escalation event. + +**1. 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. + +**2. 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. + +**3. 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. + +**4. 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 event.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-9/prebuilt-rule-8-19-9-aws-iam-login-profile-added-for-root.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-aws-iam-login-profile-added-for-root.asciidoc new file mode 100644 index 0000000000..60ee3f326d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-aws-iam-login-profile-added-for-root.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-9-aws-iam-login-profile-added-for-root]] +=== AWS IAM Login Profile Added for Root + +Identifies creation of a console login profile for the AWS account root user. While CreateLoginProfile normally applies to IAM users, when performed from a temporary root session (e.g., via AssumeRoot) and the userName parameter is omitted, the profile is created for the root principal (self-assigned). Adversaries with temporary root access may add or reset the root login profile to establish persistent console access even if original access keys are rotated or disabled. Correlate with recent AssumeRoot/STS activity and validate intent with the account owner. + +*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*: None + +*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* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +This rule detects when a console login profile is created for the AWS root account. +A login profile enables password-based console access, and because the root user has unrestricted privileges, creating one is an extremely high-impact event. Adversaries who temporarily gain root-level credentials (for example, through an STS session or credential compromise) may use `CreateLoginProfile` without specifying a `userName` to add a password to the root account. This grants persistent access even if the attacker’s API keys are later rotated or disabled. + + +*Possible investigation steps* + + +**Assess the timing and context of the event** +- Review the `@timestamp` to determine when the `CreateLoginProfile` call occurred. + - Correlate this time window with other root or IAM activity such as `AssumeRoot`, `GetSessionToken`, `ConsoleLogin`, or `CreateAccessKey`. + - Check for follow-on activity, especially `ConsoleLogin` events or `UpdateLoginProfile`, which may indicate that the root password was used immediately after creation. + +**Investigate event origin and session details** +- Review `source.ip` and `user_agent.original`: + - Determine if the request originated from an expected network range, VPN endpoint, or geolocation. + - Identify whether the access was interactive (for example, browser or AWS console) or automated (`aws-cli`, SDK, or API client). +- Examine `aws.cloudtrail.user_identity.access_key_id` and associated STS session context to see if temporary credentials were used. +- Compare this event’s IP and access key to any other recent CloudTrail activity to identify potential lateral movement or multi-account access attempts. + +**Analyze the login profile creation** +- Review `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements`: + - Check whether `passwordResetRequired` was set to `true` or omitted, absence may imply that the attacker created a password they intend to reuse. +- Cross-reference this action with previous failed login attempts, password recovery requests, or `AssumeRoot` behavior. + +**Correlate related identity and access behavior** +- Search for additional IAM management activity: + - `AttachUserPolicy`, `AttachRolePolicy`, or `PutUserPolicy` granting elevated permissions. + - New `AccessKey` creation or `UpdateAccessKey` events tied to the same session. +- Review GuardDuty findings or any other detections referencing this account or IP around the same time period. +- If available, correlate with CloudTrail to detect if other resource creation or configuration changes followed the login profile addition. + +**Validate with account owner or authorized personnel** +- Contact the designated account or root credential owner to confirm whether this action was intentional (for example, during an account recovery). +- Review any internal change-management or service ticketing systems for an approved request matching this activity. + + +*False positive analysis* + + +Although rare, legitimate scenarios include: +- **Authorized account recovery** : An administrator or AWS Support might temporarily add a root login profile to regain access. Validate against documented recovery workflows. +- **Controlled testing or sandbox environments** : Certain sandbox accounts may reuse root credentials for automation or demonstration purposes. Tag and exclude these accounts from this rule where appropriate. +- **Automated provisioning** : Review any account bootstrap or recovery automation scripts that may invoke `CreateLoginProfile` on root credentials. + +For any potential false positive, verify that: +- The `source.ip` and `user_agent.original` values align with expected administrative locations and tools. +- The change was recorded during a maintenance window or known security operation. + + +*Response and remediation* + + +> Any unapproved creation of a login profile for the root account is a critical security incident requiring immediate containment and credential rotation. + +**1. Containment** +- Delete the newly created root login profile if it was not authorized. +- Rotate the root account password using AWS’s official password-reset workflow. +- Revoke any active sessions, temporary credentials, or tokens associated with this event. +- Verify that multi-factor authentication (MFA) is enabled and functioning on the root account. +- Check that no root access keys exist — if present, remove them immediately. + +**2. Investigation and scoping** +- Examine CloudTrail logs from 30 minutes before and after this event to identify correlated actions. +- Capture and securely store these logs in an isolated S3 bucket with Object Lock enabled to preserve forensic integrity. +- Investigate for additional IAM or STS operations by the same `access_key_id` or IP address that may indicate privilege escalation or persistence attempts. +- Review whether any new IAM roles, users, or policies were created in proximity to this event. + +**3. Recovery and hardening** +- Reset the root password and distribute the new credentials securely to authorized custodians only. +- Ensure MFA is enforced for all administrative and root-level access. +- Audit all IAM policies for least-privilege adherence, focusing on `iam:CreateLoginProfile`, `iam:UpdateLoginProfile`, and `iam:CreateAccessKey` permissions. +- Enable Cloudtrail, GuardDuty, AWS Config, and Security Hub across all regions for continuous monitoring of root and IAM activity. +- Review your organization’s playbooks and detection coverage for root-level persistence techniques, and update procedures as needed. + +**4. Post-incident actions** +- Notify AWS account owners and your security operations center of the incident. +- Conduct a post-mortem to determine the initial vector of compromise (e.g., stolen credentials, misconfigured role chaining, or insufficient MFA). +- Update alerting thresholds and detection logic to minimize mean time to detect (MTTD) and respond (MTTR). + + +*Additional information* + + +- **AWS Incident Response Playbooks** + - https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-CredCompromise.md[IRP-CredCompromise] – Containment and recovery for suspected credential abuse. +- **AWS Customer Playbook Framework** + - https://github.com/aws-samples/aws-customer-playbook-framework/blob/a8c7b313636b406a375952ac00b2d68e89a991f2/docs/Compromised_IAM_Credentials.md[Compromised_IAM_Credentials.md] – Steps to contain, investigate, and recover from credential compromise. +- **AWS Documentation** + - https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateLoginProfile.html[CreateLoginProfile API Reference] + - https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html[Root User Best Practices] + + +==== Rule query + + +[source, js] +---------------------------------- +any where event.dataset == "aws.cloudtrail" + and event.provider == "iam.amazonaws.com" + and event.action == "CreateLoginProfile" + and aws.cloudtrail.user_identity.type == "Root" + and event.outcome == "success" + and not stringContains(aws.cloudtrail.request_parameters, "userName=") + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-aws-iam-user-created-access-keys-for-another-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-aws-iam-user-created-access-keys-for-another-user.asciidoc new file mode 100644 index 0000000000..4b97c48143 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-aws-iam-user-created-access-keys-for-another-user.asciidoc @@ -0,0 +1,209 @@ +[[prebuilt-rule-8-19-9-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*: 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://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*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + + +*Investigating AWS 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* + + +> AWS IR playbooks classify unauthorized credential creation as a **Priority-1 incident** because it may allow persistence or privilege escalation. +> The following steps scale for organizations with or without a dedicated IR team. + +**1. 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. + +**2. 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. + +**3. 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. + +**4. 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 event.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, + event.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.* + +---------------------------------- + +*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-9/prebuilt-rule-8-19-9-aws-management-console-brute-force-of-root-user-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-aws-management-console-brute-force-of-root-user-identity.asciidoc new file mode 100644 index 0000000000..4281aa6aaf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-aws-management-console-brute-force-of-root-user-identity.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-9-aws-management-console-brute-force-of-root-user-identity]] +=== AWS Management Console Brute Force of Root User Identity + +Identifies a high number of failed authentication attempts to the AWS management console for the Root user identity. An adversary may attempt to brute force the password for the Root user identity, as it has complete access to all services and resources for the AWS account. + +*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://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Sign-In +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS Management Console Brute Force of Root User Identity* + + +The AWS Management Console provides a web interface for managing AWS resources. Because the root user has unrestricted privileges, repeated failed console login attempts targeting this identity represent a high-risk credential access event. Even if no login succeeded, this activity may indicate reconnaissance, password spraying, or credential stuffing attempts targeting the root user. + +This rule uses a threshold rule that detects a high number of failed `ConsoleLogin` events (`event.outcom: failure` with `userIdentity.type: Root`) within a short timeframe from the same IP address or user agent. +Threshold rules only summarize grouped field values, so analysts must use timeline to review the actual events that triggered the alert. + + +*Possible investigation steps* + + +- **Review in Timeline.** + Open the alert and *Investigate in timeline* to view the individual CloudTrail events contributing to the threshold alert. Review: + - `source.ip`, `user_agent.original`, `geo fields` and `@timestamp` for each failure. + - Look for patterns such as distributed sources or repeated retries at consistent intervals. + - Look for any corresponding successful `ConsoleLogin` events around the same timeframe from the same IP or agent. + +- **Assess IP reputation and geolocation.** + Use IP intelligence tools to evaluate whether the source addresses belong to known cloud providers, TOR nodes, or foreign regions outside your normal operations. + - Correlate against `cloud.region` and `geo fields` and compare with expected login locations for your organization. + +- **Check for related activity.** + Review CloudTrail for other API calls from the same source IP (for example, `GetSessionToken`, `AssumeRole`, or `ListUsers`) that may indicate scripted credential testing or discovery. + +- **Correlate with GuardDuty findings.** + GuardDuty may raise complementary findings for anomalous console login behavior or brute force attempts. Review recent GuardDuty and AWS Config alerts for the same timeframe. + +- **Determine business context.** + Confirm whether the source IPs are internal (for example, corporate VPN, IT admin network) or part of legitimate red-team or third-party testing. If uncertain, treat as suspicious. + + +*False positive analysis* + + +- **Forgotten or mistyped credentials.** + Repeated failed logins from known internal IPs could indicate a legitimate user typing errors. Validate by checking if a successful root login followed soon after. +- **Automation or scanners.** + Misconfigured monitoring tools or old browser sessions attempting to reuse cached credentials may trigger this rule. +- **Planned penetration testing.** + Red-team or security testing activities can generate deliberate brute force attempts. Verify via ticketing or testing schedules. + + +*Response and remediation* + + +> The AWS Incident Response Playbooks classify root login attempts as Priority-1 credential compromise events. +> Follow these steps whether or not your organization has a formal IR team. + +**1. Immediate containment** +- **Check for success.** + After pivoting to Timeline, confirm whether any `ConsoleLogin` events from the same IP or user agent show `event.oucome: success`. + - If a successful login occurred, immediately follow the *AWS Management Console Root Login* rule investigation guide. +- **Rotate the root password.** + Use AWS’s password reset function to set a strong, unique password stored in an offline vault. +- **Enable or verify Multi-Factor Authentication (MFA)** on the root account. If MFA was already configured, review the device registration for changes or suspicious resets. +- **Block offending IPs or networks.** + Use AWS WAF, VPC network ACLs, or Security Groups to temporarily block the IPs used in the failed attempts. +- **Alert internal teams.** + Notify your security operations or cloud governance teams of the brute force pattern and actions taken. + +**2. Evidence preservation** +- Export all failed `ConsoleLogin` events visible in Timeline (±30 minutes around the alert window) to a restricted evidence bucket. +- Preserve GuardDuty findings, AWS Config history, and CloudTrail logs for the same timeframe for further analysis. + +**3. Scoping and investigation** +- Query CloudTrail across other AWS accounts and regions for additional failed or successful `ConsoleLogin` events from the same IPs. +- Check IAM activity for simultaneous key creation, role modifications, or new users — signs of lateral or parallel intrusion attempts. +- Review network telemetry (VPC Flow Logs, CloudFront, WAF) to determine whether the activity originated from a distributed or scripted attack pattern. + +**4. Recovery and hardening** +- Confirm MFA is enabled and enforced on the root account. +- Remove any root access keys (none should exist under normal security posture). +- Enable organization-wide CloudTrail, GuardDuty, and Security Hub across all regions. +- Set up real-time alerts for any future `ConsoleLogin` failures from the root user exceeding expected baselines. +- Store root credentials offline with dual-custody and document controlled access procedures. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks[AWS IR Playbooks]:** See “Credential Compromise” and “Account Compromise” for investigation, containment, and escalation guidance. +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]:** Reference runbooks for failed-login response, evidence preservation, and MFA enforcement. +- **AWS Documentation:** https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root[Tasks that require the root user]. +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset:aws.cloudtrail and +event.provider:signin.amazonaws.com and +event.action:ConsoleLogin and +aws.cloudtrail.user_identity.type:Root and +event.outcome:failure + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-aws-management-console-root-login.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-aws-management-console-root-login.asciidoc new file mode 100644 index 0000000000..3cf9ae9083 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-aws-management-console-root-login.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-9-aws-management-console-root-login]] +=== AWS Management Console Root Login + +Identifies a successful login to the AWS Management Console by the Root user. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html + +*Tags*: + +* 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 + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS Management Console Root Login* + + +The AWS root user is the original identity with unrestricted privileges over every resource in the account. Because it bypasses IAM boundaries and carries irreversible privileges, any successful root console login should be treated as a critical security event. AWS explicitly recommends locking away the root credentials and only using them for a small number of account-level administrative tasks (for example, closing an account, modifying support plans, or restoring MFA). See https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root[Tasks that require the root user]. + +This rule detects a successful AWS Management Console login by the root user (`ConsoleLogin` events with `userIdentity.type: Root` and `event.outcome: Success`). + + +*Possible investigation steps* + + +- **Confirm legitimacy.** + Contact the designated root credential custodian or account owner to verify whether this login was expected and approved. Root access should only occur under documented change-control conditions. +- **Review contextual event details.** + Examine the CloudTrail fields in the alert: + - `source.ip` – does it match known corporate IPs or expected admin VPNs? + - `user_agent.original` – browser or automation? + - `geo fields` – consistent with normal operations? + - `@timestamp` – within a planned maintenance window? +- **Check for prior or subsequent root activity.** + Query CloudTrail for the last 30–90 days for any other root logins or root-initiated API calls. Multiple or recent root logins can indicate credential misuse. +- **Correlate follow-on actions.** + Look for risky API calls immediately after the login, such as: + - `CreateUser`, `CreateAccessKey`, `AttachRolePolicy`, `PutBucketPolicy`, `UpdateAssumeRolePolicy`, `DeleteTrail`, or `StopLogging`. + These actions may indicate persistence or cover-up attempts. +- **Cross-account verification.** + If the root user is federated through AWS Organizations or linked accounts, confirm no simultaneous logins occurred elsewhere. + + +*False positive analysis* + + +- **Planned administrative actions.** + Some rare maintenance tasks require root credentials (for example, payment method updates). If the login aligns with documented change control and was performed using MFA by the approved owner, the alert can be closed as benign. +- **Third-party managed account scenarios.** + Managed service providers may log in as root during onboarding or support activities. Confirm via ticketing or contractual documentation. + + +*Response and remediation* + + +> The AWS Incident Response Playbooks classify root logins as **Priority-1 events** due to full-environment control. Follow these steps whether or not you have a dedicated IR team. + +**1. Immediate verification and containment** +- If the login was not authorized or cannot be confirmed quickly: + - Reset the root password using the AWS Management Console. + - Rotate or remove any root access keys (root keys should normally not exist). + - Ensure MFA is enabled and enforced on the root account. + - Notify your security operations or cloud governance team. + +**2. Evidence preservation** +- Export the alert’s CloudTrail record and all subsequent events for 1 hour after the login. + Store them in a restricted, immutable S3 evidence bucket. +- Retain related GuardDuty findings, AWS Config history, and CloudTrail logs for the same period. + +**3. Scope and investigation** +- Review additional events under the same `source.ip` to detect resource creation, IAM changes, or billing actions. +- Inspect newly created users, roles, or keys since the login time to identify potential persistence mechanisms. +- Check for any disabled or deleted CloudTrail trails, Security Hub findings suppression, or logging configuration changes. + +**4. Recovery and hardening** +- Confirm MFA is working and only the authorized owner can access the root credentials. +- Store root credentials in an offline vault under dual-custody control. +- Enable organization-wide CloudTrail, GuardDuty, and Security Hub across all regions. +- Implement policy and automation to alert on any future `userIdentity.type: Root` logins in real time. +- Conduct a short post-incident review to update root-access procedures and reinforce least-privilege IAM practices. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks[AWS IR Playbooks]:** See “Account Compromise” and “Credential Compromise” playbooks for containment and recovery procedures. +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]:** Reference “Account Access Investigation” for evidence handling and credential rotation steps. +- **AWS Documentation:** https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root[Tasks that require the root user]. +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset:aws.cloudtrail and +event.provider:signin.amazonaws.com and +event.action:ConsoleLogin and +aws.cloudtrail.user_identity.type:Root 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: 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-9/prebuilt-rule-8-19-9-aws-sign-in-console-login-with-federated-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-aws-sign-in-console-login-with-federated-user.asciidoc new file mode 100644 index 0000000000..30d10c8a5e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-aws-sign-in-console-login-with-federated-user.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-9-aws-sign-in-console-login-with-federated-user]] +=== AWS Sign-In Console Login with Federated User + +Identifies when a federated user logs into the AWS Management Console. Federated users are typically given temporary credentials to access AWS services. If a federated user logs into the AWS Management Console without using MFA, it may indicate a security risk, as MFA adds an additional layer of security to the authentication process. However, CloudTrail does not record whether a Federated User utilized MFA as part of authentication — that MFA decision often occurs at a third-party IdP (e.g., Okta, Azure AD, Google). As a result, CloudTrail fields such as MFAUsed / mfaAuthenticated appear as “No/false” for federated console logins even if IdP MFA was required. This alert should be correlated with IdP authentication logs to verify whether MFA was enforced for the session. Increase priority if you find a related "GetSigninToken" event whose source IP / ASN / geo or user-agent differs from the subsequent "ConsoleLogin" (possible token relay/abuse). Same-IP/UA pairs within a short window are more consistent with expected operator behavior and can be triaged with lower severity. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hackingthe.cloud/aws/post_exploitation/create_a_console_session_from_iam_credentials/ + +*Tags*: + +* Domain: Cloud +* Data Source: Amazon Web Services +* Data Source: AWS +* Data Source: AWS Sign-In +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS Sign-In Console Login with Federated User* + + +Federated users in AWS are granted temporary credentials to access resources, often without the need for a permanent account. This setup is convenient but can be risky if not properly secured with multi-factor authentication (MFA). Adversaries might exploit this by using stolen or misconfigured credentials to gain unauthorized access. CloudTrail alone cannot reliably indicate MFA usage for federated logins. This rule surfaces potentially risky access for analyst review and IdP correlation. + + +*Possible investigation steps* + + +- **Identify the prinicipal involved** + - `aws.cloudtrail.user_identity.arn` (federated session ARN) + - `aws.cloudtrail.user_identity.session_context.session_issuer.*` (role ARN/name, account) of the identity that created the federated session. +- **Investigate the source context** + - examine `source.ip`, ASN, `geo` fields, and `user_agent.original` + - Compare against normal IP ranges, known user-agents and expected locations for this identity + +*Correlate to raise/lower priority* + +- **Check IdP MFA:** Find the corresponding IdP login around the same time and verify MFA was required and passed. If IdP shows **no MFA**, raise severity. +- **Federation token pivot:** Look for a nearby `signin.amazonaws.com` `GetSigninToken` API call. + - **More suspicious:** token creation and console login from different public IPs/ASNs/geo fields. + - **Less suspicious:** same IP and expected user agents within ~10–15 minutes (typical operator behavior). +- **Rareness/anomaly signals:** new/rare role or session issuer, rare source IP/ASN/geo, unusual time-of-day, multiple ConsoleLogin events from disparate networks in a short window. +- Review recent activity associated with the federated user to identify any unusual or unauthorized actions that may have occurred following the login event. +- Assess the configuration and policies of the Identity Provider (IdP) used for federated access to ensure MFA is enforced and properly configured for all users. + + +*Related rules* + +- AWS Sign-In Token Created - f754e348-f36f-4510-8087-d7f29874cc12 + + +*False positive analysis* + +- Organizations using SSO for console access will routinely see federated `ConsoleLogin` where CloudTrail shows `MFAUsed: "No"` — this is expected due to IdP-side MFA. +- Internal tools/automation that create federation links (`GetSigninToken`) for operators. +- Maintain allow-lists for corp/VPN CIDRs, approved ASNs, and known automation user-agents. + + +*Response and remediation* + +- If IdP confirms MFA and the source context is expected: document and close. +- If IdP shows no MFA or context is suspicious: + - Notify the security team and relevant stakeholders about the potential security breach to ensure coordinated response efforts. + - Disable/lock the IdP account pending review; invalidate IdP sessions if supported. + - Temporarily restrict access (e.g., SCPs, session policies, IP-based conditions). + - Conduct a thorough review of AWS CloudTrail logs to identify any suspicious activities or unauthorized access attempts associated with both the intitiating user and the federated user account. + - Hunt for a preceding `GetSigninToken` from a different IP/ASN/UA (possible token relay). + - Ensure IdP policy enforces MFA for AWS app access; re-verify role trust and least-privilege policies. +- Implement or enforce multi-factor authentication (MFA) for all federated user accounts to enhance security and prevent similar incidents in the future. +- Review and update IAM policies and roles associated with federated users to ensure they follow the principle of least privilege. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" and + event.provider: "signin.amazonaws.com" and + event.action : "ConsoleLogin" and + aws.cloudtrail.user_identity.type: "FederatedUser" 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-aws-sign-in-root-password-recovery-requested.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-aws-sign-in-root-password-recovery-requested.asciidoc new file mode 100644 index 0000000000..9e872a5e91 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-aws-sign-in-root-password-recovery-requested.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-9-aws-sign-in-root-password-recovery-requested]] +=== AWS Sign-In Root Password Recovery Requested + +Identifies a password recovery request for the AWS account root user. In AWS, the PasswordRecoveryRequested event from signin.amazonaws.com applies to the root user’s “Forgot your password?” flow. Other identity types, like IAM and federated users, do not generate this event. This alert indicates that someone initiated the root password reset workflow for this account. Verify whether this was an expected action and review identity provider notifications/email to confirm legitimacy. + +*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://web.archive.org/web/20230930161727/https://www.cadosecurity.com/an-ongoing-aws-phishing-campaign/ + +*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*: 210 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS Sign-In Root Password Recovery Requested* + + +In AWS, a `PasswordRecoveryRequested` event from `signin.amazonaws.com` is only generated for the root user during the “Forgot your password?” workflow. Other identity types (IAM or federated users) do not trigger this event. A root password recovery request is a critical identity security event that could indicate a legitimate recovery by the account owner or a malicious attempt to gain full administrative access. + + +*Possible investigation steps* + + +- **Verify the event details.** + Review the alert fields (`source.ip`, `user_agent.original`, `cloud.region`, and `@timestamp`) to confirm when and from where the request originated. +- **Confirm legitimacy.** + Contact the account owner or credential custodian to verify whether they initiated the password recovery. + AWS will also send an email notification to the root account email address, check whether the owner received and acknowledged this. +- **Check CloudTrail for related events.** + Search for any subsequent `ConsoleLogin` events for the root user, or IAM changes (for example, `CreateAccessKey`, `CreateUser`, or `AttachUserPolicy`) shortly after the recovery request. +- **Assess IP reputation and location.** + Validate whether the `source.ip` aligns with known admin networks or expected geographies. + Suspicious indicators include foreign IPs, anonymization services, or unfamiliar user agents. +- **Correlate with other alerts.** + Review other AWS security detections (for example, root logins, MFA disablement, or IAM policy changes) around the same timeframe. + + +*False positive analysis* + + +- **Expected maintenance activity.** + If the root account owner confirms that the password reset was intentional (for example, for account recovery or planned credential rotation), the alert may be safely dismissed. +- **Testing or account verification.** + Security or compliance teams occasionally test password recovery flows. Confirm via ticketing or planned maintenance documentation. + + +*Response and remediation* + + +**1. Immediate actions** +- **If confirmed legitimate:** + - Ensure that MFA is enabled and operational for the root account. + - Encourage rotation of the root password if not recently updated. +- **If unconfirmed or suspicious:** + - Immediately reset the root password using the legitimate AWS recovery email link. + - Review the AWS account’s email for password-recovery notifications and secure that inbox (change its password, enable MFA). + - Check for new successful root logins or unexpected IAM changes since the recovery attempt. + +**2. Evidence preservation** +- Export the `PasswordRecoveryRequested` event from CloudTrail (±30 minutes). +- Preserve all `signin.amazonaws.com` and root `ConsoleLogin` events for the next 24 hours. +- Store this evidence in a restricted S3 bucket with Object Lock enabled. + +**3. Scoping and investigation** +- Review all root-level activities within the past 24–48 hours. + Focus on administrative actions such as `CreateAccessKey`, `UpdateAccountPasswordPolicy`, or `DisableMFA`. +- Correlate with GuardDuty findings and AWS Config change history for any unauthorized modifications. + +**4. Recovery and hardening** +- Confirm MFA is enforced on the root account. +- Rotate all root credentials and ensure no access keys exist for the root user (root keys should never be active). +- Secure the associated email account (password reset notifications are sent there). +- Enable Cloudtrail, GuardDuty, Security Hub, and AWS Config across all regions. +- Review account recovery procedures to ensure multiple custodians are aware of the legitimate process. + + +*Additional information* + + +- **AWS Incident Response Playbooks:** + and https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-CredCompromise.md[`IRP-Credential-Compromise.md`] for procedures related to root account credential recovery and unauthorized access attempts. +- **AWS Customer Playbook Framework:** + See https://github.com/aws-samples/aws-customer-playbook-framework/blob/a8c7b313636b406a375952ac00b2d68e89a991f2/docs/Compromised_IAM_Credentials.md[`Compromised_IAM_Credentials.md`] for guidance on containment, evidence collection, and recovery validation. +- **AWS Documentation:** https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html[AWS account root user best practices]. +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset:aws.cloudtrail and +event.provider:signin.amazonaws.com and +event.action:PasswordRecoveryRequested 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-azure-compute-restore-point-collection-deleted-by-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-azure-compute-restore-point-collection-deleted-by-unusual-user.asciidoc new file mode 100644 index 0000000000..36d6ad2f11 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-azure-compute-restore-point-collection-deleted-by-unusual-user.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-9-azure-compute-restore-point-collection-deleted-by-unusual-user]] +=== Azure Compute Restore Point Collection Deleted by Unusual User + +Identifies the deletion of Azure Restore Point Collections by a user who has not previously performed this activity. Restore Point Collections contain recovery points for virtual machines, enabling point-in-time recovery capabilities. Adversaries may delete these collections to prevent recovery during ransomware attacks or to cover their tracks during malicious operations. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*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.microsoft.com/en-us/security/blog/2023/07/25/storm-0501-ransomware-attacks-expanding-to-hybrid-cloud-environments/ + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* 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 Azure Compute Restore Point Collection Deleted by Unusual User* + + +Azure Compute Restore Point Collections are critical components for disaster recovery, containing snapshots that enable point-in-time +recovery of virtual machines. Deletion of these collections can severely impact an organization's ability to recover from +incidents, making them attractive targets for adversaries conducting ransomware attacks or attempting to cover their tracks. + +This rule detects when a user who has not previously deleted Restore Point Collections performs this operation, which may +indicate unauthorized activity or a compromised account. + + +*Possible investigation steps* + + +- Review the `azure.activitylogs.identity.claims_initiated_by_user.name` field to identify the specific user who performed the deletion operation. +- Investigate the `azure.resource.id` or `azure.resource.name` fields to identify which Restore Point Collection was deleted and assess its criticality to business operations. +- Review the timeline of the deletion event and correlate it with other security events or user activities to identify any suspicious patterns or related activities. +- Verify whether the user account has legitimate access to perform this operation and whether this deletion was authorized through change management processes. +- Check for any other unusual activities by the same user account around the time of the deletion, such as privilege escalation attempts or access to other sensitive resources. +- Investigate whether there are any active alerts or indicators of compromise related to ransomware activity in the environment. + + +*False positive analysis* + + +- Routine administrative activities by infrastructure teams may trigger this alert when team members rotate or new administrators are onboarded. Create exceptions for known administrative accounts after verification. +- Automated cleanup scripts or Azure policies that periodically remove old restore points may cause alerts. Identify and exclude service accounts used for these automated operations. +- Planned decommissioning activities or migration projects may involve legitimate deletion of restore point collections. Document these activities and create temporary exceptions during known maintenance windows. +- Testing and development environments may see frequent creation and deletion of resources. Consider excluding these environments from monitoring or adjusting the rule to focus on production resources only. + + +*Response and remediation* + + +- Immediately verify the legitimacy of the deletion operation with the user or their manager. If the activity is unauthorized, proceed with incident response procedures. +- If unauthorized deletion is confirmed, immediately isolate the affected user account to prevent further malicious activity. Reset credentials and review account permissions. +- Check if the deleted Restore Point Collection can be recovered through Azure backup services or other recovery mechanisms. +- Review and audit all recent activities performed by the affected user account to identify other potentially malicious actions. +- Assess the impact on disaster recovery capabilities and inform relevant stakeholders about potential recovery limitations. +- Review access controls and permissions for Restore Point Collection management, implementing principle of least privilege where necessary. +- If ransomware activity is suspected, escalate to the security incident response team and implement broader containment measures, including checking for other indicators of ransomware such as deletion of Recovery Services vaults or backup fabric containers. +- Document the incident and update detection rules or procedures based on lessons learned. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: azure.activitylogs and + event.action: "MICROSOFT.COMPUTE/RESTOREPOINTCOLLECTIONS/DELETE" and + event.outcome: (Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-azure-compute-restore-point-collections-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-azure-compute-restore-point-collections-deleted.asciidoc new file mode 100644 index 0000000000..be6a3e1dbd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-azure-compute-restore-point-collections-deleted.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-9-azure-compute-restore-point-collections-deleted]] +=== Azure Compute Restore Point Collections Deleted + +Identifies multiple Azure Restore Point Collections being deleted by a single user within a short time period. Restore Point Collections contain recovery points for virtual machines, enabling point-in-time recovery capabilities. Mass deletion of these collections is a common tactic used by adversaries during ransomware attacks to prevent victim recovery or to maximize impact during destructive operations. Multiple deletions in rapid succession may indicate malicious intent. + +*Rule type*: threshold + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*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.microsoft.com/en-us/security/blog/2023/07/25/storm-0501-ransomware-attacks-expanding-to-hybrid-cloud-environments/ + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* 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 Azure Compute Restore Point Collections Deleted* + + +Azure Compute Restore Point Collections are essential for disaster recovery, containing snapshots that enable point-in-time recovery +of virtual machines. The ability to quickly restore VMs from these recovery points is critical for business continuity and +incident response. + +Adversaries conducting ransomware attacks or destructive operations often target backup and recovery infrastructure to +prevent victims from recovering their systems without paying a ransom. Mass deletion of Restore Point Collections is a +key indicator of such activity and represents a significant threat to an organization's resilience. + +This rule detects when a single user deletes multiple Restore Point Collections within a short time window, which is +unusual in normal operations and highly suspicious when observed. + + +*Possible investigation steps* + + +- Identify the user account responsible for the deletions by examining the `azure.activitylogs.identity.claims_initiated_by_user.name` or `user.name` field in the alerts. +- Review all deletion events from this user in the specified time window to determine the scope and scale of the activity. +- Check the `azure.resource.id` and `azure.resource.name` fields to identify which Restore Point Collections were deleted and assess their criticality to business operations. +- Verify whether the user account has legitimate administrative access and whether these deletions were authorized through change management or documented maintenance activities. +- Investigate the timeline of events leading up to the deletions, looking for other suspicious activities such as: + - Privilege escalation attempts + - Deletion of other backup resources (Recovery Services vaults, backup policies) + - Unusual authentication patterns or geographic anomalies + - Creation of persistence mechanisms or backdoor accounts +- Review Azure Activity Logs for any failed deletion attempts or access denied events that might indicate reconnaissance activities preceding the successful deletions. +- Check for related data destruction activities, such as deletion of virtual machines, disks, or storage accounts. +- Correlate with sign-in logs to identify any unusual login patterns or potential account compromise indicators. + + +*False positive analysis* + + +- Large-scale decommissioning projects may involve legitimate deletion of multiple Restore Point Collections. Verify with change management records and create temporary exceptions during documented maintenance windows. +- Infrastructure migrations from Azure to another platform or between Azure regions may involve cleanup of old restore points. Confirm these activities are planned and documented before excluding them from monitoring. +- Automated cleanup scripts designed to manage storage costs by removing old restore points might trigger this alert. Identify the service accounts used for these operations and adjust the threshold or create exceptions as appropriate. +- Testing and development environments that are frequently rebuilt may see regular bulk deletion of resources. Consider excluding non-production environments or adjusting the threshold for these subscriptions. +- Review the threshold value (currently set to 3) and adjust based on your environment's baseline if legitimate administrative activities are frequently triggering false positives. + + +*Response and remediation* + + +- Immediately isolate the affected user account to prevent further malicious activity. Reset credentials and revoke active sessions. +- Verify the legitimacy of the deletions with the account owner or their manager. If unauthorized, treat this as a confirmed security incident and activate incident response procedures. +- Check if any of the deleted Restore Point Collections can be recovered through Azure backup services, soft-delete features, or other recovery mechanisms. Time is critical as retention policies may limit recovery windows. +- Conduct a comprehensive review of all recent activities by the affected user account across the Azure environment to identify other potentially malicious actions or compromised resources. +- Assess the current disaster recovery posture and identify which VMs are now missing recovery points. Prioritize creation of new restore points for critical systems if they are unaffected. +- Review and strengthen access controls for Restore Point Collection management, implementing stricter RBAC policies and requiring multi-factor authentication for privileged operations. +- If ransomware activity is suspected or confirmed: + - Activate the organization's ransomware response plan + - Isolate affected systems to prevent spread + - Search for ransomware indicators across the environment (encrypted files, ransom notes, suspicious processes) + - Check for deletion of other recovery resources (Recovery Services vaults, backups, snapshots) + - Do not pay ransom demands; engage with law enforcement and cybersecurity incident response teams +- Implement additional monitoring and alerting for related activities such as: + - Deletion of Recovery Services resources + - Modifications to backup policies + - Unusual access to disaster recovery infrastructure +- Document the incident thoroughly and conduct a post-incident review to identify gaps in security controls and opportunities for improvement. +- Consider implementing Azure Resource Locks on critical recovery resources to prevent accidental or malicious deletion. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: azure.activitylogs and + event.action: "MICROSOFT.COMPUTE/RESTOREPOINTCOLLECTIONS/DELETE" and + event.outcome: (Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-azure-storage-account-deletion-by-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-azure-storage-account-deletion-by-unusual-user.asciidoc new file mode 100644 index 0000000000..029342e9f3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-azure-storage-account-deletion-by-unusual-user.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-9-azure-storage-account-deletion-by-unusual-user]] +=== Azure Storage Account Deletion by Unusual User + +Identifies when an Azure Storage Account is deleted. Adversaries may delete storage accounts to disrupt operations, destroy evidence, or cause denial of service. This activity could indicate an attacker attempting to cover their tracks after data exfiltration or as part of a destructive attack. Monitoring storage account deletions is critical for detecting potential impact on business operations and data availability. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* + +*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.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* 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 Azure Storage Account Deletion by Unusual User* + + +Azure Storage Accounts provide scalable cloud storage for applications and services. Deletion of storage accounts is a high-impact operation that permanently removes all contained data including blobs, files, queues, and tables. Adversaries may delete storage accounts to destroy evidence of their activities, disrupt business operations, or cause denial of service as part of ransomware or destructive attacks. This detection monitors for successful storage account deletion operations to identify potential malicious activity. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the user or service principal that initiated the storage account deletion by examining the principal ID, UPN and user agent fields. +- Check the specific storage account name in `azure.resource.name` to understand which storage resources were deleted and assess the business impact. +- Investigate the timing of the event to correlate with any other suspicious activities, such as unusual login patterns, privilege escalation attempts, or other resource deletions. +- Examine the user's recent activity history to identify any other storage accounts or Azure resources that were deleted or modified by the same principal. +- Verify if the storage account deletion aligns with approved change requests or maintenance windows in your organization. +- Check if the deleted storage account contained critical data and whether backups are available for recovery. +- Review any related alerts or activities such as data exfiltration, configuration changes, or access policy modifications that occurred before the deletion. +- Investigate if the account was recently compromised by checking for suspicious authentication events or privilege escalations. + + +*False positive analysis* + + +- Legitimate decommissioning of unused storage accounts may trigger this alert. Document approved storage account cleanup activities and coordinate with infrastructure teams to understand planned deletions. +- DevOps automation tools might delete temporary storage accounts as part of infrastructure lifecycle management. Identify service principals used by CI/CD pipelines and consider creating exceptions for these automated processes. +- Testing and development environments may have frequent storage account creation and deletion cycles. Consider filtering out non-production storage accounts if appropriate for your environment. +- Cost optimization initiatives may involve deleting unused or redundant storage accounts. Coordinate with finance and infrastructure teams to understand planned resource optimization activities. + + +*Response and remediation* + + +- Immediately investigate whether the deletion was authorized by verifying with the account owner or relevant stakeholders. +- If the deletion was unauthorized, attempt to recover the storage account if soft-delete is enabled, or restore data from backups. +- Disable the compromised user account or service principal if unauthorized activity is confirmed and investigate how the credentials were obtained. +- Review and restrict Azure RBAC permissions to ensure only authorized users have storage account deletion capabilities (requires Contributor or Owner role). +- Implement Azure Resource Locks to prevent accidental or malicious deletion of critical storage accounts. +- Configure Azure Activity Log alerts to notify security teams immediately when storage accounts are deleted. +- Conduct a full security assessment to identify any other compromised resources or accounts and look for indicators of broader compromise. +- Document the incident and update security policies and procedures to prevent similar incidents in the future. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: azure.activitylogs and + azure.activitylogs.operation_name: "MICROSOFT.STORAGE/STORAGEACCOUNTS/DELETE" and + azure.activitylogs.identity.claims_initiated_by_user.name: * + +---------------------------------- + +*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: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-azure-storage-account-deletions-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-azure-storage-account-deletions-by-user.asciidoc new file mode 100644 index 0000000000..bcf7941cdb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-azure-storage-account-deletions-by-user.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-9-azure-storage-account-deletions-by-user]] +=== Azure Storage Account Deletions by User + +Identifies when a single user or service principal deletes multiple Azure Storage Accounts within a short time period. This behavior may indicate an adversary attempting to cause widespread service disruption, destroy evidence, or execute a destructive attack such as ransomware. Mass deletion of storage accounts can have severe business impact and is rarely performed by legitimate administrators except during controlled decommissioning activities. + +*Rule type*: threshold + +*Rule indices*: + +* logs-azure.activitylogs-* + +*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.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* 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 Azure Storage Account Deletions by User* + + +Azure Storage Accounts are critical infrastructure components that store application data, backups, and business-critical information. Mass deletion of storage accounts is an unusual and high-impact activity that can result in significant data loss and service disruption. Adversaries may perform bulk deletions to destroy evidence after data exfiltration, cause denial of service, or as part of ransomware campaigns targeting cloud infrastructure. This detection identifies when a single identity deletes multiple storage accounts in a short timeframe, which is indicative of potentially malicious activity. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the user or service principal that initiated the multiple storage account deletions by examining the principal ID, UPN and user agent fields in `azure.activitylogs.identity.claims_initiated_by_user.name`. +- Check the specific storage account names in `azure.resource.name` to understand which storage resources were deleted and assess the overall business impact. +- Investigate the timing and sequence of deletions to determine if they followed a pattern consistent with automated malicious activity or manual destruction. +- Examine the user's recent activity history including authentication events, privilege changes, and other Azure resource modifications to identify signs of account compromise. +- Verify if the storage account deletions align with approved change requests, maintenance windows, or decommissioning activities in your organization. +- Check if the deleted storage accounts contained critical data and whether backups are available for recovery. +- Review any related alerts or activities such as data exfiltration, unusual authentication patterns, or privilege escalation that occurred before the deletions. +- Investigate if other Azure resources (VMs, databases, resource groups) were also deleted or modified by the same principal. +- Check the authentication source and location to identify if the activity originated from an expected network location or potentially compromised session. + + +*False positive analysis* + + +- Legitimate bulk decommissioning of storage accounts during infrastructure cleanup may trigger this alert. Document approved resource cleanup activities and coordinate with infrastructure teams to create exceptions during planned maintenance windows. +- Infrastructure-as-Code (IaC) automation tools or CI/CD pipelines may delete multiple test or temporary storage accounts. Identify service principals used by automation tools and consider creating exceptions for these identities when operating in non-production environments. +- Cloud resource optimization initiatives may involve bulk deletion of unused storage accounts. Coordinate with finance and infrastructure teams to understand planned cost optimization activities and schedule them during documented maintenance windows. +- Disaster recovery testing or blue-green deployment strategies may involve deletion of multiple storage accounts. Work with DevOps teams to identify these patterns and create time-based exceptions during testing periods. + + +*Response and remediation* + + +- Immediately investigate whether the deletions were authorized by verifying with the account owner or relevant stakeholders. +- If the deletions were unauthorized, disable the compromised user account or service principal immediately to prevent further damage. +- Attempt to recover deleted storage accounts if soft-delete is enabled, or restore data from backups for critical storage accounts. +- Review and audit all Azure RBAC permissions to identify how the attacker gained storage account deletion capabilities (requires Contributor or Owner role). +- Conduct a full security assessment to identify the initial access vector and any other compromised accounts or resources. +- Implement Azure Resource Locks on all critical storage accounts to prevent accidental or malicious deletion. +- Configure Azure Policy to require approval workflows for storage account deletions using Azure Blueprints or custom governance solutions. +- Enable Azure Activity Log alerts to notify security teams immediately when storage accounts are deleted. +- Escalate the incident to the security operations center (SOC) or incident response team for investigation of potential broader compromise. +- Document the incident and update security policies, playbooks, and procedures to prevent similar incidents in the future. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: azure.activitylogs and + azure.activitylogs.operation_name: "MICROSOFT.STORAGE/STORAGEACCOUNTS/DELETE" and + azure.activitylogs.identity.claims_initiated_by_user.name: * + +---------------------------------- + +*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: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-azure-storage-blob-retrieval-via-azcopy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-azure-storage-blob-retrieval-via-azcopy.asciidoc new file mode 100644 index 0000000000..e917adc7f3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-azure-storage-blob-retrieval-via-azcopy.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-9-azure-storage-blob-retrieval-via-azcopy]] +=== Azure Storage Blob Retrieval via AzCopy + +Identifies successful GetBlob operations on Azure Storage Accounts using AzCopy user agent with SAS token authentication. AzCopy is a command-line utility for copying data to and from Azure Storage. While legitimate for data migration, adversaries may abuse AzCopy with compromised SAS tokens to exfiltrate data from Azure Storage Accounts. This rule detects the first occurrence of GetBlob operations from a specific storage account using this pattern. + +*Rule type*: new_terms + +*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://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ +* https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-v10 +* https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Azure Storage +* Use Case: Threat Detection +* Tactic: Exfiltration +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Storage Blob Retrieval via AzCopy* + + +Azure Storage Accounts provide cloud storage services for blobs, files, queues, and tables. Shared Access Signatures (SAS) tokens provide delegated access to resources in a storage account with specific permissions and time constraints. AzCopy is a Microsoft command-line utility designed for efficient data transfers to and from Azure Storage. While AzCopy is a legitimate tool, adversaries may abuse it with compromised SAS tokens to exfiltrate data from Azure Storage Accounts. + + +*Possible investigation steps* + +- Review the `azure.platformlogs.properties.accountName` field to identify which storage account is being accessed and assess the sensitivity of data stored in that account. +- Examine the `azure.platformlogs.properties.objectKey` field to identify the specific blob(s) being retrieved. Determine if the accessed files contain sensitive or confidential data. +- Check the `source.address` field to identify the source IP address of the request. Investigate if this IP is unusual, unexpected, or originates from an unexpected network or geographic location. +- Review the `azure.platformlogs.uri` field to examine the SAS token parameters, including: + - `se` (expiry time): Check when the SAS token expires + - `sp` (permissions): Verify what permissions were granted (e.g., "rl" for read and list) + - `sv` (API version): Note the storage service version being used +- Examine the `azure.platformlogs.identity.tokenHash` field to identify the specific SAS token signature being used. Correlate this with SAS token generation logs to determine when and how the token was created. +- Check the `azure.platformlogs.properties.responseBodySize` field to assess the volume of data being downloaded. Multiple GetBlob operations with large response sizes may indicate bulk data exfiltration. +- Search for related GetBlob operations from the same `source.address` or with the same `azure.platformlogs.identity.tokenHash` to identify patterns of systematic data retrieval. +- Review Azure Activity Logs for recent SAS token generation events or storage account key access operations that may indicate how the adversary obtained the credentials. +- Correlate this activity with ListBlobs or ListContainers operations from the same source, as adversaries often enumerate storage contents before exfiltration. +- Investigate the `azure.resource.group` field to understand which resource group the storage account belongs to and check for any recent security events or configuration changes in that resource group. + + +*False positive analysis* + +- Routine data migration or backup operations using AzCopy with SAS tokens are common in enterprise environments. If this is expected behavior for the storage account, consider adding exceptions for specific accounts or IP ranges. +- DevOps pipelines or automated workflows may use AzCopy with SAS tokens for legitimate data transfers. Review the automation configuration and add exceptions if appropriate. +- Third-party services or partners may have authorized access to storage accounts using AzCopy and SAS tokens. Verify these relationships and create exceptions for known authorized sources. + + +*Response and remediation* + +- If unauthorized access is confirmed, immediately revoke the compromised SAS token to prevent further data exfiltration. +- Review and rotate any additional SAS tokens that may have been compromised through the same attack vector. +- Assess the scope of data accessed or exfiltrated during the unauthorized GetBlob operations and determine if sensitive data was compromised. +- Implement additional monitoring and alerting for the affected storage account to detect any further suspicious activity. +- Review and strengthen SAS token generation policies, including implementing shorter expiration times and more restrictive permissions. +- Consider implementing Azure Storage firewall rules or private endpoints to restrict access to storage accounts from trusted networks only. +- Investigate how the SAS token was compromised and remediate the initial access vector to prevent future incidents. +- Document the incident and update security procedures to prevent similar compromises in the future. + + +==== Setup + + + +*Required Azure Storage Diagnostic Logs* + + +To ensure this rule functions correctly, the following diagnostic logs must be enabled for Azure Storage Accounts: +- StorageRead: This log captures all read operations performed on blobs in the storage account, including GetBlob operations. These logs should be streamed to the Event Hub used for the Azure integration configuration. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: azure.platformlogs and + event.action: GetBlob and + azure.platformlogs.identity.type: SAS and + azure.platformlogs.properties.userAgentHeader: AzCopy* and + azure.platformlogs.statusCode: 200 + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-deprecated-aws-root-login-without-mfa.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-deprecated-aws-root-login-without-mfa.asciidoc new file mode 100644 index 0000000000..df06908499 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-deprecated-aws-root-login-without-mfa.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-9-deprecated-aws-root-login-without-mfa]] +=== Deprecated - AWS Root Login Without MFA + +Identifies attempts to login to AWS as the root user without using multi-factor authentication (MFA). Amazon AWS best practices indicate that the root user should be protected by MFA. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Route53 +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Privilege Escalation + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Deprecated - AWS Root Login Without MFA* + + +Multi-factor authentication (MFA) in AWS is a simple best practice that adds an extra layer of protection on top of your user name and password. With MFA enabled, when a user signs in to an AWS Management Console, they will be prompted for their user name and password, as well as for an authentication code from their AWS MFA device. Taken together, these multiple factors provide increased security for your AWS account settings and resources. + +For more information about using MFA in AWS, access the https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html[official documentation]. + +The AWS root account is the one identity that has complete access to all AWS services and resources in the account, which is created when the AWS account is created. AWS strongly recommends that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks. Amazon provides a https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root[list of the tasks that require root user]. + +This rule looks for attempts to log in to AWS as the root user without using multi-factor authentication (MFA), meaning the account is not secured properly. + + +*Possible investigation steps* + + +- Investigate other alerts associated with the user account during the past 48 hours. +- Examine whether this activity is common in the environment by looking for past occurrences on your logs. +- Consider the source IP address and geolocation for the calling user who issued the command. Do they look normal for the calling user? +- Examine the commands, API calls, and data management actions performed by the account in the last 24 hours. +- Contact the account owner and confirm whether they are aware of this activity. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking access to servers, +services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- While this activity is not inherently malicious, the root account must use MFA. The security team should address any potential benign true positive (B-TP), as this configuration can risk the entire cloud environment. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Identify the services or servers involved criticality. + - 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 if there are any regulatory or legal ramifications related to this activity. +- Configure multi-factor authentication for the user. +- Follow security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset:aws.cloudtrail and event.provider:signin.amazonaws.com and event.action:ConsoleLogin and + aws.cloudtrail.user_identity.type:Root and + aws.cloudtrail.console_login.additional_eventdata.mfa_used:false 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-disabling-lsa-protection-via-registry-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-disabling-lsa-protection-via-registry-modification.asciidoc new file mode 100644 index 0000000000..b8a98ef721 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-disabling-lsa-protection-via-registry-modification.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-9-disabling-lsa-protection-via-registry-modification]] +=== Disabling Lsa Protection via Registry Modification + +LSA protecton is provided to prevent nonprotected processes from reading memory and injecting code. This feature provides added security for the credentials that LSA stores and manages. Adversaries may modify the RunAsPPL registry and wait or initiate a system restart to enable Lsass credentials access. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* 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://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender for Endpoint +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Disabling Lsa Protection via Registry Modification* + + +For more information about the Lsa Protection and how it works, check the https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection[official Microsoft docs page]. + +Attackers may disable Lsa protection to access Lsass memory for credentals. This rule identifies RunAsPPL registry value modifications. + + +*Possible investigation steps* + + +- Verify the context of the change and if it's related to a planned system administration activity. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Inspect the host for suspicious or abnormal behaviors in the alert timeframe. +- Investigate abnormal behaviors observed by the subject process such as network connections, registry or file modifications, and any spawned child processes. + + +*False positive analysis* + + +- Approved changes to relax the Lsa protection for compatibility with third party solutions such as authentication plugins or alike. + + +*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. +- Restore UAC settings to the desired state. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- 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. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.data.strings != null and registry.value : "RunAsPPL" and + registry.path : "*\\SYSTEM\\*ControlSet*\\Control\\Lsa\\RunAsPPL" and + not registry.data.strings : ("1", "0x00000001", "2", "0x00000002") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* 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-9/prebuilt-rule-8-19-9-dns-global-query-block-list-modified-or-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-dns-global-query-block-list-modified-or-disabled.asciidoc new file mode 100644 index 0000000000..b3a2f7f619 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-dns-global-query-block-list-modified-or-disabled.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-9-dns-global-query-block-list-modified-or-disabled]] +=== DNS Global Query Block List Modified or Disabled + +Identifies changes to the DNS Global Query Block List (GQBL), a security feature that prevents the resolution of certain DNS names often exploited in attacks like WPAD spoofing. Attackers with certain privileges, such as DNSAdmins, can modify or disable the GQBL, allowing exploitation of hosts running WPAD with default settings for privilege escalation and lateral movement. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* endgame-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cube0x0.github.io/Pocing-Beyond-DA/ +* https://www.thehacker.recipes/ad/movement/mitm-and-coerced-authentications/wpad-spoofing +* https://www.netspi.com/blog/technical-blog/network-penetration-testing/adidns-revisited/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender for Endpoint +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 208 + +*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 DNS Global Query Block List Modified or Disabled* + + +The DNS Global Query Block List (GQBL) is a security feature in Windows environments that blocks the resolution of specific DNS names, such as WPAD, to prevent attacks like spoofing. Adversaries with elevated privileges can alter or disable the GQBL, enabling them to exploit default settings for privilege escalation. The detection rule monitors registry changes indicating such modifications, flagging potential defense evasion attempts. + + +*Possible investigation steps* + + +- Review the registry event logs to confirm the specific changes made to the DNS Global Query Block List, focusing on the registry values "EnableGlobalQueryBlockList" and "GlobalQueryBlockList". +- Identify the user account associated with the registry change event to determine if the account has elevated privileges, such as DNSAdmins, which could indicate potential misuse. +- Check for any recent changes in user permissions or group memberships that might have granted the necessary privileges to modify the GQBL. +- Investigate any other suspicious activities or alerts related to the same user or host around the time of the registry change to identify potential lateral movement or privilege escalation attempts. +- Correlate the event with network traffic logs to detect any unusual DNS queries or attempts to resolve WPAD or other blocked names, which could suggest exploitation attempts. +- Review system and security logs for any signs of unauthorized access or other indicators of compromise on the affected host. + + +*False positive analysis* + + +- Legitimate administrative changes to DNS settings by IT staff can trigger the rule. To manage this, create exceptions for known maintenance windows or authorized personnel making these changes. +- Automated scripts or software updates that modify DNS settings might be flagged. Identify and whitelist these processes if they are verified as safe and necessary for system operations. +- Changes made by security tools or network management software that adjust DNS settings for legitimate reasons can be mistaken for threats. Review and exclude these tools from monitoring if they are part of the organization's approved security infrastructure. +- In environments where WPAD is intentionally used, the absence of "wpad" in the GlobalQueryBlockList might be a normal configuration. Document and exclude these cases if they align with the organization's network design and security policies. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement. +- Revert any unauthorized changes to the DNS Global Query Block List by restoring the registry settings to their default state, ensuring WPAD and other critical entries are included. +- Conduct a thorough review of user accounts with elevated privileges, such as DNSAdmins, to identify any unauthorized access or privilege escalation. Revoke unnecessary privileges and reset credentials as needed. +- Deploy endpoint detection and response (EDR) tools to scan the affected system for additional indicators of compromise or malicious activity, focusing on defense evasion techniques. +- Monitor network traffic for signs of WPAD spoofing or other related attacks, and implement network segmentation to limit the impact of potential threats. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Update security policies and procedures to include specific measures for monitoring and protecting the DNS Global Query Block List, ensuring rapid detection and response to similar threats in the future. + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and registry.data.strings != null and +( + (registry.value : "EnableGlobalQueryBlockList" and registry.data.strings : ("0", "0x00000000")) or + (registry.value : "GlobalQueryBlockList" and not registry.data.strings : "wpad") +) + +---------------------------------- + +*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: 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-9/prebuilt-rule-8-19-9-entra-id-oauth-user-impersonation-scope-for-unusual-user-and-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-entra-id-oauth-user-impersonation-scope-for-unusual-user-and-client.asciidoc new file mode 100644 index 0000000000..a000d64fb3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-entra-id-oauth-user-impersonation-scope-for-unusual-user-and-client.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-9-entra-id-oauth-user-impersonation-scope-for-unusual-user-and-client]] +=== Entra ID OAuth user_impersonation Scope for Unusual User and Client + +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. + +*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://github.com/Flangvik/TeamFiltration +* https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign + +*Tags*: + +* 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 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating Entra ID OAuth user_impersonation Scope for Unusual User and Client* + + +Identifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth scope containing `user_impersonation`, and a token issuer type of `AzureAD`. This rule is designed to detect suspicious +OAuth user impersonation attempts in Microsoft Entra ID, particularly those involving the `user_impersonation` scope, which is often used by adversaries to gain unauthorized access to user accounts. The rule focuses on sign-in events where +the sign-in session status is `unbound`, indicating that the session is not associated with a specific device or session, making it more vulnerable to abuse. This behavior is indicative of potential account compromise or +unauthorized access attempts, especially when the user type is `Member` and the sign-in outcome is `success`. The rule aims to identify these events to facilitate timely investigation and response to potential security incidents. This is a New Terms rule that 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. + + +*Possible investigation steps* + + +- Review the `azure.signinlogs.properties.user_principal_name` field to identify the user principal involved in the OAuth workflow. +- Check the `azure.signinlogs.properties.authentication_processing_details.Oauth Scope Info` field for the presence of `user_impersonation`. This scope is commonly used in OAuth flows to allow applications to access user resources on behalf of the user. +- Confirm that the `azure.signinlogs.properties.authentication_requirement` is set to `singleFactorAuthentication`, indicating that the sign-in did not require multi-factor authentication (MFA). This can be a red flag, as MFA is a critical security control that helps prevent unauthorized access. +- Review the `azure.signinlogs.properties.app_display_name` or `azure.signinlogs.properties.app_id` to identify the application involved in the OAuth workflow. Check if this application is known and trusted, or if it appears suspicious or unauthorized. FOCI applications are commonly abused by adversaries to evade security controls or conditional access policies. +- Analyze the `azure.signinlogs.properties.client_ip` to determine the source of the sign-in attempt. 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. +- Examine the `azure.signinlogs.properties.resource_display_name` or `azure.signinlogs.properties.resource_id` to identify the resource being accessed during the OAuth workflow. This can help determine if the access was legitimate or if it targeted sensitive resources. It may also help pivot to other related events or activities. +- Use the `azure.signinlogs.properties.session_id` or `azure.signinlogs.properties.correlation_id` to correlate this event with other related sign-in events or activities. This can help identify patterns of suspicious behavior or potential account compromise. + + +*False positive analysis* + + +- Some legitimate applications may use the `user_impersonation` scope for valid purposes, such as accessing user resources on behalf of the user. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. +- Users may occasionally authenticate using single-factor authentication for specific applications or scenarios, especially in environments where MFA is not enforced or required. If this is expected behavior, consider adjusting the rule or adding exceptions for specific user principals or applications. +- Some applications may use the `user_impersonation` scope for legitimate purposes, such as accessing user resources in a controlled manner. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. + + +*Response and remediation* + + +- Contact the user to validate the OAuth workflow and assess whether they were targeted or tricked by a malicious actor. +- If the OAuth workflow is confirmed to be malicious: + - Block the user account and reset the password to prevent further unauthorized access. + - Revoke active sessions and refresh tokens associated with the user principal. + - Review the application involved in the OAuth workflow and determine if it should be blocked or removed from the tenant. + - Investigate the source of the sign-in 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 OAuth user impersonation and encourage them to use more secure authentication methods, such as OAuth 2.0 or OpenID Connect, whenever possible. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: azure.signinlogs and + azure.signinlogs.properties.authentication_processing_details: *user_impersonation* and + azure.signinlogs.properties.authentication_requirement: "singleFactorAuthentication" and + azure.signinlogs.properties.token_issuer_type: "AzureAD" and + azure.signinlogs.properties.token_protection_status_details.sign_in_session_status: "unbound" and + azure.signinlogs.properties.user_type: "Member" and + azure.signinlogs.properties.conditional_access_status: "notApplied" and + not user_agent.original: Mozilla*PKeyAuth/1.0 and + not azure.signinlogs.properties.device_detail.operating_system: (Ios* or Android*) and + event.outcome: "success" + and not azure.signinlogs.properties.app_id: ( + "a5f63c0-b750-4f38-a71c-4fc0d58b89e2" or + "6bc3b958-689b-49f5-9006-36d165f30e00" or + "66a88757-258c-4c72-893c-3e8bed4d6899" or + "cc15fd57-2c6c-4117-a88c-83b1d56b4bbe" or + "0000000c-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/ +* 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/ +* Technique: +** Name: Impersonation +** ID: T1656 +** Reference URL: https://attack.mitre.org/techniques/T1656/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-entra-id-protection-admin-confirmed-compromise.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-entra-id-protection-admin-confirmed-compromise.asciidoc new file mode 100644 index 0000000000..e6d26ecfe5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-entra-id-protection-admin-confirmed-compromise.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-9-entra-id-protection-admin-confirmed-compromise]] +=== Entra ID Protection Admin Confirmed Compromise + +Identifies when an administrator has manually confirmed a user or sign-in as compromised in Microsoft Entra ID Protection. This indicates that an administrator has reviewed the risk detection and determined that the user account or sign-in activity is definitively compromised. This is a high-confidence indicator of account compromise and should be investigated immediately. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.identity_protection-* + +*Severity*: critical + +*Risk score*: 99 + +*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/id-protection/howto-identity-protection-investigate-risk +* https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks +* https://learn.microsoft.com/en-us/graph/api/resources/riskdetection + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Protection Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +This rule detects when an administrator has manually confirmed a user or sign-in as compromised in Microsoft Entra ID Protection. This is a critical security event that requires immediate investigation and response. + + +*Possible investigation steps* + + +- Review the `azure.identityprotection.properties.risk_detail` field to determine if the compromise was confirmed at the sign-in level (`adminConfirmedSigninCompromised`) or user level (`adminConfirmedUserCompromised`). +- Check the `azure.identityprotection.properties.user_principal_name` field to identify the compromised user account. +- Review the `azure.identityprotection.properties.user_display_name` field for additional user identification information. +- Examine the `azure.identityprotection.properties.risk_level` field to understand the severity level assigned to the risk event. +- Check the `azure.identityprotection.properties.risk_state` field to verify the current state of the risk (should be confirmed as compromised). +- Review the `azure.correlation_id` field to correlate this event with other related security events, including the original risk detections that led to the admin confirmation. +- Investigate the timeline of events leading up to the admin confirmation by reviewing Entra ID sign-in logs and audit logs for the affected user. +- Check for any suspicious activities associated with the user account, including: + - Unusual sign-in locations or IP addresses + - Access to sensitive resources or applications + - Changes to user profile, permissions, or MFA settings + - Bulk email sending or data exfiltration activities +- Review the `azure.identityprotection.properties.additional_info` field for any additional context provided by the administrator or Entra ID Protection. +- Identify which administrator confirmed the compromise by reviewing Entra ID audit logs for risk state changes. + + +*False positive analysis* + + +- Security testing or penetration testing exercises may result in administrators confirming test accounts as compromised. If this is expected behavior, consider excluding specific test accounts or implementing a testing account naming convention to filter. +- Incident response drills or tabletop exercises may involve marking accounts as compromised for training purposes. Coordinate with security teams to identify planned exercises. + + +*Response and remediation* + + +- Immediately reset the password for the compromised user account and require the user to set a new password upon next sign-in. +- Revoke all active sessions and authentication tokens for the compromised account, including: + - Primary refresh tokens (PRTs) + - OAuth tokens + - Session cookies + - Application-specific passwords +- Review and revoke any suspicious OAuth consent grants or application permissions added by the compromised account. +- Enable or enforce multi-factor authentication (MFA) for the affected user account if not already enabled. +- Review all activities performed by the compromised account, including: + - Email forwarding rules or inbox rules + - File access and downloads + - Changes to security settings or permissions + - Creation of new users or service principals +- Assess the scope of the compromise by identifying any lateral movement or privilege escalation activities. +- Consider disabling the account temporarily until the investigation is complete and all remediation steps are verified. +- Implement conditional access policies to prevent future compromises, such as requiring MFA from untrusted locations or blocking legacy authentication. +- Review and strengthen identity protection policies and risk-based conditional access rules. +- Document the incident, including the timeline, scope of compromise, and remediation actions taken. +- Conduct a post-incident review to identify gaps in security controls and implement improvements to prevent similar incidents. + + +==== Setup + + + +*Required Microsoft Entra ID Protection Logs* + +To use this rule, ensure that Microsoft Entra ID Protection logs are being collected and streamed into the Elastic Stack via the Azure integration. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: azure.identity_protection and + azure.identityprotection.properties.risk_detail: ( + "adminConfirmedSigninCompromised" or + "adminConfirmedUserCompromised" + ) + +---------------------------------- + +*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-9/prebuilt-rule-8-19-9-excessive-secret-or-key-retrieval-from-azure-key-vault.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-excessive-secret-or-key-retrieval-from-azure-key-vault.asciidoc new file mode 100644 index 0000000000..8522180662 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-excessive-secret-or-key-retrieval-from-azure-key-vault.asciidoc @@ -0,0 +1,206 @@ +[[prebuilt-rule-8-19-9-excessive-secret-or-key-retrieval-from-azure-key-vault]] +=== Excessive Secret or Key Retrieval from Azure Key Vault + +Identifies excessive secret or key retrieval operations from Azure Key Vault. This rule detects when a user principal retrieves secrets or keys from Azure Key Vault multiple times within a short time frame, which may indicate potential abuse or unauthorized access attempts. The rule focuses on high-frequency retrieval operations that deviate from normal user behavior, suggesting possible credential harvesting or misuse of sensitive information. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 43 + +*Runs every*: 8m + +*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*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Excessive Secret or Key Retrieval from Azure Key Vault* + + +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 `source.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] +---------------------------------- +from logs-azure.platformlogs-* metadata _id, _index + +// Filter for Azure Key Vault read operations +| where event.dataset == "azure.platformlogs" + and event.action in ( + "VaultGet", + "KeyGet", + "KeyList", + "KeyListVersions", + "KeyGetDeleted", + "KeyListDeleted", + "SecretGet", + "SecretList", + "SecretListVersions", + "SecretGetDeleted", + "SecretListDeleted", + "CertificateGet", + "CertificateList", + "CertificateListVersions", + "CertificateGetDeleted", + "CertificateListDeleted", + "CertificatePolicyGet", + "CertificateContactsGet", + "CertificateIssuerGet", + "CertificateIssuersList" + ) + +// Truncate timestamps into 1-minute windows +| eval Esql.time_window_date_trunc = date_trunc(1 minute, @timestamp) + +// Aggregate identity, geo, resource, and activity info +| stats + Esql_priv.azure_platformlogs_identity_claim_upn_values = values(azure.platformlogs.identity.claim.upn), + Esql.azure_platformlogs_identity_claim_upn_count_distinct = count_distinct(azure.platformlogs.identity.claim.upn), + Esql.azure_platformlogs_identity_claim_appid_values = values(azure.platformlogs.identity.claim.appid), + + Esql.source_ip_values = values(source.ip), + Esql.source_geo_city_values = values(source.geo.city_name), + Esql.source_geo_region_values = values(source.geo.region_name), + Esql.source_geo_country_values = values(source.geo.country_name), + Esql.source_as_organization_name_values = values(source.as.organization.name), + + Esql.event_action_values = values(event.action), + Esql.event_count = count(*), + Esql.event_action_count_distinct = count_distinct(event.action), + Esql.azure_resource_name_count_distinct = count_distinct(azure.resource.name), + Esql.azure_resource_name_values = values(azure.resource.name), + Esql.azure_platformlogs_result_type_values = values(azure.platformlogs.result_type), + Esql.cloud_region_values = values(cloud.region), + + Esql.agent_name_values = values(agent.name), + Esql.azure_subscription_id_values = values(azure.subscription_id), + Esql.azure_resource_group_values = values(azure.resource.group), + Esql.azure_resource_id_values = values(azure.resource.id) + +by Esql.time_window_date_trunc, azure.platformlogs.identity.claim.upn + +// keep relevant fields +| keep + Esql.time_window_date_trunc, + Esql_priv.azure_platformlogs_identity_claim_upn_values, + Esql.azure_platformlogs_identity_claim_upn_count_distinct, + Esql.azure_platformlogs_identity_claim_appid_values, + Esql.source_ip_values, + Esql.source_geo_city_values, + Esql.source_geo_region_values, + Esql.source_geo_country_values, + Esql.source_as_organization_name_values, + Esql.event_action_values, + Esql.event_count, + Esql.event_action_count_distinct, + Esql.azure_resource_name_count_distinct, + Esql.azure_resource_name_values, + Esql.azure_platformlogs_result_type_values, + Esql.cloud_region_values, + Esql.agent_name_values, + Esql.azure_subscription_id_values, + Esql.azure_resource_group_values, + Esql.azure_resource_id_values + +// Filter for suspiciously high volume of distinct Key Vault reads by a single actor +| where Esql.azure_platformlogs_identity_claim_upn_count_distinct == 1 and Esql.event_count >= 10 and Esql.event_action_count_distinct >= 2 + +| sort Esql.time_window_date_trunc desc + +---------------------------------- + +*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-9/prebuilt-rule-8-19-9-potential-command-shell-via-netcat.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-potential-command-shell-via-netcat.asciidoc new file mode 100644 index 0000000000..09c8d15255 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-potential-command-shell-via-netcat.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-9-potential-command-shell-via-netcat]] +=== Potential Command Shell via NetCat + +Identifies potential attempt to execute via a reverse shell using the netcat utility to execute Windows commands using the default interpreters like Cmd.exe and Powershell. + +*Rule type*: eql + +*Rule indices*: + +* 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*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Defend + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Command Shell via NetCat* + + +Attackers may abuse the NetCat utility to execute commands remotely using the builtin Windows Command Shell interpreters. + + +*Possible investigation steps* + + +- Verify if the user is authorized to use the Netcat utility. +- Investigate the process execution chain (parent process tree) and how the netcat binary was dropped. +- Review the network connections made by the parent process and check their reputation. +- Investiguate all child processes spawned by the Cmd or Powershell instance. +- Examine the host for other alerts within the same period. + + +*False positive analysis* + + +- IT Support or system amdinistrator authorized activity using NetCat. + + +*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. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- 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. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and +process.name : ("cmd.exe", "powershell.exe") and process.parent.args : "-e" and + ( + (process.parent.args_count == 5 and process.parent.command_line regex~ """.*[0-9]{1,3}(\.[0-9]{1,3}){3}.*""") or + (process.parent.args : "-*l*" and process.parent.args : "-*p*" and process.parent.args : ("cmd.exe", "powershell.exe")) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-potential-cve-2025-32463-sudo-chroot-execution-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-potential-cve-2025-32463-sudo-chroot-execution-attempt.asciidoc new file mode 100644 index 0000000000..4f85e84271 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-potential-cve-2025-32463-sudo-chroot-execution-attempt.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-9-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*: 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 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-potential-privilege-escalation-via-service-imagepath-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-potential-privilege-escalation-via-service-imagepath-modification.asciidoc new file mode 100644 index 0000000000..689e329c09 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-potential-privilege-escalation-via-service-imagepath-modification.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-9-potential-privilege-escalation-via-service-imagepath-modification]] +=== Potential Privilege Escalation via Service ImagePath Modification + +Identifies registry modifications to default services that could enable privilege escalation to SYSTEM. Attackers with privileges from groups like Server Operators may change the ImagePath of services to executables under their control or to execute commands. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* +* endgame-* + +*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://cube0x0.github.io/Pocing-Beyond-DA/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Data Source: SentinelOne +* Data Source: Microsoft Defender for Endpoint +* Data Source: Elastic Endgame + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation via Service ImagePath Modification* + + +Windows services are crucial for system operations, often running with high privileges. Adversaries exploit this by altering the ImagePath registry key of services to execute malicious code with elevated privileges. The detection rule identifies suspicious modifications to service ImagePaths, focusing on changes that deviate from standard executable paths, thus flagging potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the specific registry key and value that triggered the alert to confirm it matches one of the monitored service keys, such as those listed in the query (e.g., *\LanmanServer, *\Winmgmt). +- Examine the modified ImagePath value to determine if it points to a non-standard executable path or a suspicious executable, especially those not located in %systemroot%\system32\. +- Check the process.executable field to identify the process responsible for the registry modification and assess its legitimacy. +- Investigate the user account associated with the modification event to determine if it has elevated privileges, such as membership in the Server Operators group. +- Correlate the event with other logs or alerts to identify any related suspicious activities, such as unexpected service starts or process executions. +- Review recent changes or activities on the host to identify any unauthorized access or configuration changes that could indicate a broader compromise. + + +*False positive analysis* + + +- Legitimate software updates or installations may modify service ImagePaths. Users can create exceptions for known update processes or installation paths to prevent false positives. +- System administrators might intentionally change service configurations for maintenance or troubleshooting. Document and exclude these changes by adding exceptions for specific administrator actions or paths. +- Custom scripts or automation tools that modify service settings as part of their operation can trigger alerts. Identify and whitelist these scripts or tools to avoid unnecessary alerts. +- Some third-party security or management software may alter service ImagePaths as part of their functionality. Verify the legitimacy of such software and exclude their known paths from detection. +- Changes made by trusted IT personnel during system configuration or optimization should be logged and excluded from alerts to reduce noise. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified as running from non-standard executable paths, especially those not originating from the system32 directory. +- Restore the modified ImagePath registry key to its original state using a known good configuration or backup. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or persistence mechanisms. +- Review and audit user accounts and group memberships, particularly those with elevated privileges like Server Operators, to ensure no unauthorized changes have been made. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for future modifications to service ImagePath registry keys, focusing on deviations from standard paths to detect similar threats promptly. + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and process.executable != null and + registry.data.strings != null and registry.value == "ImagePath" and + registry.key : ( + "*\\ADWS", "*\\AppHostSvc", "*\\AppReadiness", "*\\AudioEndpointBuilder", "*\\AxInstSV", "*\\camsvc", "*\\CertSvc", + "*\\COMSysApp", "*\\CscService", "*\\defragsvc", "*\\DeviceAssociationService", "*\\DeviceInstall", "*\\DevQueryBroker", + "*\\Dfs", "*\\DFSR", "*\\diagnosticshub.standardcollector.service", "*\\DiagTrack", "*\\DmEnrollmentSvc", "*\\DNS", + "*\\dot3svc", "*\\Eaphost", "*\\GraphicsPerfSvc", "*\\hidserv", "*\\HvHost", "*\\IISADMIN", "*\\IKEEXT", + "*\\InstallService", "*\\iphlpsvc", "*\\IsmServ", "*\\LanmanServer", "*\\MSiSCSI", "*\\NcbService", "*\\Netlogon", + "*\\Netman", "*\\NtFrs", "*\\PlugPlay", "*\\Power", "*\\PrintNotify", "*\\ProfSvc", "*\\PushToInstall", "*\\RSoPProv", + "*\\sacsvr", "*\\SENS", "*\\SensorDataService", "*\\SgrmBroker", "*\\ShellHWDetection", "*\\shpamsvc", "*\\StorSvc", + "*\\svsvc", "*\\swprv", "*\\SysMain", "*\\Themes", "*\\TieringEngineService", "*\\TokenBroker", "*\\TrkWks", + "*\\UALSVC", "*\\UserManager", "*\\vm3dservice", "*\\vmicguestinterface", "*\\vmicheartbeat", "*\\vmickvpexchange", + "*\\vmicrdv", "*\\vmicshutdown", "*\\vmicvmsession", "*\\vmicvss", "*\\vmvss", "*\\VSS", "*\\w3logsvc", "*\\W3SVC", + "*\\WalletService", "*\\WAS", "*\\wercplsupport", "*\\WerSvc", "*\\Winmgmt", "*\\wisvc", "*\\wmiApSrv", + "*\\WPDBusEnum", "*\\WSearch" + ) and + not ( + registry.data.strings : ( + "?:\\Windows\\system32\\*.exe", + "%systemroot%\\system32\\*.exe", + "%windir%\\system32\\*.exe", + "%SystemRoot%\\system32\\svchost.exe -k *", + "%windir%\\system32\\svchost.exe -k *" + ) and + not registry.data.strings : ( + "*\\cmd.exe", + "*\\cscript.exe", + "*\\ieexec.exe", + "*\\iexpress.exe", + "*\\installutil.exe", + "*\\Microsoft.Workflow.Compiler.exe", + "*\\msbuild.exe", + "*\\mshta.exe", + "*\\msiexec.exe", + "*\\msxsl.exe", + "*\\net.exe", + "*\\powershell.exe", + "*\\pwsh.exe", + "*\\reg.exe", + "*\\RegAsm.exe", + "*\\RegSvcs.exe", + "*\\regsvr32.exe", + "*\\rundll32.exe", + "*\\vssadmin.exe", + "*\\wbadmin.exe", + "*\\wmic.exe", + "*\\wscript.exe" + ) + ) + +---------------------------------- + +*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/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Services Registry Permissions Weakness +** ID: T1574.011 +** Reference URL: https://attack.mitre.org/techniques/T1574/011/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: System Services +** ID: T1569 +** Reference URL: https://attack.mitre.org/techniques/T1569/ +* Sub-technique: +** Name: Service Execution +** ID: T1569.002 +** Reference URL: https://attack.mitre.org/techniques/T1569/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-simple-http-web-server-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-simple-http-web-server-connection.asciidoc new file mode 100644 index 0000000000..acc57d44a3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-simple-http-web-server-connection.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-9-simple-http-web-server-connection]] +=== Simple HTTP Web Server Connection + +This rule detects connections accepted by a simple HTTP web server in Python and PHP built-in modules. Adversaries may create simple HTTP web servers to establish persistence on a compromised system by uploading a reverse or command shell payload to the server web root, allowing them to regain remote access to the system if lost. This event may occur when an attacker requests the server to execute a command or script via a potential backdoor. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-endpoint.events.network* + +*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: Persistence +* Tactic: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Simple HTTP Web Server Connection* + + +Simple HTTP servers in Python and PHP are often used for development and testing, providing a quick way to serve web content. However, attackers can exploit these servers to maintain access on compromised Linux systems by deploying backdoors or executing commands remotely. The detection rule identifies suspicious server activity by monitoring for specific process patterns and command-line arguments indicative of these lightweight servers, flagging potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the process details, including the process name and command line arguments, to confirm if the server was started using Python or PHP, as indicated by the query fields. +- Check the network connection details associated with the event, such as the source and destination IP addresses and ports, to identify any suspicious or unexpected connections. +- Investigate the user account under which the process was initiated to determine if it aligns with expected behavior or if it indicates potential unauthorized access. +- Examine the system logs and any related events around the time of the alert to identify any additional suspicious activities or anomalies. +- Assess the server's web root directory for any unauthorized files or scripts that could indicate a backdoor or malicious payload. +- Correlate this event with other alerts or indicators of compromise on the system to evaluate if this is part of a larger attack campaign. + + +*False positive analysis* + + +- Development and testing environments may frequently trigger this rule when developers use Python or PHP's built-in HTTP servers for legitimate purposes. To manage this, consider excluding specific user accounts or IP addresses associated with development activities from the rule. +- Automated scripts or cron jobs that start simple HTTP servers for routine tasks can also generate false positives. Identify these scripts and add their process names or command-line patterns to an exception list. +- Educational or training environments where students are learning web development might cause alerts. In such cases, exclude the network segments or user groups associated with these activities. +- Internal tools or services that rely on lightweight HTTP servers for functionality might be flagged. Review these tools and whitelist their specific process names or command-line arguments to prevent unnecessary alerts. +- Temporary testing servers spun up for short-term projects can be mistaken for malicious activity. Document these instances and apply temporary exceptions during the project duration. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious Python or PHP processes identified by the detection rule to stop the potential backdoor or unauthorized server activity. +- Conduct a thorough review of the system's file system, focusing on the web root directory, to identify and remove any unauthorized scripts or payloads that may have been uploaded. +- Change all credentials associated with the compromised system, including SSH keys and passwords, to prevent attackers from regaining access. +- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected that cannot be easily remediated. +- Implement network monitoring to detect any future unauthorized HTTP server activity, focusing on unusual process patterns and command-line arguments. +- 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 process.entity_id with maxspan=1m +[process where host.os.type == "linux" and event.type == "start" and + ( + (process.name regex~ """php?[0-9]?\.?[0-9]{0,2}""" and process.command_line like "*-S*") or + (process.name like "python*" and process.command_line like ("*--cgi*", "*CGIHTTPServer*")) + )] +[network where host.os.type == "linux" and event.type == "start" and event.action == "connection_accepted"] + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-unusual-persistence-via-services-registry.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-unusual-persistence-via-services-registry.asciidoc new file mode 100644 index 0000000000..9ee1c6f653 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rule-8-19-9-unusual-persistence-via-services-registry.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-9-unusual-persistence-via-services-registry]] +=== Unusual Persistence via Services Registry + +Identifies processes modifying the services registry key directly, instead of through the expected Windows APIs. This could be an indication of an adversary attempting to stealthily persist through abnormal service creation or modification of an existing service. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* +* 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: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender for Endpoint +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 315 + +*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 Persistence via Services Registry* + + +Windows services are crucial for running background processes. Adversaries may exploit this by directly altering service registry keys to maintain persistence, bypassing standard APIs. The detection rule identifies such anomalies by monitoring changes to specific registry paths and filtering out legitimate processes, thus highlighting potential unauthorized service modifications indicative of malicious activity. + + +*Possible investigation steps* + + +- Review the specific registry paths and values that triggered the alert, focusing on "ServiceDLL" and "ImagePath" within the specified registry paths to identify any unauthorized or suspicious modifications. +- Examine the process responsible for the registry change, paying attention to the process name and executable path, to determine if it is a known legitimate process or potentially malicious. +- Cross-reference the process executable path against the list of known legitimate paths excluded in the query to ensure it is not a false positive. +- Investigate the historical behavior of the process and any associated files or network activity to identify patterns indicative of malicious intent or persistence mechanisms. +- Check for any recent changes or anomalies in the system's service configurations that could correlate with the registry modifications, indicating potential unauthorized service creation or alteration. +- Consult threat intelligence sources or databases to determine if the process or registry changes are associated with known malware or adversary techniques. + + +*False positive analysis* + + +- Legitimate software installations or updates may modify service registry keys directly. Users can create exceptions for known software update processes by excluding their executables from the detection rule. +- System maintenance tools like Process Explorer may trigger false positives when they interact with service registry keys. Exclude these tools by adding their process names and paths to the exception list. +- Drivers installed by trusted hardware peripherals might alter service registry keys. Users should identify and exclude these driver paths if they are known to be safe and frequently updated. +- Custom enterprise applications that require direct registry modifications for service management can be excluded by specifying their executable paths in the rule exceptions. +- Regular system processes such as svchost.exe or services.exe are already excluded, but ensure any custom scripts or automation tools that mimic these processes are also accounted for in the exceptions. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert that are not part of legitimate applications or services. +- Restore the modified registry keys to their original state using a known good backup or by manually correcting the entries to ensure the integrity of the service configurations. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious software or artifacts. +- Review and update endpoint protection policies to ensure that similar unauthorized registry modifications are detected and blocked in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Document the incident details, including the steps taken for containment and remediation, to enhance future response efforts and update threat intelligence databases. + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.data.strings != null and registry.value : ("ServiceDLL", "ImagePath") and + registry.path : ( + "HKLM\\SYSTEM\\ControlSet*\\Services\\*\\ServiceDLL", + "HKLM\\SYSTEM\\ControlSet*\\Services\\*\\ImagePath", + "\\REGISTRY\\MACHINE\\SYSTEM\\ControlSet*\\Services\\*\\ServiceDLL", + "\\REGISTRY\\MACHINE\\SYSTEM\\ControlSet*\\Services\\*\\ImagePath", + "MACHINE\\SYSTEM\\ControlSet*\\Services\\*\\ServiceDLL", + "MACHINE\\SYSTEM\\ControlSet*\\Services\\*\\ImagePath" + ) and not registry.data.strings : ( + "?:\\windows\\system32\\Drivers\\*.sys", + "\\SystemRoot\\System32\\drivers\\*.sys", + "\\??\\?:\\Windows\\system32\\Drivers\\*.SYS", + "\\??\\?:\\Windows\\syswow64\\*.sys", + "system32\\DRIVERS\\USBSTOR", + "system32\\drivers\\*.sys", + "C:\\WindowsAzure\\GuestAgent*.exe", + "\"C:\\Program Files\\Common Files\\McAfee\\*", + "C:\\Program Files (x86)\\VERITAS\\VxPBX\\bin\\pbx_exchange.exe", + "\"C:\\Program Files (x86)\\VERITAS\\VxPBX\\bin\\pbx_exchange.exe\"", + "\"C:\\ProgramData\\McAfee\\Agent\\Current\\*") and + not (process.name : "procexp??.exe" and registry.data.strings : "?:\\*\\procexp*.sys") and + not process.executable : ( + "?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\Windows\\System32\\svchost.exe", + "?:\\Windows\\winsxs\\*\\TiWorker.exe", + "?:\\Windows\\System32\\drvinst.exe", + "?:\\Windows\\System32\\services.exe", + "?:\\Windows\\System32\\msiexec.exe", + "?:\\Windows\\System32\\regsvr32.exe", + "?:\\Windows\\System32\\WaaSMedicAgent.exe", + "?:\\Windows\\UUS\\amd64\\WaaSMedicAgent.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rules-8-19-9-appendix.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rules-8-19-9-appendix.asciidoc new file mode 100644 index 0000000000..5b1908b36a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rules-8-19-9-appendix.asciidoc @@ -0,0 +1,31 @@ +["appendix",role="exclude",id="prebuilt-rule-8-19-9-prebuilt-rules-8-19-9-appendix"] += Downloadable rule update v8.19.9 + +This section lists all updates associated with version 8.19.9 of the Fleet integration *Prebuilt Security Detection Rules*. + + +include::prebuilt-rule-8-19-9-azure-storage-blob-retrieval-via-azcopy.asciidoc[] +include::prebuilt-rule-8-19-9-azure-compute-restore-point-collection-deleted-by-unusual-user.asciidoc[] +include::prebuilt-rule-8-19-9-azure-compute-restore-point-collections-deleted.asciidoc[] +include::prebuilt-rule-8-19-9-azure-storage-account-deletion-by-unusual-user.asciidoc[] +include::prebuilt-rule-8-19-9-azure-storage-account-deletions-by-user.asciidoc[] +include::prebuilt-rule-8-19-9-entra-id-protection-admin-confirmed-compromise.asciidoc[] +include::prebuilt-rule-8-19-9-potential-command-shell-via-netcat.asciidoc[] +include::prebuilt-rule-8-19-9-aws-management-console-brute-force-of-root-user-identity.asciidoc[] +include::prebuilt-rule-8-19-9-aws-management-console-root-login.asciidoc[] +include::prebuilt-rule-8-19-9-aws-sign-in-root-password-recovery-requested.asciidoc[] +include::prebuilt-rule-8-19-9-aws-sign-in-console-login-with-federated-user.asciidoc[] +include::prebuilt-rule-8-19-9-aws-iam-login-profile-added-for-root.asciidoc[] +include::prebuilt-rule-8-19-9-aws-iam-user-created-access-keys-for-another-user.asciidoc[] +include::prebuilt-rule-8-19-9-aws-iam-administratoraccess-policy-attached-to-group.asciidoc[] +include::prebuilt-rule-8-19-9-aws-iam-administratoraccess-policy-attached-to-role.asciidoc[] +include::prebuilt-rule-8-19-9-aws-iam-administratoraccess-policy-attached-to-user.asciidoc[] +include::prebuilt-rule-8-19-9-deprecated-aws-root-login-without-mfa.asciidoc[] +include::prebuilt-rule-8-19-9-excessive-secret-or-key-retrieval-from-azure-key-vault.asciidoc[] +include::prebuilt-rule-8-19-9-entra-id-oauth-user-impersonation-scope-for-unusual-user-and-client.asciidoc[] +include::prebuilt-rule-8-19-9-simple-http-web-server-connection.asciidoc[] +include::prebuilt-rule-8-19-9-potential-cve-2025-32463-sudo-chroot-execution-attempt.asciidoc[] +include::prebuilt-rule-8-19-9-disabling-lsa-protection-via-registry-modification.asciidoc[] +include::prebuilt-rule-8-19-9-dns-global-query-block-list-modified-or-disabled.asciidoc[] +include::prebuilt-rule-8-19-9-unusual-persistence-via-services-registry.asciidoc[] +include::prebuilt-rule-8-19-9-potential-privilege-escalation-via-service-imagepath-modification.asciidoc[] diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rules-8-19-9-summary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rules-8-19-9-summary.asciidoc new file mode 100644 index 0000000000..a9f5276f5e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rules-8-19-9-summary.asciidoc @@ -0,0 +1,62 @@ +[[prebuilt-rule-8-19-9-prebuilt-rules-8-19-9-summary]] +[role="xpack"] +== Update v8.19.9 + +This section lists all updates associated with version 8.19.9 of the Fleet integration *Prebuilt Security Detection Rules*. + + +[width="100%",options="header"] +|============================================== +|Rule |Description |Status |Version + +|<> | Identifies successful GetBlob operations on Azure Storage Accounts using AzCopy user agent with SAS token authentication. AzCopy is a command-line utility for copying data to and from Azure Storage. While legitimate for data migration, adversaries may abuse AzCopy with compromised SAS tokens to exfiltrate data from Azure Storage Accounts. This rule detects the first occurrence of GetBlob operations from a specific storage account using this pattern. | new | 1 + +|<> | Identifies the deletion of Azure Restore Point Collections by a user who has not previously performed this activity. Restore Point Collections contain recovery points for virtual machines, enabling point-in-time recovery capabilities. Adversaries may delete these collections to prevent recovery during ransomware attacks or to cover their tracks during malicious operations. | new | 1 + +|<> | Identifies multiple Azure Restore Point Collections being deleted by a single user within a short time period. Restore Point Collections contain recovery points for virtual machines, enabling point-in-time recovery capabilities. Mass deletion of these collections is a common tactic used by adversaries during ransomware attacks to prevent victim recovery or to maximize impact during destructive operations. Multiple deletions in rapid succession may indicate malicious intent. | new | 1 + +|<> | Identifies when an Azure Storage Account is deleted. Adversaries may delete storage accounts to disrupt operations, destroy evidence, or cause denial of service. This activity could indicate an attacker attempting to cover their tracks after data exfiltration or as part of a destructive attack. Monitoring storage account deletions is critical for detecting potential impact on business operations and data availability. | new | 1 + +|<> | Identifies when a single user or service principal deletes multiple Azure Storage Accounts within a short time period. This behavior may indicate an adversary attempting to cause widespread service disruption, destroy evidence, or execute a destructive attack such as ransomware. Mass deletion of storage accounts can have severe business impact and is rarely performed by legitimate administrators except during controlled decommissioning activities. | new | 1 + +|<> | Identifies when an administrator has manually confirmed a user or sign-in as compromised in Microsoft Entra ID Protection. This indicates that an administrator has reviewed the risk detection and determined that the user account or sign-in activity is definitively compromised. This is a high-confidence indicator of account compromise and should be investigated immediately. | new | 1 + +|<> | Identifies potential attempt to execute via a reverse shell using the netcat utility to execute Windows commands using the default interpreters like Cmd.exe and Powershell. | new | 1 + +|<> | Identifies a high number of failed authentication attempts to the AWS management console for the Root user identity. An adversary may attempt to brute force the password for the Root user identity, as it has complete access to all services and resources for the AWS account. | update | 211 + +|<> | Identifies a successful login to the AWS Management Console by the Root user. | update | 212 + +|<> | Identifies a password recovery request for the AWS account root user. In AWS, the PasswordRecoveryRequested event from signin.amazonaws.com applies to the root user’s “Forgot your password?” flow. Other identity types, like IAM and federated users, do not generate this event. This alert indicates that someone initiated the root password reset workflow for this account. Verify whether this was an expected action and review identity provider notifications/email to confirm legitimacy. | update | 210 + +|<> | Identifies when a federated user logs into the AWS Management Console. Federated users are typically given temporary credentials to access AWS services. If a federated user logs into the AWS Management Console without using MFA, it may indicate a security risk, as MFA adds an additional layer of security to the authentication process. However, CloudTrail does not record whether a Federated User utilized MFA as part of authentication — that MFA decision often occurs at a third-party IdP (e.g., Okta, Azure AD, Google). As a result, CloudTrail fields such as MFAUsed / mfaAuthenticated appear as “No/false” for federated console logins even if IdP MFA was required. This alert should be correlated with IdP authentication logs to verify whether MFA was enforced for the session. Increase priority if you find a related "GetSigninToken" event whose source IP / ASN / geo or user-agent differs from the subsequent "ConsoleLogin" (possible token relay/abuse). Same-IP/UA pairs within a short window are more consistent with expected operator behavior and can be triaged with lower severity. | update | 5 + +|<> | Identifies creation of a console login profile for the AWS account root user. While CreateLoginProfile normally applies to IAM users, when performed from a temporary root session (e.g., via AssumeRoot) and the userName parameter is omitted, the profile is created for the root principal (self-assigned). Adversaries with temporary root access may add or reset the root login profile to establish persistent console access even if original access keys are rotated or disabled. Correlate with recent AssumeRoot/STS activity and validate intent with the account owner. | 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 | 8 + +|<> | An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to user groups the compromised user account belongs to. This rule looks for use of the IAM AttachGroupPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM user group. | update | 7 + +|<> | 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. | update | 7 + +|<> | 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 | 8 + +|<> | Identifies attempts to login to AWS as the root user without using multi-factor authentication (MFA). Amazon AWS best practices indicate that the root user should be protected by MFA. | update | 212 + +|<> | Identifies excessive secret or key retrieval operations from Azure Key Vault. This rule detects when a user principal retrieves secrets or keys from Azure Key Vault multiple times within a short time frame, which may indicate potential abuse or unauthorized access attempts. The rule focuses on high-frequency retrieval operations that deviate from normal user behavior, suggesting possible credential harvesting or misuse of sensitive information. | update | 4 + +|<> | 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. | update | 3 + +|<> | This rule detects connections accepted by a simple HTTP web server in Python and PHP built-in modules. Adversaries may create simple HTTP web servers to establish persistence on a compromised system by uploading a reverse or command shell payload to the server web root, allowing them to regain remote access to the system if lost. This event may occur when an attacker requests the server to execute a command or script via a potential backdoor. | update | 5 + +|<> | 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 | 2 + +|<> | LSA protecton is provided to prevent nonprotected processes from reading memory and injecting code. This feature provides added security for the credentials that LSA stores and manages. Adversaries may modify the RunAsPPL registry and wait or initiate a system restart to enable Lsass credentials access. | update | 3 + +|<> | Identifies changes to the DNS Global Query Block List (GQBL), a security feature that prevents the resolution of certain DNS names often exploited in attacks like WPAD spoofing. Attackers with certain privileges, such as DNSAdmins, can modify or disable the GQBL, allowing exploitation of hosts running WPAD with default settings for privilege escalation and lateral movement. | update | 208 + +|<> | Identifies processes modifying the services registry key directly, instead of through the expected Windows APIs. This could be an indication of an adversary attempting to stealthily persist through abnormal service creation or modification of an existing service. | update | 315 + +|<> | Identifies registry modifications to default services that could enable privilege escalation to SYSTEM. Attackers with privileges from groups like Server Operators may change the ImagePath of services to executables under their control or to execute commands. | update | 107 + +|============================================== diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc index 54b32341fc..ddeb4720fe 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 +|<> | 20 Oct 2025 | 7 | 18 | +This release includes new rules for Windows, AWS and Azure. New rules for Windows include detection for execution. New rules for AWS include detection for initial access. New rules for Azure include detection for impact, initial access and exfiltration. Additionally, significant rule tuning for Windows, Linux, AWS and Azure rules has been added for better rule efficacy and performance. + + |<> | 07 Oct 2025 | 14 | 105 | This release includes new rules for Windows, Linux and Azure. New rules for Windows include detection for privilege escalation. New rules for Linux include detection for privilege escalation, persistence, credential access, defense evasion and command and control. New rules for Azure include detection for privilege escalation, collection, credential access, initial access and command and control. Additionally, significant rule tuning for Windows, Linux, AWS, Okta and Azure rules has been added for better rule efficacy and performance. @@ -53,3 +57,4 @@ include::downloadable-packages/8-19-5/prebuilt-rules-8-19-5-summary.asciidoc[lev include::downloadable-packages/8-19-6/prebuilt-rules-8-19-6-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-19-7/prebuilt-rules-8-19-7-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-19-8/prebuilt-rules-8-19-8-summary.asciidoc[leveloffset=+1] +include::downloadable-packages/8-19-9/prebuilt-rules-8-19-9-summary.asciidoc[leveloffset=+1] diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc index ac5655df77..8c7c708071 100644 --- a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc +++ b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc @@ -114,11 +114,11 @@ and their rule type is `machine_learning`. |<> |Detects use of sensitive AWS IAM API operations using temporary credentials (session tokens starting with 'ASIA'). This may indicate credential theft or abuse of elevated access via a stolen session. It is not common for legitimate users to perform sensitive IAM operations with temporary session tokens. |[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 |3 -|<> |An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to user groups the compromised user account belongs to. This rule looks for use of the IAM `AttachGroupPolicy` API operation to attach the highly permissive `AdministratorAccess` AWS managed policy to an existing IAM user group. |[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 |6 +|<> |An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to user groups the compromised user account belongs to. This rule looks for use of the IAM AttachGroupPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM user group. |[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 |7 -|<> |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 |6 +|<> |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 |7 -|<> |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 |7 +|<> |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 |8 |<> |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 |214 @@ -136,12 +136,10 @@ and their rule type is `machine_learning`. |<> |Identifies the deletion of a specified AWS Identity and Access Management (IAM) resource group. Deleting a resource group does not delete resources that are members of the group; it only deletes the group structure. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Tactic: Impact], [Resources: Investigation Guide] |None |209 -|<> |Detects when an AWS IAM login profile is added to a root user account and is self-assigned. Adversaries, with temporary access to the root account, may add a login profile to the root user account to maintain access even if the original access key is rotated or disabled. |[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 +|<> |Identifies creation of a console login profile for the AWS account root user. While CreateLoginProfile normally applies to IAM users, when performed from a temporary root session (e.g., via AssumeRoot) and the userName parameter is omitted, the profile is created for the root principal (self-assigned). Adversaries with temporary root access may add or reset the root login profile to establish persistent console access even if original access keys are rotated or disabled. Correlate with recent AssumeRoot/STS activity and validate intent with the account owner. |[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 when an AWS IAM login profile is added to a user. Adversaries may add a login profile to an IAM user who typically does not have one and is used only for programmatic access. This can be used to maintain access to the account even if the original access key is rotated or disabled. This is a building block rule and does not generate alerts on its own. It is meant to be used for correlation with other rules to detect suspicious activity. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Rule Type: BBR] |None |4 -|<> |Identifies AWS IAM password recovery requests. An adversary may attempt to gain unauthorized AWS access by abusing password recovery mechanisms. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Signin], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |209 - |<> |Identifies the creation of an AWS Roles Anywhere profile. AWS Roles Anywhere is a feature that allows you to use AWS Identity and Access Management (IAM) profiles to manage access to your AWS resources from any location via trusted anchors. This rule detects the creation of a profile that can be assumed from any service. Adversaries may create profiles tied to overly permissive roles to maintain access to AWS resources. Ensure that the profile creation is expected and that the trust policy is configured securely. |[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 |5 |<> |Identifies when an AWS IAM Roles Anywhere Trust Anchor with an external certificate authority is created. AWS Roles Anywhere profiles are legitimate profiles that can be created by administrators to allow access from any location. This rule detects when a trust anchor is created with an external certificate authority that is not managed by AWS Certificate Manager Private Certificate Authority (ACM PCA). Adversaries may accomplish this to maintain persistence in the environment. |[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 |5 @@ -150,7 +148,7 @@ and their rule type is `machine_learning`. |<> |Identifies the addition of a user to a specified group in AWS Identity and Access Management (IAM). |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Tactic: Persistence], [Resources: Investigation Guide] |None |211 -|<> |An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by creating a new set of credentials for an existing user. This rule looks for use of the IAM `CreateAccessKey` API operation to create new programmatic access keys for another IAM user. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide] |None |7 +|<> |An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by creating a new set of credentials for an existing user. This rule looks for use of the IAM `CreateAccessKey` API operation to create new programmatic access keys for another IAM user. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide] |None |8 |<> |Identifies attempts to register or enable an IAM Virtual MFA device using temporary credentials (access keys starting with 'ASIA'). This may indicate an adversary attempting to escalate privileges or establish persistence using stolen session tokens. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Tactic: Persistence], [Use Case: Identity and Access Audit], [Resources: Investigation Guide] |None |2 @@ -162,9 +160,9 @@ and their rule type is `machine_learning`. |<> |Identifies when an Lambda Layer is added to an existing Lambda function. AWS layers are a way to share code and data across multiple functions. By adding a layer to an existing function, an attacker can persist or execute code in the context of the function. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Lambda], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |5 -|<> |Identifies a high number of failed authentication attempts to the AWS management console for the Root user identity. An adversary may attempt to brute force the password for the Root user identity, as it has complete access to all services and resources for the AWS account. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Resources: Investigation Guide] |None |210 +|<> |Identifies a high number of failed authentication attempts to the AWS management console for the Root user identity. An adversary may attempt to brute force the password for the Root user identity, as it has complete access to all services and resources for the AWS account. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Sign-In], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Resources: Investigation Guide] |None |211 -|<> |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 Signin], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Initial Access] |None |211 +|<> |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 |212 |<> |Identifies the creation of a new Amazon Relational Database Service (RDS) Aurora DB cluster or global database spread across multiple regions. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS RDS], [Use Case: Asset Visibility], [Tactic: Persistence], [Resources: Investigation Guide] |None |209 @@ -194,8 +192,6 @@ and their rule type is `machine_learning`. |<> |Identifies the creation of an Amazon Redshift cluster. Unexpected creation of this cluster by a non-administrative user may indicate a permission or role issue with current users. If unexpected, the resource may not properly be configured and could introduce security vulnerabilities. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Redshift], [Use Case: Asset Visibility], [Tactic: Persistence], [Resources: Investigation Guide] |None |209 -|<> |Identifies attempts to login to AWS as the root user without using multi-factor authentication (MFA). Amazon AWS best practices indicate that the root user should be protected by MFA. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Route53], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Privilege Escalation] |None |211 - |<> |Identifies when a transfer lock was removed from a Route 53 domain. It is recommended to refrain from performing this action unless intending to transfer the domain to a different registrar. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Route53], [Use Case: Asset Visibility], [Tactic: Persistence], [Resources: Investigation Guide] |None |209 |<> |Identifies when a request has been made to transfer a Route 53 domain to another AWS account. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Route53], [Use Case: Asset Visibility], [Tactic: Persistence], [Resources: Investigation Guide] |None |209 @@ -254,7 +250,11 @@ and their rule type is `machine_learning`. |<> |Identifies when a single AWS resource is making `GetServiceQuota` API calls for the EC2 service quota L-1216C47A in more than 10 regions within a 30-second window. Quota code L-1216C47A represents on-demand instances which are used by adversaries to deploy malware and mine cryptocurrency. This could indicate a potential threat actor attempting to discover the AWS infrastructure across multiple regions using compromised credentials or a compromised instance. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Service Quotas], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |4 -|<> |Identifies when a federated user logs into the AWS Management Console without using multi-factor authentication (MFA). Federated users are typically given temporary credentials to access AWS services. If a federated user logs into the AWS Management Console without using MFA, it may indicate a security risk, as MFA adds an additional layer of security to the authentication process. This could also indicate the abuse of STS tokens to bypass MFA requirements. |[Domain: Cloud], [Data Source: Amazon Web Services], [Data Source: AWS], [Data Source: AWS Sign-In], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |4 +|<> |Identifies when a federated user logs into the AWS Management Console. Federated users are typically given temporary credentials to access AWS services. If a federated user logs into the AWS Management Console without using MFA, it may indicate a security risk, as MFA adds an additional layer of security to the authentication process. However, CloudTrail does not record whether a Federated User utilized MFA as part of authentication — that MFA decision often occurs at a third-party IdP (e.g., Okta, Azure AD, Google). As a result, CloudTrail fields such as MFAUsed / mfaAuthenticated appear as “No/false” for federated console logins even if IdP MFA was required. This alert should be correlated with IdP authentication logs to verify whether MFA was enforced for the session. Increase priority if you find a related "GetSigninToken" event whose source IP / ASN / geo or user-agent differs from the subsequent "ConsoleLogin" (possible token relay/abuse). Same-IP/UA pairs within a short window are more consistent with expected operator behavior and can be triaged with lower severity. |[Domain: Cloud], [Data Source: Amazon Web Services], [Data Source: AWS], [Data Source: AWS Sign-In], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |5 + +|<> |Identifies a password recovery request for the AWS account root user. In AWS, the PasswordRecoveryRequested event from signin.amazonaws.com applies to the root user’s “Forgot your password?” flow. Other identity types, like IAM and federated users, do not generate this event. This alert indicates that someone initiated the root password reset workflow for this account. Verify whether this was an expected action and review identity provider notifications/email to confirm legitimacy. |[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 |210 + +|<> |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 |1 |<> |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 |6 @@ -420,6 +420,10 @@ and their rule type is `machine_learning`. |<> |Identifies command execution on a virtual machine (VM) in Azure. A Virtual Machine Contributor role lets you manage virtual machines, but not access them, nor access the virtual network or storage account they’re connected to. However, commands can be run via PowerShell on the VM, which execute as System. Other roles, such as certain Administrator roles may be able to execute commands on a VM as well. |[Domain: Cloud], [Data Source: Azure], [Use Case: Log Auditing], [Tactic: Execution], [Resources: Investigation Guide] |None |106 +|<> |Identifies the deletion of Azure Restore Point Collections by a user who has not previously performed this activity. Restore Point Collections contain recovery points for virtual machines, enabling point-in-time recovery capabilities. Adversaries may delete these collections to prevent recovery during ransomware attacks or to cover their tracks during malicious operations. |[Domain: Cloud], [Domain: Storage], [Data Source: Azure], [Data Source: Azure Activity Logs], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |1 + +|<> |Identifies multiple Azure Restore Point Collections being deleted by a single user within a short time period. Restore Point Collections contain recovery points for virtual machines, enabling point-in-time recovery capabilities. Mass deletion of these collections is a common tactic used by adversaries during ransomware attacks to prevent victim recovery or to maximize impact during destructive operations. Multiple deletions in rapid succession may indicate malicious intent. |[Domain: Cloud], [Domain: Storage], [Data Source: Azure], [Data Source: Azure Activity Logs], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |1 + |<> |Identifies the deletion of diagnostic settings in Azure, which send platform logs and metrics to different destinations. An adversary may delete diagnostic settings in an attempt to evade defenses. |[Domain: Cloud], [Data Source: Azure], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |106 |<> |Identifies rare Azure Entra ID apps IDs requesting authentication on-behalf-of a principal user. An adversary with stolen credentials may specify an Azure-managed app ID to authenticate on-behalf-of a user. This is a rare event and may indicate an attempt to bypass conditional access policies (CAP) and multi-factor authentication (MFA) requirements. The app ID specified may not be commonly used by the user based on their historical sign-in activity. |[Domain: Cloud], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |4 @@ -456,14 +460,22 @@ and their rule type is `machine_learning`. |<> |Identifies when a user is assigned a built-in administrator role in Azure RBAC (Role-Based Access Control). These roles provide significant privileges and can be abused by attackers for lateral movement, persistence, or privilege escalation. The privileged built-in administrator roles include Owner, Contributor, User Access Administrator, Azure File Sync Administrator, Reservations Administrator, and Role Based Access Control Administrator. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure Activity Logs], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 +|<> |Identifies the deletion of Azure Recovery Services resources. Azure Recovery Services vaults contain data for copies of VMs, workloads, servers, and other resources regarding Infrastructure as a Service (IaaS). Adversaries may delete these recovery services to impact backup capabilities during stable operations or to inhibit disaster recovery services during ransom-based attacks or operational disruptions. |[Domain: Cloud], [Domain: Storage], [Data Source: Azure], [Data Source: Azure Activity Logs], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Rule Type: BBR] |None |1 + |<> |Identifies the deletion of a resource group in Azure, which includes all resources within the group. Deletion is permanent and irreversible. An adversary may delete a resource group in an attempt to evade defenses or intentionally destroy data. |[Domain: Cloud], [Data Source: Azure], [Use Case: Log Auditing], [Tactic: Impact], [Resources: Investigation Guide] |None |106 |<> |Identifies when Azure Storage Account Blob public access is enabled, allowing external access to blob containers. This technique was observed in cloud ransom-based campaigns where threat actors modified storage accounts to expose non-remotely accessible accounts to the internet for data exfiltration. Adversaries abuse the Microsoft.Storage/storageAccounts/write operation to modify public access settings. |[Domain: Cloud], [Domain: Storage], [Data Source: Azure], [Data Source: Azure Activity Logs], [Use Case: Threat Detection], [Tactic: Collection], [Resources: Investigation Guide] |None |1 +|<> |Identifies when an Azure Storage Account is deleted. Adversaries may delete storage accounts to disrupt operations, destroy evidence, or cause denial of service. This activity could indicate an attacker attempting to cover their tracks after data exfiltration or as part of a destructive attack. Monitoring storage account deletions is critical for detecting potential impact on business operations and data availability. |[Domain: Cloud], [Domain: Storage], [Data Source: Azure], [Data Source: Azure Activity Logs], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |1 + +|<> |Identifies when a single user or service principal deletes multiple Azure Storage Accounts within a short time period. This behavior may indicate an adversary attempting to cause widespread service disruption, destroy evidence, or execute a destructive attack such as ransomware. Mass deletion of storage accounts can have severe business impact and is rarely performed by legitimate administrators except during controlled decommissioning activities. |[Domain: Cloud], [Domain: Storage], [Data Source: Azure], [Data Source: Azure Activity Logs], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |1 + |<> |Identifies a rotation to storage account access keys in Azure. Regenerating access keys can affect any applications or Azure services that are dependent on the storage account key. Adversaries may regenerate a key as a means of acquiring credentials to access systems and resources. |[Domain: Cloud], [Data Source: Azure], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Resources: Investigation Guide] |None |106 |<> |Identifies unusual high-privileged access to Azure Storage Account keys by users with Owner, Contributor, or Storage Account Contributor roles. This technique was observed in STORM-0501 ransomware campaigns where compromised identities with high-privilege Azure RBAC roles retrieved access keys to perform unauthorized operations on Storage Accounts. Microsoft recommends using Shared Access Signature (SAS) models instead of direct key access for improved security. This rule detects when a user principal with high-privilege roles accesses storage keys for the first time in 7 days. |[Domain: Cloud], [Domain: Identity], [Use Case: Threat Detection], [Data Source: Azure], [Data Source: Azure Activity Logs], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 +|<> |Identifies successful GetBlob operations on Azure Storage Accounts using AzCopy user agent with SAS token authentication. AzCopy is a command-line utility for copying data to and from Azure Storage. While legitimate for data migration, adversaries may abuse AzCopy with compromised SAS tokens to exfiltrate data from Azure Storage Accounts. This rule detects the first occurrence of GetBlob operations from a specific storage account using this pattern. |[Domain: Cloud], [Domain: Storage], [Data Source: Azure], [Data Source: Azure Platform Logs], [Data Source: Azure Storage], [Use Case: Threat Detection], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |1 + |<> |Detects when the tc (transmission control) binary is utilized to set a BPF (Berkeley Packet Filter) on a network interface. Tc is used to configure Traffic Control in the Linux kernel. It can shape, schedule, police and drop traffic. A threat actor can utilize tc to set a bpf filter on an interface for the purpose of manipulating the incoming traffic. This technique is not at all common and should indicate abnormal, suspicious or malicious activity. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Threat: TripleCross], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |213 |<> |Detects use of wbadmin.exe to delete backup catalogs, system state backups, or other backup data. Ransomware and other malware may do this to prevent system recovery. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |318 @@ -578,7 +590,7 @@ and their rule type is `machine_learning`. |<> |This rule monitors for (ana)cron jobs being created or renamed. Linux cron jobs are scheduled tasks that can be leveraged by system administrators to set up scheduled tasks, but may be abused by malicious actors for persistence, privilege escalation and command execution. By creating or modifying cron job configurations, attackers can execute malicious commands or scripts at predefined intervals, ensuring their continued presence and enabling unauthorized activities. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |18 -|<> |Generates a detection alert for each CrowdStrike alert written to the configured indices. Enabling this rule allows you to immediately begin investigating CrowdStrike alerts in the app. |[Data Source: Crowdstrike], [Use Case: Threat Detection], [Resources: Investigation Guide], [Promotion: External Alerts] |8.18.0 |2 +|<> |Generates a detection alert for each CrowdStrike alert written to the configured indices. Enabling this rule allows you to immediately begin investigating CrowdStrike alerts in the app. |[Data Source: Crowdstrike], [Use Case: Threat Detection], [Resources: Investigation Guide], [Promotion: External Alerts] |None |2 |<> |This detection rule addresses multiple vulnerabilities in the CUPS printing system, including CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Specifically, this rule detects shell executions from the foomatic-rip parent process. These flaws impact components like cups-browsed, libcupsfilters, libppd, and foomatic-rip, allowing remote unauthenticated attackers to manipulate IPP URLs or inject malicious data through crafted UDP packets or network spoofing. This can result in arbitrary command execution when a print job is initiated. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Use Case: Vulnerability], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |106 @@ -594,7 +606,7 @@ and their rule type is `machine_learning`. |<> |Detects file creation events in the plugin directories for the Yum package manager. In Linux, DNF (Dandified YUM) is a command-line utility used for handling packages on Fedora-based systems, providing functions for installing, updating, upgrading, and removing software along with managing package repositories. Attackers can backdoor DNF to gain persistence by injecting malicious code into plugins that DNF runs, thereby ensuring continued unauthorized access or control each time DNF is used for package management. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |106 -|<> |Identifies changes to the DNS Global Query Block List (GQBL), a security feature that prevents the resolution of certain DNS names often exploited in attacks like WPAD spoofing. Attackers with certain privileges, such as DNSAdmins, can modify or disable the GQBL, allowing exploitation of hosts running WPAD with default settings for privilege escalation and lateral movement. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |207 +|<> |Identifies changes to the DNS Global Query Block List (GQBL), a security feature that prevents the resolution of certain DNS names often exploited in attacks like WPAD spoofing. Attackers with certain privileges, such as DNSAdmins, can modify or disable the GQBL, allowing exploitation of hosts running WPAD with default settings for privilege escalation and lateral movement. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |208 |<> |A machine learning job detected unusually large numbers of DNS queries for a single top-level DNS domain, which is often used for DNS tunneling. DNS tunneling can be used for command-and-control, persistence, or data exfiltration activity. For example, dnscat tends to generate many DNS questions for a top-level domain as it uses the DNS protocol to tunnel data. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Command and Control], [Resources: Investigation Guide] |None |107 @@ -612,6 +624,8 @@ and their rule type is `machine_learning`. |<> |Identifies use of the fsutil.exe to delete the volume USNJRNL. This technique is used by attackers to eliminate evidence of files created during post-exploitation activities. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |314 +|<> |Identifies attempts to login to AWS as the root user without using multi-factor authentication (MFA). Amazon AWS best practices indicate that the root user should be protected by MFA. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Route53], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Privilege Escalation] |None |212 + |<> |Identifies a suspicious file that was written by a PDF reader application and subsequently executed. These processes are often launched via exploitation of PDF applications. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon] |None |211 |<> |Indicates the creation or modification of a launch daemon, which adversaries may use to repeatedly execute malicious payloads as part of persistence. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |111 @@ -622,7 +636,7 @@ and their rule type is `machine_learning`. |<> |Identifies use of the netsh.exe to disable or weaken the local firewall. Attackers will use this command line tool to disable the firewall during troubleshooting or to enable network mobility. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |315 -|<> |LSA protecton is provided to prevent nonprotected processes from reading memory and injecting code. This feature provides added security for the credentials that LSA stores and manages. Adversaries may modify the RunAsPPL registry and wait or initiate a system restart to enable Lsass credentials access. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |2 +|<> |LSA protecton is provided to prevent nonprotected processes from reading memory and injecting code. This feature provides added security for the credentials that LSA stores and manages. Adversaries may modify the RunAsPPL registry and wait or initiate a system restart to enable Lsass credentials access. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |3 |<> |User Account Control (UAC) can help mitigate the impact of malware on Windows hosts. With UAC, apps and tasks always run in the security context of a non-administrator account, unless an administrator specifically authorizes administrator-level access to the system. This rule identifies registry value changes to bypass User Access Control (UAC) protection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |315 @@ -670,7 +684,7 @@ and their rule type is `machine_learning`. |<> |Identifies the Elastic endpoint agent has stopped and is no longer running on the host. Adversaries may attempt to disable security monitoring tools in an attempt to evade detection or prevention capabilities during an intrusion. This may also indicate an issue with the agent itself and should be addressed to ensure defensive measures are back in a stable state. |[Domain: Endpoint], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |110 -|<> |Generates a detection alert for each Elastic Security alert written to the configured indices. Enabling this rule allows you to immediately begin investigating Elastic Security alerts in the app. |[Data Source: Elastic Security], [Use Case: Threat Detection], [Resources: Investigation Guide], [Promotion: External Alerts] |8.18.0 |2 +|<> |Generates a detection alert for each Elastic Security alert written to the configured indices. Enabling this rule allows you to immediately begin investigating Elastic Security alerts in the app. |[Data Source: Elastic Security], [Use Case: Threat Detection], [Resources: Investigation Guide], [Promotion: External Alerts] |None |2 |<> |Identifies the creation or modification of the Event Monitor Daemon (emond) rules. Adversaries may abuse this service by writing a rule to execute commands when a defined event occurs, such as system start up or user authentication. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |112 @@ -690,10 +704,14 @@ and their rule type is `machine_learning`. |<> |Identifies when multi-factor authentication (MFA) is disabled for an Entra ID user account. An adversary may disable MFA for a user account in order to weaken the authentication requirements for the account. |[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: Persistence] |None |109 +|<> |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 |3 + |<> |Identifies sign-in risk detection events via Microsofts Entra ID Protection service. Entra ID Protection detects sign-in activity such as anonymized IP addresses, unlikely travel, password spray, and more. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Use Case: Risk Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |3 |<> |Identifies user risk detection events via Microsofts Entra ID Protection service. Entra ID Protection detects user risk activity such as anonymized IP addresses, unlikely travel, password spray, and more. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Use Case: Risk Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |2 +|<> |Identifies when an administrator has manually confirmed a user or sign-in as compromised in Microsoft Entra ID Protection. This indicates that an administrator has reviewed the risk detection and determined that the user account or sign-in activity is definitively compromised. This is a high-confidence indicator of account compromise and should be investigated immediately. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Protection Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |1 + |<> |Identifies when a user signs in with a refresh token using the Microsoft Authentication Broker (MAB) client, followed by a Primary Refresh Token (PRT) sign-in from the same device within 1 hour. This pattern may indicate that an attacker has successfully registered a device using ROADtx and transitioned from short-term token access to long-term persistent access via PRTs. Excluding access to the Device Registration Service (DRS) ensures the PRT is being used beyond registration, often to access Microsoft 365 resources like Outlook or SharePoint. |[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: Persistence], [Tactic: Initial Access], [Resources: Investigation Guide] |None |2 |<> |Identifies when a Microsoft Entra ID user signs in from a device that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. This rule detects unusual sign-in activity by comparing the device used for the sign-in against the user's typical device usage patterns. Adversaries may create and register a new device to obtain a Primary Refresh Token (PRT) and maintain persistent access. |[Domain: Cloud], [Domain: Identity], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Resources: Investigation Guide] |None |1 @@ -718,7 +736,7 @@ and their rule type is `machine_learning`. |<> |Identifies an excessive number of Microsoft 365 mailbox items accessed by a user either via aggregated counts or throttling. Microsoft audits mailbox access via the MailItemsAccessed event, which is triggered when a user accesses mailbox items. If more than 1000 mailbox items are accessed within a 24-hour period, it is then throttled. Excessive mailbox access may indicate an adversary attempting to exfiltrate sensitive information or perform reconnaissance on a target's mailbox. This rule detects both the throttled and unthrottled events with a high threshold. |[Domain: Cloud], [Domain: Email], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Tactic: Collection], [Resources: Investigation Guide] |None |1 -|<> |Identifies excessive secret or key retrieval operations from Azure Key Vault. This rule detects when a user principal retrieves secrets or keys from Azure Key Vault multiple times within a short time frame, which may indicate potential abuse or unauthorized access attempts. The rule focuses on high-frequency retrieval operations that deviate from normal user behavior, suggesting possible credential harvesting or misuse of sensitive information. |[Domain: Cloud], [Domain: Storage], [Domain: Identity], [Data Source: Azure], [Data Source: Azure Platform Logs], [Data Source: Azure Key Vault], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Resources: Investigation Guide] |None |3 +|<> |Identifies excessive secret or key retrieval operations from Azure Key Vault. This rule detects when a user principal retrieves secrets or keys from Azure Key Vault multiple times within a short time frame, which may indicate potential abuse or unauthorized access attempts. The rule focuses on high-frequency retrieval operations that deviate from normal user behavior, suggesting possible credential harvesting or misuse of sensitive information. |[Domain: Cloud], [Domain: Storage], [Domain: Identity], [Data Source: Azure], [Data Source: Azure Platform Logs], [Data Source: Azure Key Vault], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Resources: Investigation Guide] |None |4 |<> |Identifies the use of the Exchange PowerShell cmdlet, New-MailBoxExportRequest, to export the contents of a primary mailbox or archive to a .pst file. Adversaries may target user email to collect sensitive information. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Collection], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |213 @@ -936,7 +954,7 @@ and their rule type is `machine_learning`. |<> |Drive and Docs is a Google Workspace service that allows users to leverage Google Drive and Google Docs. Access to files is based on inherited permissions from the child organizational unit the user belongs to which is scoped by administrators. Typically if a user is removed, their files can be transferred to another user by the administrator. This service can also be abused by adversaries to transfer files to an adversary account for potential exfiltration. |[Domain: Cloud], [Data Source: Google Workspace], [Tactic: Collection], [Resources: Investigation Guide] |None |109 -|<> |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] |8.18.0 |1 +|<> |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 |<> |Google Workspace admins may setup 2-step verification (2SV) to add an extra layer of security to user accounts by asking users to verify their identity when they use login credentials. Admins have the ability to enforce 2SV from the admin console as well as the methods acceptable for verification and enrollment period. 2SV requires enablement on admin accounts prior to it being enabled for users within organization units. Adversaries may disable 2SV to lower the security requirements to access a valid account. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |109 @@ -1342,7 +1360,7 @@ and their rule type is `machine_learning`. |<> |Identifies attempts to open a Microsoft Management Console File from untrusted paths. Adversaries may use MSC files for initial access and execution. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Microsoft Defender for Endpoint], [Data Source: Windows Security Event Logs], [Data Source: Crowdstrike], [Resources: Investigation Guide], [Data Source: Sysmon] |None |313 -|<> |Generates a detection alert for each Microsoft Sentinel alert written to the configured indices. Enabling this rule allows you to immediately begin investigating Microsoft Sentinel alerts in the app. |[Data Source: Microsoft Sentinel], [Use Case: Threat Detection], [Resources: Investigation Guide], [Promotion: External Alerts] |8.18.0 |1 +|<> |Generates a detection alert for each Microsoft Sentinel alert written to the configured indices. Enabling this rule allows you to immediately begin investigating Microsoft Sentinel alerts in the app. |[Data Source: Microsoft Sentinel], [Use Case: Threat Detection], [Resources: Investigation Guide], [Promotion: External Alerts] |None |1 |<> |Identifies when one or more features on Microsoft Defender are disabled. Adversaries may disable or tamper with Microsoft Defender features to evade detection and conceal malicious behavior. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Data Source: Crowdstrike] |None |317 @@ -1592,7 +1610,7 @@ and their rule type is `machine_learning`. |<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Use Case: Vulnerability], [Resources: Investigation Guide] |None |1 -|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Use Case: Vulnerability], [Resources: Investigation Guide] |None |1 +|<> |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. |[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 |2 |<> |Identifies a suspicious Diagnostics Utility for Internet Explorer child process. This may indicate the successful exploitation of the vulnerability CVE-2025-33053. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |1 @@ -1602,6 +1620,8 @@ and their rule type is `machine_learning`. |<> |This rule monitors for suspicious activities that may indicate an attacker attempting to execute arbitrary code within a PostgreSQL environment. Attackers can execute code via PostgreSQL as a result of gaining unauthorized access to a public facing PostgreSQL database or exploiting vulnerabilities, such as remote command execution and SQL injection attacks, which can result in unauthorized access and malicious actions, and facilitate post-exploitation activities for unauthorized access and malicious actions. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |11 +|<> |Identifies potential attempt to execute via a reverse shell using the netcat utility to execute Windows commands using the default interpreters like Cmd.exe and Powershell. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |1 + |<> |Identifies instances of Internet Explorer (iexplore.exe) being started via the Component Object Model (COM) making unusual network connections. Adversaries could abuse Internet Explorer via COM to avoid suspicious processes making network connections and bypass host-based firewall restrictions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |109 |<> |Identifies potential relay activities against a Computer account by identifying authentication events using the computer account coming from from hosts other than the server that owns the account. Attackers may relay the computer account hash after capturing it using forced authentication. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Active Directory], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |108 @@ -1702,7 +1722,7 @@ and their rule type is `machine_learning`. |<> |Identifies the creation of a DNS record containing a base64-encoded blob matching the pattern "UWhRCA...BAAAA". This pattern corresponds to a marshaled CREDENTIAL_TARGET_INFORMATION structure, commonly used in Kerberos coercion attacks. It is associated with tools and techniques that exploit SPN spoofing via DNS. Adversaries may abuse this to coerce victim systems into authenticating to attacker-controlled hosts while requesting Kerberos tickets for legitimate services (often the victim's own identity). This enables reflective Kerberos relay attacks, potentially resulting in privileged access such as NT AUTHORITY\SYSTEM, without relying on NTLM fallback. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Active Directory], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |1 -|<> |Detects potential relay attacks by identifying coercion attempts followed by authentication events using a target server's computer account, originating from a different host. This may indicate that an attacker has captured and relayed the server's computer account hash to execute code on behalf of the compromised system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Active Directory], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |8.18.6 |1 +|<> |Detects potential relay attacks by identifying coercion attempts followed by authentication events using a target server's computer account, originating from a different host. This may indicate that an attacker has captured and relayed the server's computer account hash to execute code on behalf of the compromised system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Active Directory], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |1 |<> |Identifies queries to a DNS record containing a base64-encoded blob matching the pattern "UWhRCA...BAAAA". This pattern corresponds to a marshaled CREDENTIAL_TARGET_INFORMATION structure, commonly used in Kerberos coercion attacks. It is associated with tools and techniques that exploit SPN spoofing via DNS. Adversaries may abuse this to coerce victim systems into authenticating to attacker-controlled hosts while requesting Kerberos tickets for legitimate services (often the victim's own identity), enabling attacks such as NTLM reflection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Sysmon], [Resources: Investigation Guide] |None |1 @@ -1762,7 +1782,7 @@ and their rule type is `machine_learning`. |<> |Windows contains accessibility features that may be launched with a key combination before a user has logged in. An adversary can modify the way these programs are launched to get a command prompt or backdoor without logging in to the system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint] |None |216 -|<> |Detects potential relay attacks by identifying coercion attempts followed by authentication events using a target server's computer account, originating from a different host. This may indicate that an attacker has captured and relayed the server's computer account hash to execute code on behalf of the compromised system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Active Directory], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |8.18.6 |1 +|<> |Detects potential relay attacks by identifying coercion attempts followed by authentication events using a target server's computer account, originating from a different host. This may indicate that an attacker has captured and relayed the server's computer account hash to execute code on behalf of the compromised system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Active Directory], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |1 |<> |Identifies registry modification to force the system to fall back to NTLMv1 for authentication. This modification is possible with local administrator privileges and is commonly referred to as a `NetNTLMv1 downgrade attack`. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Sysmon], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |3 @@ -1852,7 +1872,7 @@ and their rule type is `machine_learning`. |<> |This rule monitors a sequence involving a program compilation event followed by its execution and a subsequent alteration of UID permissions to root privileges. This behavior can potentially indicate the execution of a kernel or software privilege escalation exploit. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |8 -|<> |Identifies registry modifications to default services that could enable privilege escalation to SYSTEM. Attackers with privileges from groups like Server Operators may change the ImagePath of services to executables under their control or to execute commands. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Crowdstrike], [Resources: Investigation Guide], [Data Source: SentinelOne], [Data Source: Microsoft Defender for Endpoint], [Data Source: Elastic Endgame] |None |106 +|<> |Identifies registry modifications to default services that could enable privilege escalation to SYSTEM. Attackers with privileges from groups like Server Operators may change the ImagePath of services to executables under their control or to execute commands. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Crowdstrike], [Resources: Investigation Guide], [Data Source: SentinelOne], [Data Source: Microsoft Defender for Endpoint], [Data Source: Elastic Endgame] |None |107 |<> |A sudoers file specifies the commands users or groups can run and from which terminals. Adversaries can take advantage of these configurations to execute commands as other users or spawn processes with higher privileges. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |107 @@ -2254,9 +2274,9 @@ and their rule type is `machine_learning`. |<> |Identifies attempts to access sensitive registry hives which contain credentials from the registry backup folder. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |5 -|<> |Generates a detection alert for each SentinelOne alert written to the configured indices. Enabling this rule allows you to immediately begin investigating SentinelOne alerts in the app. |[Data Source: SentinelOne], [Use Case: Threat Detection], [Resources: Investigation Guide], [Promotion: External Alerts] |8.18.0 |1 +|<> |Generates a detection alert for each SentinelOne alert written to the configured indices. Enabling this rule allows you to immediately begin investigating SentinelOne alerts in the app. |[Data Source: SentinelOne], [Use Case: Threat Detection], [Resources: Investigation Guide], [Promotion: External Alerts] |None |1 -|<> |Generates a detection alert for each SentinelOne threat written to the configured indices. Enabling this rule allows you to immediately begin investigating SentinelOne threat alerts in the app. |[Data Source: SentinelOne], [Use Case: Threat Detection], [Resources: Investigation Guide], [Promotion: External Alerts] |8.18.0 |1 +|<> |Generates a detection alert for each SentinelOne threat written to the configured indices. Enabling this rule allows you to immediately begin investigating SentinelOne threat alerts in the app. |[Data Source: SentinelOne], [Use Case: Threat Detection], [Resources: Investigation Guide], [Promotion: External Alerts] |None |1 |<> |Identifies use of sc.exe to create, modify, or start services on remote hosts. This could be indicative of adversary lateral movement but will be noisy if commonly done by admins. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |210 @@ -2288,7 +2308,7 @@ and their rule type is `machine_learning`. |<> |Identifies the use of Windows Work Folders to execute a potentially masqueraded control.exe file in the current working directory. Misuse of Windows Work Folders could indicate malicious activity. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |314 -|<> |This rule detects connections accepted by a simple HTTP web server in Python and PHP built-in modules. Adversaries may create simple HTTP web servers to establish persistence on a compromised system by uploading a reverse or command shell payload to the server web root, allowing them to regain remote access to the system if lost. This event may occur when an attacker requests the server to execute a command or script via a potential backdoor. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |4 +|<> |This rule detects connections accepted by a simple HTTP web server in Python and PHP built-in modules. Adversaries may create simple HTTP web servers to establish persistence on a compromised system by uploading a reverse or command shell payload to the server web root, allowing them to regain remote access to the system if lost. This event may occur when an attacker requests the server to execute a command or script via a potential backdoor. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |5 |<> |This rule detects the creation of a simple HTTP web server using PHP or Python built-in modules. Adversaries may create simple HTTP web servers to establish persistence on a compromised system by uploading a reverse or command shell payload to the server web root, allowing them to regain remote access to the system if lost. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |104 @@ -2344,7 +2364,7 @@ and their rule type is `machine_learning`. |<> |A machine learning job has detected a sudden spike in host based traffic. This can be due to a range of security issues, such as a compromised system, DDoS attacks, malware infections, privilege escalation, or data exfiltration. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Resources: Investigation Guide] |None |3 -|<> |Generates a detection alert for each Splunk alert written to the configured indices. Enabling this rule allows you to immediately begin investigating Splunk alerts in the app. |[Data Source: Splunk], [Use Case: Threat Detection], [Resources: Investigation Guide], [Promotion: External Alerts] |8.18.0 |1 +|<> |Generates a detection alert for each Splunk alert written to the configured indices. Enabling this rule allows you to immediately begin investigating Splunk alerts in the app. |[Data Source: Splunk], [Use Case: Threat Detection], [Resources: Investigation Guide], [Promotion: External Alerts] |None |1 |<> |Identifies files written or modified in the startup folder by unsigned processes. Adversaries may abuse this technique to maintain persistence in an environment. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |112 @@ -2424,8 +2444,6 @@ and their rule type is `machine_learning`. |<> |A suspicious Endpoint Security parent process was detected. This may indicate a process hollowing or other form of code injection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |319 -|<> |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 |2 - |<> |This detection rule addresses multiple vulnerabilities in the CUPS printing system, including CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Specifically, this rule detects suspicious process command lines executed by child processes of foomatic-rip and cupsd. These flaws impact components like cups-browsed, libcupsfilters, libppd, and foomatic-rip, allowing remote unauthenticated attackers to manipulate IPP URLs or inject malicious data through crafted UDP packets or network spoofing. This can result in arbitrary command execution when a print job is initiated. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Use Case: Vulnerability], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |106 |<> |Identifies the execution of a process with arguments pointing to the INetCache Folder. Adversaries may deliver malicious content via WININET during initial access. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Command and Control], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |210 @@ -2828,7 +2846,7 @@ and their rule type is `machine_learning`. |<> |Identifies Windows programs run from unexpected parent processes. This could indicate masquerading or other strange activity on a system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |319 -|<> |Identifies processes modifying the services registry key directly, instead of through the expected Windows APIs. This could be an indication of an adversary attempting to stealthily persist through abnormal service creation or modification of an existing service. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |314 +|<> |Identifies processes modifying the services registry key directly, instead of through the expected Windows APIs. This could be an indication of an adversary attempting to stealthily persist through abnormal service creation or modification of an existing service. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |315 |<> |This rule detects the execution of the `pkexec` command by a shell process. The `pkexec` command is used to execute programs as another user, typically as the superuser. Through the `new_terms` rule type, unusual executions of `pkexec` are identified, and may indicate an attempt to escalate privileges or perform unauthorized actions on the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Persistence], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |105 diff --git a/docs/detections/prebuilt-rules/rule-desc-index.asciidoc b/docs/detections/prebuilt-rules/rule-desc-index.asciidoc index f4448394c1..ac480d9014 100644 --- a/docs/detections/prebuilt-rules/rule-desc-index.asciidoc +++ b/docs/detections/prebuilt-rules/rule-desc-index.asciidoc @@ -61,7 +61,6 @@ include::rule-details/aws-iam-group-creation.asciidoc[] include::rule-details/aws-iam-group-deletion.asciidoc[] include::rule-details/aws-iam-login-profile-added-for-root.asciidoc[] include::rule-details/aws-iam-login-profile-added-to-user.asciidoc[] -include::rule-details/aws-iam-password-recovery-requested.asciidoc[] include::rule-details/aws-iam-roles-anywhere-profile-creation.asciidoc[] include::rule-details/aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc[] include::rule-details/aws-iam-saml-provider-updated.asciidoc[] @@ -88,7 +87,6 @@ include::rule-details/aws-rds-security-group-deletion.asciidoc[] include::rule-details/aws-rds-snapshot-deleted.asciidoc[] include::rule-details/aws-rds-snapshot-export.asciidoc[] include::rule-details/aws-redshift-cluster-creation.asciidoc[] -include::rule-details/aws-root-login-without-mfa.asciidoc[] include::rule-details/aws-route-53-domain-transfer-lock-disabled.asciidoc[] include::rule-details/aws-route-53-domain-transferred-to-another-account.asciidoc[] include::rule-details/aws-route53-private-hosted-zone-associated-with-a-vpc.asciidoc[] @@ -118,7 +116,9 @@ include::rule-details/aws-sts-role-assumption-by-service.asciidoc[] include::rule-details/aws-sts-role-assumption-by-user.asciidoc[] include::rule-details/aws-sts-role-chaining.asciidoc[] include::rule-details/aws-service-quotas-multi-region-getservicequota-requests.asciidoc[] -include::rule-details/aws-signin-single-factor-console-login-with-federated-user.asciidoc[] +include::rule-details/aws-sign-in-console-login-with-federated-user.asciidoc[] +include::rule-details/aws-sign-in-root-password-recovery-requested.asciidoc[] +include::rule-details/aws-sign-in-token-created.asciidoc[] include::rule-details/aws-systems-manager-securestring-parameter-request-with-decryption-flag.asciidoc[] include::rule-details/aws-vpc-flow-logs-deletion.asciidoc[] include::rule-details/aws-waf-access-control-list-deletion.asciidoc[] @@ -201,6 +201,8 @@ include::rule-details/azure-automation-webhook-created.asciidoc[] include::rule-details/azure-blob-container-access-level-modification.asciidoc[] include::rule-details/azure-blob-permissions-modification.asciidoc[] include::rule-details/azure-command-execution-on-virtual-machine.asciidoc[] +include::rule-details/azure-compute-restore-point-collection-deleted-by-unusual-user.asciidoc[] +include::rule-details/azure-compute-restore-point-collections-deleted.asciidoc[] include::rule-details/azure-diagnostic-settings-deletion.asciidoc[] include::rule-details/azure-entra-id-rare-app-id-for-principal-authentication.asciidoc[] include::rule-details/azure-event-hub-authorization-rule-created-or-updated.asciidoc[] @@ -219,10 +221,14 @@ include::rule-details/azure-network-watcher-deletion.asciidoc[] include::rule-details/azure-openai-insecure-output-handling.asciidoc[] include::rule-details/azure-privilege-identity-management-role-modified.asciidoc[] include::rule-details/azure-rbac-built-in-administrator-roles-assigned.asciidoc[] +include::rule-details/azure-recovery-services-resource-deleted.asciidoc[] include::rule-details/azure-resource-group-deletion.asciidoc[] include::rule-details/azure-storage-account-blob-public-access-enabled.asciidoc[] +include::rule-details/azure-storage-account-deletion-by-unusual-user.asciidoc[] +include::rule-details/azure-storage-account-deletions-by-user.asciidoc[] include::rule-details/azure-storage-account-key-regenerated.asciidoc[] include::rule-details/azure-storage-account-keys-accessed-by-privileged-user.asciidoc[] +include::rule-details/azure-storage-blob-retrieval-via-azcopy.asciidoc[] include::rule-details/bpf-filter-applied-using-tc.asciidoc[] include::rule-details/backup-deletion-with-wbadmin.asciidoc[] include::rule-details/base16-or-base32-encoding-decoding-activity.asciidoc[] @@ -297,6 +303,7 @@ include::rule-details/default-cobalt-strike-team-server-certificate.asciidoc[] include::rule-details/delayed-execution-via-ping.asciidoc[] include::rule-details/delegated-managed-service-account-modification-by-an-unusual-user.asciidoc[] include::rule-details/delete-volume-usn-journal-with-fsutil.asciidoc[] +include::rule-details/deprecated-aws-root-login-without-mfa.asciidoc[] include::rule-details/deprecated-execution-of-file-written-or-modified-by-pdf-reader.asciidoc[] include::rule-details/deprecated-launchdaemon-creation-or-modification-and-immediate-loading.asciidoc[] include::rule-details/directory-creation-in-bin-directory.asciidoc[] @@ -336,8 +343,10 @@ include::rule-details/entra-id-actor-token-user-impersonation-abuse.asciidoc[] include::rule-details/entra-id-device-code-auth-with-broker-client.asciidoc[] include::rule-details/entra-id-global-administrator-role-assigned.asciidoc[] include::rule-details/entra-id-mfa-disabled-for-user.asciidoc[] +include::rule-details/entra-id-oauth-user-impersonation-scope-for-unusual-user-and-client.asciidoc[] include::rule-details/entra-id-protection-risk-detection-sign-in-risk.asciidoc[] include::rule-details/entra-id-protection-risk-detection-user-risk.asciidoc[] +include::rule-details/entra-id-protection-admin-confirmed-compromise.asciidoc[] include::rule-details/entra-id-rt-to-prt-transition-from-same-user-and-device.asciidoc[] include::rule-details/entra-id-user-signed-in-from-unusual-device.asciidoc[] include::rule-details/enumerating-domain-trusts-via-dsquery-exe.asciidoc[] @@ -792,6 +801,7 @@ include::rule-details/potential-cve-2025-33053-exploitation.asciidoc[] include::rule-details/potential-cve-2025-41244-vmtoolsd-lpe-exploitation-attempt.asciidoc[] include::rule-details/potential-chroot-container-escape-via-mount.asciidoc[] include::rule-details/potential-code-execution-via-postgresql.asciidoc[] +include::rule-details/potential-command-shell-via-netcat.asciidoc[] include::rule-details/potential-command-and-control-via-internet-explorer.asciidoc[] include::rule-details/potential-computer-account-relay-activity.asciidoc[] include::rule-details/potential-cookies-theft-via-browser-debugging.asciidoc[] @@ -1203,7 +1213,6 @@ include::rule-details/suspicious-dynamic-linker-discovery-via-od.asciidoc[] include::rule-details/suspicious-email-access-by-first-party-application-via-microsoft-graph.asciidoc[] include::rule-details/suspicious-emond-child-process.asciidoc[] include::rule-details/suspicious-endpoint-security-parent-process.asciidoc[] -include::rule-details/suspicious-entra-id-oauth-user-impersonation-scope-detected.asciidoc[] include::rule-details/suspicious-execution-from-foomatic-rip-or-cupsd-parent.asciidoc[] include::rule-details/suspicious-execution-from-inet-cache.asciidoc[] include::rule-details/suspicious-execution-from-a-mounted-device.asciidoc[] diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-administratoraccess-policy-attached-to-group.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-administratoraccess-policy-attached-to-group.asciidoc index 48ec6b69cd..db8eec886c 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-iam-administratoraccess-policy-attached-to-group.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-administratoraccess-policy-attached-to-group.asciidoc @@ -1,11 +1,14 @@ [[aws-iam-administratoraccess-policy-attached-to-group]] === AWS IAM AdministratorAccess Policy Attached to Group -An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to user groups the compromised user account belongs to. This rule looks for use of the IAM `AttachGroupPolicy` API operation to attach the highly permissive `AdministratorAccess` AWS managed policy to an existing IAM user group. +An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to user groups the compromised user account belongs to. This rule looks for use of the IAM AttachGroupPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM user group. -*Rule type*: esql +*Rule type*: eql -*Rule indices*: None +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* *Severity*: medium @@ -34,7 +37,7 @@ An adversary with access to a set of compromised credentials may attempt to pers * Tactic: Persistence * Resources: Investigation Guide -*Version*: 6 +*Version*: 7 *Rule authors*: @@ -50,64 +53,81 @@ An adversary with access to a set of compromised credentials may attempt to pers *Triage and analysis* +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. -*Investigating AWS IAM AdministratorAccess Policy Attached to Group* +*Investigating AWS IAM AdministratorAccess Policy Attached to Group* -The AWS IAM `AdministratorAccess` managed policy provides full access to all AWS services and resources. -With access to the `iam:AttachGroupPolicy` permission, a set of compromised credentials could be used to attach -this policy to the current user's groups for privilege escalation or as a means of persistence. This rule uses https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-esql-rule[ESQL] -to look for use of the `AttachGroupPolicy` operation along with request_parameters where the policyName is `AdministratorAccess`. +The AWS-managed `AdministratorAccess` policy grants full administrative privileges across all AWS services. +When attached to a group, all group members inherit this access, often unintentionally broadening the blast radius of a compromise. +Adversaries can exploit `iam:AttachGroupPolicy` permissions to escalate privileges or establish persistence by attaching this policy to an existing user group. *Possible investigation steps* -- Identify the account and its role in the environment. -- Review IAM permission policies for the user identity. -- Identify the applications or users that should use this account. -- Investigate other alerts associated with the account during the past 48 hours. -- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc. -- Contact the account owner and confirm whether they are aware of this activity. -- Considering the source IP address and geolocation of the user who issued the command: - - Do they look normal for the calling user? - - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control? - - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance? -- 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. - - Determine what other API calls were made by the user. - - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users. +- **Identify the affected group and calling principal.** + Review `aws.cloudtrail.user_identity.arn` (caller) and `aws.cloudtrail.request_parameters.groupName` (target group). + Validate whether this aligns with legitimate change management or automation workflows. + +- **Review group membership.** + Enumerate current members using `aws iam get-group`. + Determine whether unauthorized users could have gained administrative access as a result. + +- **Inspect CloudTrail details.** + Check `source.ip`, `user_agent.original`, and `source.geo` fields for anomalies. + Compare with historical operations by the same principal. + +- **Correlate related IAM activity.** + Search for adjacent events such as `AddUserToGroup`, `CreateUser`, or `AttachUserPolicy`. + These may indicate chained privilege escalation. + +- **Assess propagation of privileges.** + If the group has many members or is linked to cross-account roles, the impact may extend beyond a single user. + Document all affected identities for containment. *False positive analysis* -- False positives may occur due to the intended usage of the IAM `AdministratorAccess` managed policy. Verify the `aws.cloudtrail.user_identity.arn` should have the `iam:AttachUserPolicy` permission and that the `target.userName` should be given full administrative access. +- **Intentional access updates.** + Policy attachment may occur during legitimate administrative provisioning. Confirm via ticketing systems. +- **Automation or compliance tasks.** + Some environments use centralized scripts to attach AdministratorAccess temporarily. Validate through automation logs. *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. - - Rotate user credentials - - Remove the `AdministratorAccess` policy from the affected group(s) -- 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. - - Rotate secrets 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. -- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. -- Consider enabling multi-factor authentication for users. -- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. -- Take the actions needed to return affected systems, data, or services to their normal operational levels. -- Identify 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). +**1. Immediate containment** +- Detach the policy from the affected group (`aws iam detach-group-policy`). +- Review and limit group membership. Temporarily remove non-essential users or disable access for impacted accounts. +- Rotate credentials for users who inherited admin privileges from the attachment. +- Enable MFA on all impacted accounts. + +**2. Evidence preservation** +- Export the triggering `AttachGroupPolicy` event and related CloudTrail entries ±30 minutes from the alert. +- Preserve AWS Config and GuardDuty records to support forensic analysis. + +**3. Scoping and investigation** +- Review additional IAM operations from the same caller (`CreateAccessKey`, `AttachRolePolicy`, `UpdateAssumeRolePolicy`). +- Identify whether new groups or roles were created shortly before or after the event. +- Check for subsequent API activity by newly privileged users (for example, S3, EC2, or IAM modifications). + +**4. Recovery and hardening** +- Reinforce least privilege, avoid assigning `AdministratorAccess` to groups. +- Use role-based access control with scoped permissions. +- Enable CloudTrail, GuardDuty, and Security Hub across all regions. +- Implement SCPs at the organization level to restrict direct `AdministratorAccess` attachments. + + +*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]. ==== Rule query @@ -115,28 +135,11 @@ to look for use of the `AttachGroupPolicy` operation along with request_paramete [source, js] ---------------------------------- -from logs-aws.cloudtrail-* metadata _id, _version, _index - -| where - event.provider == "iam.amazonaws.com" - and event.action == "AttachGroupPolicy" - and event.outcome == "success" - -// Extract policy and group details from request parameters -| dissect aws.cloudtrail.request_parameters - "{%{?policyArn}=%{?arn}:%{?aws}:%{?iam}::%{?aws}:%{?policy}/%{Esql.aws_cloudtrail_request_parameters_policy_name},%{?groupName}=%{Esql.aws_cloudtrail_request_parameters_group_name}}" - -// Filter for attachment of AdministratorAccess policy -| where Esql.aws_cloudtrail_request_parameters_policy_name == "AdministratorAccess" - -// keep ECS and derived fields -| keep - @timestamp, - event.provider, - event.action, - event.outcome, - Esql.aws_cloudtrail_request_parameters_policy_name, - Esql.aws_cloudtrail_request_parameters_group_name +iam where event.dataset == "aws.cloudtrail" + and event.provider == "iam.amazonaws.com" + and event.action == "AttachGroupPolicy" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "policyArn=arn:aws:iam::aws:policy/AdministratorAccess") ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-administratoraccess-policy-attached-to-role.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-administratoraccess-policy-attached-to-role.asciidoc index 2760e8451c..b5d2b346c6 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-iam-administratoraccess-policy-attached-to-role.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-administratoraccess-policy-attached-to-role.asciidoc @@ -1,11 +1,13 @@ [[aws-iam-administratoraccess-policy-attached-to-role]] === AWS IAM AdministratorAccess Policy Attached to Role -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. +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. -*Rule type*: esql +*Rule type*: eql -*Rule indices*: None +*Rule indices*: + +* logs-aws.cloudtrail-* *Severity*: medium @@ -34,7 +36,7 @@ An adversary with access to a set of compromised credentials may attempt to pers * Tactic: Persistence * Resources: Investigation Guide -*Version*: 6 +*Version*: 7 *Rule authors*: @@ -50,64 +52,80 @@ An adversary with access to a set of compromised credentials may attempt to pers *Triage and analysis* +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. -*Investigating AWS IAM AdministratorAccess Policy Attached to Role* +*Investigating AWS IAM AdministratorAccess Policy Attached to Role* -The AWS IAM `AdministratorAccess` managed policy provides full access to all AWS services and resources. -With access to the `iam:AttachRolePolicy` permission, a set of compromised credentials could be used to attach -this policy to a compromised role for privilege escalation or as a means of persistence. This rule uses https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-esql-rule[ESQL] -to look for use of the `AttachRolePolicy` operation along with request_parameters where the policyName is `AdministratorAccess`. +The `AdministratorAccess` managed policy grants unrestricted privileges. +When attached to a role, it can enable privilege escalation or persistence, especially if the role is assumable by other accounts or services. +This rule detects `AttachRolePolicy` events where the `policyName` is `AdministratorAccess`. *Possible investigation steps* -- Identify the account and its role in the environment. -- Review IAM permission policies for the user identity. -- Identify the applications or users that should use this account. -- Investigate other alerts associated with the account during the past 48 hours. -- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc. -- Contact the account owner and confirm whether they are aware of this activity. -- Considering the source IP address and geolocation of the user who issued the command: - - Do they look normal for the calling user? - - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control? - - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance? -- 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. - - Determine what other API calls were made by the user. - - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users. +- **Identify both identities.** + Determine the calling user or role (`aws.cloudtrail.user_identity.arn`) and the target role (`aws.cloudtrail.request_parameters.roleName`). + Validate whether this change aligns with intended administrative actions. + +- **Review the target role’s trust policy.** + Examine who can assume the role (`AssumeRolePolicyDocument`). + If the role is assumable by external accounts, this may indicate a potential persistence or lateral movement path. + +- **Review CloudTrail details.** + Check `source.ip`, `user_agent.original`, and `source.geo` fields for anomalies. + Compare with historical operations by the same principal. + +- **Correlate with adjacent IAM events.** + Look for `UpdateAssumeRolePolicy`, `CreateAccessKey`, or `PassRole` calls. + These often accompany privilege escalation activity. + +- **Inspect downstream activity.** + Query CloudTrail for recent `AssumeRole` calls for the target role — determine if the newly elevated permissions were used. *False positive analysis* -- False positives may occur due to the intended usage of the IAM `AdministratorAccess` managed policy. Verify the `aws.cloudtrail.user_identity.arn` should have the `iam:AttachRolePolicy` permission and that the `role.name` should be given full administrative access. +- **Delegated role management.** + Cloud administrators may legitimately grant temporary AdministratorAccess for troubleshooting. Confirm through tickets or change logs. +- **Automation or service-linked roles.** + Some services attach policies automatically for setup; verify whether the target is a service-linked role. *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. - - Rotate user credentials - - Remove the `AdministratorAccess` policy from the affected role(s) -- 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. - - Rotate secrets 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. -- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. -- Consider enabling multi-factor authentication for users. -- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. -- Take the actions needed to return affected systems, data, or services to their normal operational levels. -- Identify 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). +**1. Immediate containment** +- Detach the policy. Remove the `AdministratorAccess` policy from the target role. +- Restrict access. Temporarily revoke the caller’s IAM privileges until the legitimacy of the action is confirmed. +- Audit trust policies. Review the role’s trust relationships to ensure only approved principals can assume it. +- Rotate credentials for any principals who assumed the affected role during the period of elevated privileges. + +**2. Evidence preservation** +- Export the triggering `AttachRolePolicy` event and related CloudTrail entries ±30 minutes from the alert. +- Preserve AWS Config snapshots and GuardDuty findings for traceability. + +**3. Scoping and investigation** +- Identify if the elevated role was subsequently assumed. + Correlate by matching `aws.cloudtrail.eventName:AssumeRole` with the target role ARN. +- Search for other recent IAM policy attachments or modifications by the same actor or IP. + +**4. Recovery and hardening** +- Apply least privilege policies; limit who can attach or modify administrative policies. +- Enforce IAM Conditions such as `aws:PrincipalArn` or `aws:ResourceTag` to limit policy attachment scope. +- Enable CloudTrail, GuardDuty, and Security Hub across all regions. +- Implement SCPs at the organization level to restrict direct `AdministratorAccess` attachments. + + +*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]. ==== Rule query @@ -115,28 +133,11 @@ to look for use of the `AttachRolePolicy` operation along with request_parameter [source, js] ---------------------------------- -from logs-aws.cloudtrail-* metadata _id, _version, _index - -| where - event.provider == "iam.amazonaws.com" - and event.action == "AttachRolePolicy" - and event.outcome == "success" - -// Extract policy name and role name from request parameters -| dissect aws.cloudtrail.request_parameters - "{%{?policyArn}=%{?arn}:%{?aws}:%{?iam}::%{?aws}:%{?policy}/%{Esql.aws_cloudtrail_request_parameters_policy_name},%{?roleName}=%{Esql.aws_cloudtrail_request_parameters_role_name}}" - -// Filter for AdministratorAccess policy attachment -| where Esql.aws_cloudtrail_request_parameters_policy_name == "AdministratorAccess" - -// keep relevant ECS and dynamic fields -| keep - @timestamp, - event.provider, - event.action, - event.outcome, - Esql.aws_cloudtrail_request_parameters_policy_name, - Esql.aws_cloudtrail_request_parameters_role_name +iam where event.dataset == "aws.cloudtrail" + and event.provider == "iam.amazonaws.com" + and event.action == "AttachRolePolicy" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "policyArn=arn:aws:iam::aws:policy/AdministratorAccess") ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-administratoraccess-policy-attached-to-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-administratoraccess-policy-attached-to-user.asciidoc index b6359e2f2b..863d2dd8e9 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-iam-administratoraccess-policy-attached-to-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-administratoraccess-policy-attached-to-user.asciidoc @@ -1,11 +1,14 @@ [[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. +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*: esql +*Rule type*: eql -*Rule indices*: None +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* *Severity*: medium @@ -34,7 +37,7 @@ An adversary with access to a set of compromised credentials may attempt to pers * Tactic: Persistence * Resources: Investigation Guide -*Version*: 7 +*Version*: 8 *Rule authors*: @@ -50,64 +53,86 @@ An adversary with access to a set of compromised credentials may attempt to pers *Triage and analysis* +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. -*Investigating AWS IAM AdministratorAccess Policy Attached to User* +*Investigating AWS IAM AdministratorAccess Policy Attached to User* -The AWS IAM `AdministratorAccess` managed policy provides full access to all AWS services and resources. -With access to the `iam:AttachUserPolicy` permission, a set of compromised credentials could be used to attach -this policy to the current user for privilege escalation or another user as a means of persistence. This rule uses https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-esql-rule[ESQL] -to look for use of the `AttachUserPolicy` operation along with request_parameters where the policyName is `AdministratorAccess`. +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* -- Identify the account and its role in the environment. -- Review IAM permission policies for the user identity. -- Identify the applications or users that should use this account. -- Investigate other alerts associated with the account during the past 48 hours. -- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc. -- Contact the account owner and confirm whether they are aware of this activity. -- Considering the source IP address and geolocation of the user who issued the command: - - Do they look normal for the calling user? - - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control? - - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance? -- 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. - - Determine what other API calls were made by the user. - - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users. +- **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* -- False positives may occur due to the intended usage of the IAM `AdministratorAccess` managed policy. Verify the `aws.cloudtrail.user_identity.arn` should have the `iam:AttachUserPolicy` permission and that the `target.userName` should be given full administrative access. +- **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* -- Initiate the incident response process based on the outcome of the triage. -- Disable or limit the account during the investigation and response. - - Rotate user credentials - - Remove the `AdministratorAccess` policy from the affected user(s) -- 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. - - Rotate secrets 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. -- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. -- Consider enabling multi-factor authentication for users. -- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. -- Take the actions needed to return affected systems, data, or services to their normal operational levels. -- Identify 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). +> Per AWS IR Playbooks, unauthorized administrative policy attachment represents a Privilege Escalation event. + +**1. 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. + +**2. 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. + +**3. 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. + +**4. 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 @@ -115,35 +140,11 @@ to look for use of the `AttachUserPolicy` operation along with request_parameter [source, js] ---------------------------------- -from logs-aws.cloudtrail-* metadata _id, _version, _index - -| where - event.provider == "iam.amazonaws.com" - and event.action == "AttachUserPolicy" - and event.outcome == "success" - -// Extract policy name and user name from request parameters -| dissect aws.cloudtrail.request_parameters - "{%{?policyArn}=%{?arn}:%{?aws}:%{?iam}::%{?aws}:%{?policy}/%{Esql.aws_cloudtrail_request_parameters_policy_name},%{?userName}=%{Esql_priv.aws_cloudtrail_request_parameters_target_user_name}}" - -// Filter for AdministratorAccess policy -| where Esql.aws_cloudtrail_request_parameters_policy_name == "AdministratorAccess" - -// keep ECS and parsed fields -| keep - @timestamp, - cloud.region, - event.provider, - event.action, - event.outcome, - Esql.aws_cloudtrail_request_parameters_policy_name, - Esql_priv.aws_cloudtrail_request_parameters_target_user_name, - aws.cloudtrail.request_parameters, - aws.cloudtrail.user_identity.arn, - related.user, - user_agent.original, - user.name, - source.address +iam where event.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") ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-login-profile-added-for-root.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-login-profile-added-for-root.asciidoc index 812ba3f04e..32e256b8c9 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-iam-login-profile-added-for-root.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-login-profile-added-for-root.asciidoc @@ -1,11 +1,14 @@ [[aws-iam-login-profile-added-for-root]] === AWS IAM Login Profile Added for Root -Detects when an AWS IAM login profile is added to a root user account and is self-assigned. Adversaries, with temporary access to the root account, may add a login profile to the root user account to maintain access even if the original access key is rotated or disabled. +Identifies creation of a console login profile for the AWS account root user. While CreateLoginProfile normally applies to IAM users, when performed from a temporary root session (e.g., via AssumeRoot) and the userName parameter is omitted, the profile is created for the root principal (self-assigned). Adversaries with temporary root access may add or reset the root login profile to establish persistent console access even if original access keys are rotated or disabled. Correlate with recent AssumeRoot/STS activity and validate intent with the account owner. -*Rule type*: esql +*Rule type*: eql -*Rule indices*: None +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* *Severity*: high @@ -13,7 +16,7 @@ Detects when an AWS IAM login profile is added to a root user account and is sel *Runs every*: 5m -*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) *Maximum alerts per execution*: 100 @@ -29,7 +32,7 @@ Detects when an AWS IAM login profile is added to a root user account and is sel * Tactic: Persistence * Resources: Investigation Guide -*Version*: 3 +*Version*: 4 *Rule authors*: @@ -48,114 +51,96 @@ Detects when an AWS IAM login profile is added to a root user account and is sel > **Disclaimer**: > This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -*Investigating AWS IAM Login Profile Added for Root* - - -AWS IAM allows management of user access and permissions within AWS environments. A login profile enables console access using a password. Adversaries may exploit temporary root access to create a login profile, ensuring persistent access even if keys are rotated. The detection rule identifies such actions by monitoring specific API calls and conditions, flagging unauthorized profile additions to root accounts. +This rule detects when a console login profile is created for the AWS root account. +A login profile enables password-based console access, and because the root user has unrestricted privileges, creating one is an extremely high-impact event. Adversaries who temporarily gain root-level credentials (for example, through an STS session or credential compromise) may use `CreateLoginProfile` without specifying a `userName` to add a password to the root account. This grants persistent access even if the attacker’s API keys are later rotated or disabled. *Possible investigation steps* -- Review the @timestamp field to determine when the CreateLoginProfile action occurred and correlate it with any other suspicious activities around the same time. -- Examine the aws.cloudtrail.user_identity.arn and aws.cloudtrail.user_identity.access_key_id fields to identify the specific root account and access key involved in the action. -- Investigate the source.address field to trace the IP address from which the CreateLoginProfile request originated, checking for any unusual or unauthorized locations. -- Analyze the aws.cloudtrail.request_parameters and aws.cloudtrail.response_elements fields to understand the specifics of the login profile creation and verify if any unexpected parameters were used. -- Check the cloud.account.id to confirm which AWS account was affected and assess if there are any other security incidents or alerts associated with this account. -- Review the event.action field to ensure that no other unauthorized actions were performed by the root account around the same time. - - -*False positive analysis* - - -- Administrative actions by trusted personnel may trigger the rule if they are performing legitimate maintenance or security tasks. To manage this, create exceptions for known administrative accounts by filtering their access key IDs. -- Automated scripts or tools used for account management might inadvertently match the rule's conditions. Identify these scripts and exclude their specific access key IDs or user agents from the detection criteria. -- Testing environments where root access is used for simulation or development purposes can cause false positives. Implement a tagging system for test environments and exclude logs with these tags from triggering the rule. -- Third-party integrations that require root access for initial setup or configuration might be flagged. Document these integrations and adjust the rule to recognize and exclude their specific access patterns. - - -*Response and remediation* +**Assess the timing and context of the event** +- Review the `@timestamp` to determine when the `CreateLoginProfile` call occurred. + - Correlate this time window with other root or IAM activity such as `AssumeRoot`, `GetSessionToken`, `ConsoleLogin`, or `CreateAccessKey`. + - Check for follow-on activity, especially `ConsoleLogin` events or `UpdateLoginProfile`, which may indicate that the root password was used immediately after creation. +**Investigate event origin and session details** +- Review `source.ip` and `user_agent.original`: + - Determine if the request originated from an expected network range, VPN endpoint, or geolocation. + - Identify whether the access was interactive (for example, browser or AWS console) or automated (`aws-cli`, SDK, or API client). +- Examine `aws.cloudtrail.user_identity.access_key_id` and associated STS session context to see if temporary credentials were used. +- Compare this event’s IP and access key to any other recent CloudTrail activity to identify potential lateral movement or multi-account access attempts. -- Immediately revoke any active sessions and access keys associated with the root account to prevent further unauthorized access. -- Reset the root account password and ensure that multi-factor authentication (MFA) is enabled for the root user to enhance security. -- Review AWS CloudTrail logs to identify any other suspicious activities or changes made by the root account during the time of the incident. -- Conduct a thorough audit of IAM policies and permissions to ensure that no other unauthorized changes have been made and that least privilege principles are enforced. -- Notify the security operations team and relevant stakeholders about the incident for further investigation and to ensure awareness across the organization. -- Implement additional monitoring and alerting for root account activities to detect any future unauthorized access attempts promptly. -- Consider engaging AWS Support or a third-party security expert if the incident's scope is beyond internal capabilities or if further forensic analysis is required. +**Analyze the login profile creation** +- Review `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements`: + - Check whether `passwordResetRequired` was set to `true` or omitted, absence may imply that the attacker created a password they intend to reuse. +- Cross-reference this action with previous failed login attempts, password recovery requests, or `AssumeRoot` behavior. +**Correlate related identity and access behavior** +- Search for additional IAM management activity: + - `AttachUserPolicy`, `AttachRolePolicy`, or `PutUserPolicy` granting elevated permissions. + - New `AccessKey` creation or `UpdateAccessKey` events tied to the same session. +- Review GuardDuty findings or any other detections referencing this account or IP around the same time period. +- If available, correlate with CloudTrail to detect if other resource creation or configuration changes followed the login profile addition. -*Investigating AWS IAM Login Profile Added for Root* +**Validate with account owner or authorized personnel** +- Contact the designated account or root credential owner to confirm whether this action was intentional (for example, during an account recovery). +- Review any internal change-management or service ticketing systems for an approved request matching this activity. -This rule detects when a login profile is added to the AWS root account. Adding a login profile to the root account, especially if self-assigned, is highly suspicious as it might indicate an adversary trying to establish persistence in the environment. - - -*Possible Investigation Steps* - - -- **Identify the Source and Context of the Action**: - - Examine the `source.address` field to identify the IP address from which the request originated. - - Check the geographic location (`source.address`) to determine if the access is from an expected or unexpected region. - - Look at the `user_agent.original` field to identify the tool or browser used for this action. - - For example, a user agent like `Mozilla/5.0` might indicate interactive access, whereas `aws-cli` or SDKs suggest scripted activity. - -- **Confirm Root User and Request Details**: - - Validate the root user's identity through `aws.cloudtrail.user_identity.arn` and ensure this activity aligns with legitimate administrative actions. - - Review `aws.cloudtrail.user_identity.access_key_id` to identify if the action was performed using temporary or permanent credentials. This access key could be used to pivot into other actions. - -- **Analyze the Login Profile Creation**: - - Review the `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements` fields for details of the created login profile. - - For example, confirm the `userName` of the profile and whether `passwordResetRequired` is set to `true`. - - Compare the `@timestamp` of this event with other recent actions by the root account to identify potential privilege escalation or abuse. - -- **Correlate with Other Events**: - - Investigate for related IAM activities, such as: - - `CreateAccessKey` or `AttachUserPolicy` events targeting the root account. - - Unusual data access, privilege escalation, or management console logins. - - Check for any anomalies involving the same `source.address` or `aws.cloudtrail.user_identity.access_key_id` in the environment. - -- **Evaluate Policy and Permissions**: - - Verify the current security policies for the root account: - - Ensure password policies enforce complexity and rotation requirements. - - Check if MFA is enforced on the root account. - - Assess the broader IAM configuration for deviations from least privilege principles. - +*False positive analysis* -*False Positive Analysis* +Although rare, legitimate scenarios include: +- **Authorized account recovery** : An administrator or AWS Support might temporarily add a root login profile to regain access. Validate against documented recovery workflows. +- **Controlled testing or sandbox environments** : Certain sandbox accounts may reuse root credentials for automation or demonstration purposes. Tag and exclude these accounts from this rule where appropriate. +- **Automated provisioning** : Review any account bootstrap or recovery automation scripts that may invoke `CreateLoginProfile` on root credentials. -- **Routine Administrative Tasks**: Adding a login profile might be a legitimate action during certain administrative processes. Verify with the relevant AWS administrators if this event aligns with routine account maintenance or emergency recovery scenarios. +For any potential false positive, verify that: +- The `source.ip` and `user_agent.original` values align with expected administrative locations and tools. +- The change was recorded during a maintenance window or known security operation. -- **Automation**: If the action is part of an approved automation process (e.g., account recovery workflows), consider excluding these activities from alerting using specific user agents, IP addresses, or session attributes. +*Response and remediation* -*Response and Remediation* +> Any unapproved creation of a login profile for the root account is a critical security incident requiring immediate containment and credential rotation. -- **Immediate Access Review**: - - Disable the newly created login profile (`aws iam delete-login-profile`) if it is determined to be unauthorized. - - Rotate or disable the credentials associated with the root account to prevent further abuse. +**1. Containment** +- Delete the newly created root login profile if it was not authorized. +- Rotate the root account password using AWS’s official password-reset workflow. +- Revoke any active sessions, temporary credentials, or tokens associated with this event. +- Verify that multi-factor authentication (MFA) is enabled and functioning on the root account. +- Check that no root access keys exist — if present, remove them immediately. -- **Enhance Monitoring and Alerts**: - - Enable real-time monitoring and alerting for IAM actions involving the root account. - - Increase the logging verbosity for root account activities. +**2. Investigation and scoping** +- Examine CloudTrail logs from 30 minutes before and after this event to identify correlated actions. +- Capture and securely store these logs in an isolated S3 bucket with Object Lock enabled to preserve forensic integrity. +- Investigate for additional IAM or STS operations by the same `access_key_id` or IP address that may indicate privilege escalation or persistence attempts. +- Review whether any new IAM roles, users, or policies were created in proximity to this event. -- **Review and Update Security Policies**: - - Enforce MFA for all administrative actions, including root account usage. - - Restrict programmatic access to the root account by disabling access keys unless absolutely necessary. +**3. Recovery and hardening** +- Reset the root password and distribute the new credentials securely to authorized custodians only. +- Ensure MFA is enforced for all administrative and root-level access. +- Audit all IAM policies for least-privilege adherence, focusing on `iam:CreateLoginProfile`, `iam:UpdateLoginProfile`, and `iam:CreateAccessKey` permissions. +- Enable Cloudtrail, GuardDuty, AWS Config, and Security Hub across all regions for continuous monitoring of root and IAM activity. +- Review your organization’s playbooks and detection coverage for root-level persistence techniques, and update procedures as needed. -- **Conduct Post-Incident Analysis**: - - Investigate how the credentials for the root account were compromised or misused. - - Strengthen the security posture by implementing account-specific guardrails and continuous monitoring. +**4. Post-incident actions** +- Notify AWS account owners and your security operations center of the incident. +- Conduct a post-mortem to determine the initial vector of compromise (e.g., stolen credentials, misconfigured role chaining, or insufficient MFA). +- Update alerting thresholds and detection logic to minimize mean time to detect (MTTD) and respond (MTTR). -*Additional Resources* +*Additional information* -- AWS documentation on https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateLoginProfile.html[Login Profile Management]. +- **AWS Incident Response Playbooks** + - https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-CredCompromise.md[IRP-CredCompromise] – Containment and recovery for suspected credential abuse. +- **AWS Customer Playbook Framework** + - https://github.com/aws-samples/aws-customer-playbook-framework/blob/a8c7b313636b406a375952ac00b2d68e89a991f2/docs/Compromised_IAM_Credentials.md[Compromised_IAM_Credentials.md] – Steps to contain, investigate, and recover from credential compromise. +- **AWS Documentation** + - https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateLoginProfile.html[CreateLoginProfile API Reference] + - https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html[Root User Best Practices] ==== Rule query @@ -163,34 +148,12 @@ This rule detects when a login profile is added to the AWS root account. Adding [source, js] ---------------------------------- -from logs-aws.cloudtrail* metadata _id, _version, _index -| where - // filter for CloudTrail logs from IAM - event.dataset == "aws.cloudtrail" - and event.provider == "iam.amazonaws.com" - - // filter for successful CreateLoginProfile API call - and event.action == "CreateLoginProfile" - and event.outcome == "success" - - // filter for Root member account - and aws.cloudtrail.user_identity.type == "Root" - - // filter for an access key existing which sources from AssumeRoot - and aws.cloudtrail.user_identity.access_key_id is not null - - // filter on the request parameters not including UserName which assumes self-assignment - and not to_lower(aws.cloudtrail.request_parameters) like "*username*" -| keep - @timestamp, - aws.cloudtrail.request_parameters, - aws.cloudtrail.response_elements, - aws.cloudtrail.user_identity.type, - aws.cloudtrail.user_identity.arn, - aws.cloudtrail.user_identity.access_key_id, - cloud.account.id, - event.action, - source.address +any where event.dataset == "aws.cloudtrail" + and event.provider == "iam.amazonaws.com" + and event.action == "CreateLoginProfile" + and aws.cloudtrail.user_identity.type == "Root" + and event.outcome == "success" + and not stringContains(aws.cloudtrail.request_parameters, "userName=") ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-user-created-access-keys-for-another-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-user-created-access-keys-for-another-user.asciidoc index bb0d2964fb..600bd66706 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-iam-user-created-access-keys-for-another-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-user-created-access-keys-for-another-user.asciidoc @@ -35,7 +35,7 @@ An adversary with access to a set of compromised credentials may attempt to pers * Tactic: Persistence * Resources: Investigation Guide -*Version*: 7 +*Version*: 8 *Rule authors*: @@ -51,64 +51,101 @@ An adversary with access to a set of compromised credentials may attempt to pers *Triage and analysis* +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + *Investigating AWS IAM User Created Access Keys For Another User* -AWS access keys created for IAM users or root user are long-term credentials that provide programmatic access to AWS. -With access to the `iam:CreateAccessKey` permission, a set of compromised credentials could be used to create a new -set of credentials for another user for privilege escalation or as a means of persistence. This rule uses https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-esql-rule[ESQL] -to look for use of the `CreateAccessKey` operation where the user.name is different from the user.target.name. +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* -- Identify both related accounts and their role in the environment. -- Review IAM permission policies for the user identities. -- Identify the applications or users that should use these accounts. -- Investigate other alerts associated with the accounts during the past 48 hours. -- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc. -- Contact the account owners and confirm whether they are aware of this activity. -- Considering the source IP address and geolocation of the user who issued the command: - - Do they look normal for the calling user? - - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control? - - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance? -- 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. - - Determine what other API calls were made by the user. - - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users. +- **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* -- False positives may occur due to the intended usage of the IAM `CreateAccessKey` operation. Verify the `aws.cloudtrail.user_identity.arn` should use this operation against the `user.target.name` account. +- **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* -- Initiate the incident response process based on the outcome of the triage. -- Disable or limit the account during the investigation and response. - - Rotate user credentials - - Remove the newly created credentials from the affected user(s) -- 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. - - Rotate secrets 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. -- Remove unauthorized new accounts, and request password resets for other IAM users. -- Consider enabling multi-factor authentication for users. -- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. -- Take the actions needed to return affected systems, data, or services to their normal operational levels. -- Identify 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). +> AWS IR playbooks classify unauthorized credential creation as a **Priority-1 incident** because it may allow persistence or privilege escalation. +> The following steps scale for organizations with or without a dedicated IR team. + +**1. 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. + +**2. 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. + +**3. 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. + +**4. 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 @@ -117,24 +154,30 @@ to look for use of the `CreateAccessKey` operation where the user.name is differ [source, js] ---------------------------------- from logs-aws.cloudtrail-* metadata _id, _version, _index -| where event.provider == "iam.amazonaws.com" +| where event.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, + event.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.type, + aws.cloudtrail.user_identity.access_key_id, + source.geo.* ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/aws-management-console-brute-force-of-root-user-identity.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-management-console-brute-force-of-root-user-identity.asciidoc index 5a37247625..7926db03e9 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-management-console-brute-force-of-root-user-identity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-management-console-brute-force-of-root-user-identity.asciidoc @@ -16,7 +16,7 @@ Identifies a high number of failed authentication attempts to the AWS management *Runs every*: 5m -*Searches indices from*: now-20m ({ref}/common-options.html#date-math[Date Math format], see also <>) +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) *Maximum alerts per execution*: 100 @@ -29,11 +29,12 @@ Identifies a high number of failed authentication attempts to the AWS management * Domain: Cloud * Data Source: AWS * Data Source: Amazon Web Services +* Data Source: AWS Sign-In * Use Case: Identity and Access Audit * Tactic: Credential Access * Resources: Investigation Guide -*Version*: 210 +*Version*: 211 *Rule authors*: @@ -56,51 +57,100 @@ Identifies a high number of failed authentication attempts to the AWS management *Investigating AWS Management Console Brute Force of Root User Identity* -The AWS Management Console is a web-based interface for accessing and managing AWS services. The root user identity has unrestricted access, making it a prime target for adversaries seeking unauthorized control. Attackers may attempt brute force attacks to guess the root password. The detection rule identifies such attempts by monitoring failed login events specifically for the root user, flagging potential credential access threats. +The AWS Management Console provides a web interface for managing AWS resources. Because the root user has unrestricted privileges, repeated failed console login attempts targeting this identity represent a high-risk credential access event. Even if no login succeeded, this activity may indicate reconnaissance, password spraying, or credential stuffing attempts targeting the root user. + +This rule uses a threshold rule that detects a high number of failed `ConsoleLogin` events (`event.outcom: failure` with `userIdentity.type: Root`) within a short timeframe from the same IP address or user agent. +Threshold rules only summarize grouped field values, so analysts must use timeline to review the actual events that triggered the alert. *Possible investigation steps* -- Review the CloudTrail logs for the specific time frame of the failed login attempts to identify patterns or anomalies in the source IP addresses or user agents. -- Check the geographical location of the IP addresses involved in the failed login attempts to determine if they are consistent with known or expected locations for legitimate access. -- Investigate any successful login attempts from the same IP addresses or user agents to assess if the brute force attempt was successful at any point. -- Analyze the frequency and timing of the failed login attempts to determine if they align with typical brute force attack patterns, such as rapid or sequential attempts. -- Correlate the failed login events with other security events or alerts in the AWS environment to identify any concurrent suspicious activities that may indicate a broader attack campaign. -- Review AWS CloudTrail logs for any changes in IAM policies or unusual activity following the failed login attempts to ensure no unauthorized access was gained. +- **Review in Timeline.** + Open the alert and *Investigate in timeline* to view the individual CloudTrail events contributing to the threshold alert. Review: + - `source.ip`, `user_agent.original`, `geo fields` and `@timestamp` for each failure. + - Look for patterns such as distributed sources or repeated retries at consistent intervals. + - Look for any corresponding successful `ConsoleLogin` events around the same timeframe from the same IP or agent. + +- **Assess IP reputation and geolocation.** + Use IP intelligence tools to evaluate whether the source addresses belong to known cloud providers, TOR nodes, or foreign regions outside your normal operations. + - Correlate against `cloud.region` and `geo fields` and compare with expected login locations for your organization. + +- **Check for related activity.** + Review CloudTrail for other API calls from the same source IP (for example, `GetSessionToken`, `AssumeRole`, or `ListUsers`) that may indicate scripted credential testing or discovery. + +- **Correlate with GuardDuty findings.** + GuardDuty may raise complementary findings for anomalous console login behavior or brute force attempts. Review recent GuardDuty and AWS Config alerts for the same timeframe. + +- **Determine business context.** + Confirm whether the source IPs are internal (for example, corporate VPN, IT admin network) or part of legitimate red-team or third-party testing. If uncertain, treat as suspicious. *False positive analysis* -- Legitimate users may forget their password and repeatedly attempt to log in, triggering the rule. To manage this, monitor for patterns of failed logins followed by successful ones and consider excluding these from alerts if they originate from known IP addresses. -- Automated scripts or applications using outdated credentials can cause repeated failed login attempts. Identify and update these credentials or exclude the associated IP addresses from the rule. -- Security testing or penetration testing activities might simulate brute force attacks. Coordinate with your security team to whitelist IP addresses or timeframes associated with these activities to prevent false positives. -- Shared accounts or environments where multiple users attempt to access the root account can lead to multiple failed attempts. Implement stricter access controls and consider excluding known internal IP ranges from the rule. +- **Forgotten or mistyped credentials.** + Repeated failed logins from known internal IPs could indicate a legitimate user typing errors. Validate by checking if a successful root login followed soon after. +- **Automation or scanners.** + Misconfigured monitoring tools or old browser sessions attempting to reuse cached credentials may trigger this rule. +- **Planned penetration testing.** + Red-team or security testing activities can generate deliberate brute force attempts. Verify via ticketing or testing schedules. *Response and remediation* -- Immediately disable the root user account to prevent further unauthorized access attempts. This can be done through the AWS Management Console by navigating to the IAM section and selecting the root user account. -- Review the CloudTrail logs to identify the source IP addresses of the failed login attempts. Block these IP addresses using AWS security groups or network ACLs to prevent further access attempts from these locations. -- Reset the root user password and ensure it is strong and unique. Use a password manager to generate and store the new password securely. -- Enable multi-factor authentication (MFA) for the root user account to add an additional layer of security. This can be configured in the AWS Management Console under the IAM section. -- Conduct a thorough audit of recent account activity to ensure no unauthorized changes have been made. Pay special attention to IAM roles, policies, and permissions. -- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. Provide them with details of the attempted breach and actions taken. -- Implement additional monitoring and alerting for unusual login patterns or failed login attempts to the root account to enhance early detection of similar threats in the future. +> The AWS Incident Response Playbooks classify root login attempts as Priority-1 credential compromise events. +> Follow these steps whether or not your organization has a formal IR team. + +**1. Immediate containment** +- **Check for success.** + After pivoting to Timeline, confirm whether any `ConsoleLogin` events from the same IP or user agent show `event.oucome: success`. + - If a successful login occurred, immediately follow the *AWS Management Console Root Login* rule investigation guide. +- **Rotate the root password.** + Use AWS’s password reset function to set a strong, unique password stored in an offline vault. +- **Enable or verify Multi-Factor Authentication (MFA)** on the root account. If MFA was already configured, review the device registration for changes or suspicious resets. +- **Block offending IPs or networks.** + Use AWS WAF, VPC network ACLs, or Security Groups to temporarily block the IPs used in the failed attempts. +- **Alert internal teams.** + Notify your security operations or cloud governance teams of the brute force pattern and actions taken. + +**2. Evidence preservation** +- Export all failed `ConsoleLogin` events visible in Timeline (±30 minutes around the alert window) to a restricted evidence bucket. +- Preserve GuardDuty findings, AWS Config history, and CloudTrail logs for the same timeframe for further analysis. + +**3. Scoping and investigation** +- Query CloudTrail across other AWS accounts and regions for additional failed or successful `ConsoleLogin` events from the same IPs. +- Check IAM activity for simultaneous key creation, role modifications, or new users — signs of lateral or parallel intrusion attempts. +- Review network telemetry (VPC Flow Logs, CloudFront, WAF) to determine whether the activity originated from a distributed or scripted attack pattern. + +**4. Recovery and hardening** +- Confirm MFA is enabled and enforced on the root account. +- Remove any root access keys (none should exist under normal security posture). +- Enable organization-wide CloudTrail, GuardDuty, and Security Hub across all regions. +- Set up real-time alerts for any future `ConsoleLogin` failures from the root user exceeding expected baselines. +- Store root credentials offline with dual-custody and document controlled access procedures. + + +*Additional information* -==== Setup +- **https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks[AWS IR Playbooks]:** See “Credential Compromise” and “Account Compromise” for investigation, containment, and escalation guidance. +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]:** Reference runbooks for failed-login response, evidence preservation, and MFA enforcement. +- **AWS Documentation:** https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root[Tasks that require the root user]. +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. -The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. ==== Rule query [source, js] ---------------------------------- -event.dataset:aws.cloudtrail and event.provider:signin.amazonaws.com and event.action:ConsoleLogin and aws.cloudtrail.user_identity.type:Root and event.outcome:failure +event.dataset:aws.cloudtrail and +event.provider:signin.amazonaws.com and +event.action:ConsoleLogin and +aws.cloudtrail.user_identity.type:Root and +event.outcome:failure ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/aws-management-console-root-login.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-management-console-root-login.asciidoc index 76a7b3c8d5..db2fd8f840 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-management-console-root-login.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-management-console-root-login.asciidoc @@ -14,9 +14,9 @@ Identifies a successful login to the AWS Management Console by the Root user. *Risk score*: 47 -*Runs every*: 10m +*Runs every*: 5m -*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) *Maximum alerts per execution*: 100 @@ -29,12 +29,13 @@ 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 Signin +* Data Source: AWS Sign-In * Use Case: Identity and Access Audit * Resources: Investigation Guide * Tactic: Initial Access +* Tactic: Privilege Escalation -*Version*: 211 +*Version*: 212 *Rule authors*: @@ -50,58 +51,98 @@ Identifies a successful login to the AWS Management Console by the Root user. *Triage and analysis* +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + *Investigating AWS Management Console Root Login* -The AWS root account is the one identity that has complete access to all AWS services and resources in the account, which is created when the AWS account is created. AWS strongly recommends that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks. AWS provides a https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root[list of the tasks that require root user]. +The AWS root user is the original identity with unrestricted privileges over every resource in the account. Because it bypasses IAM boundaries and carries irreversible privileges, any successful root console login should be treated as a critical security event. AWS explicitly recommends locking away the root credentials and only using them for a small number of account-level administrative tasks (for example, closing an account, modifying support plans, or restoring MFA). See https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root[Tasks that require the root user]. -This rule looks for attempts to log in to the AWS Management Console as the root user. +This rule detects a successful AWS Management Console login by the root user (`ConsoleLogin` events with `userIdentity.type: Root` and `event.outcome: Success`). *Possible investigation steps* -- Investigate other alerts associated with the user account during the past 48 hours. -- Examine whether this activity is common in the environment by looking for past occurrences on your logs. -- Consider the source IP address and geolocation for the calling user who issued the command. Do they look normal for the calling user? -- Examine the commands, API calls, and data management actions performed by the account in the last 24 hours. -- Contact the account owner and confirm whether they are aware of this activity. -- If you suspect the account has been compromised, scope potentially compromised assets by tracking access to servers, -services, and data accessed by the account in the last 24 hours. +- **Confirm legitimacy.** + Contact the designated root credential custodian or account owner to verify whether this login was expected and approved. Root access should only occur under documented change-control conditions. +- **Review contextual event details.** + Examine the CloudTrail fields in the alert: + - `source.ip` – does it match known corporate IPs or expected admin VPNs? + - `user_agent.original` – browser or automation? + - `geo fields` – consistent with normal operations? + - `@timestamp` – within a planned maintenance window? +- **Check for prior or subsequent root activity.** + Query CloudTrail for the last 30–90 days for any other root logins or root-initiated API calls. Multiple or recent root logins can indicate credential misuse. +- **Correlate follow-on actions.** + Look for risky API calls immediately after the login, such as: + - `CreateUser`, `CreateAccessKey`, `AttachRolePolicy`, `PutBucketPolicy`, `UpdateAssumeRolePolicy`, `DeleteTrail`, or `StopLogging`. + These actions may indicate persistence or cover-up attempts. +- **Cross-account verification.** + If the root user is federated through AWS Organizations or linked accounts, confirm no simultaneous logins occurred elsewhere. *False positive analysis* -- The alert can be dismissed if this operation is done under change management and approved according to the organization's policy for performing a task that needs this privilege level. +- **Planned administrative actions.** + Some rare maintenance tasks require root credentials (for example, payment method updates). If the login aligns with documented change control and was performed using MFA by the approved owner, the alert can be closed as benign. +- **Third-party managed account scenarios.** + Managed service providers may log in as root during onboarding or support activities. Confirm via ticketing or contractual documentation. *Response and remediation* -- Initiate the incident response process based on the outcome of the triage. -- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: - - Identify the account role in the cloud environment. - - Identify the services or servers involved criticality. - - 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 if there are any regulatory or legal ramifications related to this activity. -- Configure multi-factor authentication for the user. -- Follow security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. -- 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). +> The AWS Incident Response Playbooks classify root logins as **Priority-1 events** due to full-environment control. Follow these steps whether or not you have a dedicated IR team. + +**1. Immediate verification and containment** +- If the login was not authorized or cannot be confirmed quickly: + - Reset the root password using the AWS Management Console. + - Rotate or remove any root access keys (root keys should normally not exist). + - Ensure MFA is enabled and enforced on the root account. + - Notify your security operations or cloud governance team. + +**2. Evidence preservation** +- Export the alert’s CloudTrail record and all subsequent events for 1 hour after the login. + Store them in a restricted, immutable S3 evidence bucket. +- Retain related GuardDuty findings, AWS Config history, and CloudTrail logs for the same period. + +**3. Scope and investigation** +- Review additional events under the same `source.ip` to detect resource creation, IAM changes, or billing actions. +- Inspect newly created users, roles, or keys since the login time to identify potential persistence mechanisms. +- Check for any disabled or deleted CloudTrail trails, Security Hub findings suppression, or logging configuration changes. + +**4. Recovery and hardening** +- Confirm MFA is working and only the authorized owner can access the root credentials. +- Store root credentials in an offline vault under dual-custody control. +- Enable organization-wide CloudTrail, GuardDuty, and Security Hub across all regions. +- Implement policy and automation to alert on any future `userIdentity.type: Root` logins in real time. +- Conduct a short post-incident review to update root-access procedures and reinforce least-privilege IAM practices. + + +*Additional information* + -==== Setup +- **https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks[AWS IR Playbooks]:** See “Account Compromise” and “Credential Compromise” playbooks for containment and recovery procedures. +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]:** Reference “Account Access Investigation” for evidence handling and credential rotation steps. +- **AWS Documentation:** https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root[Tasks that require the root user]. +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. -The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. ==== Rule query [source, js] ---------------------------------- -event.dataset:aws.cloudtrail and event.provider:signin.amazonaws.com and event.action:ConsoleLogin and aws.cloudtrail.user_identity.type:Root and event.outcome:success +event.dataset:aws.cloudtrail and +event.provider:signin.amazonaws.com and +event.action:ConsoleLogin and +aws.cloudtrail.user_identity.type:Root and +event.outcome:success ---------------------------------- @@ -115,11 +156,19 @@ event.dataset:aws.cloudtrail and event.provider:signin.amazonaws.com and event.a ** 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/ +** 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/rule-details/aws-sign-in-console-login-with-federated-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-sign-in-console-login-with-federated-user.asciidoc new file mode 100644 index 0000000000..0b85d1e905 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-sign-in-console-login-with-federated-user.asciidoc @@ -0,0 +1,136 @@ +[[aws-sign-in-console-login-with-federated-user]] +=== AWS Sign-In Console Login with Federated User + +Identifies when a federated user logs into the AWS Management Console. Federated users are typically given temporary credentials to access AWS services. If a federated user logs into the AWS Management Console without using MFA, it may indicate a security risk, as MFA adds an additional layer of security to the authentication process. However, CloudTrail does not record whether a Federated User utilized MFA as part of authentication — that MFA decision often occurs at a third-party IdP (e.g., Okta, Azure AD, Google). As a result, CloudTrail fields such as MFAUsed / mfaAuthenticated appear as “No/false” for federated console logins even if IdP MFA was required. This alert should be correlated with IdP authentication logs to verify whether MFA was enforced for the session. Increase priority if you find a related "GetSigninToken" event whose source IP / ASN / geo or user-agent differs from the subsequent "ConsoleLogin" (possible token relay/abuse). Same-IP/UA pairs within a short window are more consistent with expected operator behavior and can be triaged with lower severity. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hackingthe.cloud/aws/post_exploitation/create_a_console_session_from_iam_credentials/ + +*Tags*: + +* Domain: Cloud +* Data Source: Amazon Web Services +* Data Source: AWS +* Data Source: AWS Sign-In +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS Sign-In Console Login with Federated User* + + +Federated users in AWS are granted temporary credentials to access resources, often without the need for a permanent account. This setup is convenient but can be risky if not properly secured with multi-factor authentication (MFA). Adversaries might exploit this by using stolen or misconfigured credentials to gain unauthorized access. CloudTrail alone cannot reliably indicate MFA usage for federated logins. This rule surfaces potentially risky access for analyst review and IdP correlation. + + +*Possible investigation steps* + + +- **Identify the prinicipal involved** + - `aws.cloudtrail.user_identity.arn` (federated session ARN) + - `aws.cloudtrail.user_identity.session_context.session_issuer.*` (role ARN/name, account) of the identity that created the federated session. +- **Investigate the source context** + - examine `source.ip`, ASN, `geo` fields, and `user_agent.original` + - Compare against normal IP ranges, known user-agents and expected locations for this identity + +*Correlate to raise/lower priority* + +- **Check IdP MFA:** Find the corresponding IdP login around the same time and verify MFA was required and passed. If IdP shows **no MFA**, raise severity. +- **Federation token pivot:** Look for a nearby `signin.amazonaws.com` `GetSigninToken` API call. + - **More suspicious:** token creation and console login from different public IPs/ASNs/geo fields. + - **Less suspicious:** same IP and expected user agents within ~10–15 minutes (typical operator behavior). +- **Rareness/anomaly signals:** new/rare role or session issuer, rare source IP/ASN/geo, unusual time-of-day, multiple ConsoleLogin events from disparate networks in a short window. +- Review recent activity associated with the federated user to identify any unusual or unauthorized actions that may have occurred following the login event. +- Assess the configuration and policies of the Identity Provider (IdP) used for federated access to ensure MFA is enforced and properly configured for all users. + + +*Related rules* + +- AWS Sign-In Token Created - f754e348-f36f-4510-8087-d7f29874cc12 + + +*False positive analysis* + +- Organizations using SSO for console access will routinely see federated `ConsoleLogin` where CloudTrail shows `MFAUsed: "No"` — this is expected due to IdP-side MFA. +- Internal tools/automation that create federation links (`GetSigninToken`) for operators. +- Maintain allow-lists for corp/VPN CIDRs, approved ASNs, and known automation user-agents. + + +*Response and remediation* + +- If IdP confirms MFA and the source context is expected: document and close. +- If IdP shows no MFA or context is suspicious: + - Notify the security team and relevant stakeholders about the potential security breach to ensure coordinated response efforts. + - Disable/lock the IdP account pending review; invalidate IdP sessions if supported. + - Temporarily restrict access (e.g., SCPs, session policies, IP-based conditions). + - Conduct a thorough review of AWS CloudTrail logs to identify any suspicious activities or unauthorized access attempts associated with both the intitiating user and the federated user account. + - Hunt for a preceding `GetSigninToken` from a different IP/ASN/UA (possible token relay). + - Ensure IdP policy enforces MFA for AWS app access; re-verify role trust and least-privilege policies. +- Implement or enforce multi-factor authentication (MFA) for all federated user accounts to enhance security and prevent similar incidents in the future. +- Review and update IAM policies and roles associated with federated users to ensure they follow the principle of least privilege. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" and + event.provider: "signin.amazonaws.com" and + event.action : "ConsoleLogin" and + aws.cloudtrail.user_identity.type: "FederatedUser" 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/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-sign-in-root-password-recovery-requested.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-sign-in-root-password-recovery-requested.asciidoc new file mode 100644 index 0000000000..172be4957c --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-sign-in-root-password-recovery-requested.asciidoc @@ -0,0 +1,151 @@ +[[aws-sign-in-root-password-recovery-requested]] +=== AWS Sign-In Root Password Recovery Requested + +Identifies a password recovery request for the AWS account root user. In AWS, the PasswordRecoveryRequested event from signin.amazonaws.com applies to the root user’s “Forgot your password?” flow. Other identity types, like IAM and federated users, do not generate this event. This alert indicates that someone initiated the root password reset workflow for this account. Verify whether this was an expected action and review identity provider notifications/email to confirm legitimacy. + +*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://web.archive.org/web/20230930161727/https://www.cadosecurity.com/an-ongoing-aws-phishing-campaign/ + +*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*: 210 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS Sign-In Root Password Recovery Requested* + + +In AWS, a `PasswordRecoveryRequested` event from `signin.amazonaws.com` is only generated for the root user during the “Forgot your password?” workflow. Other identity types (IAM or federated users) do not trigger this event. A root password recovery request is a critical identity security event that could indicate a legitimate recovery by the account owner or a malicious attempt to gain full administrative access. + + +*Possible investigation steps* + + +- **Verify the event details.** + Review the alert fields (`source.ip`, `user_agent.original`, `cloud.region`, and `@timestamp`) to confirm when and from where the request originated. +- **Confirm legitimacy.** + Contact the account owner or credential custodian to verify whether they initiated the password recovery. + AWS will also send an email notification to the root account email address, check whether the owner received and acknowledged this. +- **Check CloudTrail for related events.** + Search for any subsequent `ConsoleLogin` events for the root user, or IAM changes (for example, `CreateAccessKey`, `CreateUser`, or `AttachUserPolicy`) shortly after the recovery request. +- **Assess IP reputation and location.** + Validate whether the `source.ip` aligns with known admin networks or expected geographies. + Suspicious indicators include foreign IPs, anonymization services, or unfamiliar user agents. +- **Correlate with other alerts.** + Review other AWS security detections (for example, root logins, MFA disablement, or IAM policy changes) around the same timeframe. + + +*False positive analysis* + + +- **Expected maintenance activity.** + If the root account owner confirms that the password reset was intentional (for example, for account recovery or planned credential rotation), the alert may be safely dismissed. +- **Testing or account verification.** + Security or compliance teams occasionally test password recovery flows. Confirm via ticketing or planned maintenance documentation. + + +*Response and remediation* + + +**1. Immediate actions** +- **If confirmed legitimate:** + - Ensure that MFA is enabled and operational for the root account. + - Encourage rotation of the root password if not recently updated. +- **If unconfirmed or suspicious:** + - Immediately reset the root password using the legitimate AWS recovery email link. + - Review the AWS account’s email for password-recovery notifications and secure that inbox (change its password, enable MFA). + - Check for new successful root logins or unexpected IAM changes since the recovery attempt. + +**2. Evidence preservation** +- Export the `PasswordRecoveryRequested` event from CloudTrail (±30 minutes). +- Preserve all `signin.amazonaws.com` and root `ConsoleLogin` events for the next 24 hours. +- Store this evidence in a restricted S3 bucket with Object Lock enabled. + +**3. Scoping and investigation** +- Review all root-level activities within the past 24–48 hours. + Focus on administrative actions such as `CreateAccessKey`, `UpdateAccountPasswordPolicy`, or `DisableMFA`. +- Correlate with GuardDuty findings and AWS Config change history for any unauthorized modifications. + +**4. Recovery and hardening** +- Confirm MFA is enforced on the root account. +- Rotate all root credentials and ensure no access keys exist for the root user (root keys should never be active). +- Secure the associated email account (password reset notifications are sent there). +- Enable Cloudtrail, GuardDuty, Security Hub, and AWS Config across all regions. +- Review account recovery procedures to ensure multiple custodians are aware of the legitimate process. + + +*Additional information* + + +- **AWS Incident Response Playbooks:** + and https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-CredCompromise.md[`IRP-Credential-Compromise.md`] for procedures related to root account credential recovery and unauthorized access attempts. +- **AWS Customer Playbook Framework:** + See https://github.com/aws-samples/aws-customer-playbook-framework/blob/a8c7b313636b406a375952ac00b2d68e89a991f2/docs/Compromised_IAM_Credentials.md[`Compromised_IAM_Credentials.md`] for guidance on containment, evidence collection, and recovery validation. +- **AWS Documentation:** https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html[AWS account root user best practices]. +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset:aws.cloudtrail and +event.provider:signin.amazonaws.com and +event.action:PasswordRecoveryRequested 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/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-sign-in-token-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-sign-in-token-created.asciidoc new file mode 100644 index 0000000000..b88ef4378b --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-sign-in-token-created.asciidoc @@ -0,0 +1,71 @@ +[[aws-sign-in-token-created]] +=== AWS Sign-In Token Created + +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. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hackingthe.cloud/aws/post_exploitation/create_a_console_session_from_iam_credentials/ + +*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 +* Rule Type: BBR + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" and + event.provider: "signin.amazonaws.com" and + event.action : "GetSigninToken" 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/ diff --git a/docs/detections/prebuilt-rules/rule-details/azure-compute-restore-point-collection-deleted-by-unusual-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-compute-restore-point-collection-deleted-by-unusual-user.asciidoc new file mode 100644 index 0000000000..0d4fa7f330 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/azure-compute-restore-point-collection-deleted-by-unusual-user.asciidoc @@ -0,0 +1,118 @@ +[[azure-compute-restore-point-collection-deleted-by-unusual-user]] +=== Azure Compute Restore Point Collection Deleted by Unusual User + +Identifies the deletion of Azure Restore Point Collections by a user who has not previously performed this activity. Restore Point Collections contain recovery points for virtual machines, enabling point-in-time recovery capabilities. Adversaries may delete these collections to prevent recovery during ransomware attacks or to cover their tracks during malicious operations. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*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.microsoft.com/en-us/security/blog/2023/07/25/storm-0501-ransomware-attacks-expanding-to-hybrid-cloud-environments/ + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* 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 Azure Compute Restore Point Collection Deleted by Unusual User* + + +Azure Compute Restore Point Collections are critical components for disaster recovery, containing snapshots that enable point-in-time +recovery of virtual machines. Deletion of these collections can severely impact an organization's ability to recover from +incidents, making them attractive targets for adversaries conducting ransomware attacks or attempting to cover their tracks. + +This rule detects when a user who has not previously deleted Restore Point Collections performs this operation, which may +indicate unauthorized activity or a compromised account. + + +*Possible investigation steps* + + +- Review the `azure.activitylogs.identity.claims_initiated_by_user.name` field to identify the specific user who performed the deletion operation. +- Investigate the `azure.resource.id` or `azure.resource.name` fields to identify which Restore Point Collection was deleted and assess its criticality to business operations. +- Review the timeline of the deletion event and correlate it with other security events or user activities to identify any suspicious patterns or related activities. +- Verify whether the user account has legitimate access to perform this operation and whether this deletion was authorized through change management processes. +- Check for any other unusual activities by the same user account around the time of the deletion, such as privilege escalation attempts or access to other sensitive resources. +- Investigate whether there are any active alerts or indicators of compromise related to ransomware activity in the environment. + + +*False positive analysis* + + +- Routine administrative activities by infrastructure teams may trigger this alert when team members rotate or new administrators are onboarded. Create exceptions for known administrative accounts after verification. +- Automated cleanup scripts or Azure policies that periodically remove old restore points may cause alerts. Identify and exclude service accounts used for these automated operations. +- Planned decommissioning activities or migration projects may involve legitimate deletion of restore point collections. Document these activities and create temporary exceptions during known maintenance windows. +- Testing and development environments may see frequent creation and deletion of resources. Consider excluding these environments from monitoring or adjusting the rule to focus on production resources only. + + +*Response and remediation* + + +- Immediately verify the legitimacy of the deletion operation with the user or their manager. If the activity is unauthorized, proceed with incident response procedures. +- If unauthorized deletion is confirmed, immediately isolate the affected user account to prevent further malicious activity. Reset credentials and review account permissions. +- Check if the deleted Restore Point Collection can be recovered through Azure backup services or other recovery mechanisms. +- Review and audit all recent activities performed by the affected user account to identify other potentially malicious actions. +- Assess the impact on disaster recovery capabilities and inform relevant stakeholders about potential recovery limitations. +- Review access controls and permissions for Restore Point Collection management, implementing principle of least privilege where necessary. +- If ransomware activity is suspected, escalate to the security incident response team and implement broader containment measures, including checking for other indicators of ransomware such as deletion of Recovery Services vaults or backup fabric containers. +- Document the incident and update detection rules or procedures based on lessons learned. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: azure.activitylogs and + event.action: "MICROSOFT.COMPUTE/RESTOREPOINTCOLLECTIONS/DELETE" and + event.outcome: (Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/rule-details/azure-compute-restore-point-collections-deleted.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-compute-restore-point-collections-deleted.asciidoc new file mode 100644 index 0000000000..f3cb377c59 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/azure-compute-restore-point-collections-deleted.asciidoc @@ -0,0 +1,139 @@ +[[azure-compute-restore-point-collections-deleted]] +=== Azure Compute Restore Point Collections Deleted + +Identifies multiple Azure Restore Point Collections being deleted by a single user within a short time period. Restore Point Collections contain recovery points for virtual machines, enabling point-in-time recovery capabilities. Mass deletion of these collections is a common tactic used by adversaries during ransomware attacks to prevent victim recovery or to maximize impact during destructive operations. Multiple deletions in rapid succession may indicate malicious intent. + +*Rule type*: threshold + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*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.microsoft.com/en-us/security/blog/2023/07/25/storm-0501-ransomware-attacks-expanding-to-hybrid-cloud-environments/ + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* 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 Azure Compute Restore Point Collections Deleted* + + +Azure Compute Restore Point Collections are essential for disaster recovery, containing snapshots that enable point-in-time recovery +of virtual machines. The ability to quickly restore VMs from these recovery points is critical for business continuity and +incident response. + +Adversaries conducting ransomware attacks or destructive operations often target backup and recovery infrastructure to +prevent victims from recovering their systems without paying a ransom. Mass deletion of Restore Point Collections is a +key indicator of such activity and represents a significant threat to an organization's resilience. + +This rule detects when a single user deletes multiple Restore Point Collections within a short time window, which is +unusual in normal operations and highly suspicious when observed. + + +*Possible investigation steps* + + +- Identify the user account responsible for the deletions by examining the `azure.activitylogs.identity.claims_initiated_by_user.name` or `user.name` field in the alerts. +- Review all deletion events from this user in the specified time window to determine the scope and scale of the activity. +- Check the `azure.resource.id` and `azure.resource.name` fields to identify which Restore Point Collections were deleted and assess their criticality to business operations. +- Verify whether the user account has legitimate administrative access and whether these deletions were authorized through change management or documented maintenance activities. +- Investigate the timeline of events leading up to the deletions, looking for other suspicious activities such as: + - Privilege escalation attempts + - Deletion of other backup resources (Recovery Services vaults, backup policies) + - Unusual authentication patterns or geographic anomalies + - Creation of persistence mechanisms or backdoor accounts +- Review Azure Activity Logs for any failed deletion attempts or access denied events that might indicate reconnaissance activities preceding the successful deletions. +- Check for related data destruction activities, such as deletion of virtual machines, disks, or storage accounts. +- Correlate with sign-in logs to identify any unusual login patterns or potential account compromise indicators. + + +*False positive analysis* + + +- Large-scale decommissioning projects may involve legitimate deletion of multiple Restore Point Collections. Verify with change management records and create temporary exceptions during documented maintenance windows. +- Infrastructure migrations from Azure to another platform or between Azure regions may involve cleanup of old restore points. Confirm these activities are planned and documented before excluding them from monitoring. +- Automated cleanup scripts designed to manage storage costs by removing old restore points might trigger this alert. Identify the service accounts used for these operations and adjust the threshold or create exceptions as appropriate. +- Testing and development environments that are frequently rebuilt may see regular bulk deletion of resources. Consider excluding non-production environments or adjusting the threshold for these subscriptions. +- Review the threshold value (currently set to 3) and adjust based on your environment's baseline if legitimate administrative activities are frequently triggering false positives. + + +*Response and remediation* + + +- Immediately isolate the affected user account to prevent further malicious activity. Reset credentials and revoke active sessions. +- Verify the legitimacy of the deletions with the account owner or their manager. If unauthorized, treat this as a confirmed security incident and activate incident response procedures. +- Check if any of the deleted Restore Point Collections can be recovered through Azure backup services, soft-delete features, or other recovery mechanisms. Time is critical as retention policies may limit recovery windows. +- Conduct a comprehensive review of all recent activities by the affected user account across the Azure environment to identify other potentially malicious actions or compromised resources. +- Assess the current disaster recovery posture and identify which VMs are now missing recovery points. Prioritize creation of new restore points for critical systems if they are unaffected. +- Review and strengthen access controls for Restore Point Collection management, implementing stricter RBAC policies and requiring multi-factor authentication for privileged operations. +- If ransomware activity is suspected or confirmed: + - Activate the organization's ransomware response plan + - Isolate affected systems to prevent spread + - Search for ransomware indicators across the environment (encrypted files, ransom notes, suspicious processes) + - Check for deletion of other recovery resources (Recovery Services vaults, backups, snapshots) + - Do not pay ransom demands; engage with law enforcement and cybersecurity incident response teams +- Implement additional monitoring and alerting for related activities such as: + - Deletion of Recovery Services resources + - Modifications to backup policies + - Unusual access to disaster recovery infrastructure +- Document the incident thoroughly and conduct a post-incident review to identify gaps in security controls and opportunities for improvement. +- Consider implementing Azure Resource Locks on critical recovery resources to prevent accidental or malicious deletion. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: azure.activitylogs and + event.action: "MICROSOFT.COMPUTE/RESTOREPOINTCOLLECTIONS/DELETE" and + event.outcome: (Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/rule-details/azure-recovery-services-resource-deleted.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-recovery-services-resource-deleted.asciidoc new file mode 100644 index 0000000000..77350c3eab --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/azure-recovery-services-resource-deleted.asciidoc @@ -0,0 +1,67 @@ +[[azure-recovery-services-resource-deleted]] +=== Azure Recovery Services Resource Deleted + +Identifies the deletion of Azure Recovery Services resources. Azure Recovery Services vaults contain data for copies of VMs, workloads, servers, and other resources regarding Infrastructure as a Service (IaaS). Adversaries may delete these recovery services to impact backup capabilities during stable operations or to inhibit disaster recovery services during ransom-based attacks or operational disruptions. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*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.microsoft.com/en-us/security/blog/2023/07/25/storm-0501-ransomware-attacks-expanding-to-hybrid-cloud-environments/ + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Rule Type: BBR + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset:azure.activitylogs and + azure.activitylogs.operation_name:MICROSOFT.RECOVERYSERVICES/*/DELETE and + event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/rule-details/azure-storage-account-deletion-by-unusual-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-storage-account-deletion-by-unusual-user.asciidoc new file mode 100644 index 0000000000..962814d85b --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/azure-storage-account-deletion-by-unusual-user.asciidoc @@ -0,0 +1,118 @@ +[[azure-storage-account-deletion-by-unusual-user]] +=== Azure Storage Account Deletion by Unusual User + +Identifies when an Azure Storage Account is deleted. Adversaries may delete storage accounts to disrupt operations, destroy evidence, or cause denial of service. This activity could indicate an attacker attempting to cover their tracks after data exfiltration or as part of a destructive attack. Monitoring storage account deletions is critical for detecting potential impact on business operations and data availability. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* + +*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.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* 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 Azure Storage Account Deletion by Unusual User* + + +Azure Storage Accounts provide scalable cloud storage for applications and services. Deletion of storage accounts is a high-impact operation that permanently removes all contained data including blobs, files, queues, and tables. Adversaries may delete storage accounts to destroy evidence of their activities, disrupt business operations, or cause denial of service as part of ransomware or destructive attacks. This detection monitors for successful storage account deletion operations to identify potential malicious activity. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the user or service principal that initiated the storage account deletion by examining the principal ID, UPN and user agent fields. +- Check the specific storage account name in `azure.resource.name` to understand which storage resources were deleted and assess the business impact. +- Investigate the timing of the event to correlate with any other suspicious activities, such as unusual login patterns, privilege escalation attempts, or other resource deletions. +- Examine the user's recent activity history to identify any other storage accounts or Azure resources that were deleted or modified by the same principal. +- Verify if the storage account deletion aligns with approved change requests or maintenance windows in your organization. +- Check if the deleted storage account contained critical data and whether backups are available for recovery. +- Review any related alerts or activities such as data exfiltration, configuration changes, or access policy modifications that occurred before the deletion. +- Investigate if the account was recently compromised by checking for suspicious authentication events or privilege escalations. + + +*False positive analysis* + + +- Legitimate decommissioning of unused storage accounts may trigger this alert. Document approved storage account cleanup activities and coordinate with infrastructure teams to understand planned deletions. +- DevOps automation tools might delete temporary storage accounts as part of infrastructure lifecycle management. Identify service principals used by CI/CD pipelines and consider creating exceptions for these automated processes. +- Testing and development environments may have frequent storage account creation and deletion cycles. Consider filtering out non-production storage accounts if appropriate for your environment. +- Cost optimization initiatives may involve deleting unused or redundant storage accounts. Coordinate with finance and infrastructure teams to understand planned resource optimization activities. + + +*Response and remediation* + + +- Immediately investigate whether the deletion was authorized by verifying with the account owner or relevant stakeholders. +- If the deletion was unauthorized, attempt to recover the storage account if soft-delete is enabled, or restore data from backups. +- Disable the compromised user account or service principal if unauthorized activity is confirmed and investigate how the credentials were obtained. +- Review and restrict Azure RBAC permissions to ensure only authorized users have storage account deletion capabilities (requires Contributor or Owner role). +- Implement Azure Resource Locks to prevent accidental or malicious deletion of critical storage accounts. +- Configure Azure Activity Log alerts to notify security teams immediately when storage accounts are deleted. +- Conduct a full security assessment to identify any other compromised resources or accounts and look for indicators of broader compromise. +- Document the incident and update security policies and procedures to prevent similar incidents in the future. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: azure.activitylogs and + azure.activitylogs.operation_name: "MICROSOFT.STORAGE/STORAGEACCOUNTS/DELETE" and + azure.activitylogs.identity.claims_initiated_by_user.name: * + +---------------------------------- + +*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: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/rule-details/azure-storage-account-deletions-by-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-storage-account-deletions-by-user.asciidoc new file mode 100644 index 0000000000..1dd7c2cbd0 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/azure-storage-account-deletions-by-user.asciidoc @@ -0,0 +1,121 @@ +[[azure-storage-account-deletions-by-user]] +=== Azure Storage Account Deletions by User + +Identifies when a single user or service principal deletes multiple Azure Storage Accounts within a short time period. This behavior may indicate an adversary attempting to cause widespread service disruption, destroy evidence, or execute a destructive attack such as ransomware. Mass deletion of storage accounts can have severe business impact and is rarely performed by legitimate administrators except during controlled decommissioning activities. + +*Rule type*: threshold + +*Rule indices*: + +* logs-azure.activitylogs-* + +*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.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* 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 Azure Storage Account Deletions by User* + + +Azure Storage Accounts are critical infrastructure components that store application data, backups, and business-critical information. Mass deletion of storage accounts is an unusual and high-impact activity that can result in significant data loss and service disruption. Adversaries may perform bulk deletions to destroy evidence after data exfiltration, cause denial of service, or as part of ransomware campaigns targeting cloud infrastructure. This detection identifies when a single identity deletes multiple storage accounts in a short timeframe, which is indicative of potentially malicious activity. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the user or service principal that initiated the multiple storage account deletions by examining the principal ID, UPN and user agent fields in `azure.activitylogs.identity.claims_initiated_by_user.name`. +- Check the specific storage account names in `azure.resource.name` to understand which storage resources were deleted and assess the overall business impact. +- Investigate the timing and sequence of deletions to determine if they followed a pattern consistent with automated malicious activity or manual destruction. +- Examine the user's recent activity history including authentication events, privilege changes, and other Azure resource modifications to identify signs of account compromise. +- Verify if the storage account deletions align with approved change requests, maintenance windows, or decommissioning activities in your organization. +- Check if the deleted storage accounts contained critical data and whether backups are available for recovery. +- Review any related alerts or activities such as data exfiltration, unusual authentication patterns, or privilege escalation that occurred before the deletions. +- Investigate if other Azure resources (VMs, databases, resource groups) were also deleted or modified by the same principal. +- Check the authentication source and location to identify if the activity originated from an expected network location or potentially compromised session. + + +*False positive analysis* + + +- Legitimate bulk decommissioning of storage accounts during infrastructure cleanup may trigger this alert. Document approved resource cleanup activities and coordinate with infrastructure teams to create exceptions during planned maintenance windows. +- Infrastructure-as-Code (IaC) automation tools or CI/CD pipelines may delete multiple test or temporary storage accounts. Identify service principals used by automation tools and consider creating exceptions for these identities when operating in non-production environments. +- Cloud resource optimization initiatives may involve bulk deletion of unused storage accounts. Coordinate with finance and infrastructure teams to understand planned cost optimization activities and schedule them during documented maintenance windows. +- Disaster recovery testing or blue-green deployment strategies may involve deletion of multiple storage accounts. Work with DevOps teams to identify these patterns and create time-based exceptions during testing periods. + + +*Response and remediation* + + +- Immediately investigate whether the deletions were authorized by verifying with the account owner or relevant stakeholders. +- If the deletions were unauthorized, disable the compromised user account or service principal immediately to prevent further damage. +- Attempt to recover deleted storage accounts if soft-delete is enabled, or restore data from backups for critical storage accounts. +- Review and audit all Azure RBAC permissions to identify how the attacker gained storage account deletion capabilities (requires Contributor or Owner role). +- Conduct a full security assessment to identify the initial access vector and any other compromised accounts or resources. +- Implement Azure Resource Locks on all critical storage accounts to prevent accidental or malicious deletion. +- Configure Azure Policy to require approval workflows for storage account deletions using Azure Blueprints or custom governance solutions. +- Enable Azure Activity Log alerts to notify security teams immediately when storage accounts are deleted. +- Escalate the incident to the security operations center (SOC) or incident response team for investigation of potential broader compromise. +- Document the incident and update security policies, playbooks, and procedures to prevent similar incidents in the future. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: azure.activitylogs and + azure.activitylogs.operation_name: "MICROSOFT.STORAGE/STORAGEACCOUNTS/DELETE" and + azure.activitylogs.identity.claims_initiated_by_user.name: * + +---------------------------------- + +*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: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/rule-details/azure-storage-blob-retrieval-via-azcopy.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-storage-blob-retrieval-via-azcopy.asciidoc new file mode 100644 index 0000000000..7e646d353e --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/azure-storage-blob-retrieval-via-azcopy.asciidoc @@ -0,0 +1,135 @@ +[[azure-storage-blob-retrieval-via-azcopy]] +=== Azure Storage Blob Retrieval via AzCopy + +Identifies successful GetBlob operations on Azure Storage Accounts using AzCopy user agent with SAS token authentication. AzCopy is a command-line utility for copying data to and from Azure Storage. While legitimate for data migration, adversaries may abuse AzCopy with compromised SAS tokens to exfiltrate data from Azure Storage Accounts. This rule detects the first occurrence of GetBlob operations from a specific storage account using this pattern. + +*Rule type*: new_terms + +*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://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ +* https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-v10 +* https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Azure Storage +* Use Case: Threat Detection +* Tactic: Exfiltration +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Storage Blob Retrieval via AzCopy* + + +Azure Storage Accounts provide cloud storage services for blobs, files, queues, and tables. Shared Access Signatures (SAS) tokens provide delegated access to resources in a storage account with specific permissions and time constraints. AzCopy is a Microsoft command-line utility designed for efficient data transfers to and from Azure Storage. While AzCopy is a legitimate tool, adversaries may abuse it with compromised SAS tokens to exfiltrate data from Azure Storage Accounts. + + +*Possible investigation steps* + +- Review the `azure.platformlogs.properties.accountName` field to identify which storage account is being accessed and assess the sensitivity of data stored in that account. +- Examine the `azure.platformlogs.properties.objectKey` field to identify the specific blob(s) being retrieved. Determine if the accessed files contain sensitive or confidential data. +- Check the `source.address` field to identify the source IP address of the request. Investigate if this IP is unusual, unexpected, or originates from an unexpected network or geographic location. +- Review the `azure.platformlogs.uri` field to examine the SAS token parameters, including: + - `se` (expiry time): Check when the SAS token expires + - `sp` (permissions): Verify what permissions were granted (e.g., "rl" for read and list) + - `sv` (API version): Note the storage service version being used +- Examine the `azure.platformlogs.identity.tokenHash` field to identify the specific SAS token signature being used. Correlate this with SAS token generation logs to determine when and how the token was created. +- Check the `azure.platformlogs.properties.responseBodySize` field to assess the volume of data being downloaded. Multiple GetBlob operations with large response sizes may indicate bulk data exfiltration. +- Search for related GetBlob operations from the same `source.address` or with the same `azure.platformlogs.identity.tokenHash` to identify patterns of systematic data retrieval. +- Review Azure Activity Logs for recent SAS token generation events or storage account key access operations that may indicate how the adversary obtained the credentials. +- Correlate this activity with ListBlobs or ListContainers operations from the same source, as adversaries often enumerate storage contents before exfiltration. +- Investigate the `azure.resource.group` field to understand which resource group the storage account belongs to and check for any recent security events or configuration changes in that resource group. + + +*False positive analysis* + +- Routine data migration or backup operations using AzCopy with SAS tokens are common in enterprise environments. If this is expected behavior for the storage account, consider adding exceptions for specific accounts or IP ranges. +- DevOps pipelines or automated workflows may use AzCopy with SAS tokens for legitimate data transfers. Review the automation configuration and add exceptions if appropriate. +- Third-party services or partners may have authorized access to storage accounts using AzCopy and SAS tokens. Verify these relationships and create exceptions for known authorized sources. + + +*Response and remediation* + +- If unauthorized access is confirmed, immediately revoke the compromised SAS token to prevent further data exfiltration. +- Review and rotate any additional SAS tokens that may have been compromised through the same attack vector. +- Assess the scope of data accessed or exfiltrated during the unauthorized GetBlob operations and determine if sensitive data was compromised. +- Implement additional monitoring and alerting for the affected storage account to detect any further suspicious activity. +- Review and strengthen SAS token generation policies, including implementing shorter expiration times and more restrictive permissions. +- Consider implementing Azure Storage firewall rules or private endpoints to restrict access to storage accounts from trusted networks only. +- Investigate how the SAS token was compromised and remediate the initial access vector to prevent future incidents. +- Document the incident and update security procedures to prevent similar compromises in the future. + + +==== Setup + + + +*Required Azure Storage Diagnostic Logs* + + +To ensure this rule functions correctly, the following diagnostic logs must be enabled for Azure Storage Accounts: +- StorageRead: This log captures all read operations performed on blobs in the storage account, including GetBlob operations. These logs should be streamed to the Event Hub used for the Azure integration configuration. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: azure.platformlogs and + event.action: GetBlob and + azure.platformlogs.identity.type: SAS and + azure.platformlogs.properties.userAgentHeader: AzCopy* and + azure.platformlogs.statusCode: 200 + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-aws-root-login-without-mfa.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-aws-root-login-without-mfa.asciidoc new file mode 100644 index 0000000000..d512abcfa5 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/deprecated-aws-root-login-without-mfa.asciidoc @@ -0,0 +1,124 @@ +[[deprecated-aws-root-login-without-mfa]] +=== Deprecated - AWS Root Login Without MFA + +Identifies attempts to login to AWS as the root user without using multi-factor authentication (MFA). Amazon AWS best practices indicate that the root user should be protected by MFA. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Route53 +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Privilege Escalation + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Deprecated - AWS Root Login Without MFA* + + +Multi-factor authentication (MFA) in AWS is a simple best practice that adds an extra layer of protection on top of your user name and password. With MFA enabled, when a user signs in to an AWS Management Console, they will be prompted for their user name and password, as well as for an authentication code from their AWS MFA device. Taken together, these multiple factors provide increased security for your AWS account settings and resources. + +For more information about using MFA in AWS, access the https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html[official documentation]. + +The AWS root account is the one identity that has complete access to all AWS services and resources in the account, which is created when the AWS account is created. AWS strongly recommends that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks. Amazon provides a https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root[list of the tasks that require root user]. + +This rule looks for attempts to log in to AWS as the root user without using multi-factor authentication (MFA), meaning the account is not secured properly. + + +*Possible investigation steps* + + +- Investigate other alerts associated with the user account during the past 48 hours. +- Examine whether this activity is common in the environment by looking for past occurrences on your logs. +- Consider the source IP address and geolocation for the calling user who issued the command. Do they look normal for the calling user? +- Examine the commands, API calls, and data management actions performed by the account in the last 24 hours. +- Contact the account owner and confirm whether they are aware of this activity. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking access to servers, +services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- While this activity is not inherently malicious, the root account must use MFA. The security team should address any potential benign true positive (B-TP), as this configuration can risk the entire cloud environment. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Identify the services or servers involved criticality. + - 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 if there are any regulatory or legal ramifications related to this activity. +- Configure multi-factor authentication for the user. +- Follow security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset:aws.cloudtrail and event.provider:signin.amazonaws.com and event.action:ConsoleLogin and + aws.cloudtrail.user_identity.type:Root and + aws.cloudtrail.console_login.additional_eventdata.mfa_used:false 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/ diff --git a/docs/detections/prebuilt-rules/rule-details/disabling-lsa-protection-via-registry-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/disabling-lsa-protection-via-registry-modification.asciidoc index 7452549266..86bc1a8452 100644 --- a/docs/detections/prebuilt-rules/rule-details/disabling-lsa-protection-via-registry-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/disabling-lsa-protection-via-registry-modification.asciidoc @@ -43,7 +43,7 @@ LSA protecton is provided to prevent nonprotected processes from reading memory * Data Source: SentinelOne * Data Source: Crowdstrike -*Version*: 2 +*Version*: 3 *Rule authors*: @@ -108,7 +108,8 @@ Attackers may disable Lsa protection to access Lsass memory for credentals. This [source, js] ---------------------------------- registry where host.os.type == "windows" and event.type == "change" and - registry.value : "RunAsPPL" and registry.path : "*\\SYSTEM\\*ControlSet*\\Control\\Lsa\\RunAsPPL" and + registry.data.strings != null and registry.value : "RunAsPPL" and + registry.path : "*\\SYSTEM\\*ControlSet*\\Control\\Lsa\\RunAsPPL" and not registry.data.strings : ("1", "0x00000001", "2", "0x00000002") ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/dns-global-query-block-list-modified-or-disabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/dns-global-query-block-list-modified-or-disabled.asciidoc index 4cabb9eb12..d81b77c6d5 100644 --- a/docs/detections/prebuilt-rules/rule-details/dns-global-query-block-list-modified-or-disabled.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/dns-global-query-block-list-modified-or-disabled.asciidoc @@ -45,7 +45,7 @@ Identifies changes to the DNS Global Query Block List (GQBL), a security feature * Data Source: Crowdstrike * Resources: Investigation Guide -*Version*: 207 +*Version*: 208 *Rule authors*: @@ -107,7 +107,7 @@ The DNS Global Query Block List (GQBL) is a security feature in Windows environm [source, js] ---------------------------------- -registry where host.os.type == "windows" and event.type == "change" and +registry where host.os.type == "windows" and event.type == "change" and registry.data.strings != null and ( (registry.value : "EnableGlobalQueryBlockList" and registry.data.strings : ("0", "0x00000000")) or (registry.value : "GlobalQueryBlockList" and not registry.data.strings : "wpad") diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-oauth-user-impersonation-scope-for-unusual-user-and-client.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-oauth-user-impersonation-scope-for-unusual-user-and-client.asciidoc new file mode 100644 index 0000000000..fa78e73f91 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/entra-id-oauth-user-impersonation-scope-for-unusual-user-and-client.asciidoc @@ -0,0 +1,152 @@ +[[entra-id-oauth-user-impersonation-scope-for-unusual-user-and-client]] +=== Entra ID OAuth user_impersonation Scope for Unusual User and Client + +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. + +*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://github.com/Flangvik/TeamFiltration +* https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign + +*Tags*: + +* 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 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating Entra ID OAuth user_impersonation Scope for Unusual User and Client* + + +Identifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth scope containing `user_impersonation`, and a token issuer type of `AzureAD`. This rule is designed to detect suspicious +OAuth user impersonation attempts in Microsoft Entra ID, particularly those involving the `user_impersonation` scope, which is often used by adversaries to gain unauthorized access to user accounts. The rule focuses on sign-in events where +the sign-in session status is `unbound`, indicating that the session is not associated with a specific device or session, making it more vulnerable to abuse. This behavior is indicative of potential account compromise or +unauthorized access attempts, especially when the user type is `Member` and the sign-in outcome is `success`. The rule aims to identify these events to facilitate timely investigation and response to potential security incidents. This is a New Terms rule that 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. + + +*Possible investigation steps* + + +- Review the `azure.signinlogs.properties.user_principal_name` field to identify the user principal involved in the OAuth workflow. +- Check the `azure.signinlogs.properties.authentication_processing_details.Oauth Scope Info` field for the presence of `user_impersonation`. This scope is commonly used in OAuth flows to allow applications to access user resources on behalf of the user. +- Confirm that the `azure.signinlogs.properties.authentication_requirement` is set to `singleFactorAuthentication`, indicating that the sign-in did not require multi-factor authentication (MFA). This can be a red flag, as MFA is a critical security control that helps prevent unauthorized access. +- Review the `azure.signinlogs.properties.app_display_name` or `azure.signinlogs.properties.app_id` to identify the application involved in the OAuth workflow. Check if this application is known and trusted, or if it appears suspicious or unauthorized. FOCI applications are commonly abused by adversaries to evade security controls or conditional access policies. +- Analyze the `azure.signinlogs.properties.client_ip` to determine the source of the sign-in attempt. 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. +- Examine the `azure.signinlogs.properties.resource_display_name` or `azure.signinlogs.properties.resource_id` to identify the resource being accessed during the OAuth workflow. This can help determine if the access was legitimate or if it targeted sensitive resources. It may also help pivot to other related events or activities. +- Use the `azure.signinlogs.properties.session_id` or `azure.signinlogs.properties.correlation_id` to correlate this event with other related sign-in events or activities. This can help identify patterns of suspicious behavior or potential account compromise. + + +*False positive analysis* + + +- Some legitimate applications may use the `user_impersonation` scope for valid purposes, such as accessing user resources on behalf of the user. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. +- Users may occasionally authenticate using single-factor authentication for specific applications or scenarios, especially in environments where MFA is not enforced or required. If this is expected behavior, consider adjusting the rule or adding exceptions for specific user principals or applications. +- Some applications may use the `user_impersonation` scope for legitimate purposes, such as accessing user resources in a controlled manner. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. + + +*Response and remediation* + + +- Contact the user to validate the OAuth workflow and assess whether they were targeted or tricked by a malicious actor. +- If the OAuth workflow is confirmed to be malicious: + - Block the user account and reset the password to prevent further unauthorized access. + - Revoke active sessions and refresh tokens associated with the user principal. + - Review the application involved in the OAuth workflow and determine if it should be blocked or removed from the tenant. + - Investigate the source of the sign-in 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 OAuth user impersonation and encourage them to use more secure authentication methods, such as OAuth 2.0 or OpenID Connect, whenever possible. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: azure.signinlogs and + azure.signinlogs.properties.authentication_processing_details: *user_impersonation* and + azure.signinlogs.properties.authentication_requirement: "singleFactorAuthentication" and + azure.signinlogs.properties.token_issuer_type: "AzureAD" and + azure.signinlogs.properties.token_protection_status_details.sign_in_session_status: "unbound" and + azure.signinlogs.properties.user_type: "Member" and + azure.signinlogs.properties.conditional_access_status: "notApplied" and + not user_agent.original: Mozilla*PKeyAuth/1.0 and + not azure.signinlogs.properties.device_detail.operating_system: (Ios* or Android*) and + event.outcome: "success" + and not azure.signinlogs.properties.app_id: ( + "a5f63c0-b750-4f38-a71c-4fc0d58b89e2" or + "6bc3b958-689b-49f5-9006-36d165f30e00" or + "66a88757-258c-4c72-893c-3e8bed4d6899" or + "cc15fd57-2c6c-4117-a88c-83b1d56b4bbe" or + "0000000c-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/ +* 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/ +* Technique: +** Name: Impersonation +** ID: T1656 +** Reference URL: https://attack.mitre.org/techniques/T1656/ diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-protection-admin-confirmed-compromise.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-protection-admin-confirmed-compromise.asciidoc new file mode 100644 index 0000000000..594231e90a --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/entra-id-protection-admin-confirmed-compromise.asciidoc @@ -0,0 +1,144 @@ +[[entra-id-protection-admin-confirmed-compromise]] +=== Entra ID Protection Admin Confirmed Compromise + +Identifies when an administrator has manually confirmed a user or sign-in as compromised in Microsoft Entra ID Protection. This indicates that an administrator has reviewed the risk detection and determined that the user account or sign-in activity is definitively compromised. This is a high-confidence indicator of account compromise and should be investigated immediately. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.identity_protection-* + +*Severity*: critical + +*Risk score*: 99 + +*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/id-protection/howto-identity-protection-investigate-risk +* https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks +* https://learn.microsoft.com/en-us/graph/api/resources/riskdetection + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Protection Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +This rule detects when an administrator has manually confirmed a user or sign-in as compromised in Microsoft Entra ID Protection. This is a critical security event that requires immediate investigation and response. + + +*Possible investigation steps* + + +- Review the `azure.identityprotection.properties.risk_detail` field to determine if the compromise was confirmed at the sign-in level (`adminConfirmedSigninCompromised`) or user level (`adminConfirmedUserCompromised`). +- Check the `azure.identityprotection.properties.user_principal_name` field to identify the compromised user account. +- Review the `azure.identityprotection.properties.user_display_name` field for additional user identification information. +- Examine the `azure.identityprotection.properties.risk_level` field to understand the severity level assigned to the risk event. +- Check the `azure.identityprotection.properties.risk_state` field to verify the current state of the risk (should be confirmed as compromised). +- Review the `azure.correlation_id` field to correlate this event with other related security events, including the original risk detections that led to the admin confirmation. +- Investigate the timeline of events leading up to the admin confirmation by reviewing Entra ID sign-in logs and audit logs for the affected user. +- Check for any suspicious activities associated with the user account, including: + - Unusual sign-in locations or IP addresses + - Access to sensitive resources or applications + - Changes to user profile, permissions, or MFA settings + - Bulk email sending or data exfiltration activities +- Review the `azure.identityprotection.properties.additional_info` field for any additional context provided by the administrator or Entra ID Protection. +- Identify which administrator confirmed the compromise by reviewing Entra ID audit logs for risk state changes. + + +*False positive analysis* + + +- Security testing or penetration testing exercises may result in administrators confirming test accounts as compromised. If this is expected behavior, consider excluding specific test accounts or implementing a testing account naming convention to filter. +- Incident response drills or tabletop exercises may involve marking accounts as compromised for training purposes. Coordinate with security teams to identify planned exercises. + + +*Response and remediation* + + +- Immediately reset the password for the compromised user account and require the user to set a new password upon next sign-in. +- Revoke all active sessions and authentication tokens for the compromised account, including: + - Primary refresh tokens (PRTs) + - OAuth tokens + - Session cookies + - Application-specific passwords +- Review and revoke any suspicious OAuth consent grants or application permissions added by the compromised account. +- Enable or enforce multi-factor authentication (MFA) for the affected user account if not already enabled. +- Review all activities performed by the compromised account, including: + - Email forwarding rules or inbox rules + - File access and downloads + - Changes to security settings or permissions + - Creation of new users or service principals +- Assess the scope of the compromise by identifying any lateral movement or privilege escalation activities. +- Consider disabling the account temporarily until the investigation is complete and all remediation steps are verified. +- Implement conditional access policies to prevent future compromises, such as requiring MFA from untrusted locations or blocking legacy authentication. +- Review and strengthen identity protection policies and risk-based conditional access rules. +- Document the incident, including the timeline, scope of compromise, and remediation actions taken. +- Conduct a post-incident review to identify gaps in security controls and implement improvements to prevent similar incidents. + + +==== Setup + + + +*Required Microsoft Entra ID Protection Logs* + +To use this rule, ensure that Microsoft Entra ID Protection logs are being collected and streamed into the Elastic Stack via the Azure integration. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: azure.identity_protection and + azure.identityprotection.properties.risk_detail: ( + "adminConfirmedSigninCompromised" or + "adminConfirmedUserCompromised" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/rule-details/excessive-secret-or-key-retrieval-from-azure-key-vault.asciidoc b/docs/detections/prebuilt-rules/rule-details/excessive-secret-or-key-retrieval-from-azure-key-vault.asciidoc index 0284e86277..e0dfea7f91 100644 --- a/docs/detections/prebuilt-rules/rule-details/excessive-secret-or-key-retrieval-from-azure-key-vault.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/excessive-secret-or-key-retrieval-from-azure-key-vault.asciidoc @@ -34,7 +34,7 @@ Identifies excessive secret or key retrieval operations from Azure Key Vault. Th * Tactic: Credential Access * Resources: Investigation Guide -*Version*: 3 +*Version*: 4 *Rule authors*: @@ -63,7 +63,7 @@ Azure Key Vault is a cloud service that safeguards encryption keys and secrets l - 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. +- Check the `source.ip` or `source.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. @@ -140,9 +140,9 @@ from logs-azure.platformlogs-* metadata _id, _index Esql.azure_platformlogs_identity_claim_appid_values = values(azure.platformlogs.identity.claim.appid), Esql.source_ip_values = values(source.ip), - Esql.geo_city_values = values(geo.city_name), - Esql.geo_region_values = values(geo.region_name), - Esql.geo_country_values = values(geo.country_name), + Esql.source_geo_city_values = values(source.geo.city_name), + Esql.source_geo_region_values = values(source.geo.region_name), + Esql.source_geo_country_values = values(source.geo.country_name), Esql.source_as_organization_name_values = values(source.as.organization.name), Esql.event_action_values = values(event.action), @@ -167,9 +167,9 @@ by Esql.time_window_date_trunc, azure.platformlogs.identity.claim.upn Esql.azure_platformlogs_identity_claim_upn_count_distinct, Esql.azure_platformlogs_identity_claim_appid_values, Esql.source_ip_values, - Esql.geo_city_values, - Esql.geo_region_values, - Esql.geo_country_values, + Esql.source_geo_city_values, + Esql.source_geo_region_values, + Esql.source_geo_country_values, Esql.source_as_organization_name_values, Esql.event_action_values, Esql.event_count, diff --git a/docs/detections/prebuilt-rules/rule-details/potential-command-shell-via-netcat.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-command-shell-via-netcat.asciidoc new file mode 100644 index 0000000000..1e38e64a26 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/potential-command-shell-via-netcat.asciidoc @@ -0,0 +1,120 @@ +[[potential-command-shell-via-netcat]] +=== Potential Command Shell via NetCat + +Identifies potential attempt to execute via a reverse shell using the netcat utility to execute Windows commands using the default interpreters like Cmd.exe and Powershell. + +*Rule type*: eql + +*Rule indices*: + +* 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*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Defend + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Command Shell via NetCat* + + +Attackers may abuse the NetCat utility to execute commands remotely using the builtin Windows Command Shell interpreters. + + +*Possible investigation steps* + + +- Verify if the user is authorized to use the Netcat utility. +- Investigate the process execution chain (parent process tree) and how the netcat binary was dropped. +- Review the network connections made by the parent process and check their reputation. +- Investiguate all child processes spawned by the Cmd or Powershell instance. +- Examine the host for other alerts within the same period. + + +*False positive analysis* + + +- IT Support or system amdinistrator authorized activity using NetCat. + + +*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. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- 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. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and +process.name : ("cmd.exe", "powershell.exe") and process.parent.args : "-e" and + ( + (process.parent.args_count == 5 and process.parent.command_line regex~ """.*[0-9]{1,3}(\.[0-9]{1,3}){3}.*""") or + (process.parent.args : "-*l*" and process.parent.args : "-*p*" and process.parent.args : ("cmd.exe", "powershell.exe")) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ diff --git a/docs/detections/prebuilt-rules/rule-details/potential-cve-2025-32463-sudo-chroot-execution-attempt.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-cve-2025-32463-sudo-chroot-execution-attempt.asciidoc index 988e591f56..7d66bad2b8 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-cve-2025-32463-sudo-chroot-execution-attempt.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-cve-2025-32463-sudo-chroot-execution-attempt.asciidoc @@ -43,7 +43,7 @@ Detects suspicious use of sudo's --chroot / -R option consistent with attempts t * Use Case: Vulnerability * Resources: Investigation Guide -*Version*: 1 +*Version*: 2 *Rule authors*: @@ -75,7 +75,7 @@ This rule highlights sudo invoked with the chroot (-R/--chroot) option outside n - 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. +- 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. @@ -141,7 +141,7 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ ---------------------------------- 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 in ("-R", "--chroot") 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*") diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-service-imagepath-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-service-imagepath-modification.asciidoc index f7f0e5956f..358fa4d703 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-service-imagepath-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-service-imagepath-modification.asciidoc @@ -44,7 +44,7 @@ Identifies registry modifications to default services that could enable privileg * Data Source: Microsoft Defender for Endpoint * Data Source: Elastic Endgame -*Version*: 106 +*Version*: 107 *Rule authors*: @@ -108,7 +108,7 @@ Windows services are crucial for system operations, often running with high priv [source, js] ---------------------------------- registry where host.os.type == "windows" and event.type == "change" and process.executable != null and - registry.value == "ImagePath" and + registry.data.strings != null and registry.value == "ImagePath" and registry.key : ( "*\\ADWS", "*\\AppHostSvc", "*\\AppReadiness", "*\\AudioEndpointBuilder", "*\\AxInstSV", "*\\camsvc", "*\\CertSvc", "*\\COMSysApp", "*\\CscService", "*\\defragsvc", "*\\DeviceAssociationService", "*\\DeviceInstall", "*\\DevQueryBroker", diff --git a/docs/detections/prebuilt-rules/rule-details/simple-http-web-server-connection.asciidoc b/docs/detections/prebuilt-rules/rule-details/simple-http-web-server-connection.asciidoc index 2d9d18c859..828fe89249 100644 --- a/docs/detections/prebuilt-rules/rule-details/simple-http-web-server-connection.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/simple-http-web-server-connection.asciidoc @@ -7,6 +7,7 @@ This rule detects connections accepted by a simple HTTP web server in Python and *Rule indices*: +* logs-endpoint.events.process* * logs-endpoint.events.network* *Severity*: low @@ -32,7 +33,7 @@ This rule detects connections accepted by a simple HTTP web server in Python and * Data Source: Elastic Defend * Resources: Investigation Guide -*Version*: 4 +*Version*: 5 *Rule authors*: @@ -132,10 +133,13 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ [source, js] ---------------------------------- -network where host.os.type == "linux" and event.type == "start" and event.action == "connection_accepted" and ( +sequence by process.entity_id with maxspan=1m +[process where host.os.type == "linux" and event.type == "start" and + ( (process.name regex~ """php?[0-9]?\.?[0-9]{0,2}""" and process.command_line like "*-S*") or (process.name like "python*" and process.command_line like ("*--cgi*", "*CGIHTTPServer*")) -) + )] +[network where host.os.type == "linux" and event.type == "start" and event.action == "connection_accepted"] ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-persistence-via-services-registry.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-persistence-via-services-registry.asciidoc index 40a3136bbe..a47aa894a5 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-persistence-via-services-registry.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-persistence-via-services-registry.asciidoc @@ -40,7 +40,7 @@ Identifies processes modifying the services registry key directly, instead of th * Data Source: SentinelOne * Resources: Investigation Guide -*Version*: 314 +*Version*: 315 *Rule authors*: @@ -104,7 +104,7 @@ Windows services are crucial for running background processes. Adversaries may e [source, js] ---------------------------------- registry where host.os.type == "windows" and event.type == "change" and - registry.value : ("ServiceDLL", "ImagePath") and + registry.data.strings != null and registry.value : ("ServiceDLL", "ImagePath") and registry.path : ( "HKLM\\SYSTEM\\ControlSet*\\Services\\*\\ServiceDLL", "HKLM\\SYSTEM\\ControlSet*\\Services\\*\\ImagePath", diff --git a/docs/index.asciidoc b/docs/index.asciidoc index afcaaf7cd5..4ac69e4c6c 100644 --- a/docs/index.asciidoc +++ b/docs/index.asciidoc @@ -99,3 +99,5 @@ include::detections/prebuilt-rules/downloadable-packages/8-19-6/prebuilt-rules-8 include::detections/prebuilt-rules/downloadable-packages/8-19-7/prebuilt-rules-8-19-7-appendix.asciidoc[] include::detections/prebuilt-rules/downloadable-packages/8-19-8/prebuilt-rules-8-19-8-appendix.asciidoc[] + +include::detections/prebuilt-rules/downloadable-packages/8-19-9/prebuilt-rules-8-19-9-appendix.asciidoc[]