From e5f7010a7d9a29410e7aa323da41d49f77b2df84 Mon Sep 17 00:00:00 2001 From: tradebot-elastic <178941316+tradebot-elastic@users.noreply.github.com> Date: Wed, 23 Jul 2025 03:59:50 +0000 Subject: [PATCH 1/2] Update latest docs --- ...aws-dynamodb-table-exported-to-s3.asciidoc | 118 +++++++++ ...2-ami-shared-with-another-account.asciidoc | 120 +++++++++ ...-aws-ec2-deprecated-ami-discovery.asciidoc | 148 +++++++++++ ...curity-group-configuration-change.asciidoc | 150 +++++++++++ ...r-data-retrieval-for-ec2-instance.asciidoc | 146 ++++++++++ ...oraccess-policy-attached-to-group.asciidoc | 151 +++++++++++ ...toraccess-policy-attached-to-role.asciidoc | 151 +++++++++++ ...toraccess-policy-attached-to-user.asciidoc | 164 ++++++++++++ ...alls-via-temporary-session-tokens.asciidoc | 118 +++++++++ ...aws-iam-assume-role-policy-update.asciidoc | 130 +++++++++ ...icy-attached-to-role-by-rare-user.asciidoc | 132 ++++++++++ ...ated-access-keys-for-another-user.asciidoc | 166 ++++++++++++ ...encryption-using-external-kms-key.asciidoc | 138 ++++++++++ ...endcommand-execution-by-rare-user.asciidoc | 138 ++++++++++ ...eter-request-with-decryption-flag.asciidoc | 132 ++++++++++ ...e-8-18-9-azure-key-vault-modified.asciidoc | 106 ++++++++ ...ret-key-usage-by-unusual-identity.asciidoc | 149 +++++++++++ ...s-s3-object-encryption-with-sse-c.asciidoc | 143 ++++++++++ ...ey-retrieval-from-azure-key-vault.asciidoc | 208 +++++++++++++++ ...ition-or-modification-in-entra-id.asciidoc | 118 +++++++++ ...nnections-from-unusual-executable.asciidoc | 170 ++++++++++++ ...kies-generated-for-authentication.asciidoc | 156 +++++++++++ ...security-group-ingress-rule-added.asciidoc | 125 +++++++++ ...es-unusual-decision-by-user-agent.asciidoc | 105 ++++++++ ...e-file-downloads-with-oauth-token.asciidoc | 139 ++++++++++ ...euse-with-suspicious-graph-access.asciidoc | 184 +++++++++++++ ...a-id-sign-in-brute-force-activity.asciidoc | 249 ++++++++++++++++++ ...en-hashes-for-single-okta-session.asciidoc | 147 +++++++++++ ...unt-lockouts-in-short-time-window.asciidoc | 164 ++++++++++++ ...cation-events-with-client-address.asciidoc | 155 +++++++++++ ...vents-with-same-device-token-hash.asciidoc | 153 +++++++++++ ...discovery-url-changed-in-entra-id.asciidoc | 127 +++++++++ ...arted-from-different-geolocations.asciidoc | 137 ++++++++++ ...impersonation-attempt-via-kubectl.asciidoc | 184 +++++++++++++ ...re-driven-ssh-brute-force-attempt.asciidoc | 178 +++++++++++++ ...ng-activity-from-compromised-host.asciidoc | 150 +++++++++++ ...ng-activity-from-compromised-host.asciidoc | 149 +++++++++++ ...-8-18-9-sudoers-file-modification.asciidoc | 120 +++++++++ ...amfiltration-user-agents-detected.asciidoc | 169 ++++++++++++ ...s-s3-object-encryption-with-sse-c.asciidoc | 143 ++++++++++ ...base64-encoding-decoding-activity.asciidoc | 186 +++++++++++++ ...-execution-from-web-server-parent.asciidoc | 205 ++++++++++++++ ...al-file-transfer-utility-launched.asciidoc | 152 +++++++++++ ...t-rule-8-18-9-unusual-kill-signal.asciidoc | 141 ++++++++++ ...ss-spawned-from-web-server-parent.asciidoc | 196 ++++++++++++++ .../prebuilt-rules-8-18-9-appendix.asciidoc | 53 ++++ .../prebuilt-rules-8-18-9-summary.asciidoc | 106 ++++++++ ...ebuilt-rules-downloadable-updates.asciidoc | 5 + .../prebuilt-rules-reference.asciidoc | 92 ++++--- .../prebuilt-rules/rule-desc-index.asciidoc | 11 +- ...aws-dynamodb-table-exported-to-s3.asciidoc | 22 +- ...2-ami-shared-with-another-account.asciidoc | 120 +++++++++ .../aws-ec2-deprecated-ami-discovery.asciidoc | 5 +- ...curity-group-configuration-change.asciidoc | 57 +--- ...r-data-retrieval-for-ec2-instance.asciidoc | 2 +- ...oraccess-policy-attached-to-group.asciidoc | 4 +- ...toraccess-policy-attached-to-role.asciidoc | 4 +- ...toraccess-policy-attached-to-user.asciidoc | 4 +- ...alls-via-temporary-session-tokens.asciidoc | 19 +- ...aws-iam-assume-role-policy-update.asciidoc | 6 +- ...icy-attached-to-role-by-rare-user.asciidoc | 16 +- ...ated-access-keys-for-another-user.asciidoc | 4 +- ...encryption-using-external-kms-key.asciidoc | 4 +- ...endcommand-execution-by-rare-user.asciidoc | 6 +- ...eter-request-with-decryption-flag.asciidoc | 10 +- .../azure-key-vault-modified.asciidoc | 84 +++--- ...ret-key-usage-by-unusual-identity.asciidoc | 149 +++++++++++ ...s-s3-object-encryption-with-sse-c.asciidoc | 13 +- ...ey-retrieval-from-azure-key-vault.asciidoc | 208 +++++++++++++++ ...ition-or-modification-in-entra-id.asciidoc | 118 +++++++++ ...nnections-from-unusual-executable.asciidoc | 4 +- ...kies-generated-for-authentication.asciidoc | 4 +- ...security-group-ingress-rule-added.asciidoc | 10 +- ...es-unusual-decision-by-user-agent.asciidoc | 105 ++++++++ ...e-file-downloads-with-oauth-token.asciidoc | 4 +- ...euse-with-suspicious-graph-access.asciidoc | 4 +- ...en-hashes-for-single-okta-session.asciidoc | 4 +- ...unt-lockouts-in-short-time-window.asciidoc | 4 +- ...cation-events-with-client-address.asciidoc | 4 +- ...vents-with-same-device-token-hash.asciidoc | 4 +- ...discovery-url-changed-in-entra-id.asciidoc | 127 +++++++++ ...arted-from-different-geolocations.asciidoc | 4 +- ...impersonation-attempt-via-kubectl.asciidoc | 184 +++++++++++++ ...re-driven-ssh-brute-force-attempt.asciidoc | 4 +- ...ng-activity-from-compromised-host.asciidoc | 4 +- ...ng-activity-from-compromised-host.asciidoc | 4 +- .../sudoers-file-modification.asciidoc | 12 +- ...s-s3-object-encryption-with-sse-c.asciidoc | 13 +- ...base64-encoding-decoding-activity.asciidoc | 4 +- ...-execution-from-web-server-parent.asciidoc | 4 +- ...al-file-transfer-utility-launched.asciidoc | 4 +- .../rule-details/unusual-kill-signal.asciidoc | 141 ++++++++++ ...ss-spawned-from-web-server-parent.asciidoc | 4 +- docs/index.asciidoc | 2 + 94 files changed, 8340 insertions(+), 250 deletions(-) create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-dynamodb-table-exported-to-s3.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-ec2-ami-shared-with-another-account.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-ec2-deprecated-ami-discovery.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-ec2-security-group-configuration-change.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-ec2-user-data-retrieval-for-ec2-instance.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-administratoraccess-policy-attached-to-group.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-administratoraccess-policy-attached-to-role.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-administratoraccess-policy-attached-to-user.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-api-calls-via-temporary-session-tokens.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-assume-role-policy-update.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-customer-managed-policy-attached-to-role-by-rare-user.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-user-created-access-keys-for-another-user.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-s3-object-encryption-using-external-kms-key.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-ssm-sendcommand-execution-by-rare-user.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-systems-manager-securestring-parameter-request-with-decryption-flag.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-azure-key-vault-modified.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-azure-key-vault-secret-key-usage-by-unusual-identity.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-excessive-aws-s3-object-encryption-with-sse-c.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-excessive-secret-or-key-retrieval-from-azure-key-vault.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-external-authentication-method-addition-or-modification-in-entra-id.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-high-number-of-egress-network-connections-from-unusual-executable.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-high-number-of-okta-device-token-cookies-generated-for-authentication.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-insecure-aws-ec2-vpc-security-group-ingress-rule-added.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-kubernetes-unusual-decision-by-user-agent.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-m365-onedrive-excessive-file-downloads-with-oauth-token.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-microsoft-entra-id-session-reuse-with-suspicious-graph-access.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-microsoft-entra-id-sign-in-brute-force-activity.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-multiple-device-token-hashes-for-single-okta-session.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-multiple-microsoft-365-user-account-lockouts-in-short-time-window.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-multiple-okta-user-authentication-events-with-client-address.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-oidc-discovery-url-changed-in-entra-id.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-okta-user-sessions-started-from-different-geolocations.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-potential-impersonation-attempt-via-kubectl.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-potential-malware-driven-ssh-brute-force-attempt.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-potential-port-scanning-activity-from-compromised-host.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-potential-subnet-scanning-activity-from-compromised-host.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-sudoers-file-modification.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-teamfiltration-user-agents-detected.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-aws-s3-object-encryption-with-sse-c.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-base64-encoding-decoding-activity.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-command-execution-from-web-server-parent.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-file-transfer-utility-launched.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-kill-signal.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-process-spawned-from-web-server-parent.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rules-8-18-9-appendix.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rules-8-18-9-summary.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/aws-ec2-ami-shared-with-another-account.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/azure-key-vault-secret-key-usage-by-unusual-identity.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/excessive-secret-or-key-retrieval-from-azure-key-vault.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/external-authentication-method-addition-or-modification-in-entra-id.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/kubernetes-unusual-decision-by-user-agent.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/oidc-discovery-url-changed-in-entra-id.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/potential-impersonation-attempt-via-kubectl.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/unusual-kill-signal.asciidoc diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-dynamodb-table-exported-to-s3.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-dynamodb-table-exported-to-s3.asciidoc new file mode 100644 index 0000000000..2df9fb85d2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-dynamodb-table-exported-to-s3.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-18-9-aws-dynamodb-table-exported-to-s3]] +=== AWS DynamoDB Table Exported to S3 + +Identifies when an AWS DynamoDB table is exported to S3. Adversaries may use the ExportTableToPointInTime operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the ExportTableToPointInTime action in CloudTrail logs. This is a New Terms rule that only flags when this behavior is observed by the "user.name" for the first time. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ExportTableToPointInTime.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS DynamoDB +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Exfiltration + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + + +*Investigating AWS DynamoDB Table Exported to S3* + + +This rule identifies when an AWS DynamoDB table is exported to S3. Adversaries may use the ExportTableToPointInTime operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the ExportTableToPointInTime action in CloudTrail logs. + +This is a New Terms rule that only flags when this behavior is observed for the first time. + + +*Possible Investigation Steps* + +- Identify the Actor: Review the `aws.cloudtrail.user_identity.arn` field to identify the user who requested the export. Verify if this actor typically performs such actions and has the necessary permissions. It may be unusual for this activity to originate from certain user types, such as an assumed role or federated user. +- Review the Source IP: Check the `source.ip` field to determine the source of the request. If the request comes from an unexpected location or IP address, it may indicate a compromised account or unauthorized access. +- Review Access Key: Check the `aws.cloudtrail.user_identity.access_key_id` field to identify the access key used for the request. Determine if this key has been compromised. +- Analyze the Request Parameters: Examine the `aws.cloudtrail.request_parameters` field to understand the details of the ExportTableToPointInTime request. Look for any unusual parameters or patterns that may indicate malicious intent. This also details the DynamoDB table being exported. + + +*False Positive Analysis* + +- Historical User Actions: If the user has a history of exporting DynamoDB tables for legitimate purposes, this may be a false positive. Review the user's activity logs to determine if this behavior is consistent with their normal actions. +- Automated Processes: Some automated processes or applications may perform exports on DynamoDB tables as part of their functionality. If the user is associated with such a process, this may be a false positive. + + +*Response and Remediation* + +- Immediate Review and Reversal: If the ExportTableToPointInTime action is determined to be unauthorized, immediately revoke the user's access to the DynamoDB table and any associated resources. This may involve disabling the user's access keys or removing their permissions. +- Investigate Compromise: If the ExportTableToPointInTime action is determined to be malicious, investigate the source and destination of the request and any potential compromise of the user's account. If the destination S3 bucket is not known, it may be a sign of data exfiltration and may require incident response. +- Review IAM Policies: Review the IAM policies associated with the user to ensure that they have the appropriate permissions for their role. If necessary, update the policies to restrict access to sensitive resources. +- Monitor for Future Activity: Continue to monitor the user's activity for any further suspicious behavior. Set up additional alerts or logging to detect any future unauthorized access attempts. + + +*Additional Information* + + +For further guidance on managing and securing DynamoDB in AWS environments, refer to the https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/security.html[AWS DynamoDB documentation] and AWS best practices for security. + + +==== Setup + + +DynamoDB data events must be enabled in CloudTrail to capture the ExportTableToPointInTime actions. Ensure that the AWS CloudTrail service is configured to log data events for DynamoDB tables. + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "dynamodb.amazonaws.com" + and event.action: "ExportTableToPointInTime" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-ec2-ami-shared-with-another-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-ec2-ami-shared-with-another-account.asciidoc new file mode 100644 index 0000000000..b0fbf6b796 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-ec2-ami-shared-with-another-account.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-18-9-aws-ec2-ami-shared-with-another-account]] +=== AWS EC2 AMI Shared with Another Account + +Identifies an AWS Amazon Machine Image (AMI) being shared with another AWS account. Adversaries with access may share an AMI with an external AWS account as a means of data exfiltration. AMIs can contain secrets, bash histories, code artifacts, and other sensitive data that adversaries may abuse if shared with unauthorized accounts. AMIs can be made publicly available accidentally as well. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html +* https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.ec2-share-ami/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Use Case: Threat Detection +* Tactic: Exfiltration +* Resources: Investigation Guide + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 AMI Shared with Another Account* + + +This rule identifies when an Amazon Machine Image (AMI) is shared with another AWS account. While sharing AMIs is a common practice, adversaries may exploit this feature to exfiltrate data by sharing AMIs with external accounts under their control. + + +*Possible Investigation Steps* + + +- **Review the Sharing Event**: Identify the AMI involved and review the event details in AWS CloudTrail. Look for `ModifyImageAttribute` actions where the AMI attributes were changed to include additional user accounts. + - **Request and Response Parameters**: Check the `aws.cloudtrail.request_parameters` and `aws.response.response_elements` fields in the CloudTrail event to identify the AMI ID and the user ID of the account with which the AMI was shared. +- **Verify the Shared AMI**: Check the AMI that was shared and its contents to determine the sensitivity of the data stored within it. +- **Contextualize with Recent Changes**: Compare this sharing event against recent changes in AMI configurations and deployments. Look for any other recent permissions changes or unusual administrative actions. +- **Validate External Account**: Examine the AWS account to which the AMI was shared. Determine whether this account is known and previously authorized to access such resources. +- **Interview Relevant Personnel**: If the share was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing AMI deployments. +- **Audit Related Security Policies**: Check the security policies governing AMI sharing within your organization to ensure they are being followed and are adequate to prevent unauthorized sharing. + + +*False Positive Analysis* + + +- **Legitimate Sharing Practices**: AMI sharing is a common and legitimate practice for collaboration and resource management in AWS. Always verify that the sharing activity was unauthorized before escalating. +- **Automation Tools**: Some organizations use automation tools for AMI management which might programmatically share AMIs. Verify if such tools are in operation and whether their actions are responsible for the observed behavior. +- **AWS Services**: Some AWS services, such as WorkSpaces and Backup, automate AMI sharing when users configure cross-account sharing or disaster recovery plans. These will appear in CloudTrail with `userIdentity.invokedBy` and `source.address` fields like `workspaces.amazonaws.com` or `backup.amazonaws.com`. Confirm that such activity aligns with your organization's approved configurations. + + +*Response and Remediation* + + +- **Review and Revoke Unauthorized Shares**: If the share is found to be unauthorized, immediately revoke the shared permissions from the AMI. +- **Enhance Monitoring of Shared AMIs**: Implement monitoring to track changes to shared AMIs and alert on unauthorized access patterns. +- **Incident Response**: If malicious intent is confirmed, consider it a data breach incident and initiate the incident response protocol. This includes further investigation, containment, and recovery. +- **Policy Update**: Review and possibly update your organization’s policies on AMI sharing to tighten control and prevent unauthorized access. +- **Educate Users**: Conduct training sessions for users involved in managing AMIs to reinforce best practices and organizational policies regarding AMI sharing. + + +*Additional Information* + + +For more information on managing and sharing AMIs, refer to the https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html[Amazon EC2 User Guide on AMIs] and https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html[Sharing AMIs]. Additionally, explore adversarial techniques related to data exfiltration via AMI sharing as documented by Stratus Red Team https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.ec2-share-ami/[here]. + + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" and event.provider: "ec2.amazonaws.com" + and event.action: ModifyImageAttribute and event.outcome: success + and aws.cloudtrail.request_parameters: *add=* + and not aws.cloudtrail.user_identity.invoked_by: "assets.marketplace.amazonaws.com" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-ec2-deprecated-ami-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-ec2-deprecated-ami-discovery.asciidoc new file mode 100644 index 0000000000..716fddc8ff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-ec2-deprecated-ami-discovery.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-18-9-aws-ec2-deprecated-ami-discovery]] +=== AWS EC2 Deprecated AMI Discovery + +Identifies when a user has queried for deprecated Amazon Machine Images (AMIs) in AWS. This may indicate an adversary looking for outdated AMIs that may be vulnerable to exploitation. While deprecated AMIs are not inherently malicious or indicative of a breach, they may be more susceptible to vulnerabilities and should be investigated for potential security risks. + +*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/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: AWS EC2 +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Discovery + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Deprecated AMI Discovery* + + +This rule detects when a user queries AWS for deprecated Amazon Machine Images (AMIs). While deprecated AMIs are not inherently malicious, their use can introduce vulnerabilities or misconfigurations. Adversaries may exploit deprecated AMIs in search of outdated or unpatched systems. Investigating these queries can help identify potential risks or misconfigurations. + + +*Possible Investigation Steps* + + +1. **Identify the User Performing the Query**: + - Review the `aws.cloudtrail.user_identity.arn` field to determine the AWS user or role making the request. + - Check `aws.cloudtrail.user_identity.type` and `aws.cloudtrail.user_identity.access_key_id` to verify the type of access (e.g., IAM user, role, or federated identity). + +2. **Analyze the Source of the Request**: + - Review the `source.ip` field to determine the IP address of the source making the request. + - Check `source.geo` for the geographic location of the IP address. + - Analyze the `user_agent.original` field to determine the client or tool used (e.g., AWS CLI, SDK). + +3. **Validate the Query Context**: + - Inspect the `aws.cloudtrail.request_parameters` field + - Determine if the request is part of legitimate activity, such as: + - Security assessments or vulnerability scans. + - Maintenance or testing of legacy systems. + - Check if the query aligns with recent changes in the AWS environment, such as new configurations or services. + +4. **Correlate with Other Events**: + - Investigate additional AWS API calls from the same user or IP address for signs of reconnaissance or exploitation. + - Review logs for related actions, such as launching instances from deprecated AMIs (`RunInstances` API call). + +5. **Assess Security Risks**: + - Evaluate the use of deprecated AMIs within your environment and their associated vulnerabilities. + - Ensure that deprecated AMIs are not being used in production environments or systems exposed to external threats. + + +*False Positive Analysis* + + +- **Legitimate Use**: Users may query for deprecated AMIs for testing or compatibility purposes. +- **Automated Tools**: Security or compliance tools might query deprecated AMIs as part of regular assessments. +- **Misconfigured Services**: Legacy systems may rely on deprecated AMIs for compatibility, leading to legitimate queries. + + +*Response and Remediation* + + +1. **Immediate Actions**: + - Verify the intent of the user querying for deprecated AMIs. + - Restrict IAM permissions to prevent unauthorized access to deprecated AMIs. + +2. **Mitigation Steps**: + - Identify and replace deprecated AMIs in use with supported and updated AMIs. + - Update AWS IAM policies to minimize permissions for querying or using deprecated AMIs. + +3. **Enhance Monitoring**: + - Enable alerts for future queries involving deprecated AMIs or other unusual API activity. + - Monitor CloudTrail logs for additional reconnaissance or suspicious behavior. + +4. **Security Audits**: + - Conduct a review of all AMIs in use across your environment to identify outdated or deprecated images. + - Remove any deprecated AMIs from production environments and restrict their usage to isolated testing. + +5. **Add Rule Exceptions**: + - Create exceptions for legitimate use cases or automated tools that query for deprecated AMIs. + - Document and communicate the exceptions to relevant teams to avoid future alerts. + + +*Additional Resources* + + +- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html[AWS Documentation: AMI Lifecycle Management] +- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-deprecate.html[AWS Documentation: Deprecated AMIs] + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "ec2.amazonaws.com" + and event.action: "DescribeImages" + and event.outcome: "success" + and aws.cloudtrail.flattened.request_parameters.includeDeprecated: "true" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-ec2-security-group-configuration-change.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-ec2-security-group-configuration-change.asciidoc new file mode 100644 index 0000000000..c890ed4595 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-ec2-security-group-configuration-change.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-18-9-aws-ec2-security-group-configuration-change]] +=== AWS EC2 Security Group Configuration Change + +Identifies a change to an AWS Security Group Configuration. A security group is like a virtual firewall, and modifying configurations may allow unauthorized access. Threat actors may abuse this to establish persistence, exfiltrate data, or pivot in an AWS environment. + +*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://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-security-groups.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Use Case: Network Security Monitoring +* Resources: Investigation Guide +* Tactic: Persistence +* Tactic: Defense Evasion + +*Version*: 211 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS EC2 Security Group Configuration Change* + + +This rule identifies any changes to an AWS Security Group, which functions as a virtual firewall controlling inbound and outbound traffic for resources like EC2 instances. Modifications to a security group configuration could expose critical assets to unauthorized access. Threat actors may exploit such changes to establish persistence, exfiltrate data, or pivot within an AWS environment. + + +*Possible Investigation Steps* + + +1. **Identify the Modified Security Group**: + - **Security Group ID**: Check the `aws.cloudtrail.request_parameters` field to identify the specific security group affected. + - **Rule Changes**: Review `aws.cloudtrail.response_elements` to determine the new rules or configurations, including any added or removed IP ranges, protocol changes, and port specifications. + +2. **Review User Context**: + - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine which user or role made the modification. Verify if this is an authorized administrator or a potentially compromised account. + - **Access Patterns**: Analyze whether this user regularly interacts with security group configurations or if this event is out of the ordinary for their account. + +3. **Analyze the Configuration Change**: + - **Egress vs. Ingress**: Determine if the change affected inbound (ingress) or outbound (egress) traffic by reviewing fields like `isEgress` in the `securityGroupRuleSet`. Unauthorized changes to outbound traffic can indicate data exfiltration attempts. + - **IP Ranges and Ports**: Assess any added IP ranges, especially `0.0.0.0/0`, which exposes resources to the internet. Port changes should also be evaluated to ensure only necessary ports are open. + +4. **Check User Agent and Source IP**: + - **User Agent Analysis**: Examine the `user_agent.original` field to identify the tool or application used, such as `AWS Console` or `Terraform`, which may reveal if the action was automated or manual. + - **Source IP and Geolocation**: Use `source.address` and `source.geo` fields to verify if the IP address and geolocation match expected locations for your organization. Unexpected IPs or regions may indicate unauthorized access. + +5. **Evaluate for Persistence Indicators**: + - **Repeated Changes**: Investigate if similar changes were recently made across multiple security groups, which may suggest an attempt to maintain or expand access. + - **Permissions Review**: Confirm that the user’s IAM policies are configured to limit changes to security groups only as necessary. + +6. **Correlate with Other CloudTrail Events**: + - **Cross-Reference Other Security Events**: Look for related actions like `AuthorizeSecurityGroupIngress`, `CreateSecurityGroup`, or `RevokeSecurityGroupIngress` that may indicate additional or preparatory steps for unauthorized access. + - **Monitor for IAM or Network Changes**: Check for IAM modifications, network interface changes, or other configuration updates in the same timeframe to detect broader malicious activities. + + +*False Positive Analysis* + + +- **Routine Security Changes**: Security group modifications may be part of regular infrastructure maintenance. Verify if this action aligns with known, scheduled administrative activities. +- **Automated Configuration Management**: If you are using automated tools like `Terraform` or `CloudFormation`, confirm if the change matches expected configuration drift corrections or deployments. + + +*Response and Remediation* + + +- **Revert Unauthorized Changes**: If unauthorized, revert the security group configuration to its previous state to secure the environment. +- **Restrict Security Group Permissions**: Remove permissions to modify security groups from any compromised or unnecessary accounts to limit future access. +- **Quarantine Affected Resources**: If necessary, isolate any affected instances or resources to prevent further unauthorized activity. +- **Audit IAM and Security Group Policies**: Regularly review permissions related to security groups to ensure least privilege access and prevent excessive access. + + +*Additional Information* + + +For more details on managing AWS Security Groups and best practices, refer to the https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-security-groups.html[AWS EC2 Security Groups Documentation] and AWS security best practices. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "ec2.amazonaws.com" and event.outcome: "success" + and (event.action:( + "AuthorizeSecurityGroupIngress" or + "AuthorizeSecurityGroupEgress" or + "CreateSecurityGroup" or + "ModifySecurityGroupRules" or + "RevokeSecurityGroupEgress" or + "RevokeSecurityGroupIngress") or + (event.action: "ModifyInstanceAttribute" and aws.cloudtrail.flattened.request_parameters.groupSet.items.groupId:*)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-ec2-user-data-retrieval-for-ec2-instance.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-ec2-user-data-retrieval-for-ec2-instance.asciidoc new file mode 100644 index 0000000000..7794416863 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-ec2-user-data-retrieval-for-ec2-instance.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-18-9-aws-ec2-user-data-retrieval-for-ec2-instance]] +=== AWS EC2 User Data Retrieval for EC2 Instance + +Identifies discovery request DescribeInstanceAttribute with the attribute userData and instanceId in AWS CloudTrail logs. This may indicate an attempt to retrieve user data from an EC2 instance. Adversaries may use this information to gather sensitive data from the instance such as hardcoded credentials or to identify potential vulnerabilities. This is a New Terms rule that identifies the first time an IAM user or role requests the user data for a specific EC2 instance. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceAttribute.html +* https://hackingthe.cloud/aws/exploitation/local_ec2_priv_esc_through_user_data + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: Amazon EC2 +* Resources: Investigation Guide +* Use Case: Log Auditing +* Tactic: Discovery + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS EC2 User Data Retrieval for EC2 Instance* + + +This rule detects requests to retrieve the `userData` attribute of an EC2 instance using the `DescribeInstanceAttribute` API action. The `userData` field can contain sensitive information, such as hardcoded credentials or configuration scripts, that adversaries may exploit for further attacks. + + +*Possible Investigation Steps* + + +- **Identify the Target Instance**: + - **Instance ID**: Review the `aws.cloudtrail.flattened.request_parameters.instanceId` field to identify the EC2 instance targeted by the request. Confirm whether this instance should expose its `userData` and whether it is associated with sensitive workloads. + - **Analyze userData**: If possible, retrieve and inspect the `userData` field to identify sensitive information like hardcoded credentials or configuration scripts. + +- **Review User Context**: + - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to identify the user or role that executed the `DescribeInstanceAttribute` action. Investigate whether this user typically performs such actions. + - **Access Patterns**: Validate whether the user or role has the necessary permissions and whether the frequency of this action aligns with expected behavior. + - **Access Key ID**: Check the `aws.cloudtrail.user_identity.access_key_id` field to determine the key used to make the request as it may be compromised. + - **Source IP and Geolocation**: Check the `source.address` and `source.geo` fields to validate whether the request originated from a trusted location or network. Unexpected geolocations can indicate adversarial activity. + - **User Agent**: Inspect the `user_agent.original` field to determine the tool or client used (e.g., Terraform, AWS CLI). Legitimate automation tools may trigger this activity, but custom or unknown user agents may indicate malicious intent. + +- **Check for Related Activity**: + - **IAM Changes**: Correlate this event with any IAM changes or temporary credential creation to identify potential privilege escalation attempts. + - **API Usage**: Look for other unusual API calls (e.g., `RunInstances`, `GetObject`, `AssumeRole`) by the same user or IP to detect lateral movement or data exfiltration attempts. + +- **Validate Intent**: + - **Permissions and Justification**: Ensure that the user has the least privilege required to perform this action. Investigate whether there is a valid reason for accessing the `userData` field. + + +*False Positive Analysis* + + +- **Automation**: This event is often triggered by legitimate automation tools, such as Terraform or custom scripts, that require access to `userData` during instance initialization. +- **Maintenance Activity**: Verify whether this event aligns with expected administrative activities, such as debugging or instance configuration updates. + + +*Response and Remediation* + + +- **Revoke Excessive Permissions**: If unauthorized, immediately remove `DescribeInstanceAttribute` permissions from the user or role. +- **Quarantine the Target Instance**: If malicious behavior is confirmed, isolate the affected EC2 instance to limit further exposure. +- **Secure User Data**: + - Avoid storing sensitive information, such as credentials, in `userData`. Use AWS Secrets Manager or Parameter Store instead. + - Encrypt user data and ensure only authorized users can decrypt it. +- **Audit IAM Policies**: Regularly review IAM policies to ensure they adhere to the principle of least privilege. +- **Monitor and Detect**: Set up additional alerts for unexpected `DescribeInstanceAttribute` calls or other suspicious API activity. + + +*Additional Information* + + +For more details on managing EC2 user data securely, refer to the https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html[AWS EC2 User Data Documentation]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "ec2.amazonaws.com" + and event.action: "DescribeInstanceAttribute" + and event.outcome: "success" + and aws.cloudtrail.flattened.request_parameters.attribute: "userData" + and not aws.cloudtrail.user_identity.invoked_by: ( + "AWS Internal" or + "cloudformation.amazonaws.com" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-administratoraccess-policy-attached-to-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-administratoraccess-policy-attached-to-group.asciidoc new file mode 100644 index 0000000000..3136dd3c22 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-administratoraccess-policy-attached-to-group.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-18-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*: 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://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*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*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`. + + + +*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. + + +*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. + + +*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). + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* metadata _id, _version, _index +| where event.provider == "iam.amazonaws.com" and event.action == "AttachGroupPolicy" and event.outcome == "success" +| dissect aws.cloudtrail.request_parameters "{%{?policyArn}=%{?arn}:%{?aws}:%{?iam}::%{?aws}:%{?policy}/%{policyName},%{?groupName}=%{group.name}}" +| where policyName == "AdministratorAccess" +| keep @timestamp, event.provider, event.action, event.outcome, policyName, group.name + +---------------------------------- + +*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-18-9/prebuilt-rule-8-18-9-aws-iam-administratoraccess-policy-attached-to-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-administratoraccess-policy-attached-to-role.asciidoc new file mode 100644 index 0000000000..0fe9739146 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-administratoraccess-policy-attached-to-role.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-18-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*: 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://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*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*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`. + + + +*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. + + +*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. + + +*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). + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* metadata _id, _version, _index +| where event.provider == "iam.amazonaws.com" and event.action == "AttachRolePolicy" and event.outcome == "success" +| dissect aws.cloudtrail.request_parameters "{%{?policyArn}=%{?arn}:%{?aws}:%{?iam}::%{?aws}:%{?policy}/%{policyName},%{?roleName}=%{role.name}}" +| where policyName == "AdministratorAccess" +| keep @timestamp, event.provider, event.action, event.outcome, policyName, role.name + +---------------------------------- + +*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-18-9/prebuilt-rule-8-18-9-aws-iam-administratoraccess-policy-attached-to-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-administratoraccess-policy-attached-to-user.asciidoc new file mode 100644 index 0000000000..710fc3db5f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-administratoraccess-policy-attached-to-user.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-18-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*: 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://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*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*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`. + + + +*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. + + +*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. + + +*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). + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* metadata _id, _version, _index +| where event.provider == "iam.amazonaws.com" and event.action == "AttachUserPolicy" and event.outcome == "success" +| dissect aws.cloudtrail.request_parameters "{%{?policyArn}=%{?arn}:%{?aws}:%{?iam}::%{?aws}:%{?policy}/%{policyName},%{?userName}=%{target.userName}}" +| where policyName == "AdministratorAccess" +| keep + @timestamp, + cloud.region, + event.provider, + event.action, + event.outcome, + policyName, + target.userName, + aws.cloudtrail.request_parameters, + aws.cloudtrail.user_identity.arn, + related.user, + user_agent.original, + user.name, + source.address + +---------------------------------- + +*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-18-9/prebuilt-rule-8-18-9-aws-iam-api-calls-via-temporary-session-tokens.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-api-calls-via-temporary-session-tokens.asciidoc new file mode 100644 index 0000000000..1588999dbc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-api-calls-via-temporary-session-tokens.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-18-9-aws-iam-api-calls-via-temporary-session-tokens]] +=== AWS IAM API Calls via Temporary Session Tokens + +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. + +*Rule type*: new_terms + +*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://www.sygnia.co/blog/sygnia-investigation-bybit-hack/ + +*Tags*: + +* 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 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM API Calls via Temporary Session Tokens* + + +This rule detects sensitive IAM API operations performed using temporary AWS credentials (session tokens starting with 'ASIA'). These are short-lived credentials commonly obtained via sts:GetSessionToken, sts:AssumeRole, or AWS SSO login. While temporary credentials are often used for development and automation, they are rarely associated with direct IAM manipulation and may indicate credential theft, privilege escalation, or abuse of developer access. + + +*Possible investigation steps:* + + +- Review `aws.cloudtrail.user_identity.arn` to determine which IAM user or assumed role initiated the request. +- Check `aws.cloudtrail.user_identity.access_key_id` to confirm if the credential starts with 'ASIA', indicating a temporary session token. +- Examine `aws.cloudtrail.user_identity.session_context.mfa_authenticated` to verify whether MFA was present during session creation. +- Investigate `source.ip` to assess whether the request originated from a known network, office IP, or corporate VPN. +- Look at `user_agent.original` to determine if the API call came from a known CLI version or unexpected tool (e.g., unknown SDK, custom script). +- Confirm whether a recent sts:GetSessionToken, sts:AssumeRole, or AWS SSO login event issued the temporary credential. +- Correlate other events using the same access key ID to identify additional privileged actions, such as iam:CreateAccessKey, iam:PutUserPolicy, or iam:EnableMFADevice. +- Analyze timing via @timestamp to determine if the action occurred during off-hours or deviates from normal user behavior. +- Review the `event.outcome` to check if the API call was successful or failed, which may indicate unauthorized access attempts. +- Check for related events in the same session, such as iam:CreateUser, iam:AttachUserPolicy, or sts:GetCallerIdentity, to identify potential lateral movement or privilege escalation. + + +*False positive analysis:* + + +- Determine if the IAM user or automation pipeline routinely performs privileged actions using temporary session tokens. +- Validate whether the MFA context and source IP match expected developer or CI/CD behavior. +- Review recent IAM policy changes or deployments that may explain the behavior. +- Confirm if the user has a legitimate reason to perform sensitive IAM operations with temporary credentials, such as during a deployment or maintenance window. + + +*Response and remediation:* + + +- Revoke the temporary session token and rotate long-term access keys for the associated user if the behavior is unauthorized. +- Audit related CloudTrail events within the same session to identify policy changes, resource creation, or lateral movement. +- Add explicit deny statements in IAM policies to prevent sensitive IAM actions when aws:authType is not "console". +- Implement IP restrictions for IAM and STS API actions using aws:SourceIp conditions. +- Strengthen monitoring for IAM activity initiated by session tokens with MFA to improve detection coverage. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: aws.cloudtrail + and event.provider: ("iam.amazonaws.com") + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: "IAMUser" + and aws.cloudtrail.user_identity.access_key_id: ASIA* + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-assume-role-policy-update.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-assume-role-policy-update.asciidoc new file mode 100644 index 0000000000..129bba5d2f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-assume-role-policy-update.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-18-9-aws-iam-assume-role-policy-update]] +=== AWS IAM Assume Role Policy Update + +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. + +*Rule type*: new_terms + +*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://labs.bishopfox.com/tech-blog/5-privesc-attack-vectors-in-aws + +*Tags*: + +* 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 + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Assume Role Policy Update* + + +An IAM role is an IAM identity that you can create in your account that has specific permissions. An IAM role is similar to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session. + +The role trust policy is a JSON document in which you define the principals you trust to assume the role. This policy is a required resource-based policy that is attached to a role in IAM. An attacker may attempt to modify this policy by using the `UpdateAssumeRolePolicy` API action to gain the privileges of that role. + + +*Possible investigation steps* + + +- Review the `aws.cloudtrail.user_identity.arn` to determine the IAM User that performed the action. +- If an AssumedRole identity type performed the action review the `aws.cloudtrail.user_identity.session_context.session_issuer.arn` field to determine which role was used. +- Review the `target.entity.id` field to confirm the role that was updated. +- Within the `aws.cloudtrail.request_parameters` field, review the `policyDocument` to understand the changes made to the trust policy. +- If `aws.cloudtrail.user_identity.access_key_id` is present, investigate the access key used to perform the action as it may be compromised. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account and resource owners and confirm whether they are aware of this activity. +- Check if this operation was approved and performed according to the organization's change management policy. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- False positives may occur due to the intended usage of the service. Tuning is needed in order to have higher confidence. Consider adding exceptions — preferably with a combination of the user agent and user ID conditions — to cover administrator activities and infrastructure as code tooling. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Use AWS https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-versioning.html[policy versioning] to restore the trust policy to the desired state. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- 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. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "UpdateAssumeRolePolicy" + and event.outcome: "success" + and not source.address: "cloudformation.amazonaws.com" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-customer-managed-policy-attached-to-role-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-customer-managed-policy-attached-to-role-by-rare-user.asciidoc new file mode 100644 index 0000000000..d6305016cb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-customer-managed-policy-attached-to-role-by-rare-user.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-18-9-aws-iam-customer-managed-policy-attached-to-role-by-rare-user]] +=== AWS IAM Customer-Managed Policy Attached to Role by Rare User + +Detects when an AWS Identity and Access Management (IAM) customer-managed policy is attached to a role by an unusual or unauthorized user. Customer-managed policies are policies created and controlled within an AWS account, granting specific permissions to roles or users when attached. This rule identifies potential privilege escalation by flagging cases where a customer-managed policy is attached to a role by an unexpected actor, which could signal unauthorized access or misuse. Attackers may attach policies to roles to expand permissions and elevate their privileges within the AWS environment. This is a New Terms rule that uses the "cloud.account.id", "user.name" and "target.entity.id" fields to check if the combination of the actor identity and target role name has not been seen before. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Resources: Investigation Guide +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Customer-Managed Policy Attached to Role by Rare User* + + +This rule detects when a customer-managed IAM policy is attached to a role by an unusual or unauthorized user. This activity may indicate a potential privilege escalation attempt within the AWS environment. Adversaries could attach policies to roles to expand permissions, thereby increasing their capabilities and achieving elevated access. + + +*Possible Investigation Steps* + + +- **Identify the Initiating User and Target Role**: + - **User Identity**: Examine the `aws.cloudtrail.user_identity.arn` field to determine the user who initiated the policy attachment. Confirm if this user typically has permissions to modify IAM roles and if their activity is consistent with their usual responsibilities. + - **Target Role**: Review `target.entity.id` to identify the role to which the policy was attached. Assess whether modifying this role is expected for this user or if this action is unusual in your environment. + +- **Analyze the Attached Policy**: + - **Policy ARN**: Inspect the `aws.cloudtrail.request_parameters` field to identify the specific customer-managed policy attached to the role. Evaluate if this policy grants sensitive permissions, especially permissions that could enable privileged actions or data access. + - **Policy Permissions**: Examine the policy content to determine the scope of permissions granted. Policies enabling actions like `s3:*`, `ec2:*`, or `iam:*` could be leveraged for broader access, persistence, or lateral movement. + +- **Review Source and User Agent Details**: + - **Source IP and Location**: Analyze the `source.ip` and `source.geo` fields to confirm the IP address and geographic location where the policy attachment originated. Verify if this matches expected locations for the initiating user. + - **User Agent Analysis**: Examine `user_agent.original` to determine if AWS CLI, SDK, or other tooling was used to perform this action. Tool identifiers like `aws-cli` or `boto3` may indicate automation, while others may suggest interactive sessions. + +- **Evaluate Anomalous Behavior Patterns**: + - **User’s Historical Activity**: Check if the initiating user has a history of attaching policies to roles. An unusual pattern in policy attachments could indicate suspicious behavior, especially if the user lacks authorization. + - **Role Modification History**: Investigate if the targeted role is frequently modified by this or other users. Repeated, unauthorized modifications to a role could signal an attempt to maintain elevated access. + +- **Correlate with Related CloudTrail Events**: + - **Other IAM or CloudTrail Activities**: Look for recent actions associated with the same user or role by reviewing `event.action` and `event.provider` to identify which AWS services were accessed. This may provide context on the user’s intent or additional actions taken. + - **Broader Suspicious Patterns**: Identify if similar anomalous events have recently occurred, potentially suggesting a coordinated or escalating attack pattern within the AWS account. + + +*False Positive Analysis* + + +- **Authorized Administrative Actions**: IAM administrators may legitimately attach policies to roles as part of routine role management. Verify if the user is authorized and if the activity aligns with expected administrative tasks. +- **Role-Specific Modifications**: Roles that frequently undergo policy updates may trigger this rule during standard operations. Consider monitoring for patterns or establishing known exceptions for specific users or roles where appropriate. + + +*Response and Remediation* + + +- **Immediate Access Review**: If the policy attachment is unauthorized, consider detaching the policy and reviewing the permissions granted to the initiating user. +- **Restrict Role Modification Permissions**: Limit which users or roles can attach policies to critical IAM roles. Apply least privilege principles to reduce the risk of unauthorized policy changes. +- **Enhance Monitoring and Alerts**: Enable real-time alerts and monitoring on IAM policy modifications to detect similar actions promptly. +- **Regular Policy Audits**: Conduct periodic audits of IAM policies and role permissions to ensure that unauthorized changes are quickly identified and addressed. + + +*Additional Information* + + +For more information on managing IAM policies and roles in AWS environments, refer to the https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html[AWS IAM Documentation] and AWS security best practices. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "AttachRolePolicy" + and event.outcome: "success" + and not related.entity: arn\:aws\:iam\:\:aws\:policy* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Temporary Elevated Cloud Access +** ID: T1548.005 +** Reference URL: https://attack.mitre.org/techniques/T1548/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-user-created-access-keys-for-another-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-user-created-access-keys-for-another-user.asciidoc new file mode 100644 index 0000000000..ed08334b4e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-iam-user-created-access-keys-for-another-user.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-18-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*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*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. + + + +*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. + + +*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. + + +*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). + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* metadata _id, _version, _index +| where event.provider == "iam.amazonaws.com" + and event.action == "CreateAccessKey" + and event.outcome == "success" + and user.name != user.target.name +| keep + @timestamp, + cloud.region, + event.provider, + event.action, + event.outcome, + user.name, + source.address, + user.target.name, + user_agent.original, + aws.cloudtrail.request_parameters, + aws.cloudtrail.response_elements, + aws.cloudtrail.user_identity.arn, + aws.cloudtrail.user_identity.type + +---------------------------------- + +*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-18-9/prebuilt-rule-8-18-9-aws-s3-object-encryption-using-external-kms-key.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-s3-object-encryption-using-external-kms-key.asciidoc new file mode 100644 index 0000000000..b66ed5416e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-s3-object-encryption-using-external-kms-key.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-18-9-aws-s3-object-encryption-using-external-kms-key]] +=== AWS S3 Object Encryption Using External KMS Key + +Identifies `CopyObject` events within an S3 bucket using an AWS KMS key from an external account for encryption. Adversaries with access to a misconfigured S3 bucket and the proper permissions may encrypt objects with an external KMS key to deny their victims access to their own data. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html/ +* https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html/ +* https://www.gem.security/post/cloud-ransomware-a-new-take-on-an-old-attack-pattern/ +* https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Data Source: AWS KMS +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Object Encryption Using External KMS Key* + + +This rule detects the use of an external AWS KMS key to encrypt objects within an S3 bucket. Adversaries with access to a misconfigured S3 bucket may use an external key to copy objects within a bucket and deny victims the ability to access their own data. +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 `CopyObject` operation where the target bucket's `cloud.account.id` is different from the `key.account.id` dissected from the AWS KMS key used for encryption. + + +*Possible Investigation Steps:* + + +- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who performed the action. Verify if this actor typically performs such actions and if they have the necessary permissions. +- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific details of the `CopyObject` action. Look for any unusual parameters that could suggest unauthorized or malicious modifications or usage of an unknown KMS keyId. +- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access. +- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the object was copied. Changes during non-business hours or outside regular maintenance windows might require further scrutiny. +- **Correlate with Other Activities**: Search for related CloudTrail events before and after this action to see if the same actor or IP address engaged in other potentially suspicious activities. +- **Check for Object Deletion or Access**: Look for `DeleteObject`, `DeleteObjects`, or `GetObject` API calls to the same S3 bucket that may indicate the adversary accessing and destroying objects including older object versions. +- **Interview Relevant Personnel**: If the copy event was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing S3 buckets. + + +*False Positive Analysis:* + + +- **Legitimate Administrative Actions**: Confirm if the `CopyObject` action aligns with scheduled updates, maintenance activities, or legitimate administrative tasks documented in change management systems. +- **Consistency Check**: Compare the action against historical data of similar activities performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm. + + +*Response and Remediation:* + + +- **Immediate Review**: If the activity was unauthorized, search for potential ransom note placed in S3 bucket and review the bucket's access logs for any suspicious activity. +- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar `CopyObject` actions, especially those involving sensitive data or unusual file extensions. +- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning S3 bucket management and the risks of ransomware. +- **Audit S3 Bucket Policies and Permissions**: Conduct a comprehensive audit of all S3 bucket policies and associated permissions to ensure they adhere to the principle of least privilege. +- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences. + + +*Additional Information:* + + +For further guidance on managing S3 bucket security and protecting against ransomware, refer to the https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html[AWS S3 documentation] and AWS best practices for security. Additionally, consult the following resources for specific details on S3 ransomware protection: +- https://s3.amazonaws.com/bizzabo.file.upload/PtZzA0eFQwV2RA5ysNeo_ERMETIC%20REPORT%20-%20AWS%20S3%20Ransomware%20Exposure%20in%20the%20Wild.pdf[ERMETIC REPORT - AWS S3 Ransomware Exposure in the Wild] +- https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/[S3 Ransomware Part 1: Attack Vector] + + +==== Setup + + +AWS S3 data event types need to be enabled in the CloudTrail trail configuration. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* metadata _id, _version, _index + +// any successful copy event +| where event.dataset == "aws.cloudtrail" + and event.provider == "s3.amazonaws.com" + and event.action == "CopyObject" + and event.outcome == "success" + +// abstract key account id, key id, encrypted object bucket name and object name +| dissect aws.cloudtrail.request_parameters "{%{?bucketName}=%{target.bucketName},%{?x-amz-server-side-encryption-aws-kms-key-id}=%{?arn}:%{?aws}:%{?kms}:%{?region}:%{key.account.id}:%{?key}/%{keyId},%{?Host}=%{?tls.client.server_name},%{?x-amz-server-side-encryption}=%{?server-side-encryption},%{?x-amz-copy-source}=%{?bucket.objectName},%{?key}=%{target.objectName}}" + +// filter for s3 objects whose account id is different from the encryption key's account id +// add exceptions based on key.account.id or keyId for known external accounts or encryption keys +| where cloud.account.id != key.account.id + +// keep relevant fields +| keep @timestamp, aws.cloudtrail.user_identity.arn, cloud.account.id, event.action, target.bucketName, key.account.id, keyId, target.objectName + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-ssm-sendcommand-execution-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-ssm-sendcommand-execution-by-rare-user.asciidoc new file mode 100644 index 0000000000..b0d71a9e63 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-ssm-sendcommand-execution-by-rare-user.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-18-9-aws-ssm-sendcommand-execution-by-rare-user]] +=== AWS SSM `SendCommand` Execution by Rare User + +Detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM), such as RunShellScript, RunPowerShellScript or custom documents. While legitimate users may employ these commands for management tasks, they can also be exploited by attackers with credentials to establish persistence, install malware, or execute reverse shells for further access to compromised instances. This is a New Terms rule that looks for the first instance of this behavior by a user or role. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS SSM +* Data Source: AWS Systems Manager +* Use Case: Log Auditing +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SSM `SendCommand` Execution by Rare User* + + +This rule detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM) by an unexpected or new user. The SSM `SendCommand` action can enable remote command execution, which adversaries may exploit to install backdoors, deploy malware, or interact with compromised instances through reverse shells. + + +*Possible Investigation Steps* + + +- **Identify the Target Instance**: + - **Instance ID**: Review the `aws.cloudtrail.request_parameters` field to identify which EC2 instances were targeted by this command. Confirm if these instances are expected to be managed through SSM. + - **Document Used**: Check the `aws.cloudtrail.request_parameters` field, which specifies the name of the document or script being executed. Commands such as `RunShellScript` or `RunPowerShellScript` can indicate interactive sessions or script-based interactions. + +- **Review User Context**: + - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine the user or role executing the `SendCommand`. If this user is not typically involved in EC2 or SSM interactions, this could indicate unauthorized access. + - **Access Patterns**: Validate whether the user typically has permissions to perform `SendCommand` operations on instances and whether the frequency of this action matches expected behavior. + +- **Analyze Command Parameters**: + - **Document Contents**: While the exact command may not be visible in CloudTrail, use logs to determine the purpose of the script, especially if the document name suggests encryption, data transfer, or reverse shell capabilities. + - **Timing and Context**: Compare this command execution with other recent SSM actions in your environment. A single `SendCommand` event by an unusual user can indicate an early stage of a larger attack. + +- **Check User Agent and Source IP**: + - **User Agent Analysis**: Review the `user_agent.original` field to verify the tool or client used (e.g., `aws-cli`). This can provide insight into whether this action was automated, scripted, or executed manually. + - **Source IP and Geolocation**: Use `source.ip` and `source.geo` fields to check if the IP address and geolocation align with expected regions for your organization. Unusual IP addresses or locations can indicate external adversaries. + +- **Evaluate for Persistence Indicators**: + - **Command Consistency**: Investigate if this action is part of a recurring pattern, such as repeated command executions across instances, which may suggest an attempt to maintain access. + - **Permissions**: Ensure that the IAM policies associated with the user limit `SendCommand` actions to necessary use cases. Consider adding alerts for commands executed by users with minimal roles or permissions. + +- **Correlate with Other CloudTrail Events**: + - **Cross-Reference SSM Actions**: Look for other recent SSM actions like `CreateDocument`, `UpdateDocument`, or additional `SendCommand` events that could indicate preparation for further exploitation. + - **Monitor Data Access or Modification**: Correlate with S3 access patterns, IAM changes, or EC2 modifications in recent events to detect broader malicious activities. + + +*False Positive Analysis* + + +- **Routine Automation**: SSM `SendCommand` may be used by automation scripts or management tools. Verify if this event aligns with known, routine automated workflows. +- **Maintenance Activity**: Confirm if legitimate administrative activities, such as patching or updates, are expected at this time, which may involve similar commands executed on multiple instances. + + +*Response and Remediation* + + +- **Limit SSM Permissions**: If unauthorized, immediately revoke `SendCommand` permissions from the user or role to prevent further access. +- **Quarantine Target Instance**: If malicious behavior is confirmed, isolate the affected EC2 instance(s) to limit lateral movement or data exfiltration. +- **Investigate and Contain User Account**: If the action was performed by a compromised account, review recent activity and reset access credentials as necessary. +- **Audit SSM and IAM Configurations**: Periodically review permissions associated with SSM usage and ensure least privilege access principles are in place. + + +*Additional Information* + + +For further details on managing AWS SSM and security best practices for EC2 instances, refer to the https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html[AWS Systems Manager Documentation] and AWS best practices. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "ssm.amazonaws.com" + and event.action: "SendCommand" + and event.outcome: "success" + and not source.address: ( + "ssm-guiconnect.amazonaws.com" or + "ssm.amazonaws.com" or + "inspector2.amazonaws.com" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-systems-manager-securestring-parameter-request-with-decryption-flag.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-systems-manager-securestring-parameter-request-with-decryption-flag.asciidoc new file mode 100644 index 0000000000..e773390fc7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-aws-systems-manager-securestring-parameter-request-with-decryption-flag.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-18-9-aws-systems-manager-securestring-parameter-request-with-decryption-flag]] +=== AWS Systems Manager SecureString Parameter Request with Decryption Flag + +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. + +*Rule type*: new_terms + +*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/vsts/latest/userguide/systemsmanager-getparameter.html +* https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Systems Manager +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Systems Manager SecureString Parameter Request with Decryption Flag* + + +This rule detects when an AWS resource accesses SecureString parameters within AWS Systems Manager (SSM) with the decryption flag set to true. SecureStrings are encrypted using a KMS key, and accessing these with decryption can indicate attempts to access sensitive data. + +Adversaries may target SecureStrings to retrieve sensitive information such as encryption keys, passwords, and other credentials that are stored securely. Accessing these parameters with decryption enabled is particularly concerning because it implies the adversary is attempting to bypass the encryption to obtain plain text values that can be immediately used or exfiltrated. This behavior might be part of a larger attack strategy aimed at escalating privileges or moving laterally within an environment to access protected data or critical infrastructure. + + +*Possible Investigation Steps* + + +- **Review the Access Event**: Identify the specific API call (`GetParameter` or `GetParameters`) that triggered the rule. Examine the `request_parameters` for `withDecryption` set to true and the name of the accessed parameter. +- **Verify User Identity and Access Context**: Check the `aws.cloudtrail.user_identity` details to understand who accessed the parameter and their role within the organization. This includes checking the ARN and access key ID to determine if the access was authorized. + - **User ID**: Review the `user.name` field to identify the specific user or role that initiated the API call. Note that the ARN associated may be an assumed role and may not directly correspond to a human user. +- **Contextualize with User Behavior**: Assess whether the access pattern fits the user’s normal behavior or job responsibilities. Investigate any out-of-pattern activities around the time of the event. +- **Analyze Geographic and IP Context**: Using the `source.ip` and `source.geo` information, verify if the request came from a trusted location or if there are any anomalies that suggest a compromised account. +- **Inspect Related CloudTrail Events**: Look for other related events in CloudTrail to see if there was unusual activity before or after this event, such as unusual login attempts, changes to permissions, or other API calls that could indicate broader unauthorized actions. + + +*False Positive Analysis* + + +- **Legitimate Administrative Use**: Verify if the decryption of SecureString parameters is a common practice for the user’s role, particularly if used in automation scripts or deployment processes like those involving Terraform or similar tools. +- **Authorized Access**: Ensure that the user or role has a legitimate reason to access the SecureString parameters and that the access is part of their expected job responsibilities. + + +*Response and Remediation* + + +- **Immediate Verification**: Contact the user or team responsible for the API call to verify their intent and authorization. +- **Review and Revise Permissions**: If the access was unauthorized, review the permissions assigned to the user or role to ensure they align with the principle of least privilege. +- **Audit Parameter Access Policies**: Ensure that policies governing access to SecureString parameters are strict and audit logs are enabled to track access with decryption. +- **Incident Response**: If suspicious activity is confirmed, follow through with your organization's incident response plan to mitigate any potential security issues. +- **Enhanced Monitoring and Alerting**: Strengthen monitoring rules to detect unusual accesses to SecureString parameters, especially those that involve decryption. + + +*Additional Information* + + +This rule focuses solely on SecureStrings in AWS Systems Manager (SSM) parameters. SecureStrings are encrypted using an AWS Key Management Service (KMS) key. When a user accesses a SecureString parameter, they can specify whether the parameter should be decrypted. If the user specifies that the parameter should be decrypted, the decrypted value is returned in the response. + + +==== Setup + + +This rule requires that AWS CloudTrail logs are ingested into the Elastic Stack. Ensure that the AWS integration is properly configured to collect AWS CloudTrail logs. This rule also requires event logging for AWS Systems Manager (SSM) API actions which can be enabled in CloudTrail's data events settings. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: aws.cloudtrail + and event.provider: "ssm.amazonaws.com" + and event.action: (GetParameters or GetParameter) + and event.outcome: success + and aws.cloudtrail.flattened.request_parameters.withDecryption: true + and not source.address: ( + "cloudformation.amazonaws.com" or + "servicecatalog.amazonaws.com" + ) + +---------------------------------- + +*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-18-9/prebuilt-rule-8-18-9-azure-key-vault-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-azure-key-vault-modified.asciidoc new file mode 100644 index 0000000000..350177071c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-azure-key-vault-modified.asciidoc @@ -0,0 +1,106 @@ +[[prebuilt-rule-8-18-9-azure-key-vault-modified]] +=== Azure Key Vault Modified + +Identifies modifications to a Key Vault in Azure. The Key Vault is a service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. Because this data is sensitive and business critical, access to key vaults should be secured to allow only authorized applications and users. This is a New Terms rule that detects when this activity hasn't been seen by the user in a specified time frame. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.activitylogs-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/key-vault/general/basic-concepts +* https://docs.microsoft.com/en-us/azure/key-vault/general/secure-your-key-vault +* https://learn.microsoft.com/en-us/azure/key-vault/general/security-features + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Azure Activity Logs +* Tactic: Impact +* Use Case: Configuration Audit +* Resources: Investigation Guide + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Key Vault Modified* + + +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 modifications to Key Vaults, which may indicate potential security incidents or misconfigurations. + + +*Possible investigation steps* + +- Review the `azure.activitylogs.operation_name` field to identify the specific operation performed on the Key Vault. Common operations include `Microsoft.KeyVault/vaults/write` for modifications and `Microsoft.KeyVault/vaults/delete` for deletions. +- Check the `event.outcome` field to confirm the success of the operation. A successful outcome indicates that the modification or deletion was completed. +- Investigate the `azure.activitylogs.identity.principal_id` or `azure.activitylogs.identity.principal_name` fields to determine the user or service principal that performed the operation. This can help identify whether the action was authorized or potentially malicious. +- Analyze the `azure.activitylogs.resource_id` field to identify the specific Key Vault that was modified. This can help assess the impact of the change and whether it affects critical resources or applications. +- Cross-reference the time of the modification with other security events or alerts in the environment to identify any patterns or related activities that may indicate a coordinated attack or misconfiguration. +- Consult with relevant stakeholders or system owners to verify if the modification was planned or expected, and gather additional context if necessary. + + +*False positive analysis* + +- Routine maintenance activities by administrators can trigger alerts when they modify or delete Key Vaults. To manage this, create exceptions for known maintenance windows or specific administrator accounts. +- Automated scripts or tools used for Key Vault management might perform frequent updates or deletions, leading to false positives. Identify these scripts and exclude their operations from triggering alerts by using specific identifiers or tags. +- Changes made by authorized third-party services or integrations that manage Key Vault configurations can also result in false positives. Review and whitelist these services to prevent unnecessary alerts. +- Regular updates or deployments in a development or testing environment may cause alerts. Consider excluding these environments from monitoring or adjusting the rule to focus on production environments only. +- Temporary changes for troubleshooting or testing purposes might be flagged. Document these activities and use temporary exceptions to avoid false positives during these periods. + + +*Response and remediation* + +- Immediately isolate the affected Key Vault to prevent further unauthorized access or changes. +- Review the Azure activity logs to identify the specific operations performed on the Key Vault and their outcomes. +- Collaborate with security teams to assess the impact of the modifications and determine if any sensitive data was compromised. +- If unauthorized changes are confirmed, initiate incident response procedures, including notifying affected parties and conducting a thorough investigation. +- Implement additional monitoring and alerting for the affected Key Vault to detect any further suspicious activity. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "azure.activitylogs" + and azure.activitylogs.operation_name: MICROSOFT.KEYVAULT/VAULTS/* + and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-azure-key-vault-secret-key-usage-by-unusual-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-azure-key-vault-secret-key-usage-by-unusual-identity.asciidoc new file mode 100644 index 0000000000..cccfef62fb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-azure-key-vault-secret-key-usage-by-unusual-identity.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-18-9-azure-key-vault-secret-key-usage-by-unusual-identity]] +=== Azure Key Vault Secret Key Usage by Unusual Identity + +Identifies secrets, keys, or certificates retrieval operations from Azure Key Vault by a user principal that has not been seen previously doing so in a certain amount of days. Azure Key Vault is a cloud service for securely storing and accessing secrets, keys, and certificates. Unauthorized or excessive retrievals may indicate potential abuse or unauthorized access attempts. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.platformlogs-* + +*Severity*: medium + +*Risk score*: 43 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.inversecos.com/2022/05/detection-and-compromise-azure-key.html + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Domain: Identity +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Azure Key Vault +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Key Vault Secret Key Usage by Unusual Identity* + + +Azure Key Vault is a cloud service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. It is crucial for managing sensitive data in Azure environments. Unauthorized modifications to Key Vaults can lead to data breaches or service disruptions. This rule detects excessive secret or key retrieval operations from Azure Key Vault, which may indicate potential abuse or unauthorized access attempts. + + +*Possible investigation steps* + +- Review the `azure.platformlogs.identity.claim.upn` field to identify the user principal making the retrieval requests. This can help determine if the activity is legitimate or suspicious. +- Check the `azure.platformlogs.identity.claim.appid` or `azure.platformlogs.identity.claim.appid_display_name` to identify the application or service making the requests. If the application is not recognized or authorized, it may indicate a potential security incident. It is plausible that the application is a FOCI compliant application, which are commonly abused by adversaries to evade security controls or conditional access policies. +- Analyze the `azure.platformlogs.resource.name` field to determine which Key Vault is being accessed. This can help assess the impact of the retrieval operations and whether they target sensitive resources. +- Review the `event.action` field to confirm the specific actions being performed, such as `KeyGet`, `SecretGet`, or `CertificateGet`. These actions indicate retrieval of keys, secrets, or certificates from the Key Vault. +- Check the `source.ip` or `geo.*` fields to identify the source of the retrieval requests. Look for unusual or unexpected IP addresses, especially those associated with known malicious activity or geographic locations that do not align with the user's typical behavior. +- Use the `time_window` field to analyze the frequency of retrieval operations. If multiple retrievals occur within a short time frame (e.g., within a few minutes), it may indicate excessive or suspicious activity. +- Correlate the retrieval operations with other security events or alerts in the environment to identify any patterns or related incidents. +- Triage the user with Entra ID sign-in logs to gather more context about their authentication behavior and any potential anomalies. + + +*False positive analysis* + +- Routine administrative tasks or automated scripts may trigger excessive retrievals, especially in environments where Key Vaults are heavily utilized for application configurations or secrets management. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. +- Legitimate applications or services may perform frequent retrievals of keys or secrets for operational purposes, such as configuration updates or secret rotation. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. +- Security teams may perform periodic audits or assessments that involve retrieving keys or secrets from Key Vaults. If this is expected behavior, consider adjusting the rule or adding exceptions for specific user principals or applications. +- Some applications may require frequent access to keys or secrets for normal operation, leading to high retrieval counts. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. + + +*Response and remediation* + +- Investigate the user principal making the excessive retrieval requests to determine if they are authorized to access the Key Vault and its contents. If the user is not authorized, take appropriate actions to block their access and prevent further unauthorized retrievals. +- Review the application or service making the requests to ensure it is legitimate and authorized to access the Key Vault. If the application is unauthorized or suspicious, consider blocking it and revoking its permissions to access the Key Vault. +- Assess the impact of the excessive retrieval operations on the Key Vault and its contents. Determine if any sensitive data was accessed or compromised during the retrievals. +- Implement additional monitoring and alerting for the Key Vault to detect any further suspicious activity or unauthorized access attempts. +- Consider implementing stricter access controls or policies for Key Vaults to limit excessive retrievals and ensure that only authorized users and applications can access sensitive keys and secrets. +- Educate users and administrators about the risks associated with excessive retrievals from Key Vaults and encourage them to follow best practices for managing keys and secrets in Azure environments. + + +==== Setup + + + +*Required Azure Key Vault Diagnostic Logs* + + +To ensure this rule functions correctly, the following diagnostic logs must be enabled for Azure Key Vault: +- AuditEvent: This log captures all read and write operations performed on the Key Vault, including secret, key, and certificate retrievals. These logs should be streamed to the Event Hub used for the Azure integration configuration. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset : "azure.platformlogs" and +event.outcome: "success" and +event.action : ( + "VaultGet" or + "KeyGet" or + "KeyList" or + "KeyListVersions" or + "KeyGetDeleted" or + "KeyListDeleted" or + "SecretGet" or + "SecretList" or + "SecretListVersions" or + "SecretGetDeleted" or + "SecretListDeleted" or + "CertificateGet" or + "CertificateList" or + "CertificateListVersions" or + "CertificateGetDeleted" or + "CertificateListDeleted" or + "CertificatePolicyGet" or + "CertificateContactsGet" or + "CertificateIssuerGet" or + "CertificateIssuersList" +) and azure.platformlogs.identity.claim.upn: * and azure.platformlogs.properties.id: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Cloud Secrets Management Stores +** ID: T1555.006 +** Reference URL: https://attack.mitre.org/techniques/T1555/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-excessive-aws-s3-object-encryption-with-sse-c.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-excessive-aws-s3-object-encryption-with-sse-c.asciidoc new file mode 100644 index 0000000000..0d5f0df258 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-excessive-aws-s3-object-encryption-with-sse-c.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-18-9-excessive-aws-s3-object-encryption-with-sse-c]] +=== Excessive AWS S3 Object Encryption with SSE-C + +Identifies a high-volume of AWS S3 objects stored in a bucket using using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a Threshold rule that triggers when this behavior is observed multiple times for a specific bucket in a short time-window. + +*Rule type*: threshold + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.halcyon.ai/blog/abusing-aws-native-services-ransomware-encrypting-s3-buckets-with-sse-c +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Impact + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating Excessive AWS S3 Object Encryption with SSE-C* + +This rule identifies a high volume of objects being encrypted using Server-Side Encryption with Customer-Provided Keys (SSE-C) in AWS S3. This could indicate malicious activity, such as ransomware encrypting objects, rendering them inaccessible without the corresponding encryption keys. + + +*Possible Investigation Steps* + + +1. **Identify the User and Source**: + - Review the `aws.cloudtrail.user_identity.arn` to identify the IAM user or role performing the operation. + - Cross-check the `source.ip` and `user_agent.original` fields for unusual IPs or user agents that could indicate unauthorized access. + - Review the `aws.cloudtrail.user_identity.access_key_id` to identify the access key used. This could be a compromised key. + +2. **Examine the Targeted Resources**: + - Check `aws.cloudtrail.request_parameters` to identify the bucket involved. + - Analyze the object key from `aws.cloudtrail.request_parameters`. + +3. **Evaluate Encryption Behavior**: + - Confirm the encryption details in `aws.cloudtrail.request_parameters` and `aws.cloudtrail.additional_eventdata`. + - Note if `SSEApplied` is `SSE-C`, which confirms encryption using a customer-provided key. + +4. **Correlate with Recent Events**: + - Look for any suspicious activity in proximity to the encryption event, such as new access key creation, policy changes, or unusual access patterns from the same user or IP. + - Identify `ListBucket` or `GetObject` operations on the same bucket to determine all affected objects. + - For `PutObject` events, identify any other unusual objecs uploaded such as a ransom note. + +5. **Validate Access Permissions**: + - Check the IAM policies and roles associated with the user to verify if they had legitimate access to encrypt objects. + +6. **Assess Impact**: + - Identify the number of encrypted objects in the bucket by examining other similar events. + - Determine if this encryption aligns with standard business practices or constitutes a deviation. + + +*False Positive Analysis* + + +- **Legitimate Use Cases**: + - Confirm if SSE-C encryption is part of regular operations for compliance or data protection. + - Cross-reference known processes or users authorized for SSE-C encryption in the affected bucket. + + +*Response and Remediation* + + +1. **Immediate Actions**: + - Disable access keys or permissions for the user if unauthorized behavior is confirmed. + - Rotate the bucket's encryption configuration to mitigate further misuse. + +2. **Data Recovery**: + - Attempt to identify and contact the party holding the SSE-C encryption keys if recovery is necessary. + +3. **Enhance Monitoring**: + - Enable alerts for future SSE-C encryption attempts in critical buckets. + - Review and tighten IAM policies for roles and users accessing S3. + +4. **Post-Incident Review**: + - Audit logs for additional activities by the same user or IP. + - Document findings and apply lessons learned to improve preventive measures. + + +==== Setup + + +AWS S3 data event types need to be enabled in the CloudTrail trail configuration. + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "s3.amazonaws.com" + and event.action: "PutObject" + and event.outcome: "success" + and aws.cloudtrail.flattened.request_parameters.x-amz-server-side-encryption-customer-algorithm: "AES256" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-excessive-secret-or-key-retrieval-from-azure-key-vault.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-excessive-secret-or-key-retrieval-from-azure-key-vault.asciidoc new file mode 100644 index 0000000000..7470c79f95 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-excessive-secret-or-key-retrieval-from-azure-key-vault.asciidoc @@ -0,0 +1,208 @@ +[[prebuilt-rule-8-18-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*: 1 + +*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 `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.azure.platformlogs.identity.claim.upn.values = VALUES(azure.platformlogs.identity.claim.upn), + Esql.azure.platformlogs.identity.claim.upn.count_unique = COUNT_DISTINCT(azure.platformlogs.identity.claim.upn), + Esql.azure.platformlogs.identity.claim.appid.values = VALUES(azure.platformlogs.identity.claim.appid), + Esql.azure.platformlogs.identity.claim.objectid.values = VALUES(azure.platformlogs.identity.claim.objectid), + + 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.network.as_org.values = VALUES(source.as.organization.name), + + Esql.event.actions.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.azure.platformlogs.identity.claim.upn.values, + Esql.azure.platformlogs.identity.claim.upn.count_unique, + Esql.azure.platformlogs.identity.claim.appid.values, + Esql.azure.platformlogs.identity.claim.objectid.values, + Esql.source.ip.values, + Esql.geo.city.values, + Esql.geo.region.values, + Esql.geo.country.values, + Esql.network.as_org.values, + Esql.event.actions.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_unique == 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-18-9/prebuilt-rule-8-18-9-external-authentication-method-addition-or-modification-in-entra-id.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-external-authentication-method-addition-or-modification-in-entra-id.asciidoc new file mode 100644 index 0000000000..10470de532 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-external-authentication-method-addition-or-modification-in-entra-id.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-18-9-external-authentication-method-addition-or-modification-in-entra-id]] +=== External Authentication Method Addition or Modification in Entra ID + +Identifies when an external authentication method (EAM) is added or modified in Entra ID. EAM may allow adversaries to bypass multi-factor authentication (MFA) requirements, potentially leading to unauthorized access to user accounts and sensitive resources by using bring-your-own IdP (BYOIDP) methods. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.graphactivitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://dirkjanm.io/persisting-with-federated-credentials-entra-apps-managed-identities/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Graph +* Data Source: Microsoft Graph Activity Logs +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating External Authentication Method Addition or Modification in Entra ID* + + +This rule detects suspicious modifications to external authentication methods (EAMs) in Microsoft Entra ID via Microsoft Graph API. Adversaries may abuse this capability to bypass multi-factor authentication (MFA), enabling persistence or unauthorized access through bring-your-own identity provider (BYOIDP) methods. + + +*Possible investigation steps* + +- Validate that `event.action` is `"Microsoft Graph Activity"` and that `http.request.method` is `"PATCH"`, indicating a configuration change was made. +- Confirm that `url.path` contains the string `authenticationMethodsPolicy`, which is associated with external authentication settings in Entra ID. +- Review `user.id` to identify the Azure AD object ID of the user or service principal that initiated the change. +- Examine `azure.graphactivitylogs.properties.app_id` to determine the application ID that performed the action. +- Analyze `azure.graphactivitylogs.properties.scopes[]` to assess whether the request used privileged scopes such as `AuthenticationMethod.ReadWrite.All`. +- Review the geographic origin of the request using `source.geo.*` and the `source.ip` field to identify anomalous locations. +- Examine `user_agent.original` to determine whether the request was made through a browser or automation (e.g., scripted activity). +- Correlate `azure.graphactivitylogs.properties.token_issued_at` and `azure.graphactivitylogs.properties.time_generated` to assess whether the change occurred shortly after token issuance. +- Investigate additional activity by the same `user.id` or `app_id` within a short timeframe (e.g., 30 minutes) to detect related suspicious behavior. +- Use the `operation_id` or `correlation_id` to pivot across related Graph API or Entra ID activity logs, if available. + + +*False positive analysis* + +- Legitimate administrative activity may trigger this rule, such as configuring FIDO2 or enabling passwordless sign-in methods during onboarding or security upgrades. +- Some enterprise integrations or federated identity providers may programmatically update EAM settings as part of legitimate operations. +- Routine security assessments or red team exercises may include changes to authentication policies. Validate with internal teams when in doubt. +- If appropriate, filter or suppress alerts originating from known trusted service principals or administrative accounts. + + +*Response and remediation* + +- Confirm whether the user or application that made the change was authorized to do so. If not, immediately revoke access and reset credentials as needed. +- Review the application or automation that triggered the change to ensure it is legitimate. If unauthorized, disable or remove it and rotate secrets or tokens it may have accessed. +- Audit current external authentication configurations and conditional access policies to ensure no persistent backdoors were introduced. +- Revoke session tokens associated with the change using Entra ID's portal or Microsoft Graph API, and enforce reauthentication where appropriate. +- Implement stricter RBAC or conditional access policies to prevent unauthorized EAM changes in the future. +- Monitor for repeat or similar activity from the same source or identity as part of an ongoing compromise assessment. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: azure.graphactivitylogs and + url.path: *authenticationMethodsPolicy* and + http.request.method: "PATCH" and + http.response.status_code: 200 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Conditional Access Policies +** ID: T1556.009 +** Reference URL: https://attack.mitre.org/techniques/T1556/009/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-high-number-of-egress-network-connections-from-unusual-executable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-high-number-of-egress-network-connections-from-unusual-executable.asciidoc new file mode 100644 index 0000000000..9df54d5ced --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-high-number-of-egress-network-connections-from-unusual-executable.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-18-9-high-number-of-egress-network-connections-from-unusual-executable]] +=== High Number of Egress Network Connections from Unusual Executable + +This rule detects a high number of egress network connections from an unusual executable on a Linux system. This could indicate a command and control (C2) communication attempt, a brute force attack via a malware infection, or other malicious activity. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-61m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating High Number of Egress Network Connections from Unusual Executable* + + +In Linux environments, executables can initiate network connections for legitimate purposes. However, adversaries exploit this by deploying malware in temporary directories to establish command and control (C2) channels. The detection rule identifies unusual executables making numerous outbound connections, excluding trusted IP ranges and known benign paths, to flag potential threats. + + +*Possible investigation steps* + + +- Review the process.executable field to identify the specific executable making the connections and determine if it is known or expected in the environment. +- Examine the destination.ip field to identify the external IP addresses the executable is attempting to connect to and check if they are known malicious or suspicious. +- Check the host.os.type and agent.id fields to identify the specific host and agent involved, and gather additional context about the system's role and recent activity. +- Analyze the @timestamp field to correlate the timing of the connections with other events or activities on the network or host. +- Cross-reference the identified executable and IP addresses with threat intelligence sources to determine if they are associated with known threats or campaigns. +- If the executable is determined to be malicious or suspicious, isolate the affected host and perform a deeper forensic analysis to identify any additional indicators of compromise or lateral movement. + + +*False positive analysis* + + +- Executables in temporary directories used by legitimate applications or scripts can trigger alerts. Review the process name and executable path to determine if they are associated with known applications or scripts. +- Automated scripts or cron jobs that perform network operations might be flagged. Identify these scripts and consider excluding their paths from the rule if they are verified as non-malicious. +- Development or testing environments often use temporary directories for network operations. If these environments are known and trusted, add their specific paths to the exclusion list. +- Backup or synchronization tools that use temporary directories for data transfer can generate numerous connections. Verify these tools and exclude their paths if they are confirmed to be safe. +- Security tools or monitoring agents that operate in temporary directories might be mistakenly flagged. Confirm their legitimacy and exclude their paths to prevent false positives. + + +*Response and remediation* + + +- Isolate the affected host immediately from the network to prevent further potential malicious communication and lateral movement. +- Terminate the suspicious process identified by the alert to stop any ongoing malicious activity. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise (IOCs) and assess the extent of the infection. +- Remove any malicious executables or files found in temporary directories such as /tmp, /var/tmp, or /dev/shm to eliminate the threat. +- Patch and update the affected system to the latest security standards to close any vulnerabilities that may have been exploited. +- Monitor network traffic for any unusual outbound connections from other systems to detect potential spread or similar threats. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation. + + +==== 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] +---------------------------------- +from logs-endpoint.events.network-* +| keep @timestamp, host.os.type, event.type, event.action, process.name, process.executable, destination.ip, agent.id, host.name +| where @timestamp > now() - 1 hours +| where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and ( + ( + process.executable like "/tmp/*" or + process.executable like "/var/tmp/*" or + process.executable like "/dev/shm/*" + ) or + (process.name like ".*") +) and not ( + CIDR_MATCH( + destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", + "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", + "224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "224.0.0.0/4", "240.0.0.0/4", "::1", + "FE80::/10", "FF00::/8" + ) or + process.executable like "/nix/store/*" or + process.executable like "/tmp/newroot/*" or + process.executable like "/tmp/.mount*" or + process.executable like "/tmp/go-build*" + ) +| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable +| where agent_count == 1 and cc > 15 +| sort cc asc +| limit 100 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-high-number-of-okta-device-token-cookies-generated-for-authentication.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-high-number-of-okta-device-token-cookies-generated-for-authentication.asciidoc new file mode 100644 index 0000000000..19924bdae2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-high-number-of-okta-device-token-cookies-generated-for-authentication.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-18-9-high-number-of-okta-device-token-cookies-generated-for-authentication]] +=== High Number of Okta Device Token Cookies Generated for Authentication + +Detects when an Okta client address has a certain threshold of Okta user authentication events with multiple device token hashes generated for single user authentication. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/ +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 205 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating High Number of Okta Device Token Cookies Generated for Authentication* + + +This rule detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack. + + +*Possible investigation steps:* + +- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.client.ip` values can be used to pivot into the raw authentication events related to this activity. +- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields. +- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields. +- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy. + - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying. +- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful. + - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context. +- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field. + - Historical analysis should indicate if this device token hash is commonly associated with the user. +- Review the `okta.event_type` field to determine the type of authentication event that occurred. + - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons. + - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying. + - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API. +- Examine the `okta.outcome.result` field to determine if the authentication was successful. +- Review the past activities of the actor(s) involved in this action by checking their previous actions. +- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity. + - This may help determine the authentication and authorization actions that occurred between the user, Okta and application. + + +*False positive analysis:* + +- A user may have legitimately started a session via a proxy for security or privacy reasons. +- Users may share an endpoint related to work or personal use in which separate Okta accounts are used. + - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons. + - Shared systems such as Kiosks and conference room computers may be used by multiple users. + - Shared working spaces may have a single endpoint that is used by multiple users. + + +*Response and remediation:* + +- Review the profile of the users involved in this action to determine if proxy usage may be expected. +- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required. +- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA). + - If MFA is already enabled, consider resetting MFA for the users. +- If any of the users are not legitimate, consider deactivating the user's account. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user. + - If so, confirm with the user this was a legitimate request. + - If so and this was not a legitimate request, consider deactivating the user's account temporarily. + - Reset passwords and reset MFA for the user. +- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule. + - This will prevent future occurrences of this event for this device from triggering the rule. + - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule. + - This should be done with caution as it may prevent legitimate alerts from being generated. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta* +| WHERE + event.dataset == "okta.system" + AND (event.action RLIKE "user\\.authentication(.*)" OR event.action == "user.session.start") + AND okta.debug_context.debug_data.request_uri == "/api/v1/authn" + AND okta.outcome.reason == "INVALID_CREDENTIALS" +| KEEP event.action, okta.debug_context.debug_data.dt_hash, okta.client.ip, okta.actor.alternate_id, okta.debug_context.debug_data.request_uri, okta.outcome.reason +| STATS + source_auth_count = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash) + BY okta.client.ip, okta.actor.alternate_id +| WHERE + source_auth_count >= 30 +| SORT + source_auth_count DESC + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-insecure-aws-ec2-vpc-security-group-ingress-rule-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-insecure-aws-ec2-vpc-security-group-ingress-rule-added.asciidoc new file mode 100644 index 0000000000..a485fb4b06 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-insecure-aws-ec2-vpc-security-group-ingress-rule-added.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-18-9-insecure-aws-ec2-vpc-security-group-ingress-rule-added]] +=== Insecure AWS EC2 VPC Security Group Ingress Rule Added + +Identifies when a specified inbound (ingress) rule is added or adjusted for a VPC security group in AWS EC2. This rule detects when a security group rule is added that allows traffic from any IP address or from a specific IP address to common remote access ports, such as 22 (SSH) or 3389 (RDP). Adversaries may add these rules to allow remote access to VPC instances from any location, increasing the attack surface and potentially exposing the instances to unauthorized access. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AuthorizeSecurityGroupEgress.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AuthorizeSecurityGroupIngress.html +* https://www.linkedin.com/pulse/my-backdoors-your-aws-infrastructure-part-3-network-micha%C5%82-brygidyn/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Insecure AWS EC2 VPC Security Group Ingress Rule Added* + + +This rule detects the addition of ingress rules to a VPC security group that allow traffic from any IP address (`0.0.0.0/0` or `::/0`) to sensitive ports commonly used for remote access, such as SSH (port 22) and RDP (port 3389). This configuration change can significantly increase the exposure of EC2 instances to potential threats, making it crucial to understand the context and legitimacy of such changes. + + +*Possible Investigation Steps:* + + +- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Investigate whether this actor has the necessary permissions and typically performs these actions. +- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand exactly what changes were made to the security group. Check for any unusual parameters that could suggest a misconfiguration or malicious intent. +- **Analyze the Source of the Request**: Look at the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unusual location could indicate compromised credentials. +- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the change occurred. Modifications outside of typical business hours might warrant additional scrutiny. +- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor engaged in other potentially suspicious activities. + + +*False Positive Analysis:* + + +- **Legitimate Administrative Actions**: Verify if the ingress rule change aligns with scheduled updates, maintenance activities, or legitimate administrative tasks documented in change management tickets or systems. +- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. Consistency with past legitimate actions might indicate a false alarm. +- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the change was successful and intended as per policy. + + +*Response and Remediation:* + + +- **Immediate Review and Reversal if Necessary**: If the change was unauthorized, revert the security group rules to their previous state to close any unintended access. +- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar security group changes, especially those that open access to well-known ports from any IP address. +- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning security group management. +- **Audit Security Groups and Policies**: Conduct a comprehensive audit of all security groups and associated policies to ensure they adhere to the principle of least privilege. +- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences. + + +*Additional Information:* + + +For further guidance on managing security group rules and securing AWS environments, refer to the https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html[Amazon VPC Security Groups documentation] and AWS best practices for security. + + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: ec2.amazonaws.com + and event.action: AuthorizeSecurityGroupIngress + and event.outcome: success + and aws.cloudtrail.flattened.request_parameters.ipPermissions.items.ipRanges.items.cidrIp: ("0.0.0.0/0" or "::/0") + and aws.cloudtrail.flattened.request_parameters.ipPermissions.items.fromPort: ( + 21 or 22 or 23 or 445 or 3389 or 5985 or 5986) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-kubernetes-unusual-decision-by-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-kubernetes-unusual-decision-by-user-agent.asciidoc new file mode 100644 index 0000000000..13e36a08b8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-kubernetes-unusual-decision-by-user-agent.asciidoc @@ -0,0 +1,105 @@ +[[prebuilt-rule-8-18-9-kubernetes-unusual-decision-by-user-agent]] +=== Kubernetes Unusual Decision by User Agent + +This rule detects unusual request responses in Kubernetes audit logs through the use of the "new_terms" rule type. In production environments, default API requests are typically made by system components or trusted users, who are expected to have a consistent user agent and allowed response annotations. By monitoring for anomalies in the username and response annotations, this rule helps identify potential unauthorized access or misconfigurations in the Kubernetes environment. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Kubernetes +* Domain: Container +* Use Case: Threat Detection +* Data Source: Kubernetes +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Unusual Decision by User Agent* + + +Kubernetes orchestrates containerized applications, relying on API requests for operations. Typically, these requests originate from system components or trusted users with consistent user agents. Adversaries might exploit this by using atypical user agents to mask unauthorized access or misconfigurations. The detection rule identifies anomalies in user agents and response annotations, signaling potential threats in the Kubernetes environment. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs for entries where the user_agent.original field is present to identify any unusual or unexpected user agents. +- Cross-reference the identified user agents with known system components and trusted users to determine if the user agent is legitimate or potentially malicious. +- Examine the kubernetes.audit.stage field for "ResponseComplete" entries to understand the context and outcome of the requests associated with the unusual user agent. +- Investigate the source IP addresses and associated usernames in the audit logs to identify any patterns or anomalies that could indicate unauthorized access. +- Check for any recent changes or deployments in the Kubernetes environment that might explain the presence of unusual user agents or unexpected behavior. +- Assess the risk and impact of the detected anomaly by considering the sensitivity of the accessed resources and the permissions associated with the user account involved. + + +*False positive analysis* + + +- System components or trusted users with legitimate but infrequent user agents may trigger the rule. To manage this, identify these user agents and add them to an exception list to prevent unnecessary alerts. +- Automated scripts or tools used for maintenance or monitoring might use unique user agents. Regularly review these tools and update the exception list to include their user agents if they are verified as non-threatening. +- New deployments or updates to Kubernetes components can introduce new user agents temporarily. Monitor these changes and adjust the rule exceptions accordingly to accommodate expected behavior during these periods. +- Third-party integrations or plugins may use distinct user agents. Validate these integrations and, if deemed safe, include their user agents in the exception list to reduce false positives. + + +*Response and remediation* + + +- Immediately isolate the affected Kubernetes node or cluster to prevent further unauthorized access or potential lateral movement by the adversary. +- Review and terminate any suspicious or unauthorized sessions identified in the audit logs to cut off any active malicious activity. +- Revoke and rotate credentials associated with the compromised user agent to prevent further unauthorized access using the same credentials. +- Conduct a thorough review of the affected system's configurations and permissions to identify and rectify any misconfigurations or overly permissive access controls. +- Implement additional monitoring and logging for the affected systems to detect any further anomalies or unauthorized activities promptly. +- Escalate the incident to the security operations team for a comprehensive investigation and to determine if any data exfiltration or further compromise has occurred. +- Update and enhance detection rules and alerts to better identify similar anomalies in user agents and response annotations in the future, ensuring quicker response times. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:"linux" and event.dataset:"kubernetes.audit_logs" and kubernetes.audit.stage:"ResponseComplete" and user_agent.original:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-m365-onedrive-excessive-file-downloads-with-oauth-token.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-m365-onedrive-excessive-file-downloads-with-oauth-token.asciidoc new file mode 100644 index 0000000000..140773f5c8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-m365-onedrive-excessive-file-downloads-with-oauth-token.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-18-9-m365-onedrive-excessive-file-downloads-with-oauth-token]] +=== M365 OneDrive Excessive File Downloads with OAuth Token + +Identifies when an excessive number of files are downloaded from OneDrive using OAuth authentication. Adversaries may conduct phishing campaigns to steal OAuth tokens and impersonate users. These access tokens can then be used to download files from OneDrive. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: SharePoint +* Data Source: OneDrive +* Use Case: Threat Detection +* Tactic: Collection +* Tactic: Exfiltration +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 OneDrive Excessive File Downloads with OAuth Token* + + +This rule detects an excessive number of files downloaded from OneDrive using OAuth authentication. Threat actors may use OAuth phishing attacks, such as **Device Code Authentication phishing**, to obtain valid access tokens and perform unauthorized data exfiltration. This method allows adversaries to bypass traditional authentication mechanisms, making it a stealthy and effective technique. + +This rule leverages ESQL aggregations which limit the field values available in the alert document. To investigate further, it is recommended to identify the original documents ingested. + + +*Possible Investigation Steps* + + +- Review the `o365.audit.UserId` field to identify the user who performed the downloads. Check if this user typically downloads large amounts of data from OneDrive. +- Correlate `o365.audit.UserId` with Entra Sign-In logs to verify the authentication method used and determine if it was expected for this user. +- Review the authentication method used. If OAuth authentication was used, investigate whether it was expected for this user. +- Identify the client application used for authentication. Determine if it is a legitimate enterprise-approved app or an unauthorized third-party application. +- Check the number of unique files downloaded. If a user downloads a high volume of unique files in a short period, it may indicate data exfiltration. +- Analyze the file types and directories accessed to determine if sensitive or confidential data was involved. +- Investigate the source IP address and geolocation of the download activity. If it originates from an unusual or anonymized location, further scrutiny is needed. +- Review other recent activities from the same user, such as file access, sharing, or permission changes, that may indicate further compromise. +- Check for signs of session persistence using OAuth. If Azure sign-in logs are correlated where `authentication_protocol` or `originalTransferMethod` field shows `deviceCode`, the session was established through device code authentication. +- Look for multiple authentication attempts from different devices or locations within a short timeframe, which could indicate unauthorized access. +- Investigate if other OAuth-related anomalies exist, such as consent grants for unfamiliar applications or unexpected refresh token activity. +- Review the `file.directory` value from the original documents to identify the specific folders or paths where the files were downloaded. + + +*False Positive Analysis* + + +- Verify if the user regularly downloads large batches of files as part of their job function. +- Determine if the downloads were triggered by an authorized automated process, such as a data backup or synchronization tool. +- Confirm if the detected OAuth application is approved for enterprise use and aligns with expected usage patterns. + + +*Response and Remediation* + + +- If unauthorized activity is confirmed, revoke the OAuth token used and terminate active OneDrive sessions. +- Reset the affected user's password and require reauthentication to prevent continued unauthorized access. +- Restrict OAuth app permissions and enforce conditional access policies to limit authentication to trusted devices and applications. +- Monitor for additional signs of compromise, such as unusual email forwarding rules, external sharing of OneDrive files, or privilege escalation attempts. +- Educate users on OAuth phishing risks and encourage the use of **Microsoft Defender for Office 365 Safe Links** to mitigate credential-based attacks. +- Enable continuous monitoring for OAuth authentication anomalies using **Microsoft Entra ID sign-in logs** and security tools. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-o365.audit-* +| WHERE @timestamp > now() - 14 day +| WHERE + event.dataset == "o365.audit" and + + // filter on files downloaded from OneDrive + event.provider == "OneDrive" and + event.action == "FileDownloaded" and + + // filter on OAuth authentication which encompasses device code workflow + o365.audit.AuthenticationType == "OAuth" + and event.outcome == "success" +// bucket authentication attempts by 1 minute +| EVAL target_time_window = DATE_TRUNC(1 minutes, @timestamp) +| KEEP target_time_window, o365.audit.UserId, file.name, source.ip + +// aggregate on unique file names and download attempts +| STATS unique_file_count = count_distinct(file.name), download_attempt_count = count(*) BY target_time_window, o365.audit.UserId, source.ip + +// adjustable range for "excessive" unique files that were downloaded +| WHERE unique_file_count >= 25 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-microsoft-entra-id-session-reuse-with-suspicious-graph-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-microsoft-entra-id-session-reuse-with-suspicious-graph-access.asciidoc new file mode 100644 index 0000000000..2491bb7a2c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-microsoft-entra-id-session-reuse-with-suspicious-graph-access.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-18-9-microsoft-entra-id-session-reuse-with-suspicious-graph-access]] +=== Microsoft Entra ID Session Reuse with Suspicious Graph Access + +Identifies potential session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID within a short time window. This may indicate the use of a stolen refresh/access token or session cookie to impersonate the user and interact with Microsoft services. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-1h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://github.com/dirkjanm/ROADtools +* https://attack.mitre.org/techniques/T1078/004/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Data Source: Microsoft Graph +* Data Source: Microsoft Graph Activity Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Defense Evasion +* Tactic: Initial Access + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Entra ID Session Reuse with Suspicious Graph Access* + + +This rule identifies when Microsoft Graph is accessed from a different IP than the one used for the original sign-in, +but using the same session ID within 5 minutes. This may suggest an adversary has stolen a session cookie or refresh/access +token and is impersonating the user from an alternate host or location. + +This rule uses ESQL aggregations and thus has dynamically generated fields. Correlation of the values in the alert document may need to be +performed to the original sign-in and Graph events for further context. + + +*Investigation Steps* + + +- Review the `user_id`, `session_id`, and `source_ip_list`. Confirm whether both IPs belong to the same user and geography. +- Check for inconsistencies in `client_id_list` (e.g., unknown apps) or user agents across correlated events. +- Investigate recent phishing reports or device infections for the `user_id`. +- Pivot to Entra ID `auditlogs` to see if a device was registered or privileges were modified. +- Review `graph_time` to determine what action was taken after the sign-in. +- Use the `session_id` to correlate with other logs in the same time window to identify any additional suspicious activity. + + +*False Positive Analysis* + +- This pattern may occur if the user is switching between networks (e.g., corporate to mobile) or using a VPN. +- Developers or power users leveraging multiple environments may also trigger this detection if session persistence spans IP ranges. +- However, this behavior is rare and warrants investigation when rapid IP switching and Graph access are involved. +- If the user is a developer or automation engineer, validate if this behavior was for testing purposes. +- If the user is a system administrator, validate if this behavior was for administrative purposes. + + +*Response Recommendations* + + +- If confirmed malicious, revoke all refresh/access tokens for the `user_id`. +- Block the source IP(s) involved in the Graph access. +- Notify the user and reset credentials. +- Review session control policies and conditional access enforcement. +- Monitor for follow-on activity, such as lateral movement or privilege escalation. +- Review conditional access policies to ensure they are enforced correctly. + + +==== Setup + + + +*Required Microsoft Entra ID Sign-In and Graph Activity Logs* + +This rule requires the Microsoft Entra ID Sign-In Logs and Microsoft Graph Activity Logs integration to be enabled and configured to collect audit and activity logs via Azure Event Hub. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-azure.* +| WHERE + (event.dataset == "azure.signinlogs" AND source.`as`.organization.name != "MICROSOFT-CORP-MSN-AS-BLOCK" AND azure.signinlogs.properties.session_id IS NOT NULL) + OR + (event.dataset == "azure.graphactivitylogs" AND source.`as`.organization.name != "MICROSOFT-CORP-MSN-AS-BLOCK" AND azure.graphactivitylogs.properties.c_sid IS NOT NULL) +| EVAL + session_id = COALESCE(azure.signinlogs.properties.session_id, azure.graphactivitylogs.properties.c_sid), + user_id = COALESCE(azure.signinlogs.properties.user_id, azure.graphactivitylogs.properties.user_principal_object_id), + client_id = COALESCE(azure.signinlogs.properties.app_id, azure.graphactivitylogs.properties.app_id), + source_ip = source.ip, + event_time = @timestamp, + event_type = CASE( + event.dataset == "azure.signinlogs", "signin", + event.dataset == "azure.graphactivitylogs", "graph", + "other" + ), + time_window = DATE_TRUNC(5 minutes, @timestamp) +| KEEP session_id, source_ip, event_time, event_type, time_window, user_id, client_id +| STATS + user_id = VALUES(user_id), + session_id = VALUES(session_id), + source_ip_list = VALUES(source_ip), + source_ip_count = COUNT_DISTINCT(source_ip), + client_id_list = VALUES(client_id), + application_count = COUNT_DISTINCT(client_id), + event_type_list = VALUES(event_type), + event_type_count = COUNT_DISTINCT(event_type), + event_start = MIN(event_time), + event_end = MAX(event_time), + signin_time = MIN(CASE(event_type == "signin", event_time, NULL)), + graph_time = MIN(CASE(event_type == "graph", event_time, NULL)), + document_count = COUNT() + BY session_id, time_window +| EVAL + duration_minutes = DATE_DIFF("minutes", event_start, event_end), + signin_to_graph_delay_minutes = DATE_DIFF("minutes", signin_time, graph_time) +| WHERE + event_type_count > 1 AND + source_ip_count > 1 AND + duration_minutes <= 5 AND + signin_time IS NOT NULL AND + graph_time IS NOT NULL AND + signin_to_graph_delay_minutes >= 0 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-microsoft-entra-id-sign-in-brute-force-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-microsoft-entra-id-sign-in-brute-force-activity.asciidoc new file mode 100644 index 0000000000..90aba858a6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-microsoft-entra-id-sign-in-brute-force-activity.asciidoc @@ -0,0 +1,249 @@ +[[prebuilt-rule-8-18-9-microsoft-entra-id-sign-in-brute-force-activity]] +=== Microsoft Entra ID Sign-In Brute Force Activity + +Identifies potential brute-force attacks targeting user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to applications integrated with Entra ID or to compromise valid user accounts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 15m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign +* https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/ +* https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying +* https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray +* https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties +* https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/ +* https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes +* https://github.com/0xZDH/Omnispray +* https://github.com/0xZDH/o365spray + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Sign-in Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Entra ID Sign-In Brute Force Activity* + + +This rule detects brute-force authentication activity in Entra ID sign-in logs. It classifies failed sign-in attempts into behavior types such as password spraying, credential stuffing, or password guessing. The classification (`bf_type`) helps prioritize triage and incident response. + + +*Possible investigation steps* + + +- Review `bf_type`: Determines the brute-force technique being used (`password_spraying`, `credential_stuffing`, or `password_guessing`). +- Examine `user_id_list`: Identify if high-value accounts (e.g., administrators, service principals, federated identities) are being targeted. +- Review `login_errors`: Repetitive error types like `"Invalid Grant"` or `"User Not Found"` suggest automated attacks. +- Check `ip_list` and `source_orgs`: Investigate if the activity originates from suspicious infrastructure (VPNs, hosting providers, etc.). +- Validate `unique_ips` and `countries`: Geographic diversity and IP volume may indicate distributed or botnet-based attacks. +- Compare `total_attempts` vs `duration_seconds`: High rate of failures in a short time period implies automation. +- Analyze `user_agent.original` and `device_detail_browser`: User agents like `curl`, `Python`, or generic libraries may indicate scripting tools. +- Investigate `client_app_display_name` and `incoming_token_type`: Detect potential abuse of legacy or unattended login mechanisms. +- Inspect `target_resource_display_name`: Understand what application or resource the attacker is trying to access. +- Pivot using `session_id` and `device_detail_device_id`: Determine if a device is targeting multiple accounts. +- Review `conditional_access_status`: If not enforced, ensure Conditional Access policies are scoped correctly. + + +*False positive analysis* + + +- Legitimate automation (e.g., misconfigured scripts, sync processes) can trigger repeated failures. +- Internal red team activity or penetration tests may mimic brute-force behaviors. +- Certain service accounts or mobile clients may generate repetitive sign-in noise if not properly configured. + + +*Response and remediation* + + +- Notify your identity security team for further analysis. +- Investigate and lock or reset impacted accounts if compromise is suspected. +- Block offending IPs or ASNs at the firewall, proxy, or using Conditional Access. +- Confirm MFA and Conditional Access are enforced for all user types. +- Audit targeted accounts for credential reuse across services. +- Implement account lockout or throttling for failed sign-in attempts where possible. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-azure.signinlogs* + +// Define a time window for grouping and maintain the original event timestamp +| EVAL + time_window = DATE_TRUNC(15 minutes, @timestamp), + event_time = @timestamp + +// Filter relevant failed authentication events with specific error codes +| WHERE event.dataset == "azure.signinlogs" + AND event.category == "authentication" + AND azure.signinlogs.category IN ("NonInteractiveUserSignInLogs", "SignInLogs") + AND event.outcome == "failure" + AND azure.signinlogs.properties.authentication_requirement == "singleFactorAuthentication" + AND azure.signinlogs.properties.status.error_code IN ( + 50034, // UserAccountNotFound + 50126, // InvalidUsernameOrPassword + 50055, // PasswordExpired + 50056, // InvalidPassword + 50057, // UserDisabled + 50064, // CredentialValidationFailure + 50076, // MFARequiredButNotPassed + 50079, // MFARegistrationRequired + 50105, // EntitlementGrantsNotFound + 70000, // InvalidGrant + 70008, // ExpiredOrRevokedRefreshToken + 70043, // BadTokenDueToSignInFrequency + 80002, // OnPremisePasswordValidatorRequestTimedOut + 80005, // OnPremisePasswordValidatorUnpredictableWebException + 50144, // InvalidPasswordExpiredOnPremPassword + 50135, // PasswordChangeCompromisedPassword + 50142, // PasswordChangeRequiredConditionalAccess + 120000, // PasswordChangeIncorrectCurrentPassword + 120002, // PasswordChangeInvalidNewPasswordWeak + 120020 // PasswordChangeFailure + ) + AND azure.signinlogs.properties.user_principal_name IS NOT NULL AND azure.signinlogs.properties.user_principal_name != "" + AND user_agent.original != "Mozilla/5.0 (compatible; MSAL 1.0) PKeyAuth/1.0" + AND source.`as`.organization.name != "MICROSOFT-CORP-MSN-AS-BLOCK" + +// Aggregate statistics for behavioral pattern analysis +| STATS + authentication_requirement = VALUES(azure.signinlogs.properties.authentication_requirement), + client_app_id = VALUES(azure.signinlogs.properties.app_id), + client_app_display_name = VALUES(azure.signinlogs.properties.app_display_name), + target_resource_id = VALUES(azure.signinlogs.properties.resource_id), + target_resource_display_name = VALUES(azure.signinlogs.properties.resource_display_name), + conditional_access_status = VALUES(azure.signinlogs.properties.conditional_access_status), + device_detail_browser = VALUES(azure.signinlogs.properties.device_detail.browser), + device_detail_device_id = VALUES(azure.signinlogs.properties.device_detail.device_id), + device_detail_operating_system = VALUES(azure.signinlogs.properties.device_detail.operating_system), + incoming_token_type = VALUES(azure.signinlogs.properties.incoming_token_type), + risk_state = VALUES(azure.signinlogs.properties.risk_state), + session_id = VALUES(azure.signinlogs.properties.session_id), + user_id = VALUES(azure.signinlogs.properties.user_id), + user_principal_name = VALUES(azure.signinlogs.properties.user_principal_name), + result_description = VALUES(azure.signinlogs.result_description), + result_signature = VALUES(azure.signinlogs.result_signature), + result_type = VALUES(azure.signinlogs.result_type), + + unique_users = COUNT_DISTINCT(azure.signinlogs.properties.user_id), + user_id_list = VALUES(azure.signinlogs.properties.user_id), + login_errors = VALUES(azure.signinlogs.result_description), + unique_login_errors = COUNT_DISTINCT(azure.signinlogs.result_description), + error_codes = VALUES(azure.signinlogs.properties.status.error_code), + unique_error_codes = COUNT_DISTINCT(azure.signinlogs.properties.status.error_code), + request_types = VALUES(azure.signinlogs.properties.incoming_token_type), + app_names = VALUES(azure.signinlogs.properties.app_display_name), + ip_list = VALUES(source.ip), + unique_ips = COUNT_DISTINCT(source.ip), + source_orgs = VALUES(source.`as`.organization.name), + countries = VALUES(source.geo.country_name), + unique_country_count = COUNT_DISTINCT(source.geo.country_name), + unique_asn_orgs = COUNT_DISTINCT(source.`as`.organization.name), + first_seen = MIN(@timestamp), + last_seen = MAX(@timestamp), + total_attempts = COUNT() +BY time_window + +// Determine brute force behavior type based on statistical thresholds +| EVAL + duration_seconds = DATE_DIFF("seconds", first_seen, last_seen), + bf_type = CASE( + // Many users, relatively few distinct login errors, distributed over multiple IPs (but not too many), + // and happens quickly. Often bots using leaked credentials. + unique_users >= 10 AND total_attempts >= 30 AND unique_login_errors <= 3 + AND unique_ips >= 5 + AND duration_seconds <= 600 + AND unique_users > unique_ips, + "credential_stuffing", + + // One password against many users. Single error (e.g., "InvalidPassword"), not necessarily fast. + unique_users >= 15 AND unique_login_errors == 1 AND total_attempts >= 15 AND duration_seconds <= 1800, + "password_spraying", + + // One user targeted repeatedly (same error), OR extremely noisy pattern from many IPs. + (unique_users == 1 AND unique_login_errors == 1 AND total_attempts >= 30 AND duration_seconds <= 300) + OR (unique_users <= 3 AND unique_ips > 30 AND total_attempts >= 100), + "password_guessing", + + // everything else + "other" + ) + +// Only keep columns necessary for detection output/reporting +| KEEP + time_window, bf_type, duration_seconds, total_attempts, first_seen, last_seen, + unique_users, user_id_list, login_errors, unique_login_errors, + unique_error_codes, error_codes, request_types, app_names, + ip_list, unique_ips, source_orgs, countries, + unique_country_count, unique_asn_orgs, + authentication_requirement, client_app_id, client_app_display_name, + target_resource_id, target_resource_display_name, conditional_access_status, + device_detail_browser, device_detail_device_id, device_detail_operating_system, + incoming_token_type, risk_state, session_id, user_id, + user_principal_name, result_description, result_signature, result_type + +// Remove anything not classified as credential attack activity +| WHERE bf_type != "other" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-multiple-device-token-hashes-for-single-okta-session.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-multiple-device-token-hashes-for-single-okta-session.asciidoc new file mode 100644 index 0000000000..9a596e0083 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-multiple-device-token-hashes-for-single-okta-session.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-18-9-multiple-device-token-hashes-for-single-okta-session]] +=== Multiple Device Token Hashes for Single Okta Session + +This rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://support.okta.com/help/s/article/session-hijacking-attack-definition-damage-defense?language=en_US +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Credential Access +* Domain: SaaS +* Resources: Investigation Guide + +*Version*: 306 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multiple Device Token Hashes for Single Okta Session* + + +This rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources. + + +*Possible investigation steps:* + +- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.authentication_context.external_session_id` values can be used to pivot into the raw authentication events related to this alert. +- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields. +- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields. +- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field. + - Historical analysis should indicate if this device token hash is commonly associated with the user. +- Review the `okta.event_type` field to determine the type of authentication event that occurred. + - Authentication events have been filtered out to focus on Okta activity via established sessions. +- Review the past activities of the actor(s) involved in this action by checking their previous actions. +- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity. + - This may help determine the authentication and authorization actions that occurred between the user, Okta and application. +- Aggregate by `okta.actor.alternate_id` and `event.action` to determine the type of actions that are being performed by the actor(s) involved in this action. + - If various activity is reported that seems to indicate actions from separate users, consider deactivating the user's account temporarily. + + +*False positive analysis:* + +- It is very rare that a legitimate user would have multiple device token hashes for a single Okta session as DT hashes do not change after an authenticated session is established. + + +*Response and remediation:* + +- Consider stopping all sessions for the user(s) involved in this action. +- If this does not appear to be a false positive, consider resetting passwords for the users involved and enabling multi-factor authentication (MFA). + - If MFA is already enabled, consider resetting MFA for the users. +- If any of the users are not legitimate, consider deactivating the user's account. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user. + - If so, confirm with the user this was a legitimate request. + - If so and this was not a legitimate request, consider deactivating the user's account temporarily. + - Reset passwords and reset MFA for the user. +- Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule. + - This should be done with caution as it may prevent legitimate alerts from being generated. + + +==== Setup + + + +*Setup* + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta* +| WHERE + event.dataset == "okta.system" + // ignore authentication events where session and device token hash change often + AND NOT event.action IN ( + "policy.evaluate_sign_on", + "user.session.start", + "user.authentication.sso" + ) + // ignore Okta system events and only allow registered users + AND ( + okta.actor.alternate_id != "system@okta.com" + AND okta.actor.alternate_id RLIKE "[^@\\s]+\\@[^@\\s]+" + ) + AND okta.authentication_context.external_session_id != "unknown" +| KEEP event.action, okta.actor.alternate_id, okta.authentication_context.external_session_id, okta.debug_context.debug_data.dt_hash +| STATS + dt_hash_counts = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash) BY + okta.actor.alternate_id, + okta.authentication_context.external_session_id +| WHERE + dt_hash_counts >= 2 +| SORT + dt_hash_counts DESC + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-multiple-microsoft-365-user-account-lockouts-in-short-time-window.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-multiple-microsoft-365-user-account-lockouts-in-short-time-window.asciidoc new file mode 100644 index 0000000000..e15b49274b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-multiple-microsoft-365-user-account-lockouts-in-short-time-window.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-18-9-multiple-microsoft-365-user-account-lockouts-in-short-time-window]] +=== Multiple Microsoft 365 User Account Lockouts in Short Time Window + +Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray +* https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties +* https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/ +* https://github.com/0xZDH/Omnispray +* https://github.com/0xZDH/o365spray + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating Multiple Microsoft 365 User Account Lockouts in Short Time Window* + + +Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts. + +This rule uses ESQL aggregations and thus has dynamically generated fields. Correlation of the values in the alert document may need to be performed to the original sign-in and Graph events for further context. + + +*Investigation Steps* + + +- Review the `user_id_list`: Are specific naming patterns targeted (e.g., admin, helpdesk)? +- Examine `ip_list` and `source_orgs`: Look for suspicious ISPs or hosting providers. +- Check `duration_seconds`: A very short window with a high lockout rate often indicates automation. +- Confirm lockout policy thresholds with IAM or Entra ID admins. Did the policy trigger correctly? +- Use the `first_seen` and `last_seen` values to pivot into related authentication or audit logs. +- Correlate with any recent detection of password spraying or credential stuffing activity. +- Review the `request_type` field to identify which authentication methods were used (e.g., OAuth, SAML, etc.). +- Check for any successful logins from the same IP or ASN after the lockouts. + + +*False Positive Analysis* + + +- Automated systems with stale credentials may cause repeated failed logins. +- Legitimate bulk provisioning or scripted tests could unintentionally cause account lockouts. +- Red team exercises or penetration tests may resemble the same lockout pattern. +- Some organizations may have a high volume of lockouts due to user behavior or legacy systems. + + +*Response Recommendations* + + +- Notify affected users and confirm whether activity was expected or suspicious. +- Lock or reset credentials for impacted accounts. +- Block the source IP(s) or ASN temporarily using conditional access or firewall rules. +- Strengthen lockout and retry delay policies if necessary. +- Review the originating application(s) involved via `request_types`. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-o365.audit-* + +| MV_EXPAND event.category +| EVAL + time_window = DATE_TRUNC(5 minutes, @timestamp), + user_id = TO_LOWER(o365.audit.UserId), + ip = source.ip, + login_error = o365.audit.LogonError, + request_type = TO_LOWER(o365.audit.ExtendedProperties.RequestType), + asn_org = source.`as`.organization.name, + country = source.geo.country_name, + event_time = @timestamp + +| WHERE event.dataset == "o365.audit" + AND event.category == "authentication" + AND event.provider IN ("AzureActiveDirectory", "Exchange") + AND event.action IN ("UserLoginFailed", "PasswordLogonInitialAuthUsingPassword") + AND request_type RLIKE "(oauth.*||.*login.*)" + AND login_error == "IdsLocked" + AND user_id != "not available" + AND o365.audit.Target.Type IN ("0", "2", "6", "10") + AND asn_org != "MICROSOFT-CORP-MSN-AS-BLOCK" + +| STATS + unique_users = COUNT_DISTINCT(user_id), + user_id_list = VALUES(user_id), + ip_list = VALUES(ip), + unique_ips = COUNT_DISTINCT(ip), + source_orgs = VALUES(asn_org), + countries = VALUES(country), + unique_country_count = COUNT_DISTINCT(country), + unique_asn_orgs = COUNT_DISTINCT(asn_org), + request_types = VALUES(request_type), + first_seen = MIN(event_time), + last_seen = MAX(event_time), + total_lockout_responses = COUNT() + BY time_window + +| EVAL + duration_seconds = DATE_DIFF("seconds", first_seen, last_seen) + +| KEEP + time_window, unique_users, user_id_list, ip_list, + unique_ips, source_orgs, countries, unique_country_count, + unique_asn_orgs, request_types, first_seen, last_seen, + total_lockout_responses, duration_seconds + +| WHERE + unique_users >= 10 AND + total_lockout_responses >= 10 AND + duration_seconds <= 300 + +---------------------------------- + +*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-18-9/prebuilt-rule-8-18-9-multiple-okta-user-authentication-events-with-client-address.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-multiple-okta-user-authentication-events-with-client-address.asciidoc new file mode 100644 index 0000000000..442151fae3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-multiple-okta-user-authentication-events-with-client-address.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-18-9-multiple-okta-user-authentication-events-with-client-address]] +=== Multiple Okta User Authentication Events with Client Address + +Detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/ +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 205 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multiple Okta User Authentication Events with Client Address* + + +This rule detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack. + + +*Possible investigation steps:* + +Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.client.ip` values can be used to pivot into the raw authentication events related to this activity. +- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields. +- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields. +- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy. + - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying. +- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful. + - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context. +- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field. + - Historical analysis should indicate if this device token hash is commonly associated with the user. +- Review the `okta.event_type` field to determine the type of authentication event that occurred. + - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons. + - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying. + - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API. +- Examine the `okta.outcome.result` field to determine if the authentication was successful. +- Review the past activities of the actor(s) involved in this action by checking their previous actions. +- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity. + - This may help determine the authentication and authorization actions that occurred between the user, Okta and application. + + +*False positive analysis:* + +- A user may have legitimately started a session via a proxy for security or privacy reasons. +- Users may share an endpoint related to work or personal use in which separate Okta accounts are used. + - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons. + - Shared systems such as Kiosks and conference room computers may be used by multiple users. + - Shared working spaces may have a single endpoint that is used by multiple users. + + +*Response and remediation:* + +- Review the profile of the users involved in this action to determine if proxy usage may be expected. +- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required. +- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA). + - If MFA is already enabled, consider resetting MFA for the users. +- If any of the users are not legitimate, consider deactivating the user's account. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user. + - If so, confirm with the user this was a legitimate request. + - If so and this was not a legitimate request, consider deactivating the user's account temporarily. + - Reset passwords and reset MFA for the user. +- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule. + - This will prevent future occurrences of this event for this device from triggering the rule. + - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule. + - This should be done with caution as it may prevent legitimate alerts from being generated. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta* +| WHERE + event.dataset == "okta.system" + AND (event.action == "user.session.start" OR event.action RLIKE "user\\.authentication(.*)") + AND okta.outcome.reason == "INVALID_CREDENTIALS" +| KEEP okta.client.ip, okta.actor.alternate_id, okta.actor.id, event.action, okta.outcome.reason +| STATS + source_auth_count = COUNT_DISTINCT(okta.actor.id) + BY okta.client.ip, okta.actor.alternate_id +| WHERE + source_auth_count > 5 +| SORT + source_auth_count DESC + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc new file mode 100644 index 0000000000..671e118402 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-18-9-multiple-okta-user-authentication-events-with-same-device-token-hash]] +=== Multiple Okta User Authentication Events with Same Device Token Hash + +Detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/ +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 205 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multiple Okta User Authentication Events with Same Device Token Hash* + + +This rule detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack. + + +*Possible investigation steps:* + +- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.debug_context.debug_data.dt_hash` values can be used to pivot into the raw authentication events related to this activity. +- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields. +- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields. +- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy. + - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying. +- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful. + - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context. +- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field. + - Historical analysis should indicate if this device token hash is commonly associated with the user. +- Review the `okta.event_type` field to determine the type of authentication event that occurred. + - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons. + - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying. +- Examine the `okta.outcome.result` field to determine if the authentication was successful. +- Review the past activities of the actor(s) involved in this action by checking their previous actions. +- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity. + - This may help determine the authentication and authorization actions that occurred between the user, Okta and application. + + +*False positive analysis:* + +- A user may have legitimately started a session via a proxy for security or privacy reasons. +- Users may share an endpoint related to work or personal use in which separate Okta accounts are used. + - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons. + - Shared systems such as Kiosks and conference room computers may be used by multiple users. + - Shared working spaces may have a single endpoint that is used by multiple users. + + +*Response and remediation:* + +- Review the profile of the users involved in this action to determine if proxy usage may be expected. +- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required. +- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA). + - If MFA is already enabled, consider resetting MFA for the users. +- If any of the users are not legitimate, consider deactivating the user's account. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user. + - If so, confirm with the user this was a legitimate request. + - If so and this was not a legitimate request, consider deactivating the user's account temporarily. + - Reset passwords and reset MFA for the user. +- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule. + - This will prevent future occurrences of this event for this device from triggering the rule. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta* +| WHERE + event.dataset == "okta.system" + AND (event.action RLIKE "user\\.authentication(.*)" OR event.action == "user.session.start") + AND okta.debug_context.debug_data.dt_hash != "-" + AND okta.outcome.reason == "INVALID_CREDENTIALS" +| KEEP event.action, okta.debug_context.debug_data.dt_hash, okta.actor.id, okta.actor.alternate_id, okta.outcome.reason +| STATS + target_auth_count = COUNT_DISTINCT(okta.actor.id) + BY okta.debug_context.debug_data.dt_hash, okta.actor.alternate_id +| WHERE + target_auth_count > 20 +| SORT + target_auth_count DESC + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-oidc-discovery-url-changed-in-entra-id.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-oidc-discovery-url-changed-in-entra-id.asciidoc new file mode 100644 index 0000000000..7801cda95b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-oidc-discovery-url-changed-in-entra-id.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-18-9-oidc-discovery-url-changed-in-entra-id]] +=== OIDC Discovery URL Changed in Entra ID + +Detects a change to the OpenID Connect (OIDC) discovery URL in the Entra ID Authentication Methods Policy. This behavior may indicate an attempt to federate Entra ID with an attacker-controlled identity provider, enabling bypass of multi-factor authentication (MFA) and unauthorized access through bring-your-own IdP (BYOIDP) methods. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://dirkjanm.io/persisting-with-federated-credentials-entra-apps-managed-identities/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating OIDC Discovery URL Changed in Entra ID* + + +This rule detects when the OIDC `discoveryUrl` is changed within the Entra ID Authentication Methods policy. Adversaries may leverage this to federate Entra ID with a rogue Identity Provider (IdP) under their control, allowing them to authenticate users with attacker-owned credentials and bypass MFA. This misconfiguration allows an attacker to impersonate valid users by issuing tokens via a third-party OIDC IdP while still passing validation in Entra ID. This technique has been publicly demonstrated and has critical implications for trust in federated identity. + + +*Possible investigation steps* + +- Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and `ipAddress` to identify who made the change and from where. +- Examine the `old_oidc_discovery` and `new_oidc_discovery` to confirm if the new `discoveryUrl` points to an unexpected or untrusted IdP. +- Check that the discovery URLs have `.well-known/openid-configuration` endpoints, which are standard for OIDC providers. +- Use `azure.auditlogs.properties.correlation_id` to pivot to related changes and activity from the same session. +- Review any subsequent sign-in activity that may have originated from the new IdP. +- Pivot to additional logs associated with the user or application that made the change to identify any further suspicious activity. + + +*False positive analysis* + +- Entra ID administrators may intentionally reconfigure OIDC trust relationships to support new business requirements. +- Validate any changes with the identity or security operations team before taking action. + + +*Response and remediation* + +- If the change is unauthorized, immediately revert the discovery URL to the trusted IdP via the Entra ID portal. +- Revoke tokens or sessions issued after the configuration change. +- Investigate how the unauthorized change occurred (e.g., compromised account or over-privileged app). +- Apply conditional access policies and change control procedures to protect IdP configuration changes. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-azure.auditlogs-* metadata _id, _version, _index +| WHERE event.action == "Authentication Methods Policy Update" +| EVAL Esql.azure.auditlogs.properties.target_resources.modified_properties.new_value.replace = REPLACE(`azure.auditlogs.properties.target_resources.0.modified_properties.0.new_value`, "\\\\", "") +| EVAL Esql.azure.auditlogs.properties.target_resources.modified_properties.old_value.replace = REPLACE(`azure.auditlogs.properties.target_resources.0.modified_properties.0.old_value`, "\\\\", "") +| DISSECT Esql.azure.auditlogs.properties.target_resources.modified_properties.new_value.replace "%{}discoveryUrl\":\"%{Esql.azure.auditlogs.properties.auth.oidc.discovery.url.new}\"}%{}" +| DISSECT Esql.azure.auditlogs.properties.target_resources.modified_properties.old_value.replace "%{}discoveryUrl\":\"%{Esql.azure.auditlogs.properties.auth.oidc.discovery.url.old}\"}%{}" +| WHERE Esql.azure.auditlogs.properties.auth.oidc.discovery.url.new IS NOT NULL and Esql.azure.auditlogs.properties.auth.oidc.discovery.url.old IS NOT NULL +| WHERE Esql.azure.auditlogs.properties.auth.oidc.discovery.url.new != Esql.azure.auditlogs.properties.auth.oidc.discovery.url.old +| KEEP + @timestamp, + event.action, + event.outcome, + azure.tenant_id, + azure.correlation_id, + azure.auditlogs.properties.activity_datetime, + azure.auditlogs.properties.operation_type, + azure.auditlogs.properties.initiated_by.user.userPrincipalName, + azure.auditlogs.properties.initiated_by.user.displayName, + azure.auditlogs.properties.initiated_by.user.ipAddress, + source.geo.city_name, + source.geo.region_name, + source.geo.country_name, + Esql.azure.auditlogs.properties.auth.oidc.discovery.url.new, + Esql.azure.auditlogs.properties.auth.oidc.discovery.url.old + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Conditional Access Policies +** ID: T1556.009 +** Reference URL: https://attack.mitre.org/techniques/T1556/009/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-okta-user-sessions-started-from-different-geolocations.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-okta-user-sessions-started-from-different-geolocations.asciidoc new file mode 100644 index 0000000000..7a391a50c0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-okta-user-sessions-started-from-different-geolocations.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-18-9-okta-user-sessions-started-from-different-geolocations]] +=== Okta User Sessions Started from Different Geolocations + +Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://www.rezonate.io/blog/okta-logs-decoded-unveiling-identity-threats-through-threat-hunting/ +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 306 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Okta User Sessions Started from Different Geolocations* + + +This rule detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations. + + +*Possible investigation steps:* + +- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.client.id` values can be used to pivot into the raw authentication events related to this alert. +- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields. +- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields. +- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field. + - Historical analysis should indicate if this device token hash is commonly associated with the user. +- Review the `okta.event_type` field to determine the type of authentication event that occurred. + - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons. + - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying. + - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API. +- Review the past activities of the actor(s) involved in this action by checking their previous actions. +- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity. + - This may help determine the authentication and authorization actions that occurred between the user, Okta and application. + + +*False positive analysis:* + +- It is very rare that a legitimate user would have multiple sessions started from different geo-located countries in a short time frame. + + +*Response and remediation:* + +- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required. +- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA). + - If MFA is already enabled, consider resetting MFA for the users. +- If any of the users are not legitimate, consider deactivating the user's account. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user. + - If so, confirm with the user this was a legitimate request. + - If so and this was not a legitimate request, consider deactivating the user's account temporarily. + - Reset passwords and reset MFA for the user. +- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule. + - This will prevent future occurrences of this event for this device from triggering the rule. + - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule. + - This should be done with caution as it may prevent legitimate alerts from being generated. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta* +| WHERE + event.dataset == "okta.system" + AND (event.action RLIKE "user\\.authentication(.*)" OR event.action == "user.session.start") + AND okta.security_context.is_proxy != true and okta.actor.id != "unknown" + AND event.outcome == "success" +| KEEP event.action, okta.security_context.is_proxy, okta.actor.id, event.outcome, client.geo.country_name, okta.actor.alternate_id +| STATS + geo_auth_counts = COUNT_DISTINCT(client.geo.country_name) + BY okta.actor.id, okta.actor.alternate_id +| WHERE + geo_auth_counts >= 2 + +---------------------------------- + +*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-18-9/prebuilt-rule-8-18-9-potential-impersonation-attempt-via-kubectl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-potential-impersonation-attempt-via-kubectl.asciidoc new file mode 100644 index 0000000000..bfc776cf02 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-potential-impersonation-attempt-via-kubectl.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-18-9-potential-impersonation-attempt-via-kubectl]] +=== Potential Impersonation Attempt via Kubectl + +This rule detects potential impersonation attempts via the "kubectl" command in Linux environments. It identifies process events where "kubectl" is executed with arguments that suggest an attempt to impersonate another user or group, such as using "--kubeconfig", "--token", "--as", or "--as-group". This could indicate an adversary trying to gain unauthorized access or escalate privileges within a Kubernetes cluster. If this rule is triggered, in conjunction with rules related to secret access or kubeconfig file discovery, it may indicate a potential impersonation attempt. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* Domain: Container +* Domain: Kubernetes +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Discovery +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Impersonation Attempt via Kubectl* + + +Kubectl is a command-line tool for interacting with Kubernetes clusters, allowing users to manage applications and resources. Adversaries may exploit kubectl by using specific arguments to impersonate users, gaining unauthorized access or escalating privileges. The detection rule identifies suspicious kubectl executions, focusing on arguments that suggest impersonation, such as those related to user identity and authentication, to flag potential misuse. + + +*Possible investigation steps* + + +- Review the process arguments to confirm the presence of impersonation-related flags such as "--kubeconfig", "--token", "--as", "--as-group", or "--as-uid" to understand the scope of the impersonation attempt. +- Examine the parent process name and executable path to determine if the kubectl command was initiated from a suspicious location or script, such as "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/root/*", or "/home/*". +- Check the user account associated with the kubectl execution to assess whether it aligns with expected usage patterns or if it indicates potential unauthorized access. +- Investigate related alerts or logs for secret access or kubeconfig file discovery to identify if there is a broader pattern of suspicious activity that could indicate a coordinated impersonation attempt. +- Analyze the network activity associated with the kubectl execution to identify any unusual connections or data transfers that may suggest unauthorized access or data exfiltration. + + +*False positive analysis* + + +- Legitimate administrative tasks: System administrators may use kubectl with impersonation arguments for legitimate purposes such as testing permissions or managing resources on behalf of other users. To handle this, create exceptions for known administrative accounts or specific IP addresses. +- Automation scripts: Automated scripts or CI/CD pipelines might use impersonation arguments to perform tasks across different environments. Review and whitelist these scripts by identifying their unique execution patterns or specific user accounts. +- Development and testing environments: Developers might use impersonation features in non-production environments for testing purposes. Exclude these environments by filtering based on environment-specific identifiers or network segments. +- Security tools: Some security tools or monitoring solutions may use impersonation arguments to audit or verify access controls. Identify these tools and exclude their processes by recognizing their signatures or execution paths. +- Frequent legitimate use cases: If certain teams or departments regularly use impersonation for valid reasons, consider creating role-based exceptions to reduce noise while maintaining security oversight. + + +*Response and remediation* + + +- Immediately isolate the affected Kubernetes node or cluster to prevent further unauthorized access or privilege escalation. +- Revoke any potentially compromised credentials, such as tokens or kubeconfig files, and issue new ones with updated security policies. +- Review and audit the Kubernetes RBAC (Role-Based Access Control) settings to ensure that only authorized users have the necessary permissions, and adjust roles and permissions as needed to minimize privilege escalation risks. +- Conduct a thorough investigation of the affected systems to identify any unauthorized changes or deployments made by the adversary, and roll back any malicious or suspicious configurations. +- Monitor for any further suspicious kubectl activity, especially those involving impersonation arguments, and set up alerts for any similar future attempts. +- Escalate the incident to the security operations team for a comprehensive review and to determine if additional security measures or incident response actions are required. +- Implement additional logging and monitoring for kubectl commands and Kubernetes API interactions to enhance detection capabilities for similar threats in the future. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "executed", "process_started") and +process.name == "kubectl" and ( + process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") or + ( + process.parent.executable like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/root/*", "/home/*") or + process.parent.name like (".*", "*.sh") + ) +) and process.args like~ ("--kubeconfig*", "--token*", "--as*", "--as-group*", "--as-uid*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-potential-malware-driven-ssh-brute-force-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-potential-malware-driven-ssh-brute-force-attempt.asciidoc new file mode 100644 index 0000000000..ef6751d8e7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-potential-malware-driven-ssh-brute-force-attempt.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-18-9-potential-malware-driven-ssh-brute-force-attempt]] +=== Potential Malware-Driven SSH Brute Force Attempt + +This detection identifies a Linux host that has potentially been infected with malware and is being used to conduct brute-force attacks against external systems over SSH (port 22 and common alternative SSH ports). The detection looks for a high volume of outbound connection attempts to non-private IP addresses from a single process. A compromised host may be part of a botnet or controlled by an attacker, attempting to gain unauthorized access to remote systems. This behavior is commonly observed in SSH brute-force campaigns where malware hijacks vulnerable machines to expand its attack surface. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-61m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Impact +* Tactic: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Malware-Driven SSH Brute Force Attempt* + + +SSH is a protocol used to securely access remote systems. Adversaries exploit it by deploying malware on compromised Linux hosts to perform brute-force attacks, attempting unauthorized access to other systems. The detection rule identifies such abuse by monitoring high volumes of outbound SSH connection attempts from a single process to external IPs, indicating potential malware activity. + + +*Possible investigation steps* + + +- Review the process executable identified in the alert to determine if it is a legitimate application or potentially malicious. Check for known malware signatures or unusual file paths. +- Analyze the destination IP addresses involved in the connection attempts to identify if they are known malicious hosts or part of a larger attack infrastructure. Use threat intelligence sources to gather more information. +- Examine the host's recent activity logs to identify any unusual behavior or signs of compromise, such as unexpected process executions or changes in system configurations. +- Investigate the specific agent.id associated with the alert to determine if other alerts or suspicious activities have been reported from the same host, indicating a broader compromise. +- Check for any recent changes or updates to the host's software or configurations that could have introduced vulnerabilities exploited by the malware. +- Assess the network traffic patterns from the host to identify any other unusual outbound connections that may indicate additional malicious activity or data exfiltration attempts. + + +*False positive analysis* + + +- High-volume legitimate SSH operations from a single process can trigger alerts. Exclude known safe processes or scripts that perform frequent SSH operations by adding them to an exception list. +- Automated backup or synchronization tools using SSH to connect to external servers may be misidentified. Identify these tools and exclude their process names or IP addresses from the detection rule. +- Development or testing environments where SSH connections are frequently initiated to external systems for legitimate purposes can cause false positives. Document these environments and adjust the rule to exclude their specific IP ranges or process identifiers. +- Security scanning tools that perform SSH checks on external systems might be flagged. Ensure these tools are recognized and their activities are excluded by specifying their process names or IP addresses in the rule exceptions. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network immediately to prevent further unauthorized access attempts and potential spread of malware to other systems. +- Terminate the suspicious process identified by the detection rule to stop ongoing brute-force attempts and reduce the risk of further compromise. +- Conduct a thorough malware scan on the isolated host using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious software. +- Review and reset credentials for any accounts that may have been targeted or compromised during the brute-force attempts to ensure account security. +- Apply security patches and updates to the affected host and any other vulnerable systems to mitigate known vulnerabilities that could be exploited by similar threats. +- Monitor network traffic for any signs of continued or new suspicious activity, particularly focusing on outbound SSH connections, to detect and respond to any further attempts promptly. +- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and to assess the potential impact on the broader network infrastructure. + + +==== 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] +---------------------------------- +from logs-endpoint.events.network-* +| keep @timestamp, host.os.type, event.type, event.action, destination.port, process.executable, destination.ip, agent.id, host.name +| where @timestamp > now() - 1 hours +| where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and + destination.port in (22, 222, 2222, 10022, 2022, 2200, 62612, 8022) and not + CIDR_MATCH( + destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", + "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", + "224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "224.0.0.0/4", "240.0.0.0/4", "::1", + "FE80::/10", "FF00::/8" + ) +| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable, destination.port +| where agent_count == 1 and cc > 15 +| sort cc asc +| limit 100 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* 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-18-9/prebuilt-rule-8-18-9-potential-port-scanning-activity-from-compromised-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-potential-port-scanning-activity-from-compromised-host.asciidoc new file mode 100644 index 0000000000..ca563fd76d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-potential-port-scanning-activity-from-compromised-host.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-18-9-potential-port-scanning-activity-from-compromised-host]] +=== Potential Port Scanning Activity from Compromised Host + +This rule detects potential port scanning activity from a compromised host. Port scanning is a common reconnaissance technique used by attackers to identify open ports and services on a target system. A compromised host may exhibit port scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable services, or prepare for further exploitation. This rule identifies potential port scanning activity by monitoring network connection attempts from a single host to a large number of ports within a short time frame. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 1h + +*Searches indices from*: now-61m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Port Scanning Activity from Compromised Host* + + +Port scanning is a reconnaissance method used by attackers to identify open ports and services on a network, often as a precursor to exploitation. In Linux environments, compromised hosts may perform rapid connection attempts to numerous ports, signaling potential scanning activity. The detection rule identifies such behavior by analyzing network logs for a high number of distinct port connections from a single host within a short timeframe, indicating possible malicious intent. + + +*Possible investigation steps* + + +- Review the network logs to identify the specific host exhibiting the port scanning behavior by examining the destination.ip and process.executable fields. +- Analyze the @timestamp field to determine the exact time frame of the scanning activity and correlate it with any other suspicious activities or alerts from the same host. +- Investigate the process.executable field to understand which application or service initiated the connection attempts, and verify if it is a legitimate process or potentially malicious. +- Check the destination.port field to identify the range and types of ports targeted by the scanning activity, which may provide insights into the attacker's objectives or the services they are interested in. +- Assess the host's security posture by reviewing recent changes, installed software, and user activity to determine if the host has been compromised or if the scanning is part of legitimate network operations. +- Consult the original documents and logs for additional context and details that may not be captured in the alert to aid in a comprehensive investigation. + + +*False positive analysis* + + +- Legitimate network scanning tools used by system administrators for network maintenance or security assessments can trigger this rule. To handle this, identify and whitelist the IP addresses or processes associated with these tools. +- Automated vulnerability scanners or monitoring systems that perform regular checks on network services may cause false positives. Exclude these systems by creating exceptions for their known IP addresses or process names. +- High-volume legitimate services that open multiple connections to different ports, such as load balancers or proxy servers, might be flagged. Review and exclude these services by specifying their IP addresses or process executables. +- Development or testing environments where frequent port scanning is part of routine operations can be mistakenly identified. Implement exceptions for these environments by excluding their specific network segments or host identifiers. +- Scheduled network discovery tasks that are part of IT operations can mimic port scanning behavior. Document and exclude these tasks by setting up time-based exceptions or identifying their unique process signatures. + + +*Response and remediation* + + +- Isolate the compromised host from the network immediately to prevent further scanning and potential lateral movement. +- Terminate any suspicious processes identified by the process.executable field to halt ongoing malicious activities. +- Conduct a thorough review of the compromised host's system logs and network traffic to identify any unauthorized access or data exfiltration attempts. +- Patch and update all software and services on the compromised host to close any vulnerabilities that may have been exploited. +- Change all credentials associated with the compromised host and any potentially affected systems to prevent unauthorized access. +- Monitor the network for any further signs of scanning activity or other suspicious behavior from other hosts, indicating potential additional compromises. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.network-* +| keep @timestamp, host.os.type, event.type, event.action, destination.port, process.executable, destination.ip, agent.id, host.name +| where @timestamp > now() - 1 hours +| where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" +| stats cc = count(), port_count = count_distinct(destination.port), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable, destination.ip +| where agent_count == 1 and port_count > 100 +| sort cc asc +| limit 100 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-potential-subnet-scanning-activity-from-compromised-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-potential-subnet-scanning-activity-from-compromised-host.asciidoc new file mode 100644 index 0000000000..f62eda4d65 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-potential-subnet-scanning-activity-from-compromised-host.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-18-9-potential-subnet-scanning-activity-from-compromised-host]] +=== Potential Subnet Scanning Activity from Compromised Host + +This rule detects potential subnet scanning activity from a compromised host. Subnet scanning is a common reconnaissance technique used by attackers to identify live hosts within a network range. A compromised host may exhibit subnet scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable hosts, or prepare for further exploitation. This rule identifies potential subnet scanning activity by monitoring network connection attempts from a single host to a large number of hosts within a short time frame. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 1h + +*Searches indices from*: now-61m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Subnet Scanning Activity from Compromised Host* + + +Subnet scanning is a reconnaissance method used by attackers to map network topology and identify active hosts. Adversaries exploit compromised hosts to perform these scans, seeking vulnerabilities for further attacks. The detection rule identifies such activity by monitoring Linux hosts for numerous connection attempts to different IPs within a short period, indicating potential scanning behavior. This helps in early detection and mitigation of network threats. + + +*Possible investigation steps* + + +- Review the process executable identified in the alert to determine if it is a known or legitimate application that should be making network connections. +- Examine the destination IP addresses to identify any patterns or known malicious IPs, and check if these IPs are part of the organization's network or external. +- Investigate the specific host (using the agent.id) to assess if there are any signs of compromise, such as unusual processes or unauthorized access. +- Correlate the event timestamp with other logs or alerts to identify any concurrent suspicious activities or anomalies on the host. +- Check for any recent changes or updates on the host that might explain the scanning behavior, such as new software installations or configuration changes. + + +*False positive analysis* + + +- High-volume legitimate network monitoring tools may trigger the rule. Identify and exclude these tools by adding their process executables to an exception list. +- Automated backup systems that connect to multiple hosts within a short timeframe can be mistaken for scanning activity. Review and exclude these systems by their process executable or agent ID. +- Security software performing routine network health checks might generate false positives. Verify these activities and create exceptions based on the specific process executable involved. +- Internal IT scripts or administrative tasks that involve connecting to numerous hosts for maintenance purposes can trigger alerts. Document these tasks and exclude them by process executable or agent ID. +- Cloud-based services or applications that require frequent connections to various hosts for functionality may appear as scanning. Identify these services and exclude them by their process executable or agent ID. + + +*Response and remediation* + + +- Isolate the compromised host immediately from the network to prevent further scanning and potential lateral movement by the attacker. +- Terminate any suspicious processes identified by the executable name in the alert to stop ongoing scanning activities. +- Conduct a thorough examination of the compromised host to identify and remove any malware or unauthorized access tools that may have been installed. +- Reset credentials and review access permissions for the compromised host to ensure no unauthorized access persists. +- Update and patch the compromised host and any other vulnerable systems identified during the investigation to close security gaps. +- Monitor network traffic closely for any signs of continued scanning or other suspicious activities from other hosts, indicating potential further compromise. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine if additional hosts are affected. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.network-* +| keep @timestamp, host.os.type, event.type, event.action, process.executable, destination.ip, agent.id, host.name +| where @timestamp > now() - 1 hours +| where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" +| stats cc = count(), dest_count = count_distinct(destination.ip), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable +| where agent_count == 1 and dest_count > 250 +| sort cc asc +| limit 100 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-sudoers-file-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-sudoers-file-modification.asciidoc new file mode 100644 index 0000000000..0ad52c2743 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-sudoers-file-modification.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-18-9-sudoers-file-modification]] +=== Sudoers File Modification + +A sudoers file specifies the commands that 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. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 209 + +*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 Sudoers File Modification* + + +The sudoers file is crucial in Unix-like systems, defining user permissions for executing commands with elevated privileges. Adversaries may exploit this by altering the file to gain unauthorized access or escalate privileges. The detection rule identifies suspicious changes to the sudoers file, excluding legitimate processes, to flag potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific file path that triggered the alert, focusing on /etc/sudoers* or /private/etc/sudoers*. +- Examine the process information associated with the change event, particularly the process.name and process.executable fields, to determine if the modification was made by a suspicious or unauthorized process. +- Check the user account associated with the process that made the change to the sudoers file to assess if the account has a legitimate reason to modify the file. +- Investigate recent login activity and user behavior for the account involved in the modification to identify any anomalies or signs of compromise. +- Review system logs around the time of the alert to gather additional context on what other activities occurred on the system, which might indicate a broader attack or compromise. +- Assess the current state of the sudoers file to identify any unauthorized or suspicious entries that could indicate privilege escalation attempts. + + +*False positive analysis* + + +- System updates and package installations can trigger changes to the sudoers file. Exclude processes like dpkg, yum, dnf, and platform-python from triggering alerts as they are commonly involved in legitimate updates. +- Configuration management tools such as Puppet and Chef may modify the sudoers file as part of their normal operations. Exclude process executables like /opt/chef/embedded/bin/ruby and /opt/puppetlabs/puppet/bin/ruby to prevent false positives. +- Docker daemon processes might interact with the sudoers file during container operations. Exclude /usr/bin/dockerd to avoid unnecessary alerts related to Docker activities. +- Regularly review and update the exclusion list to ensure it reflects the current environment and operational tools, minimizing false positives while maintaining security vigilance. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation. +- Review the recent changes to the sudoers file to identify unauthorized modifications and revert them to the last known good configuration. +- Conduct a thorough examination of system logs to identify any unauthorized access or actions performed using elevated privileges, focusing on the time frame of the detected change. +- Reset passwords and review access permissions for all users with sudo privileges to ensure no unauthorized accounts have been added or existing accounts have been compromised. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been affected. +- Implement additional monitoring on the affected system and similar systems to detect any further attempts to modify the sudoers file or other privilege escalation activities. +- Review and update security policies and configurations to prevent similar incidents, ensuring that only authorized processes can modify the sudoers file. + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type in ("linux", "macos") and event.type in ("creation", "change") and +file.path like ("/etc/sudoers*", "/private/etc/sudoers*") and not ( + process.name in ("dpkg", "platform-python", "puppet", "yum", "dnf") or + process.executable in ("/opt/chef/embedded/bin/ruby", "/opt/puppetlabs/puppet/bin/ruby", "/usr/bin/dockerd") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-teamfiltration-user-agents-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-teamfiltration-user-agents-detected.asciidoc new file mode 100644 index 0000000000..887780847b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-teamfiltration-user-agents-detected.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-18-9-teamfiltration-user-agents-detected]] +=== TeamFiltration User-Agents Detected + +Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign +* https://github.com/Flangvik/TeamFiltration + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-in Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs. + +The detection is based on TeamFiltration's hardcoded user agent string and/or the use of `Electron` by monitoring multiple log sources, including: + +- Azure Graph API Activity Logs +- Microsoft 365 Audit Logs +- Entra ID Sign-in Logs +- Entra ID Audit Logs +- Azure Activity Logs + + +*Possible investigation steps* + + +- Confirm the tool used via `user_agent.original`. +- Identify the `user.id`, `user.name`, or `azure.signinlogs.properties.user_principal_name` fields to determine which identity executed the API requests or sign-in attempts. +- Review `app_id`, `app_display_name`, or `client_id` to identify the application context (e.g., Azure CLI, Graph Explorer, unauthorized app). TeamFiltration uses a list of FOCI compliant applications to perform enumeration and password spraying. TeamFiltration uses Microsoft Teams client ID `1fec8e78-bce4-4aaf-ab1b-5451cc387264` for enumeration. +- Check `http.request.method`, `http.response.status_code`, and `event.action` for enumeration patterns (many successful GETs in a short period) if Graph API activity logs. +- Investigate correlated sign-ins (`azure.signinlogs`) by the same user, IP, or app immediately preceding the API calls. Was MFA used? Is the location suspicious? +- Review `source.ip` or `client.geo.*` fields to determine the origin of the requests. Flag unexpected IPs or ISPs. Check the for the use of several source addresses originating from Amazon ASNs (e.g., `AS16509`, `AS14618`, `AS14618`) which are commonly used by TeamFiltration as it proxies requests through FireProx and Amazon API Gateway. +- If the event originates in M365 Audit Logs, investigate cross-service activity: Exchange Online, Teams, SharePoint, or role escalations via Unified Audit. + + +*False positive analysis* + + +- This activity may be benign if performed by red teams, internal security auditors, or known security tools under authorization. + + +*Response and remediation* + + +- If confirmed malicious: + - Identify successful sign-in attempts or API calls made by the user or app. + - Revoke active sessions or tokens associated with the identified user/app. + - Disable the account or rotate credentials immediately. + - Review the role assignments (`Directory.Read.All`, `AuditLog.Read.All`, `Directory.AccessAsUser.All`) and remove excessive privileges. + - Conduct historical analysis to determine how long enumeration has been occurring and what objects were queried. + - Enable Conditional Access policies to require MFA for API and CLI-based access. + - Validate audit logging and alerting is enabled across Microsoft Graph, Azure Activity Logs, and M365 workloads. + +- If legitimate: + - Document the source or user (e.g., red team operation, security tool). + - Add appropriate allowlist conditions for service principal, user, source address or device if policy allows. + + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset:("azure.signinlogs" or "o365.audit") + and ((user_agent.name:"Electron" and user_agent.os.name:"Windows" and user_agent.version:"8.5.1") or + user_agent.original:"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Teams/1.3.00.30866 Chrome/80.0.3987.165 Electron/8.5.1 Safari/537.36") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Technique: +** Name: Password Policy Discovery +** ID: T1201 +** Reference URL: https://attack.mitre.org/techniques/T1201/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ +* Technique: +** Name: Virtual Machine Discovery +** ID: T1673 +** Reference URL: https://attack.mitre.org/techniques/T1673/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-aws-s3-object-encryption-with-sse-c.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-aws-s3-object-encryption-with-sse-c.asciidoc new file mode 100644 index 0000000000..59fc4a85eb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-aws-s3-object-encryption-with-sse-c.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-18-9-unusual-aws-s3-object-encryption-with-sse-c]] +=== Unusual AWS S3 Object Encryption with SSE-C + +Identifies when AWS S3 objects stored in a bucket are encrypted using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a New Terms rule that flags when this behavior is observed for the first time user and target bucket name. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.halcyon.ai/blog/abusing-aws-native-services-ransomware-encrypting-s3-buckets-with-sse-c +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Impact + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating Unusual AWS S3 Object Encryption with SSE-C* + +This rule identifies the use of Server-Side Encryption with Customer-Provided Keys (SSE-C) in AWS S3. This could indicate malicious activity, such as ransomware encrypting objects, rendering them inaccessible without the corresponding encryption keys. + + +*Possible Investigation Steps* + + +1. **Identify the User and Source**: + - Review the `aws.cloudtrail.user_identity.arn` to identify the IAM user or role performing the operation. + - Cross-check the `source.ip` and `user_agent.original` fields for unusual IPs or user agents that could indicate unauthorized access. + - Review the `aws.cloudtrail.user_identity.access_key_id` to identify the access key used. This could be a compromised key. + +2. **Examine the Targeted Resources**: + - Check `aws.cloudtrail.request_parameters` to identify the bucket involved. + - Analyze the object key from `aws.cloudtrail.request_parameters`. + +3. **Evaluate Encryption Behavior**: + - Confirm the encryption details in `aws.cloudtrail.request_parameters` and `aws.cloudtrail.additional_eventdata`. + - Note if `SSEApplied` is `SSE-C`, which confirms encryption using a customer-provided key. + +4. **Correlate with Recent Events**: + - Look for any suspicious activity in proximity to the encryption event, such as new access key creation, policy changes, or unusual access patterns from the same user or IP. + - Identify `ListBucket` or `GetObject` operations on the same bucket to determine all affected objects. + - For `PutObject` events, identify any other unusual objecs uploaded such as a ransom note. + +5. **Validate Access Permissions**: + - Check the IAM policies and roles associated with the user to verify if they had legitimate access to encrypt objects. + +6. **Assess Impact**: + - Identify the number of encrypted objects in the bucket by examining other similar events. + - Determine if this encryption aligns with standard business practices or constitutes a deviation. + + +*False Positive Analysis* + + +- **Legitimate Use Cases**: + - Confirm if SSE-C encryption is part of regular operations for compliance or data protection. + - Cross-reference known processes or users authorized for SSE-C encryption in the affected bucket. + + +*Response and Remediation* + + +1. **Immediate Actions**: + - Disable access keys or permissions for the user if unauthorized behavior is confirmed. + - Rotate the bucket's encryption configuration to mitigate further misuse. + +2. **Data Recovery**: + - Attempt to identify and contact the party holding the SSE-C encryption keys if recovery is necessary. + +3. **Enhance Monitoring**: + - Enable alerts for future SSE-C encryption attempts in critical buckets. + - Review and tighten IAM policies for roles and users accessing S3. + +4. **Post-Incident Review**: + - Audit logs for additional activities by the same user or IP. + - Document findings and apply lessons learned to improve preventive measures. + + +==== Setup + + +AWS S3 data event types need to be enabled in the CloudTrail trail configuration. + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "s3.amazonaws.com" + and event.action: "PutObject" + and event.outcome: "success" + and aws.cloudtrail.flattened.request_parameters.x-amz-server-side-encryption-customer-algorithm: "AES256" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-base64-encoding-decoding-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-base64-encoding-decoding-activity.asciidoc new file mode 100644 index 0000000000..b5408dc534 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-base64-encoding-decoding-activity.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-18-9-unusual-base64-encoding-decoding-activity]] +=== Unusual Base64 Encoding/Decoding Activity + +This rule leverages ESQL to detect unusual base64 encoding/decoding activity on Linux systems. Attackers may use base64 encoding/decoding to obfuscate data, such as command and control traffic or payloads, to evade detection by host- or network-based security controls. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 1h + +*Searches indices from*: now-61m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Base64 Encoding/Decoding Activity* + +Base64 encoding is a method to convert binary data into ASCII text, often used for data transmission. Adversaries exploit this to obfuscate malicious payloads or commands, bypassing security controls. The detection rule identifies suspicious Base64 activity on Linux by monitoring specific processes and command patterns, flagging anomalies for further investigation. + + +*Possible investigation steps* + + +- Review the process name and command line arguments to understand the context of the Base64 activity. Check if the process name matches known legitimate applications or scripts. +- Examine the timestamp of the event to determine if the activity occurred during normal operational hours or if it coincides with other suspicious activities. +- Investigate the host operating system type and agent ID to identify the specific Linux system involved and assess if it has a history of similar alerts or other security incidents. +- Analyze the process command line for any unusual patterns or parameters that might indicate obfuscation or malicious intent, such as the presence of decode flags or unexpected Base64 operations. +- Correlate the event with other logs or alerts from the same host or network to identify potential lateral movement or coordinated attacks. +- Check for any recent changes or deployments on the affected system that might explain the Base64 activity, such as new software installations or updates. +- Consult threat intelligence sources to determine if the observed Base64 patterns or command line arguments are associated with known malware or attack techniques. + + +*False positive analysis* + + +- Routine administrative scripts may use base64 encoding for legitimate data processing tasks. Review the process.command_line and process.args fields to identify known scripts and consider excluding them from the rule. +- Backup or data transfer operations might employ base64 encoding to handle binary data. Verify the process.name and process.command_line to ensure these operations are recognized and add exceptions for these specific processes. +- Development environments often use base64 encoding for testing purposes. Identify development-related processes by examining the process.name and process.command_line and exclude them if they are part of regular development activities. +- Automated system monitoring tools might trigger this rule if they use base64 encoding for log or data analysis. Check the agent.id and process.command_line to confirm these tools and exclude them from the rule if they are verified as non-threatening. +- Security tools that perform data encoding for analysis or reporting could be flagged. Validate these tools by reviewing the process.name and process.command_line and create exceptions for them if they are part of the security infrastructure. + + +*Response and remediation* + + +- Isolate the affected Linux system from the network to prevent further data exfiltration or lateral movement by the adversary. +- Terminate any suspicious processes identified by the alert, particularly those involving base64 encoding/decoding, to halt potential malicious activity. +- Conduct a thorough review of the process command lines and arguments flagged by the alert to identify any malicious scripts or payloads. Remove or quarantine these files as necessary. +- Check for any unauthorized user accounts or privilege escalations that may have been established during the attack and revoke access immediately. +- Restore any affected systems or files from a known good backup to ensure the integrity of the system and data. +- Implement additional monitoring on the affected system and similar environments to detect any recurrence of the suspicious base64 activity. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if broader organizational impacts exist. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- 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] +---------------------------------- +from logs-endpoint.events.process-* +| keep @timestamp, host.os.type, event.type, event.action, process.name, process.args, process.command_line, agent.id, host.name +| where @timestamp > now() - 1 hours +| where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + (process.name in ("base64", "base64plain", "base64url", "base64mime", "base64pem", "base32", "base16") and process.command_line like "*-*d*") or + (process.name == "openssl" and process.args == "enc" and process.args in ("-d", "-base64", "-a")) or + (process.name like "python*" and + (process.args == "base64" and process.args in ("-d", "-u", "-t")) or + (process.args == "-c" and process.command_line like "*base64*" and process.command_line like "*b64decode*") + ) or + (process.name like "perl*" and process.command_line like "*decode_base64*") or + (process.name like "ruby*" and process.args == "-e" and process.command_line like "*Base64.decode64*") +) +| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.name, process.command_line +| where agent_count == 1 and cc < 15 +| sort cc asc +| limit 100 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-command-execution-from-web-server-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-command-execution-from-web-server-parent.asciidoc new file mode 100644 index 0000000000..ec60db6a52 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-command-execution-from-web-server-parent.asciidoc @@ -0,0 +1,205 @@ +[[prebuilt-rule-8-18-9-unusual-command-execution-from-web-server-parent]] +=== Unusual Command Execution from Web Server Parent + +This rule detects potential command execution from a web server parent process on a Linux host. Adversaries may attempt to execute commands from a web server parent process to blend in with normal web server activity and evade detection. This behavior is commonly observed in web shell attacks where adversaries exploit web server vulnerabilities to execute arbitrary commands on the host. The detection rule identifies unusual command execution from web server parent processes, which may indicate a compromised host or an ongoing attack. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-61m ({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*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Command Execution from Web Server Parent* + + +Web servers, such as Apache or Nginx, are crucial for hosting web applications, often running on Linux systems. Adversaries exploit vulnerabilities in these servers to execute arbitrary commands, typically through web shells, blending malicious activity with legitimate server processes. The detection rule identifies suspicious command executions originating from web server processes, focusing on unusual patterns and contexts, such as unexpected working directories or command structures, to flag potential compromises. + + +*Possible investigation steps* + + +- Review the process.command_line field to understand the specific command executed and assess its legitimacy or potential malicious intent. +- Examine the process.working_directory to determine if the command was executed from an unusual or suspicious directory, which could indicate a compromise. +- Check the process.parent.executable and process.parent.name fields to identify the parent process and verify if it is a known web server or related service that could be exploited. +- Investigate the user.name and user.id fields to confirm if the command was executed by a legitimate user or service account, or if it was potentially executed by an unauthorized user. +- Correlate the @timestamp with other logs and events to identify any related activities or anomalies occurring around the same time, which could provide additional context or evidence of an attack. +- Assess the agent.id to determine if the alert is isolated to a single host or if similar activities are observed across multiple hosts, indicating a broader issue. + + +*False positive analysis* + + +- Web development or testing environments may frequently execute commands from web server processes. To handle this, exclude specific working directories like /var/www/dev or /var/www/test from the rule. +- Automated scripts or cron jobs running under web server user accounts can trigger alerts. Identify these scripts and add exceptions for their specific command lines or user IDs. +- Legitimate administrative tasks performed by web server administrators might appear suspicious. Document these tasks and exclude their associated command lines or parent executables. +- Continuous integration or deployment processes that involve web server interactions can be mistaken for threats. Exclude known CI/CD tool command lines or working directories from the rule. +- Monitoring or logging tools that interact with web server processes may generate false positives. Identify these tools and exclude their specific process names or parent executables. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further malicious activity and lateral movement within the network. This can be done by removing the host from the network or applying network segmentation. + +- Terminate any suspicious processes identified by the detection rule, especially those originating from web server parent processes executing shell commands. Use process IDs and command lines from the alert to target specific processes. + +- Conduct a thorough review of the web server logs and application logs to identify any unauthorized access or modifications. Look for patterns that match the command execution detected and any other anomalies. + +- Patch the web server and any associated applications to address known vulnerabilities that may have been exploited. Ensure that all software is up to date with the latest security patches. + +- Restore the affected system from a known good backup if any unauthorized changes or persistent threats are detected. Ensure that the backup is free from compromise before restoration. + +- Implement additional monitoring and alerting for similar activities, focusing on unusual command executions and web server behavior. Enhance logging and alerting to capture more detailed information about process executions and network connections. + +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the attack is part of a larger campaign. Provide them with all relevant data and findings from the initial containment and remediation steps. + + +==== 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] +---------------------------------- +from logs-endpoint.events.process-* +| keep @timestamp, host.os.type, event.type, event.action, process.parent.name, user.name, user.id, process.working_directory, process.name, process.command_line, process.parent.executable, agent.id, host.name +| where @timestamp > now() - 1 hours +| where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + process.parent.name in ( + "apache", "nginx", "apache2", "httpd", "lighttpd", "caddy", "node", "mongrel_rails", "java", "gunicorn", + "uwsgi", "openresty", "cherokee", "h2o", "resin", "puma", "unicorn", "traefik", "tornado", "hypercorn", + "daphne", "twistd", "yaws", "webfsd", "httpd.worker", "flask", "rails", "mongrel" + ) or + process.parent.name like "php-*" or + process.parent.name like "python*" or + process.parent.name like "ruby*" or + process.parent.name like "perl*" or + user.name in ( + "apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat", "tomcat8", "tomcat9", "ftp", "ftpuser", "ftpd" + ) or + user.id in ("99", "33", "498", "48") or + process.working_directory like "/var/www/*" +) and + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.command_line like "* -c *" and + not ( + process.working_directory like "/home/*" or + process.working_directory like "/" or + process.working_directory like "/vscode/vscode-server/*" or + process.parent.executable like "/vscode/vscode-server/*" or + process.parent.executable == "/usr/bin/xfce4-terminal" +) +| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.command_line, process.working_directory, process.parent.executable +| where agent_count == 1 and cc < 5 +| sort cc asc +| limit 100 + +---------------------------------- + +*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-18-9/prebuilt-rule-8-18-9-unusual-file-transfer-utility-launched.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-file-transfer-utility-launched.asciidoc new file mode 100644 index 0000000000..a59c6236b5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-file-transfer-utility-launched.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-18-9-unusual-file-transfer-utility-launched]] +=== Unusual File Transfer Utility Launched + +This rule leverages ESQL to detect the execution of unusual file transfer utilities on Linux systems. Attackers may use these utilities to exfiltrate data from a compromised system. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 1h + +*Searches indices from*: now-61m ({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: Exfiltration +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual File Transfer Utility Launched* + + +File transfer utilities like scp, ftp, and rsync are essential for data movement in Linux environments. However, adversaries can exploit these tools to exfiltrate sensitive data. The detection rule identifies suspicious executions of these utilities by monitoring process activities, focusing on rare occurrences and unique agent IDs, which may indicate unauthorized data transfers. This helps in early detection of potential data breaches. + + +*Possible investigation steps* + + +- Review the process.command_line field to understand the exact command executed and assess if it aligns with typical usage patterns or if it appears suspicious. +- Examine the process.parent.executable field to determine the parent process that initiated the file transfer utility, which may provide insights into whether the execution was part of a legitimate workflow or potentially malicious activity. +- Check the agent.id field to identify the specific host involved in the alert and correlate it with other security events or logs from the same host to gather additional context. +- Investigate the @timestamp field to verify the timing of the event and cross-reference with any known scheduled tasks or user activities that could explain the execution. +- Analyze the host.os.type field to confirm the operating system and ensure that the alert pertains to a Linux environment, as expected by the rule. + + +*False positive analysis* + + +- Routine administrative tasks using file transfer utilities may trigger alerts. Regularly scheduled backups or updates using scp, rsync, or ftp should be documented and excluded from alerts by creating exceptions for known scripts or cron jobs. +- Automated system updates or patches that utilize these utilities can be mistaken for suspicious activity. Identify and whitelist the processes and command lines associated with these updates to prevent false positives. +- Internal data transfers between trusted servers for legitimate business purposes might be flagged. Establish a list of trusted agent IDs and exclude them from the rule to avoid unnecessary alerts. +- Development and testing environments often use these utilities for transferring test data. Ensure that these environments are recognized and excluded by specifying their hostnames or IP addresses in the rule configuration. +- User-initiated file transfers for legitimate reasons, such as data analysis or reporting, can be misinterpreted. Educate users to notify the security team of such activities in advance, allowing for temporary exceptions to be made. + + +*Response and remediation* + + +- Immediately isolate the affected Linux system from the network to prevent further data exfiltration and unauthorized access. +- Terminate any suspicious file transfer processes identified by the alert, such as scp, ftp, or rsync, to halt ongoing data transfers. +- Conduct a thorough review of the process command lines and parent executables to identify any malicious scripts or unauthorized software that initiated the file transfer. +- Change credentials and access keys associated with the compromised system to prevent further unauthorized access. +- Escalate the incident to the security operations team for a deeper forensic analysis to determine the extent of the breach and identify any additional compromised systems. +- Implement network monitoring to detect any further attempts of unauthorized file transfers or suspicious activities from the affected system. +- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- 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] +---------------------------------- +from logs-endpoint.events.process-* +| keep @timestamp, host.os.type, event.type, event.action, process.name, process.executable, process.parent.executable, process.command_line, agent.id, host.name +| where @timestamp > now() - 1 hours +| where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.name in ("scp", "ftp", "sftp", "vsftpd", "sftp-server", "rsync") +| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable, process.parent.executable, process.command_line +| where agent_count == 1 and cc < 5 +| sort cc asc +| limit 100 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-kill-signal.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-kill-signal.asciidoc new file mode 100644 index 0000000000..7e3b77a701 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-kill-signal.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-18-9-unusual-kill-signal]] +=== Unusual Kill Signal + +This rule detects the use of unusual kill signals, specifically kill signals in the range of 32-64, which are not commonly used in standard operations. Rootkits may leverage these signals to conduct certain actions, such as manipulating processes in unexpected ways, potentially escalating privileges or evading detection. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/m0nad/Diamorphine/blob/master/diamorphine.c#L302 +* https://www.elastic.co/security-labs/linux-detection-engineering-with-auditd + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Auditd Manager +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Kill Signal* + + +In Linux environments, kill signals are used to manage process lifecycles. Signals in the range of 32-64 are less common and can be exploited by adversaries, such as rootkits, to manipulate processes stealthily, potentially leading to privilege escalation or evasion of security measures. The 'Unusual Kill Signal' detection rule identifies these rare signals, flagging potential misuse by monitoring specific syscall activities, thus aiding in early threat detection. + + +*Possible investigation steps* + + +- Review the process details associated with the alert, focusing on the process name, PID, and parent process to understand the context of the kill signal usage. +- Examine the user account under which the process was executed to determine if it aligns with expected behavior or if it indicates potential unauthorized access. +- Investigate the command line arguments and environment variables of the process to identify any suspicious or unusual commands that may suggest malicious activity. +- Check the system logs around the time of the alert for any related events or anomalies that could provide additional context or indicate a broader attack pattern. +- Correlate the alert with other security events or alerts from the same host to identify if this is part of a larger attack or if there are other indicators of compromise. +- Assess the network activity of the host to identify any unusual outbound connections that could suggest data exfiltration or communication with a command and control server. + + +*False positive analysis* + + +- Legitimate applications or services may use signals in the 32-64 range for custom inter-process communication, leading to false positives. Identify these applications and create exceptions for their specific processes. +- Some system monitoring or management tools might utilize these signals for legitimate process management tasks. Review the tools in use and whitelist their activities if they are verified as non-threatening. +- Development environments or testing frameworks might employ unusual signals for debugging or testing purposes. Ensure these environments are properly isolated and exclude their activities from triggering alerts. +- Custom scripts or automation tasks could be configured to use these signals for specific operations. Audit these scripts and, if deemed safe, add them to an exception list to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes identified with unusual kill signals in the range of 32-64 to halt any ongoing malicious activity. +- Conduct a thorough forensic analysis of the affected system to identify any rootkits or malicious software that may have been installed, focusing on the processes and files associated with the unusual kill signals. +- Restore the system from a known good backup if rootkit presence is confirmed, ensuring that the backup is free from any compromise. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Implement enhanced monitoring and logging for unusual kill signals and related activities to detect any future attempts at similar attacks. +- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to assess the need for broader organizational response measures. + + +==== Setup + + + +*Setup* + + +This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system. +``` +Kibana --> +Management --> +Integrations --> +Auditd Manager --> +Add Auditd Manager +``` +`Auditd_manager` subscribes to the kernel and receives events as they occur without any additional configuration. However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +For this detection rule to trigger, the following additional audit rules are required to be added to the integration: +``` +-a always,exit -F arch=b64 -S kill +``` +Add the newly installed `auditd manager` to an agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.action == "killed-pid" and auditd.data.syscall == "kill" and +auditd.data.a1 in ( + "21", "22", "23", "24", "25", "26", "27", "28", "29", "2a", "2b", "2c", "2d", "2e", "2f", "30", + "31", "32", "33", "34", "35", "36", "37", "38", "39", "3a", "3b", "3c", "3d", "3e", "3f", "40", + "41", "42", "43", "44", "45", "46", "47" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-process-spawned-from-web-server-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-process-spawned-from-web-server-parent.asciidoc new file mode 100644 index 0000000000..83c5978d1d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rule-8-18-9-unusual-process-spawned-from-web-server-parent.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-18-9-unusual-process-spawned-from-web-server-parent]] +=== Unusual Process Spawned from Web Server Parent + +This rule detects unusual processes spawned from a web server parent process by identifying low frequency counts of process spawning activity. Unusual process spawning activity may indicate an attacker attempting to establish persistence, execute malicious commands, or establish command and control channels on the host system. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-61m ({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*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Process Spawned from Web Server Parent* + + +Web servers like Apache, Nginx, and others are crucial for hosting applications and services. Adversaries exploit these servers by spawning unauthorized processes to maintain persistence or execute malicious commands. The detection rule identifies anomalies by monitoring low-frequency process spawns from web server parents, focusing on unusual user IDs, directories, and process counts, which may indicate potential threats. + + +*Possible investigation steps* + + +- Review the process.executable and process.command_line fields to understand the nature of the process that was spawned and assess if it aligns with expected behavior for the web server environment. +- Examine the process.working_directory to determine if the directory is a legitimate location for web server operations or if it appears suspicious, such as being outside typical web server directories. +- Check the user.name and user.id fields to verify if the process was executed by a legitimate web server user or if it was initiated by an unexpected or unauthorized user account. +- Investigate the process.parent.executable to confirm whether the parent process is a known and trusted web server executable or if it has been tampered with or replaced. +- Correlate the event with other logs or alerts from the same agent.id to identify any additional suspicious activities or patterns that may indicate a broader compromise. +- Assess the host.os.type to ensure the alert pertains to a Linux system, as specified in the query, and verify if there are any known vulnerabilities or misconfigurations on the host that could have been exploited. + + +*False positive analysis* + + +- Processes related to legitimate web server maintenance tasks may trigger alerts. Review scheduled tasks or cron jobs that align with the alert timing and consider excluding these specific processes if they are verified as non-threatening. +- Development environments often spawn processes that mimic attack patterns. Identify and exclude processes originating from known development directories or executed by development user accounts. +- Automated scripts or monitoring tools running under web server user accounts can be mistaken for malicious activity. Verify these scripts and add exceptions for their specific process names or working directories. +- Frequent updates or deployments in web applications can lead to unusual process spawns. Document these activities and exclude related processes if they consistently match the alert criteria during known update windows. +- Custom web server modules or plugins may execute processes that appear suspicious. Validate these modules and exclude their associated processes if they are part of normal operations. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further malicious activity and potential lateral movement. +- Terminate any suspicious processes identified by the alert that are not part of legitimate web server operations. +- Conduct a thorough review of the process command lines and executables flagged by the alert to identify any malicious scripts or binaries. Remove or quarantine these files as necessary. +- Check for unauthorized changes in web server configurations or files within the working directories flagged by the alert. Restore any altered files from a known good backup. +- Review user accounts and permissions associated with the web server processes to ensure no unauthorized accounts or privilege escalations have occurred. Reset passwords and revoke unnecessary access. +- Monitor network traffic from the affected host for any signs of command and control communication, and block any identified malicious IP addresses or domains. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.process-* +| keep @timestamp, host.os.type, event.type, event.action, process.parent.name, user.name, user.id, process.working_directory, process.name, process.executable, process.command_line, process.parent.executable, agent.id, host.name +| where @timestamp > now() - 1 hours +| where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + process.parent.name in ( + "apache", "nginx", "apache2", "httpd", "lighttpd", "caddy", "node", "mongrel_rails", "java", "gunicorn", + "uwsgi", "openresty", "cherokee", "h2o", "resin", "puma", "unicorn", "traefik", "tornado", "hypercorn", + "daphne", "twistd", "yaws", "webfsd", "httpd.worker", "flask", "rails", "mongrel" + ) or + process.parent.name like "php-*" or + process.parent.name like "python*" or + process.parent.name like "ruby*" or + process.parent.name like "perl*" or + user.name in ( + "apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat", "tomcat8", "tomcat9", "ftp", "ftpuser", "ftpd" + ) or + user.id in ("99", "33", "498", "48") or + process.working_directory like "/var/www/*" +) and +not ( + process.working_directory like "/home/*" or + process.working_directory like "/" or + process.parent.executable like "/vscode/vscode-server/*" +) +| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable, process.working_directory, process.parent.executable +| where agent_count == 1 and cc < 5 +| sort cc asc +| limit 100 + +---------------------------------- + +*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-18-9/prebuilt-rules-8-18-9-appendix.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rules-8-18-9-appendix.asciidoc new file mode 100644 index 0000000000..519a9798af --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rules-8-18-9-appendix.asciidoc @@ -0,0 +1,53 @@ +["appendix",role="exclude",id="prebuilt-rule-8-18-9-prebuilt-rules-8-18-9-appendix"] += Downloadable rule update v8.18.9 + +This section lists all updates associated with version 8.18.9 of the Fleet integration *Prebuilt Security Detection Rules*. + + +include::prebuilt-rule-8-18-9-excessive-secret-or-key-retrieval-from-azure-key-vault.asciidoc[] +include::prebuilt-rule-8-18-9-azure-key-vault-secret-key-usage-by-unusual-identity.asciidoc[] +include::prebuilt-rule-8-18-9-teamfiltration-user-agents-detected.asciidoc[] +include::prebuilt-rule-8-18-9-oidc-discovery-url-changed-in-entra-id.asciidoc[] +include::prebuilt-rule-8-18-9-external-authentication-method-addition-or-modification-in-entra-id.asciidoc[] +include::prebuilt-rule-8-18-9-kubernetes-unusual-decision-by-user-agent.asciidoc[] +include::prebuilt-rule-8-18-9-potential-impersonation-attempt-via-kubectl.asciidoc[] +include::prebuilt-rule-8-18-9-unusual-kill-signal.asciidoc[] +include::prebuilt-rule-8-18-9-sudoers-file-modification.asciidoc[] +include::prebuilt-rule-8-18-9-aws-systems-manager-securestring-parameter-request-with-decryption-flag.asciidoc[] +include::prebuilt-rule-8-18-9-insecure-aws-ec2-vpc-security-group-ingress-rule-added.asciidoc[] +include::prebuilt-rule-8-18-9-aws-ec2-deprecated-ami-discovery.asciidoc[] +include::prebuilt-rule-8-18-9-aws-ec2-user-data-retrieval-for-ec2-instance.asciidoc[] +include::prebuilt-rule-8-18-9-aws-ssm-sendcommand-execution-by-rare-user.asciidoc[] +include::prebuilt-rule-8-18-9-aws-dynamodb-table-exported-to-s3.asciidoc[] +include::prebuilt-rule-8-18-9-aws-ec2-ami-shared-with-another-account.asciidoc[] +include::prebuilt-rule-8-18-9-excessive-aws-s3-object-encryption-with-sse-c.asciidoc[] +include::prebuilt-rule-8-18-9-aws-s3-object-encryption-using-external-kms-key.asciidoc[] +include::prebuilt-rule-8-18-9-unusual-aws-s3-object-encryption-with-sse-c.asciidoc[] +include::prebuilt-rule-8-18-9-aws-ec2-security-group-configuration-change.asciidoc[] +include::prebuilt-rule-8-18-9-aws-iam-api-calls-via-temporary-session-tokens.asciidoc[] +include::prebuilt-rule-8-18-9-aws-iam-user-created-access-keys-for-another-user.asciidoc[] +include::prebuilt-rule-8-18-9-aws-iam-administratoraccess-policy-attached-to-group.asciidoc[] +include::prebuilt-rule-8-18-9-aws-iam-administratoraccess-policy-attached-to-role.asciidoc[] +include::prebuilt-rule-8-18-9-aws-iam-administratoraccess-policy-attached-to-user.asciidoc[] +include::prebuilt-rule-8-18-9-aws-iam-customer-managed-policy-attached-to-role-by-rare-user.asciidoc[] +include::prebuilt-rule-8-18-9-aws-iam-assume-role-policy-update.asciidoc[] +include::prebuilt-rule-8-18-9-microsoft-entra-id-sign-in-brute-force-activity.asciidoc[] +include::prebuilt-rule-8-18-9-azure-key-vault-modified.asciidoc[] +include::prebuilt-rule-8-18-9-microsoft-entra-id-session-reuse-with-suspicious-graph-access.asciidoc[] +include::prebuilt-rule-8-18-9-m365-onedrive-excessive-file-downloads-with-oauth-token.asciidoc[] +include::prebuilt-rule-8-18-9-multiple-microsoft-365-user-account-lockouts-in-short-time-window.asciidoc[] +include::prebuilt-rule-8-18-9-multiple-device-token-hashes-for-single-okta-session.asciidoc[] +include::prebuilt-rule-8-18-9-multiple-okta-user-authentication-events-with-client-address.asciidoc[] +include::prebuilt-rule-8-18-9-multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc[] +include::prebuilt-rule-8-18-9-high-number-of-okta-device-token-cookies-generated-for-authentication.asciidoc[] +include::prebuilt-rule-8-18-9-okta-user-sessions-started-from-different-geolocations.asciidoc[] +include::prebuilt-rule-8-18-9-high-number-of-egress-network-connections-from-unusual-executable.asciidoc[] +include::prebuilt-rule-8-18-9-unusual-base64-encoding-decoding-activity.asciidoc[] +include::prebuilt-rule-8-18-9-potential-port-scanning-activity-from-compromised-host.asciidoc[] +include::prebuilt-rule-8-18-9-potential-subnet-scanning-activity-from-compromised-host.asciidoc[] +include::prebuilt-rule-8-18-9-unusual-file-transfer-utility-launched.asciidoc[] +include::prebuilt-rule-8-18-9-potential-malware-driven-ssh-brute-force-attempt.asciidoc[] +include::prebuilt-rule-8-18-9-unusual-process-spawned-from-web-server-parent.asciidoc[] +include::prebuilt-rule-8-18-9-unusual-command-execution-from-web-server-parent.asciidoc[] +include::prebuilt-rule-8-18-9-deprecated-aws-ec2-snapshot-activity.asciidoc[] +include::prebuilt-rule-8-18-9-deprecated-azure-virtual-network-device-modified-or-deleted.asciidoc[] diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rules-8-18-9-summary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rules-8-18-9-summary.asciidoc new file mode 100644 index 0000000000..ad35448488 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-18-9/prebuilt-rules-8-18-9-summary.asciidoc @@ -0,0 +1,106 @@ +[[prebuilt-rule-8-18-9-prebuilt-rules-8-18-9-summary]] +[role="xpack"] +== Update v8.18.9 + +This section lists all updates associated with version 8.18.9 of the Fleet integration *Prebuilt Security Detection Rules*. + + +[width="100%",options="header"] +|============================================== +|Rule |Description |Status |Version + +|<> | 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. | new | 1 + +|<> | Identifies secrets, keys, or certificates retrieval operations from Azure Key Vault by a user principal that has not been seen previously doing so in a certain amount of days. Azure Key Vault is a cloud service for securely storing and accessing secrets, keys, and certificates. Unauthorized or excessive retrievals may indicate potential abuse or unauthorized access attempts. | new | 2 + +|<> | Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs. | new | 1 + +|<> | Detects a change to the OpenID Connect (OIDC) discovery URL in the Entra ID Authentication Methods Policy. This behavior may indicate an attempt to federate Entra ID with an attacker-controlled identity provider, enabling bypass of multi-factor authentication (MFA) and unauthorized access through bring-your-own IdP (BYOIDP) methods. | new | 2 + +|<> | Identifies when an external authentication method (EAM) is added or modified in Entra ID. EAM may allow adversaries to bypass multi-factor authentication (MFA) requirements, potentially leading to unauthorized access to user accounts and sensitive resources by using bring-your-own IdP (BYOIDP) methods. | new | 1 + +|<> | This rule detects unusual request responses in Kubernetes audit logs through the use of the "new_terms" rule type. In production environments, default API requests are typically made by system components or trusted users, who are expected to have a consistent user agent and allowed response annotations. By monitoring for anomalies in the username and response annotations, this rule helps identify potential unauthorized access or misconfigurations in the Kubernetes environment. | new | 1 + +|<> | This rule detects potential impersonation attempts via the "kubectl" command in Linux environments. It identifies process events where "kubectl" is executed with arguments that suggest an attempt to impersonate another user or group, such as using "--kubeconfig", "--token", "--as", or "--as-group". This could indicate an adversary trying to gain unauthorized access or escalate privileges within a Kubernetes cluster. If this rule is triggered, in conjunction with rules related to secret access or kubeconfig file discovery, it may indicate a potential impersonation attempt. | new | 1 + +|<> | This rule detects the use of unusual kill signals, specifically kill signals in the range of 32-64, which are not commonly used in standard operations. Rootkits may leverage these signals to conduct certain actions, such as manipulating processes in unexpected ways, potentially escalating privileges or evading detection. | new | 1 + +|<> | A sudoers file specifies the commands that 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. | update | 209 + +|<> | 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. | update | 6 + +|<> | Identifies when a specified inbound (ingress) rule is added or adjusted for a VPC security group in AWS EC2. This rule detects when a security group rule is added that allows traffic from any IP address or from a specific IP address to common remote access ports, such as 22 (SSH) or 3389 (RDP). Adversaries may add these rules to allow remote access to VPC instances from any location, increasing the attack surface and potentially exposing the instances to unauthorized access. | update | 5 + +|<> | Identifies when a user has queried for deprecated Amazon Machine Images (AMIs) in AWS. This may indicate an adversary looking for outdated AMIs that may be vulnerable to exploitation. While deprecated AMIs are not inherently malicious or indicative of a breach, they may be more susceptible to vulnerabilities and should be investigated for potential security risks. | update | 6 + +|<> | Identifies discovery request DescribeInstanceAttribute with the attribute userData and instanceId in AWS CloudTrail logs. This may indicate an attempt to retrieve user data from an EC2 instance. Adversaries may use this information to gather sensitive data from the instance such as hardcoded credentials or to identify potential vulnerabilities. This is a New Terms rule that identifies the first time an IAM user or role requests the user data for a specific EC2 instance. | update | 7 + +|<> | Detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM), such as RunShellScript, RunPowerShellScript or custom documents. While legitimate users may employ these commands for management tasks, they can also be exploited by attackers with credentials to establish persistence, install malware, or execute reverse shells for further access to compromised instances. This is a New Terms rule that looks for the first instance of this behavior by a user or role. | update | 215 + +|<> | Identifies when an AWS DynamoDB table is exported to S3. Adversaries may use the ExportTableToPointInTime operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the ExportTableToPointInTime action in CloudTrail logs. This is a New Terms rule that only flags when this behavior is observed by the "user.name" for the first time. | update | 4 + +|<> | Identifies an AWS Amazon Machine Image (AMI) being shared with another AWS account. Adversaries with access may share an AMI with an external AWS account as a means of data exfiltration. AMIs can contain secrets, bash histories, code artifacts, and other sensitive data that adversaries may abuse if shared with unauthorized accounts. AMIs can be made publicly available accidentally as well. | update | 6 + +|<> | Identifies a high-volume of AWS S3 objects stored in a bucket using using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a Threshold rule that triggers when this behavior is observed multiple times for a specific bucket in a short time-window. | update | 4 + +|<> | Identifies `CopyObject` events within an S3 bucket using an AWS KMS key from an external account for encryption. Adversaries with access to a misconfigured S3 bucket and the proper permissions may encrypt objects with an external KMS key to deny their victims access to their own data. | update | 5 + +|<> | Identifies when AWS S3 objects stored in a bucket are encrypted using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a New Terms rule that flags when this behavior is observed for the first time user and target bucket name. | update | 4 + +|<> | Identifies a change to an AWS Security Group Configuration. A security group is like a virtual firewall, and modifying configurations may allow unauthorized access. Threat actors may abuse this to establish persistence, exfiltrate data, or pivot in an AWS environment. | update | 211 + +|<> | 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. | update | 3 + +|<> | 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 | 7 + +|<> | 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 | 5 + +|<> | 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 | 5 + +|<> | 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 | 6 + +|<> | Detects when an AWS Identity and Access Management (IAM) customer-managed policy is attached to a role by an unusual or unauthorized user. Customer-managed policies are policies created and controlled within an AWS account, granting specific permissions to roles or users when attached. This rule identifies potential privilege escalation by flagging cases where a customer-managed policy is attached to a role by an unexpected actor, which could signal unauthorized access or misuse. Attackers may attach policies to roles to expand permissions and elevate their privileges within the AWS environment. This is a New Terms rule that uses the "cloud.account.id", "user.name" and "target.entity.id" fields to check if the combination of the actor identity and target role name has not been seen before. | update | 5 + +|<> | 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. | update | 214 + +|<> | Identifies potential brute-force attacks targeting user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to applications integrated with Entra ID or to compromise valid user accounts. | update | 3 + +|<> | Identifies modifications to a Key Vault in Azure. The Key Vault is a service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. Because this data is sensitive and business critical, access to key vaults should be secured to allow only authorized applications and users. This is a New Terms rule that detects when this activity hasn't been seen by the user in a specified time frame. | update | 107 + +|<> | Identifies potential session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID within a short time window. This may indicate the use of a stolen refresh/access token or session cookie to impersonate the user and interact with Microsoft services. | update | 2 + +|<> | Identifies when an excessive number of files are downloaded from OneDrive using OAuth authentication. Adversaries may conduct phishing campaigns to steal OAuth tokens and impersonate users. These access tokens can then be used to download files from OneDrive. | update | 2 + +|<> | Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts. | update | 2 + +|<> | This rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources. | update | 306 + +|<> | Detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. | update | 205 + +|<> | Detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. | update | 205 + +|<> | Detects when an Okta client address has a certain threshold of Okta user authentication events with multiple device token hashes generated for single user authentication. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. | update | 205 + +|<> | Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations. | update | 306 + +|<> | This rule detects a high number of egress network connections from an unusual executable on a Linux system. This could indicate a command and control (C2) communication attempt, a brute force attack via a malware infection, or other malicious activity. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. | update | 4 + +|<> | This rule leverages ESQL to detect unusual base64 encoding/decoding activity on Linux systems. Attackers may use base64 encoding/decoding to obfuscate data, such as command and control traffic or payloads, to evade detection by host- or network-based security controls. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. | update | 4 + +|<> | This rule detects potential port scanning activity from a compromised host. Port scanning is a common reconnaissance technique used by attackers to identify open ports and services on a target system. A compromised host may exhibit port scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable services, or prepare for further exploitation. This rule identifies potential port scanning activity by monitoring network connection attempts from a single host to a large number of ports within a short time frame. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. | update | 4 + +|<> | This rule detects potential subnet scanning activity from a compromised host. Subnet scanning is a common reconnaissance technique used by attackers to identify live hosts within a network range. A compromised host may exhibit subnet scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable hosts, or prepare for further exploitation. This rule identifies potential subnet scanning activity by monitoring network connection attempts from a single host to a large number of hosts within a short time frame. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. | update | 4 + +|<> | This rule leverages ESQL to detect the execution of unusual file transfer utilities on Linux systems. Attackers may use these utilities to exfiltrate data from a compromised system. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. | update | 4 + +|<> | This detection identifies a Linux host that has potentially been infected with malware and is being used to conduct brute-force attacks against external systems over SSH (port 22 and common alternative SSH ports). The detection looks for a high volume of outbound connection attempts to non-private IP addresses from a single process. A compromised host may be part of a botnet or controlled by an attacker, attempting to gain unauthorized access to remote systems. This behavior is commonly observed in SSH brute-force campaigns where malware hijacks vulnerable machines to expand its attack surface. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. | update | 4 + +|<> | This rule detects unusual processes spawned from a web server parent process by identifying low frequency counts of process spawning activity. Unusual process spawning activity may indicate an attacker attempting to establish persistence, execute malicious commands, or establish command and control channels on the host system. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. | update | 4 + +|<> | This rule detects potential command execution from a web server parent process on a Linux host. Adversaries may attempt to execute commands from a web server parent process to blend in with normal web server activity and evade detection. This behavior is commonly observed in web shell attacks where adversaries exploit web server vulnerabilities to execute arbitrary commands on the host. The detection rule identifies unusual command execution from web server parent processes, which may indicate a compromised host or an ongoing attack. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. | update | 4 + +|<> | An attempt was made to modify AWS EC2 snapshot attributes. Snapshots are sometimes shared by threat actors in order to exfiltrate bulk data from an EC2 fleet. If the permissions were modified, verify the snapshot was not shared with an unauthorized or unexpected AWS account. | deprecated | 213 + +|<> | Identifies when a virtual network device is modified or deleted. This can be a network virtual appliance, virtual hub, or virtual router. **Deprecated Notice** - This rule has been deprecated in favor of other rules that provide more contextual threat behavior for Azure Virtual Network. | deprecated | 106 + +|============================================== diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc index 67704975d3..67e751e6ef 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 +|<> | 23 Jul 2025 | 8 | 37 | +This release includes new rules for Linux, Azure and Kubernetes. The deprecated rules includes Deprecated - Azure Virtual Network Device Modified or Deleted and Deprecated - AWS EC2 Snapshot Activity New rules for Linux include detection for defense evasion. New rules for Azure include detection for persistence, credential access and discovery. New rules for Kubernetes include detection for execution. Additionally, significant rule tuning for Linux, AWS and Azure rules has been added for better rule efficacy and performance. + + |<> | 08 Jul 2025 | 15 | 73 | This release includes new rules for Linux, Azure, Kubernetes and Microsoft 365. The deprecated rule includes Suspicious File Creation in /etc for Persistence New rules for Linux include detection for persistence, defense evasion, discovery, command and control and execution. New rules for Azure include detection for persistence, initial access and defense evasion. New rules for Kubernetes include detection for defense evasion and execution. New rules for Microsoft 365 include detection for collection. Additionally, significant rule tuning for Windows, Linux, AWS, Azure and Microsoft 365 rules has been added for better rule efficacy and performance. @@ -54,3 +58,4 @@ include::downloadable-packages/8-18-5/prebuilt-rules-8-18-5-summary.asciidoc[lev include::downloadable-packages/8-18-6/prebuilt-rules-8-18-6-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-18-7/prebuilt-rules-8-18-7-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-18-8/prebuilt-rules-8-18-8-summary.asciidoc[leveloffset=+1] +include::downloadable-packages/8-18-9/prebuilt-rules-8-18-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 48bc59a606..bb73b02b54 100644 --- a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc +++ b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc @@ -62,9 +62,11 @@ and their rule type is `machine_learning`. |<> |Identifies when an AWS DynamoDB table is scanned by a user who does not typically perform this action. Adversaries may use the Scan operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the Scan action in CloudTrail logs. This is a New Terms rule that only flags when this behavior is observed by the `aws.cloudtrail.user_identity.arn` for the first time in the last 14 days. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS DynamoDB], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Exfiltration] |None |3 -|<> |Identifies when an AWS DynamoDB table is exported to S3. Adversaries may use the ExportTableToPointInTime operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the ExportTableToPointInTime action in CloudTrail logs. This is a New Terms rule that only flags when this behavior is observed by the `aws.cloudtrail.user_identity.arn` for the first time in the last 14 days. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS DynamoDB], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Exfiltration] |None |3 +|<> |Identifies when an AWS DynamoDB table is exported to S3. Adversaries may use the ExportTableToPointInTime operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the ExportTableToPointInTime action in CloudTrail logs. This is a New Terms rule that only flags when this behavior is observed by the "user.name" for the first time. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS DynamoDB], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Exfiltration] |None |4 -|<> |Identifies when a user has queried for deprecated Amazon Machine Images (AMIs) in AWS. This may indicate an adversary looking for outdated AMIs that may be vulnerable to exploitation. While deprecated AMIs are not inherently malicious or indicative of a breach, they may be more susceptible to vulnerabilities and should be investigated for potential security risks. |[Domain: Cloud], [Data Source: AWS], [Data Source: AWS EC2], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Discovery] |None |5 +|<> |Identifies an AWS Amazon Machine Image (AMI) being shared with another AWS account. Adversaries with access may share an AMI with an external AWS account as a means of data exfiltration. AMIs can contain secrets, bash histories, code artifacts, and other sensitive data that adversaries may abuse if shared with unauthorized accounts. AMIs can be made publicly available accidentally as well. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Threat Detection], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |6 + +|<> |Identifies when a user has queried for deprecated Amazon Machine Images (AMIs) in AWS. This may indicate an adversary looking for outdated AMIs that may be vulnerable to exploitation. While deprecated AMIs are not inherently malicious or indicative of a breach, they may be more susceptible to vulnerabilities and should be investigated for potential security risks. |[Domain: Cloud], [Data Source: AWS], [Data Source: AWS EC2], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Discovery] |None |6 |<> |Identifies the removal of access permissions from a shared AWS EC2 EBS snapshot. EBS snapshots are essential for data retention and disaster recovery. Adversaries may revoke or modify snapshot permissions to prevent legitimate users from accessing backups, thereby obstructing recovery efforts after data loss or destructive actions. This tactic can also be used to evade detection or maintain exclusive access to critical backups, ultimately increasing the impact of an attack and complicating incident response. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |1 @@ -88,11 +90,11 @@ and their rule type is `machine_learning`. |<> |Identifies AWS CloudTrail events where an EC2 route table or association has been modified or deleted. Route table or association modifications can be used by attackers to disrupt network traffic, reroute communications, or maintain persistence in a compromised environment. This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that detects the first instance of this behavior by the `aws.cloudtrail.user_identity.arn` field in the last 10 days. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Network Security Monitoring], [Resources: Investigation Guide], [Tactic: Persistence] |None |210 -|<> |Identifies a change to an AWS Security Group Configuration. A security group is like a virtual firewall, and modifying configurations may allow unauthorized access. Threat actors may abuse this to establish persistence, exfiltrate data, or pivot in an AWS environment. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Network Security Monitoring], [Resources: Investigation Guide], [Tactic: Persistence], [Tactic: Defense Evasion] |None |210 +|<> |Identifies a change to an AWS Security Group Configuration. A security group is like a virtual firewall, and modifying configurations may allow unauthorized access. Threat actors may abuse this to establish persistence, exfiltrate data, or pivot in an AWS environment. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Network Security Monitoring], [Resources: Investigation Guide], [Tactic: Persistence], [Tactic: Defense Evasion] |None |211 |<> |Identifies the first occurrence of an unauthorized attempt by an AWS role to use `GetPassword` to access the administrator password of an EC2 instance. Adversaries may use this API call to escalate privileges or move laterally within EC2 instances. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Credential Access] |None |7 -|<> |Identifies discovery request DescribeInstanceAttribute with the attribute userData and instanceId in AWS CloudTrail logs. This may indicate an attempt to retrieve user data from an EC2 instance. Adversaries may use this information to gather sensitive data from the instance such as hardcoded credentials or to identify potential vulnerabilities. This is a New Terms rule that identifies the first time an IAM user or role requests the user data for a specific EC2 instance. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon EC2], [Resources: Investigation Guide], [Use Case: Log Auditing], [Tactic: Discovery] |None |6 +|<> |Identifies discovery request DescribeInstanceAttribute with the attribute userData and instanceId in AWS CloudTrail logs. This may indicate an attempt to retrieve user data from an EC2 instance. Adversaries may use this information to gather sensitive data from the instance such as hardcoded credentials or to identify potential vulnerabilities. This is a New Terms rule that identifies the first time an IAM user or role requests the user data for a specific EC2 instance. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon EC2], [Resources: Investigation Guide], [Use Case: Log Auditing], [Tactic: Discovery] |None |7 |<> |Identifies an attempt to export an AWS EC2 instance. A virtual machine (VM) export may indicate an attempt to extract or exfiltrate information. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Use Case: Asset Visibility], [Tactic: Exfiltration], [Tactic: Collection], [Resources: Investigation Guide] |None |209 @@ -106,15 +108,15 @@ and their rule type is `machine_learning`. |<> |Identifies the deletion of an Amazon GuardDuty detector. Upon deletion, GuardDuty stops monitoring the environment and all existing findings are lost. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |209 -|<> |Detects use of sensitive AWS STS or 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 |2 +|<> |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 |4 +|<> |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 |5 -|<> |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 |4 +|<> |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 |5 -|<> |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 |5 +|<> |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 |6 -|<> |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 "aws.cloudtrail.flattened.request_parameters.roleName" fields, that have not been seen making this API request within the last 14 days. |[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 |213 +|<> |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] |8.16.5 |214 |<> |Identifies a high number of failed attempts to assume an AWS Identity and Access Management (IAM) role. IAM roles are used to delegate access to users or services. An adversary may attempt to enumerate IAM roles in order to determine if a role exists before attempting to assume or hijack the discovered role. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Credential Access] |None |212 @@ -122,7 +124,7 @@ and their rule type is `machine_learning`. |<> |Detects the creation of an AWS Identity and Access Management (IAM) user initiated by an assumed role on an EC2 instance. Assumed roles allow users or services to temporarily adopt different AWS permissions, but the creation of IAM users through these roles—particularly from within EC2 instances—may indicate a compromised instance. Adversaries might exploit such permissions to establish persistence by creating new IAM users under unauthorized conditions. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |4 -|<> |Detects when an AWS Identity and Access Management (IAM) customer-managed policy is attached to a role by an unusual or unauthorized user. Customer-managed policies are policies created and controlled within an AWS account, granting specific permissions to roles or users when attached. This rule identifies potential privilege escalation by flagging cases where a customer-managed policy is attached to a role by an unexpected actor, which could signal unauthorized access or misuse. Attackers may attach policies to roles to expand permissions and elevate their privileges within the AWS environment. This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that uses the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.flattened.request_parameters.roleName` fields to check if the combination of the actor ARN and target role name has not been seen in the last 14 days. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Resources: Investigation Guide], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation] |None |4 +|<> |Detects when an AWS Identity and Access Management (IAM) customer-managed policy is attached to a role by an unusual or unauthorized user. Customer-managed policies are policies created and controlled within an AWS account, granting specific permissions to roles or users when attached. This rule identifies potential privilege escalation by flagging cases where a customer-managed policy is attached to a role by an unexpected actor, which could signal unauthorized access or misuse. Attackers may attach policies to roles to expand permissions and elevate their privileges within the AWS environment. This is a New Terms rule that uses the "cloud.account.id", "user.name" and "target.entity.id" fields to check if the combination of the actor identity and target role name has not been seen before. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Resources: Investigation Guide], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation] |8.16.5 |5 |<> |Identifies the deactivation of a specified multi-factor authentication (MFA) device and removes it from association with the user name for which it was originally enabled. In AWS Identity and Access Management (IAM), a device must be deactivated before it can be deleted. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Resources: Investigation Guide], [Tactic: Impact], [Tactic: Persistence] |None |212 @@ -144,7 +146,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 |6 +|<> |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 |<> |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 @@ -210,7 +212,7 @@ and their rule type is `machine_learning`. |<> |Identifies when server access logging is disabled for an Amazon S3 bucket. Server access logs provide a detailed record of requests made to an S3 bucket. When server access logging is disabled for a bucket, it could indicate an adversary's attempt to impair defenses by disabling logs that contain evidence of malicious activity. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon S3], [Use Case: Asset Visibility], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |4 -|<> |Identifies `CopyObject` events within an S3 bucket using an AWS KMS key from an external account for encryption. Adversaries with access to a misconfigured S3 bucket and the proper permissions may encrypt objects with an external KMS key to deny their victims access to their own data. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Data Source: AWS KMS], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |4 +|<> |Identifies `CopyObject` events within an S3 bucket using an AWS KMS key from an external account for encryption. Adversaries with access to a misconfigured S3 bucket and the proper permissions may encrypt objects with an external KMS key to deny their victims access to their own data. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Data Source: AWS KMS], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |5 |<> |Identifies when object versioning is suspended for an Amazon S3 bucket. Object versioning allows for multiple versions of an object to exist in the same bucket. This allows for easy recovery of deleted or overwritten objects. When object versioning is suspended for a bucket, it could indicate an adversary's attempt to inhibit system recovery following malicious activity. Additionally, when versioning is suspended, buckets can then be deleted. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |5 @@ -226,7 +228,7 @@ and their rule type is `machine_learning`. |<> |Identifies when an AWS Systems Manager (SSM) command document is created by a user or role who does not typically perform this action. Adversaries may create SSM command documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, data exfiltration and more. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS SSM], [Data Source: AWS Systems Manager], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Execution] |None |5 -|<> |Detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM), such as RunShellScript, RunPowerShellScript or custom documents. While legitimate users may employ these commands for management tasks, they can also be exploited by attackers with credentials to establish persistence, install malware, or execute reverse shells for further access to compromised instances. This is a New Terms rule that looks for the first instance of this behavior by a user or role. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS SSM], [Data Source: AWS Systems Manager], [Use Case: Log Auditing], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |214 +|<> |Detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM), such as RunShellScript, RunPowerShellScript or custom documents. While legitimate users may employ these commands for management tasks, they can also be exploited by attackers with credentials to establish persistence, install malware, or execute reverse shells for further access to compromised instances. This is a New Terms rule that looks for the first instance of this behavior by a user or role. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS SSM], [Data Source: AWS Systems Manager], [Use Case: Log Auditing], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |215 |<> |Identifies the use of the AWS Systems Manager (SSM) `SendCommand` API with the either `AWS-RunShellScript` or `AWS-RunPowerShellScript` parameters. The `SendCommand` API call allows users to execute commands on EC2 instances using the SSM service. Adversaries may use this technique to execute commands on EC2 instances without the need for SSH or RDP access. This behavior may indicate an adversary attempting to execute commands on an EC2 instance for malicious purposes. This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that only flags when this behavior is observed for the first time on a host in the last 7 days. |[Domain: Endpoint], [Domain: Cloud], [OS: Linux], [OS: macOS], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Resources: Investigation Guide] |None |6 @@ -248,7 +250,7 @@ and their rule type is `machine_learning`. |<> |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 |3 -|<> |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 [NewTerms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that detects the first occurrence of a specific AWS ARN accessing SecureString parameters with decryption within the last 10 days. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Systems Manager], [Tactic: Credential Access], [Resources: Investigation Guide] |None |5 +|<> |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 |<> |Identifies the deletion of one or more flow logs in AWS Elastic Compute Cloud (EC2). An adversary may delete flow logs in an attempt to evade defenses. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Log Auditing], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |212 @@ -430,7 +432,9 @@ and their rule type is `machine_learning`. |<> |Identifies an Azure Active Directory (AD) Global Administrator role addition to a Privileged Identity Management (PIM) user account. PIM is a service that enables you to manage, control, and monitor access to important resources in an organization. Users who are assigned to the Global administrator role can read and modify any administrative setting in your Azure AD organization. |[Domain: Cloud], [Data Source: Azure], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |105 -|<> |Identifies modifications to a Key Vault in Azure. The Key Vault is a service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. Because this data is sensitive and business critical, access to key vaults should be secured to allow only authorized applications and users. |[Domain: Cloud], [Data Source: Azure], [Tactic: Credential Access], [Resources: Investigation Guide] |None |106 +|<> |Identifies modifications to a Key Vault in Azure. The Key Vault is a service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. Because this data is sensitive and business critical, access to key vaults should be secured to allow only authorized applications and users. This is a New Terms rule that detects when this activity hasn't been seen by the user in a specified time frame. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Azure Activity Logs], [Tactic: Impact], [Use Case: Configuration Audit], [Resources: Investigation Guide] |None |107 + +|<> |Identifies secrets, keys, or certificates retrieval operations from Azure Key Vault by a user principal that has not been seen previously doing so in a certain amount of days. Azure Key Vault is a cloud service for securely storing and accessing secrets, keys, and certificates. Unauthorized or excessive retrievals may indicate potential abuse or unauthorized access attempts. |[Domain: Cloud], [Domain: Storage], [Domain: Identity], [Data Source: Azure], [Data Source: Azure Platform Logs], [Data Source: Azure Key Vault], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Resources: Investigation Guide] |None |2 |<> |Identifies when events are deleted in Azure Kubernetes. Kubernetes events are objects that log any state changes. Example events are a container creation, an image pull, or a pod scheduling on a node. An adversary may delete events in Azure Kubernetes in an attempt to evade detection. |[Domain: Cloud], [Data Source: Azure], [Use Case: Log Auditing], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |105 @@ -584,12 +588,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 -|<> |An attempt was made to modify AWS EC2 snapshot attributes. Snapshots are sometimes shared by threat actors in order to exfiltrate bulk data from an EC2 fleet. If the permissions were modified, verify the snapshot was not shared with an unauthorized or unexpected AWS account. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Use Case: Asset Visibility], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |212 - |<> |Identifies potential brute-force attempts against Microsoft 365 user accounts by detecting a high number of failed interactive or non-interactive login attempts within a 30-minute window from a single source. Attackers may attempt to brute force user accounts to gain unauthorized access to Microsoft 365 services via different services such as Exchange, SharePoint, or Teams. |[Domain: Cloud], [Domain: SaaS], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |4 -|<> |Identifies when a virtual network device is modified or deleted. This can be a network virtual appliance, virtual hub, or virtual router. **Deprecated Notice** - This rule has been deprecated in favor of other rules that provide more contextual threat behavior for Azure Virtual Network. |[Domain: Cloud], [Data Source: Azure], [Use Case: Network Security Monitoring], [Tactic: Impact], [Resources: Investigation Guide] |None |105 - |<> |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 |<> |This rule identifies the creation of directories in the /bin directory. The /bin directory contains essential binary files that are required for the system to function properly. The creation of directories in this location could be an attempt to hide malicious files or executables, as these /bin directories usually just contain binaries. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |105 @@ -634,8 +634,6 @@ and their rule type is `machine_learning`. |<> |Detects the creation or modification of files related to the dynamic linker on Linux systems. The dynamic linker is a shared library that is used by the Linux kernel to load and execute programs. Attackers may attempt to hijack the execution flow of a program by modifying the dynamic linker configuration files. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |6 -|<> |Identifies an AWS Amazon Machine Image (AMI) being shared with another AWS account. Adversaries with access may share an AMI with an external AWS account as a means of data exfiltration. AMIs can contain secrets, bash histories, code artifacts, and other sensitive data that adversaries may abuse if shared with unauthorized accounts. AMIs can be made publicly available accidentally as well. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Threat Detection], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |5 - |<> |Identifies instances where the 'find' command is started on a Linux system with arguments targeting specific VM-related paths, such as "/etc/vmware/", "/usr/lib/vmware/", or "/vmfs/*". These paths are associated with VMware virtualization software, and their presence in the find command arguments may indicate that a threat actor is attempting to search for, analyze, or manipulate VM-related files and configurations on the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |111 |<> |Identifies instances where a process named 'grep', 'egrep', or 'pgrep' is started on a Linux system with arguments related to virtual machine (VM) files, such as "vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", or "vmem". These file extensions are associated with VM-related file formats, and their presence in grep command arguments may indicate that a threat actor is attempting to search for, analyze, or manipulate VM files on the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |111 @@ -684,10 +682,12 @@ and their rule type is `machine_learning`. |<> |Identifies the execution of macOS built-in commands related to account or group enumeration. Adversaries may use account and group information to orient themselves before deciding how to act. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |212 -|<> |Identifies a high-volume of AWS S3 objects stored in a bucket using using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a [Threshold](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-threshold-rule) rule that flags when this behavior is observed for a specific bucket more than 15 times in a short time-window. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Impact] |None |3 +|<> |Identifies a high-volume of AWS S3 objects stored in a bucket using using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a Threshold rule that triggers when this behavior is observed multiple times for a specific bucket in a short time-window. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Impact] |None |4 |<> |Identifies an excessive number of Microsoft 365 mailbox items accessed by a user either via aggregated counts or throttling. Microsoft audits mailbox access via the MailItemsAccessed event, which is triggered when a user accesses mailbox items. If more than 1000 mailbox items are accessed within a 24-hour period, it is then throttled. Excessive mailbox access may indicate an adversary attempting to exfiltrate sensitive information or perform reconnaissance on a target's mailbox. This rule detects both the throttled and unthrottled events with a high threshold. |[Domain: Cloud], [Domain: Email], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Tactic: Collection], [Resources: Investigation Guide] |None |1 +|<> |Identifies 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 |1 + |<> |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 |212 |<> |This rule monitors for the addition of an executable bit for scripts that are located in directories which are commonly abused for persistence. An alert of this rule is an indicator that a persistence mechanism is being set up within your environment. Adversaries may create these scripts to execute malicious code at start-up, or at a set interval to gain persistence onto the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |107 @@ -742,6 +742,8 @@ and their rule type is `machine_learning`. |<> |Generates a detection alert for each external alert written to the configured indices. Enabling this rule allows you to immediately begin investigating external alerts in the app. |[OS: Windows], [Data Source: APM], [OS: macOS], [OS: Linux], [Resources: Investigation Guide] |None |105 +|<> |Identifies when an external authentication method (EAM) is added or modified in Entra ID. EAM may allow adversaries to bypass multi-factor authentication (MFA) requirements, potentially leading to unauthorized access to user accounts and sensitive resources by using bring-your-own IdP (BYOIDP) methods. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Graph], [Data Source: Microsoft Graph Activity Logs], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Persistence] |None |1 + |<> |Identifies domains commonly used by adversaries for post-exploitation IP lookups. It is common for adversaries to test for Internet access and acquire their external IP address after they have gained access to a system. Among others, this has been observed in campaigns leveraging the information stealer, Trickbot. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Rule Type: BBR] |None |110 |<> |Detects an external Google Workspace user account being added to an existing group. Adversaries may add external user accounts as a means to intercept shared files or emails with that specific group. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |5 @@ -952,9 +954,9 @@ and their rule type is `machine_learning`. |<> |Detects a high number of unique private repo clone events originating from a single personal access token within a short time period. |[Domain: Cloud], [Use Case: Threat Detection], [Use Case: UEBA], [Tactic: Execution], [Data Source: Github], [Resources: Investigation Guide] |None |207 -|<> |This rule detects a high number of egress network connections from an unusual executable on a Linux system. This could indicate a command and control (C2) communication attempt, a brute force attack via a malware infection, or other malicious activity. ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |3 +|<> |This rule detects a high number of egress network connections from an unusual executable on a Linux system. This could indicate a command and control (C2) communication attempt, a brute force attack via a malware infection, or other malicious activity. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |4 -|<> |Detects when an Okta client address has a certain threshold of Okta user authentication events with multiple device token hashes generated for single user authentication. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Resources: Investigation Guide] |None |204 +|<> |Detects when an Okta client address has a certain threshold of Okta user authentication events with multiple device token hashes generated for single user authentication. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Resources: Investigation Guide] |None |205 |<> |Identifies a high number of Okta user password reset or account unlock attempts. An adversary may attempt to obtain unauthorized access to Okta user accounts using these methods and attempt to blend in with normal activity in their target's environment and evade detection. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |415 @@ -1004,7 +1006,7 @@ and their rule type is `machine_learning`. |<> |This rule detects the unpacking of an initramfs image using the `unmkinitramfs` command on Linux systems. The `unmkinitramfs` command is used to extract the contents of an initramfs image, which is used to boot the system. Attackers may use `unmkinitramfs` to unpack an initramfs image and modify its contents to include malicious code or backdoors, allowing them to maintain persistence on the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |4 -|<> |Identifies when a specified inbound (ingress) rule is added or adjusted for a VPC security group in AWS EC2. This rule detects when a security group rule is added that allows traffic from any IP address or from a specific IP address to common remote access ports, such as 22 (SSH) or 3389 (RDP). Adversaries may add these rules to allow remote access to VPC instances from any location, increasing the attack surface and potentially exposing the instances to unauthorized access. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |4 +|<> |Identifies when a specified inbound (ingress) rule is added or adjusted for a VPC security group in AWS EC2. This rule detects when a security group rule is added that allows traffic from any IP address or from a specific IP address to common remote access ports, such as 22 (SSH) or 3389 (RDP). Adversaries may add these rules to allow remote access to VPC instances from any location, increasing the attack surface and potentially exposing the instances to unauthorized access. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |5 |<> |InstallUtil is a command-line utility that allows for installation and uninstallation of resources by executing specific installer components specified in .NET binaries. Adversaries may use InstallUtil to proxy the execution of code through a trusted Windows utility. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Rule Type: BBR], [Data Source: Elastic Endgame], [Data Source: Windows Security Event Logs] |None |107 @@ -1098,6 +1100,8 @@ and their rule type is `machine_learning`. |<> |This rule detects when a service account or node attempts to enumerate their own permissions via the selfsubjectaccessreview or selfsubjectrulesreview APIs. This is highly unusual behavior for non-human identities like service accounts and nodes. An adversary may have gained access to credentials/tokens and this could be an attempt to determine what privileges they have to facilitate further movement or execution within the cluster. |[Data Source: Kubernetes], [Tactic: Discovery], [Resources: Investigation Guide] |None |207 +|<> |This rule detects unusual request responses in Kubernetes audit logs through the use of the "new_terms" rule type. In production environments, default API requests are typically made by system components or trusted users, who are expected to have a consistent user agent and allowed response annotations. By monitoring for anomalies in the username and response annotations, this rule helps identify potential unauthorized access or misconfigurations in the Kubernetes environment. |[Domain: Kubernetes], [Domain: Container], [Use Case: Threat Detection], [Data Source: Kubernetes], [Tactic: Execution], [Resources: Investigation Guide] |None |1 + |<> |This rule detects a user attempt to establish a shell session into a pod using the 'exec' command. Using the 'exec' command in a pod allows a user to establish a temporary shell session and execute any process/commands in the pod. An adversary may call bash to gain a persistent interactive shell which will allow access to any data the pod has permissions to, including secrets. |[Data Source: Kubernetes], [Tactic: Execution], [Resources: Investigation Guide] |None |208 |<> |Identifies the creation of a Local Security Authority Subsystem Service (lsass.exe) default memory dump. This may indicate a credential access attempt via trusted system utilities such as Task Manager (taskmgr.exe) and SQL Dumper (sqldumper.exe) or known pentesting tools such as Dumpert and AndrewSpecial. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne] |None |314 @@ -1142,7 +1146,7 @@ and their rule type is `machine_learning`. |<> |This rule identifies successful logins by system users that are uncommon to authenticate. These users have `nologin` set by default, and must be modified to allow SSH access. Adversaries may backdoor these users to gain unauthorized access to the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Data Source: System], [Resources: Investigation Guide] |None |4 -|<> |Identifies when an excessive number of files are downloaded from OneDrive using OAuth authentication. Adversaries may conduct phishing campaigns to steal OAuth tokens and impersonate users. These access tokens can then be used to download files from OneDrive. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: SharePoint], [Data Source: OneDrive], [Use Case: Threat Detection], [Tactic: Collection], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |1 +|<> |Identifies when an excessive number of files are downloaded from OneDrive using OAuth authentication. Adversaries may conduct phishing campaigns to steal OAuth tokens and impersonate users. These access tokens can then be used to download files from OneDrive. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: SharePoint], [Data Source: OneDrive], [Use Case: Threat Detection], [Tactic: Collection], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |2 |<> |Detects multi-factor authentication (MFA) deactivation with no subsequent re-activation for an Okta user account. An adversary may deactivate MFA for an Okta user account in order to weaken the authentication requirements for the account. |[Tactic: Persistence], [Use Case: Identity and Access Audit], [Data Source: Okta], [Domain: Cloud], [Resources: Investigation Guide] |None |415 @@ -1274,7 +1278,7 @@ and their rule type is `machine_learning`. |<> |Identifies when new Service Principal credentials have been added in Microsoft Entra ID. In most organizations, credentials will be added to service principals infrequently. Hijacking an application (by adding a rogue secret or certificate) with granted permissions will allow the attacker to access data that is normally protected by MFA requirements. |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |107 -|<> |Identifies potential session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID within a short time window. This may indicate the use of a stolen refresh/access token or session cookie to impersonate the user and interact with Microsoft services. |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-In Logs], [Data Source: Microsoft Graph], [Data Source: Microsoft Graph Activity Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Defense Evasion], [Tactic: Initial Access] |None |1 +|<> |Identifies potential session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID within a short time window. This may indicate the use of a stolen refresh/access token or session cookie to impersonate the user and interact with Microsoft services. |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-In Logs], [Data Source: Microsoft Graph], [Data Source: Microsoft Graph Activity Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Defense Evasion], [Tactic: Initial Access] |None |2 |<> |This rule detects non-interactive authentication activity against SharePoint Online (`Office 365 SharePoint Online`) by a user principal via the `Microsoft Authentication Broker` application. The session leverages a refresh token or Primary Refresh Token (PRT) without interactive sign-in, often used in OAuth phishing or token replay scenarios. |[Domain: Cloud], [Use Case: Identity and Access Audit], [Tactic: Collection], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Resources: Investigation Guide] |None |2 @@ -1342,13 +1346,13 @@ and their rule type is `machine_learning`. |<> |This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |6 -|<> |This rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Domain: SaaS], [Resources: Investigation Guide] |None |305 +|<> |This rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Domain: SaaS], [Resources: Investigation Guide] |None |306 |<> |Identifies multiple logon failures followed by a successful one from the same source address. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to accounts. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: Windows Security Event Logs] |None |115 |<> |Identifies multiple consecutive logon failures from the same source address and within a short time interval. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to accounts. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: Windows Security Event Logs] |None |114 -|<> |Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 +|<> |Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Resources: Investigation Guide] |None |2 |<> |Identifies more than two Microsoft Entra ID Protection alerts associated to the user principal in a short time period. Microsoft Entra ID Protection alerts are triggered by suspicious sign-in activity, such as anomalous IP addresses, risky sign-ins, or other risk detections. Multiple alerts in a short time frame may indicate an ongoing attack or compromised account. |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Protection Logs], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Initial Access] |None |1 @@ -1356,9 +1360,9 @@ and their rule type is `machine_learning`. |<> |Detects when Okta user authentication events are reported for multiple users with the same device token hash behind a proxy. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Resources: Investigation Guide] |None |209 -|<> |Detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Resources: Investigation Guide] |None |204 +|<> |Detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Resources: Investigation Guide] |None |205 -|<> |Detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Resources: Investigation Guide] |None |204 +|<> |Detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Resources: Investigation Guide] |None |205 |<> |Windows Credential Manager allows you to create, view, or delete saved credentials for signing into websites, connected applications, and networks. An adversary may abuse this to list or dump credentials stored in the Credential Manager for saved usernames and passwords. This may also be performed in preparation of lateral movement. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |115 @@ -1434,6 +1438,8 @@ and their rule type is `machine_learning`. |<> |Detects the occurrence of mailbox audit bypass associations. The mailbox audit is responsible for logging specified mailbox events (like accessing a folder or a message or permanently deleting a message). However, actions taken by some authorized accounts, such as accounts used by third-party tools or accounts used for lawful monitoring, can create a large number of mailbox audit log entries and may not be of interest to your organization. Because of this, administrators can create bypass associations, allowing certain accounts to perform their tasks without being logged. Attackers can abuse this allowlist mechanism to conceal actions taken, as the mailbox audit will log no activity done by the account. |[Domain: Cloud], [Data Source: Microsoft 365], [Tactic: Initial Access], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |209 +|<> |Detects a change to the OpenID Connect (OIDC) discovery URL in the Entra ID Authentication Methods Policy. This behavior may indicate an attempt to federate Entra ID with an attacker-controlled identity provider, enabling bypass of multi-factor authentication (MFA) and unauthorized access through bring-your-own IdP (BYOIDP) methods. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |2 + |<> |Identifies the modification of the Microsoft Office "Office Test" Registry key, a registry location that can be used to specify a DLL which will be executed every time an MS Office application is started. Attackers can abuse this to gain persistence on a compromised host. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |106 |<> |Identifies a high number of failed Okta user authentication attempts from a single IP address, which could be indicative of a brute force or password spraying attack. An adversary may attempt a brute force or password spraying attack to obtain unauthorized access to user accounts. |[Use Case: Identity and Access Audit], [Tactic: Credential Access], [Data Source: Okta], [Resources: Investigation Guide] |None |415 @@ -1446,7 +1452,7 @@ and their rule type is `machine_learning`. |<> |A user has initiated a session impersonation granting them access to the environment with the permissions of the user they are impersonating. This would likely indicate Okta administrative access and should only ever occur if requested and expected. |[Use Case: Identity and Access Audit], [Tactic: Credential Access], [Data Source: Okta], [Resources: Investigation Guide] |None |414 -|<> |Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Initial Access], [Resources: Investigation Guide] |None |305 +|<> |Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Initial Access], [Resources: Investigation Guide] |None |306 |<> |Identifies the occurence of files uploaded to OneDrive being detected as Malware by the file scanning engine. Attackers can use File Sharing and Organization Repositories to spread laterally within the company and amplify their access. Users can inadvertently share these files without knowing their maliciousness, giving adversaries opportunity to gain initial access to other endpoints in the environment. |[Domain: Cloud], [Data Source: Microsoft 365], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |209 @@ -1628,6 +1634,8 @@ and their rule type is `machine_learning`. |<