diff --git a/rules/integrations/aws/collection_cloudtrail_logging_created.toml b/rules/integrations/aws/collection_cloudtrail_logging_created.toml index 9596dc81e..21998af81 100644 --- a/rules/integrations/aws/collection_cloudtrail_logging_created.toml +++ b/rules/integrations/aws/collection_cloudtrail_logging_created.toml @@ -2,7 +2,7 @@ creation_date = "2020/06/10" integration = ["aws"] maturity = "production" -updated_date = "2025/11/07" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -26,9 +26,6 @@ license = "Elastic License v2" name = "AWS CloudTrail Log Created" note = """## 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 CloudTrail Log Created AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. Adversaries may create new trails to capture sensitive data or cover their tracks. This detection identifies diff --git a/rules/integrations/aws/collection_s3_unauthenticated_bucket_access_by_rare_source.toml b/rules/integrations/aws/collection_s3_unauthenticated_bucket_access_by_rare_source.toml index 6b645d1ed..d649ef077 100644 --- a/rules/integrations/aws/collection_s3_unauthenticated_bucket_access_by_rare_source.toml +++ b/rules/integrations/aws/collection_s3_unauthenticated_bucket_access_by_rare_source.toml @@ -2,7 +2,7 @@ creation_date = "2024/12/17" integration = ["aws"] maturity = "production" -updated_date = "2025/12/16" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -19,9 +19,6 @@ license = "Elastic License v2" name = "AWS S3 Unauthenticated Bucket Access by Rare Source" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - ### Investigating AWS S3 Unauthenticated Bucket Access by Rare Source This rule detects requests to an AWS S3 bucket by an unauthenticated source, which could indicate a misconfigured bucket policy allowing public access. Adversaries can exploit this misconfiguration by using tools or AWS CLI options like `--no-sign-request` to access bucket contents. @@ -30,32 +27,32 @@ The rule triggers when an unauthenticated IP address retrieves an object, and th ### Possible Investigation Steps -1. **Identify the Source of the Request**: +**Identify the Source of the Request**: - Review the `source.address` field to determine the IP address of the request source. - Check `source.geo` fields for geographic details of the originating IP address. - Analyze the `user_agent.original` field to identify the client or tool used (e.g., `Python Requests`, `aws-cli`, browser). -2. **Review the Accessed Bucket and Object**: +**Review the Accessed Bucket and Object**: - Analyze the `aws.cloudtrail.resources.arn` field to identify the S3 bucket and object being accessed. - Inspect `aws.cloudtrail.request_parameters` for bucket name and object key to determine which file was retrieved. - Review the `even.action` field to identify which API call was made (e.g., `GetObject`, `ListObjects`, `PutObject`, `ListBucket`). -3. **Validate the Source IP and Context**: +**Validate the Source IP and Context**: - Determine if the IP address (`source.address`) has any prior activity in your environment. - Correlate the IP with threat intelligence or blocklist databases to check for malicious indicators. - Review CloudTrail logs for other activities originating from the same IP. -4. **Analyze the S3 Bucket Configuration**: +**Analyze the S3 Bucket Configuration**: - Review the S3 bucket's Access Control List (ACL) and bucket policy to check for misconfigurations allowing public or unauthenticated access. - Look for overly permissive settings, such as `Principal: *` or `Effect: Allow` rules that expose the bucket. -5. **Investigate Additional Activity**: +**Investigate Additional Activity**: - Check if there are subsequent actions, such as: - **Additional `GetObject` API calls**: Indicating further data exfiltration. - **ListObjects requests**: Attempting to enumerate the bucket's contents. - Correlate events within the same timeframe to identify related suspicious activity. -6. **Assess the Data Exposed**: +**Assess the Data Exposed**: - Identify the retrieved object(s) and analyze their content to assess potential data exposure. - Determine if the file contains sensitive information, such as credentials, intellectual property, or PII. @@ -66,20 +63,20 @@ The rule triggers when an unauthenticated IP address retrieves an object, and th ### Response and Remediation -1. **Immediate Action**: +**Immediate Action**: - Restrict or remove public access to the affected S3 bucket. - Update the bucket policy to ensure access is restricted to trusted principals. - Enable **S3 Block Public Access** settings to prevent unintended public access. -2. **Monitoring and Detection**: +**Monitoring and Detection**: - Enable detailed logging and monitoring for all S3 bucket activities. - Configure real-time alerts for unauthenticated `GetObject` or `ListObjects` events on sensitive S3 buckets. -3. **Security Audits**: +**Security Audits**: - Regularly audit S3 bucket policies and ACLs to ensure they adhere to AWS security best practices. - Use AWS tools like **Trusted Advisor** or **Access Analyzer** to identify and address misconfigurations. -4. **Investigate for Data Exfiltration**: +**Investigate for Data Exfiltration**: - Analyze historical CloudTrail logs to determine if other sensitive files were accessed or exfiltrated. - Assess the scope of the exposure and initiate further response if sensitive data was compromised. diff --git a/rules/integrations/aws/credential_access_iam_user_addition_to_group.toml b/rules/integrations/aws/credential_access_iam_user_addition_to_group.toml index 7233b4912..d134a095d 100644 --- a/rules/integrations/aws/credential_access_iam_user_addition_to_group.toml +++ b/rules/integrations/aws/credential_access_iam_user_addition_to_group.toml @@ -2,7 +2,7 @@ creation_date = "2020/06/04" integration = ["aws"] maturity = "production" -updated_date = "2025/10/30" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -27,9 +27,6 @@ license = "Elastic License v2" name = "AWS IAM User Addition to Group" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - ### Investigating AWS IAM User Addition to Group This rule detects when an IAM user is added to an IAM group via the `AddUserToGroup` API call. If the target group holds elevated privileges, this action may immediately grant that user wide-ranging access useful for credential misuse or lateral movement. This rule helps detect unauthorized privilege escalation via group membership change. Treat as high-risk when the destination group has wide scope (e.g., AdministratorAccess or permissive inline policies). @@ -60,9 +57,11 @@ This rule detects when an IAM user is added to an IAM group via the `AddUserToGr - **Containment**: - If unapproved, remove the user from the group immediately (`RemoveUserFromGroup`) and rotate their access keys. - Temporarily restrict group policy changes while assessing blast radius. + - **Investigation and scoping**: - Review all actions executed by the newly added user since the change (ex: PutBucketPolicy, CreateAccessKey, PassRole). - Confirm whether other users were added to the same group within the same window. + - **Recovery and hardening**: - Enforce least privilege by redesigning large-group membership. - Restrict `iam:AddUserToGroup` to only appropriate service principals with approval workflow. diff --git a/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml b/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml index 5af5ee246..2fd99ea0b 100644 --- a/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml +++ b/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml @@ -2,7 +2,7 @@ creation_date = "2020/07/21" integration = ["aws"] maturity = "production" -updated_date = "2025/10/10" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -24,9 +24,6 @@ license = "Elastic License v2" name = "AWS Management Console Brute Force of Root User Identity" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - ### Investigating AWS Management Console Brute Force of Root User Identity The AWS Management Console provides a web interface for managing AWS resources. Because the root user has unrestricted privileges, repeated failed console login attempts targeting this identity represent a high-risk credential access event. Even if no login succeeded, this activity may indicate reconnaissance, password spraying, or credential stuffing attempts targeting the root user. @@ -69,7 +66,7 @@ Threshold rules only summarize grouped field values, so analysts must use timeli > The AWS Incident Response Playbooks classify root login attempts as Priority-1 credential compromise events. > Follow these steps whether or not your organization has a formal IR team. -**1. Immediate containment** +**Immediate containment** - **Check for success.** After pivoting to Timeline, confirm whether any `ConsoleLogin` events from the same IP or user agent show `event.oucome: success`. - If a successful login occurred, immediately follow the *AWS Management Console Root Login* rule investigation guide. @@ -81,16 +78,16 @@ Threshold rules only summarize grouped field values, so analysts must use timeli - **Alert internal teams.** Notify your security operations or cloud governance teams of the brute force pattern and actions taken. -**2. Evidence preservation** +**Evidence preservation** - Export all failed `ConsoleLogin` events visible in Timeline (±30 minutes around the alert window) to a restricted evidence bucket. - Preserve GuardDuty findings, AWS Config history, and CloudTrail logs for the same timeframe for further analysis. -**3. Scoping and investigation** +**Scoping and investigation** - Query CloudTrail across other AWS accounts and regions for additional failed or successful `ConsoleLogin` events from the same IPs. - Check IAM activity for simultaneous key creation, role modifications, or new users — signs of lateral or parallel intrusion attempts. - Review network telemetry (VPC Flow Logs, CloudFront, WAF) to determine whether the activity originated from a distributed or scripted attack pattern. -**4. Recovery and hardening** +**Recovery and hardening** - Confirm MFA is enabled and enforced on the root account. - Remove any root access keys (none should exist under normal security posture). - Enable organization-wide CloudTrail, GuardDuty, and Security Hub across all regions. diff --git a/rules/integrations/aws/defense_evasion_cloudtrail_logging_deleted.toml b/rules/integrations/aws/defense_evasion_cloudtrail_logging_deleted.toml index 642cd5ab3..bd7b5bb2f 100644 --- a/rules/integrations/aws/defense_evasion_cloudtrail_logging_deleted.toml +++ b/rules/integrations/aws/defense_evasion_cloudtrail_logging_deleted.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/26" integration = ["aws"] maturity = "production" -updated_date = "2025/11/07" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -25,9 +25,6 @@ license = "Elastic License v2" name = "AWS CloudTrail Log Deleted" note = """## 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 CloudTrail Log Deleted AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. This rule identifies the deletion of an AWS log trail using the `DeleteTrail` API. Deleting a trail can eliminate visibility and is a strong indicator of defense evasion or sabotage. diff --git a/rules/integrations/aws/defense_evasion_cloudtrail_logging_suspended.toml b/rules/integrations/aws/defense_evasion_cloudtrail_logging_suspended.toml index 8cf01a200..19a1700b0 100644 --- a/rules/integrations/aws/defense_evasion_cloudtrail_logging_suspended.toml +++ b/rules/integrations/aws/defense_evasion_cloudtrail_logging_suspended.toml @@ -2,7 +2,7 @@ creation_date = "2020/06/10" integration = ["aws"] maturity = "production" -updated_date = "2025/11/07" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -26,9 +26,6 @@ license = "Elastic License v2" name = "AWS CloudTrail Log Suspended" note = """## 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 CloudTrail Log Suspended AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. This rule identifies the suspension of an AWS log trail using the `StopLogging` API. Attackers can do this to cover their tracks and impact security monitoring that relies on this source. diff --git a/rules/integrations/aws/defense_evasion_cloudwatch_alarm_deletion.toml b/rules/integrations/aws/defense_evasion_cloudwatch_alarm_deletion.toml index 019fd66ee..a59d032da 100644 --- a/rules/integrations/aws/defense_evasion_cloudwatch_alarm_deletion.toml +++ b/rules/integrations/aws/defense_evasion_cloudwatch_alarm_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/06/15" integration = ["aws"] maturity = "production" -updated_date = "2025/11/13" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -28,10 +28,6 @@ license = "Elastic License v2" name = "AWS CloudWatch Alarm Deletion" note = """## 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, validate and adapt it to your operational context. - ### Investigating AWS CloudWatch Alarm Deletion Amazon CloudWatch is a monitoring and observability service that collects monitoring and operational data in the form of logs, metrics, and events for resources and applications. This data can be used to detect anomalous behavior in your environments, set alarms, visualize logs and metrics side by side, take automated actions, troubleshoot issues, and discover insights to keep your applications running smoothly. diff --git a/rules/integrations/aws/defense_evasion_config_service_rule_deletion.toml b/rules/integrations/aws/defense_evasion_config_service_rule_deletion.toml index 5f905e153..8d37020dc 100644 --- a/rules/integrations/aws/defense_evasion_config_service_rule_deletion.toml +++ b/rules/integrations/aws/defense_evasion_config_service_rule_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/06/26" integration = ["aws"] maturity = "production" -updated_date = "2025/12/12" +updated_date = "2026/01/16" [rule] author = ["Elastic", "Austin Songer"] @@ -27,9 +27,6 @@ license = "Elastic License v2" name = "AWS Config Resource Deletion" note = """## 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 Config Resource Deletion AWS Config records configuration changes, relationships, and compliance status for AWS resources over time. diff --git a/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml b/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml index 7d37cb494..5d3c8b9b0 100644 --- a/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml +++ b/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml @@ -2,7 +2,7 @@ creation_date = "2020/06/16" integration = ["aws"] maturity = "production" -updated_date = "2025/12/12" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -27,9 +27,6 @@ license = "Elastic License v2" name = "AWS Configuration Recorder Stopped" note = """## 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 Configuration Recorder Stopped AWS Config provides continuous visibility into resource configuration changes and underpins many security, compliance, diff --git a/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml b/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml index 5ef5161ce..94ab7f359 100644 --- a/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml +++ b/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/26" integration = ["aws"] maturity = "production" -updated_date = "2025/06/05" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -22,9 +22,6 @@ license = "Elastic License v2" name = "AWS EC2 Network Access Control List Deletion" note = """## 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 Network Access Control List Deletion AWS EC2 Network ACLs are essential for controlling inbound and outbound traffic to subnets, acting as a firewall layer. Adversaries may delete these ACLs to disable security controls, facilitating unauthorized access or data exfiltration. The detection rule monitors AWS CloudTrail logs for successful deletion events of ACLs or their entries, signaling potential defense evasion attempts. diff --git a/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml b/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml index 316650f18..27ff1add1 100644 --- a/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml +++ b/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/28" integration = ["aws"] maturity = "production" -updated_date = "2025/11/12" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -27,10 +27,6 @@ license = "Elastic License v2" name = "AWS GuardDuty Detector Deletion" note = """## 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 GuardDuty Detector Deletion Amazon GuardDuty is a continuous threat detection service that analyzes CloudTrail, DNS, and VPC Flow Logs to identify malicious activity and compromised resources. Deleting a GuardDuty detector stops this monitoring entirely and permanently removes all historical findings for the affected AWS account. This rule detects successful `DeleteDetector` API calls, which may represent an attacker attempting to impair defenses and evade detection. Such actions should be rare and always performed under controlled administrative change processes. diff --git a/rules/integrations/aws/defense_evasion_rds_instance_restored.toml b/rules/integrations/aws/defense_evasion_rds_instance_restored.toml index 874fa8cb9..4a871a745 100644 --- a/rules/integrations/aws/defense_evasion_rds_instance_restored.toml +++ b/rules/integrations/aws/defense_evasion_rds_instance_restored.toml @@ -2,7 +2,7 @@ creation_date = "2021/06/29" integration = ["aws"] maturity = "production" -updated_date = "2025/12/01" +updated_date = "2026/01/16" [rule] author = ["Austin Songer", "Elastic"] @@ -27,10 +27,6 @@ license = "Elastic License v2" name = "AWS RDS DB Instance Restored" note = """## 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, validate and adapt it to suit your operational needs. - ### Investigating AWS RDS DB Instance Restored Restoring an RDS DB instance from a snapshot or from S3 is a powerful operation that recreates a full database environment. While legitimate for recovery, migrations, or cloning, adversaries may use restore actions to access historical data, duplicate sensitive environments, evade guardrails, or prepare for data exfiltration. diff --git a/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml b/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml index cd6eb4c53..624bc2957 100644 --- a/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml +++ b/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/12" integration = ["aws"] maturity = "production" -updated_date = "2025/12/10" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -26,9 +26,6 @@ license = "Elastic License v2" name = "AWS Route 53 Resolver Query Log Configuration Deleted" note = """## 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 Route 53 Resolver Query Log Configuration Deleted Route 53 Resolver query logs provide essential telemetry for DNS visibility across AWS environments. Deleting a Resolver Query Log Configuration immediately halts DNS logging for one or more VPCs, creating a significant monitoring gap. Adversaries may intentionally delete these configurations to hide malicious activity. This rule detects successful invocations of `DeleteResolverQueryLogConfig`. diff --git a/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml b/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml index 20e0fd7f1..a3f2352b5 100644 --- a/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml +++ b/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/27" integration = ["aws"] maturity = "production" -updated_date = "2025/10/29" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -30,9 +30,6 @@ license = "Elastic License v2" name = "AWS S3 Bucket Configuration Deletion" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - ### Investigating AWS S3 Bucket Configuration Deletion Amazon S3 is a scalable storage service where configurations like policies, replication, and encryption ensure data security and compliance. The detection rule monitors successful deletions of these configurations via the following APIs: `DeleteBucketPolicy`, `DeleteBucketReplication`, `DeleteBucketCors`, `DeleteBucketEncryption` or `DeleteBucketLifecycle`. These operations can be used by an adversary to remove visibility, erase governance or compliance controls, or prepare a bucket for destructive or exfiltration activity. @@ -71,20 +68,20 @@ Deleting or disabling important configurations may hamper audit trails, hide mal ### Response and remediation -**1. Containment & Immediate Actions** +**Containment & Immediate Actions** - Temporarily restrict the IAM user or role that performed the deletion, especially for `DeleteBucketPolicy`, `DeleteBucketEncryption`, or `DeleteBucketLifecycle`. - Restore missing configurations as soon as possible (e.g., re-apply bucket policy, lifecycle rules, inventory configuration) to prevent further blind spots. -**2. Investigation & Scope Assessment** +**Investigation & Scope Assessment** - Using CloudTrail and S3 Data Events, check object‐level activity from the timeframe immediately before and after the configuration deletion. Look for bulk deletes, new uploads, or copies to external accounts. - Check whether other buckets in the account suffered similar configuration changes – potentially part of a wider campaign. -**3. Recovery & Hardening** +**Recovery & Hardening** - Recover affected bucket configurations and ensure they match your organizational baseline and compliance standards (e.g., logging enabled, inventory configured, lifecycle rules active). - Enable AWS Config rules such as `s3-bucket-policy-check`, `s3-bucket-lifecycle-configuration-check`, `s3-bucket-logging-enabled` to monitor for unauthorized changes. - Apply least‐privilege for configuration deletion permissions; segregate duties so bucket config deletion can only be done via controlled workflows and require multi-step approval. -**4. Lessons Learned & Prevention** +**Lessons Learned & Prevention** - Conduct a post-incident review to determine root cause (credential compromise, misconfigured automation, malicious insider) and strengthen monitoring, alerting and access controls accordingly. """ diff --git a/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml b/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml index f4d6a6e9e..d7bf8608f 100644 --- a/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml +++ b/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/12" integration = ["aws"] maturity = "production" -updated_date = "2025/10/24" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -31,9 +31,6 @@ note = """## Triage and analysis ### Investigating AWS S3 Bucket Expiration Lifecycle Configuration Added -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - This rule detects when a lifecycle expiration policy is added to an S3 bucket via the `PutBucketLifecycle` or `PutBucketLifecycleConfiguration` API. Note: `PutBucketLifecycleConfiguration` is the newer supported API call, however both of these API calls show up as `PutBucketLifecycle` in Cloudtrail [ref](https://docs.aws.amazon.com/AmazonS3/latest/userguide/cloudtrail-logging-s3-info.html#cloudtrail-bucket-level-tracking). Lifecycle expiration automatically deletes objects after a defined period (`Expiration:Days`), which can be leveraged by adversaries to erase logs, exfiltration evidence, or security artifacts before detection and response teams can review them. @@ -87,24 +84,24 @@ Use AWS CloudTrail search or your SIEM to pivot for: ### Response and remediation **Containment and validation** -1. **Revert or disable** the lifecycle configuration if it is unauthorized: +**Revert or disable** the lifecycle configuration if it is unauthorized: - Use the AWS Console or CLI (`delete-bucket-lifecycle` or `put-bucket-lifecycle-configuration --lifecycle-configuration Disabled`). -2. **Preserve evidence**: +**Preserve evidence**: - Copy existing objects (especially logs or forensic data) before they expire. - Enable object versioning or replication to protect against loss. **Investigation** -3. Review CloudTrail and S3 Access Logs for the same bucket: +Review CloudTrail and S3 Access Logs for the same bucket: - Identify who and what performed previous deletions. - Determine whether any objects of investigative value have already been removed. -4. Search for other S3 buckets where similar lifecycle configurations were added in a short timeframe. +Search for other S3 buckets where similar lifecycle configurations were added in a short timeframe. **Recovery and hardening** -5. Implement guardrails: +Implement guardrails: - Use AWS Config rules like `s3-bucket-lifecycle-configuration-check` to monitor lifecycle changes. - Restrict `s3:PutLifecycleConfiguration` to specific administrative roles. - Enable [S3 Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html) on log or evidence buckets to enforce immutability. -6. Enable Security Hub and GuardDuty findings for additional anomaly detection on S3 data management activity. +Enable Security Hub and GuardDuty findings for additional anomaly detection on S3 data management activity. ### Additional information diff --git a/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml b/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml index c40234f06..70175107d 100644 --- a/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml +++ b/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml @@ -2,7 +2,7 @@ creation_date = "2024/07/12" integration = ["aws"] maturity = "production" -updated_date = "2025/10/27" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -29,9 +29,6 @@ note = """ ### Investigating AWS S3 Bucket Server Access Logging Disabled -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - This detection alerts when the server-access logging configuration for an S3 bucket is changed so that logging is disabled. Because detailed request logs are central to tracking object access, modifications here are significant from a visibility and forensics standpoint. They can signal that an adversary is preparing to act (exfiltrate, delete, or manipulate data) while minimizing audit evidence. @@ -63,20 +60,20 @@ Because detailed request logs are central to tracking object access, modificatio ### Response and remediation -**1. Contain & restore visibility** +**Contain & restore visibility** - Immediately re-enable server‐access logging for the affected bucket (ensure `LoggingEnabled=true` and correct `TargetBucket/Prefix`). - If you suspect activity while logging was disabled, preserve any remaining object versions, cross-account access logs, or S3 Inventory data. -**2. Investigate scope and impact** +**Investigate scope and impact** - Use CloudTrail Lake or Athena to query access to the bucket and objects for the timeframe when logging was disabled. - Identify external IP addresses, unusual principals, or rapid object transfers or deletions. -**3. Recover & harden** +**Recover & harden** - Apply bucket-policy or SCP restrictions to prevent unauthorized modifications of `PutBucketLogging` for audit/logging buckets. - Enable AWS Config rule (e.g., `cloudtrail-s3-bucket-access-logging`) to alert if logging is disabled. - Ensure logging target buckets are configured with retention, versioning, and immutability (S3 Object Lock) to prevent tampering. -**4. Improve & monitor** +**Improve & monitor** - Update your incident response playbook to include this scenario (see AWS IR + Customer Playbook Framework). - Educate stakeholders (storage, DevOps, security) that any change to logging configuration on buckets — especially audit/log buckets should be treated as a security event and ticketed. diff --git a/rules/integrations/aws/defense_evasion_sqs_purge_queue.toml b/rules/integrations/aws/defense_evasion_sqs_purge_queue.toml index b212a7ad4..d441f9f41 100644 --- a/rules/integrations/aws/defense_evasion_sqs_purge_queue.toml +++ b/rules/integrations/aws/defense_evasion_sqs_purge_queue.toml @@ -2,7 +2,7 @@ creation_date = "2025/01/08" integration = ["aws"] maturity = "production" -updated_date = "2025/12/12" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -25,9 +25,6 @@ license = "Elastic License v2" name = "AWS SQS Queue Purge" note = """## 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 SQS Queue Purge AWS SQS is a managed message queuing service commonly used to decouple services and buffer events across distributed and serverless architectures. Purging a queue removes all pending messages and cannot be undone. While this may be required for maintenance or testing, adversaries may abuse this action to disrupt operations, delete forensic evidence, or evade detection by removing queued security or audit events. diff --git a/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml b/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml index a1b14ba6f..ff639694e 100644 --- a/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml +++ b/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml @@ -2,7 +2,7 @@ creation_date = "2024/08/19" integration = ["aws"] maturity = "production" -updated_date = "2025/08/25" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -44,9 +44,6 @@ event.dataset: "aws.cloudtrail" ''' note = """## 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 First Occurrence of STS GetFederationToken Request by User AWS Security Token Service (STS) enables users to request temporary credentials for accessing AWS resources. While beneficial for legitimate use, adversaries may exploit this to gain unauthorized access. These credentials will remain active for the duration specified (maximum 36 hours), even if the initial compromised identity is deleted. They can also be used to request a console signin token which allows the adversary to make sensitive IAM API calls which would otherwise be denied with the federation token alone. The detection rule identifies unusual activity by flagging the first instance of a `GetFederationToken` request by a user helping to uncover potential misuse aimed at evading defenses and gaining persistence. diff --git a/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml b/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml index 3649da884..1c83e963b 100644 --- a/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml +++ b/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/21" integration = ["aws"] maturity = "production" -updated_date = "2025/12/08" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -29,10 +29,6 @@ license = "Elastic License v2" name = "AWS WAF Access Control List Deletion" note = """## 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, validate and adapt it to suit your operational needs. - ### Investigating AWS WAF Access Control List Deletion AWS Web Application Firewall (WAF) protects applications by inspecting HTTP/S traffic and applying rule groups, diff --git a/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml b/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml index dc84bb60e..a6e6fa7bf 100644 --- a/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml +++ b/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/06/09" integration = ["aws"] maturity = "production" -updated_date = "2025/12/08" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -28,9 +28,6 @@ license = "Elastic License v2" name = "AWS WAF Rule or Rule Group Deletion" note = """## 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 WAF Rule or Rule Group Deletion AWS WAF rules and rule groups define the security boundary for web applications by blocking malicious inputs, diff --git a/rules/integrations/aws/discovery_ec2_deprecated_ami_discovery.toml b/rules/integrations/aws/discovery_ec2_deprecated_ami_discovery.toml index d889edd26..6d6583be3 100644 --- a/rules/integrations/aws/discovery_ec2_deprecated_ami_discovery.toml +++ b/rules/integrations/aws/discovery_ec2_deprecated_ami_discovery.toml @@ -2,7 +2,7 @@ creation_date = "2024/12/24" integration = ["aws"] maturity = "production" -updated_date = "2025/07/09" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -23,65 +23,65 @@ license = "Elastic License v2" name = "AWS EC2 Deprecated AMI Discovery" note = """## Triage and analysis -## Investigating AWS EC2 Deprecated AMI Discovery +### 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 +### Possible investigation steps -1. **Identify the User Performing the Query**: +**Identify the user**: - 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**: +**Analyze the source**: - 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**: +**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**: +**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**: +**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 +### 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. +- Users may query for deprecated AMIs for testing or compatibility purposes. +- Security or compliance tools might query deprecated AMIs as part of regular assessments. +- Legacy systems may rely on deprecated AMIs for compatibility, leading to legitimate queries. -### Response and Remediation +### Response and remediation -1. **Immediate Actions**: +**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**: +**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**: +**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**: +**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**: +**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 +### Additional resources - [AWS Documentation: AMI Lifecycle Management](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) - [AWS Documentation: Deprecated AMIs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-deprecate.html) diff --git a/rules/integrations/aws/discovery_iam_principal_enumeration_via_update_assume_role_policy.toml b/rules/integrations/aws/discovery_iam_principal_enumeration_via_update_assume_role_policy.toml index 30b853341..197e4fc57 100644 --- a/rules/integrations/aws/discovery_iam_principal_enumeration_via_update_assume_role_policy.toml +++ b/rules/integrations/aws/discovery_iam_principal_enumeration_via_update_assume_role_policy.toml @@ -2,7 +2,7 @@ creation_date = "2020/07/16" integration = ["aws"] maturity = "production" -updated_date = "2025/11/25" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -23,9 +23,6 @@ license = "Elastic License v2" name = "AWS IAM Principal Enumeration via UpdateAssumeRolePolicy" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - ### Investigating AWS IAM Principal Enumeration via UpdateAssumeRolePolicy This rule detects bursts of failed attempts to update an IAM role’s trust policy — typically resulting in `MalformedPolicyDocumentException` errors — which can indicate enumeration of IAM principals. diff --git a/rules/integrations/aws/discovery_multiple_discovery_api_calls_via_cli.toml b/rules/integrations/aws/discovery_multiple_discovery_api_calls_via_cli.toml index 2f9b7ba54..b9e3d273e 100644 --- a/rules/integrations/aws/discovery_multiple_discovery_api_calls_via_cli.toml +++ b/rules/integrations/aws/discovery_multiple_discovery_api_calls_via_cli.toml @@ -2,7 +2,7 @@ creation_date = "2024/11/04" integration = ["aws"] maturity = "production" -updated_date = "2025/12/04" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -24,9 +24,6 @@ license = "Elastic License v2" name = "AWS Discovery API Calls via CLI from a Single Resource" note = """## 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 Discovery API Calls via CLI from a Single Resource This rule detects when a single AWS identity executes more than five unique discovery-related API calls (`Describe*`, `List*`, `Get*`, or `Generate*`) within a 10-second window using the AWS CLI. @@ -78,20 +75,20 @@ Validate by confirming: If the activity is unexpected or originates from unrecognized credentials, follow AWS’s incident-handling guidance: -**1. Contain** +**Contain** - Temporarily disable or rotate the access key (`Esql.aws_cloudtrail_user_identity_access_key_id_values`) using IAM. - Restrict outbound connectivity for the instance or resource from which the API calls originated. -**2. Investigate** +**Investigate** - Retrieve full CloudTrail logs for the actor and `Esql.time_window_date_trunc` interval. - Identify any subsequent write or privilege-modification actions. - Review associated IAM policies for excessive permissions. -**3. Recover and Harden** +**Recover and Harden** - Rotate credentials, enforce MFA on human users, and tighten IAM role trust policies. - Implement AWS Config rules or SCPs to monitor and restrict large-scale enumeration. -**4. Post-Incident Actions** +**Post-Incident Actions** - Document the finding and response in your organization’s IR management system. - Update detection logic or allow-lists for known benign automation. - Validate recovery by confirming no new suspicious discovery bursts occur. diff --git a/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml b/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml index b746c719b..cf02dd8f7 100644 --- a/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml +++ b/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2024/08/26" maturity = "production" -updated_date = "2025/12/15" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -26,9 +26,6 @@ license = "Elastic License v2" name = "AWS Service Quotas Multi-Region GetServiceQuota Requests" note = """## 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 Service Quotas Multi-Region GetServiceQuota Requests AWS Service Quotas define usage limits for AWS services and are commonly referenced during capacity planning or automation. However, adversaries frequently enumerate EC2 on-demand instance quotas across many regions to identify where they can rapidly deploy compute resources for malicious purposes such as cryptocurrency mining, botnet hosting, or malware staging. This rule detects unusually fast, multi-region enumeration of the EC2 on-demand vCPU quota (`L-1216C47A`), a pattern that is uncommon for normal administrative activity and strongly associated with cloud infrastructure discovery. diff --git a/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml b/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml index 0dbd667c5..f410c0aad 100644 --- a/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml +++ b/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/30" integration = ["aws"] maturity = "production" -updated_date = "2025/12/11" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -28,10 +28,6 @@ license = "Elastic License v2" name = "AWS Lambda Layer Added to Existing Function" note = """## 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 Lambda Layer Added to Existing Function Lambda layers introduce external code artifacts into a function’s runtime. Adding a layer to an existing Lambda function diff --git a/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml b/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml index 470aba641..7164fa9a5 100644 --- a/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml +++ b/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml @@ -2,7 +2,7 @@ creation_date = "2024/07/25" integration = ["aws"] maturity = "production" -updated_date = "2025/08/27" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -47,9 +47,6 @@ event.dataset:aws.cloudtrail and event.provider:cloudformation.amazonaws.com and ''' note = """## 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 First Time AWS CloudFormation Stack Creation AWS CloudFormation automates the setup of cloud resources using templates, streamlining infrastructure management. Adversaries with access can exploit this to deploy malicious resources, escalating their control. The detection rule identifies unusual activity by flagging the initial use of stack creation APIs by a user or role, helping to spot potential unauthorized actions early. diff --git a/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml b/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml index 18d302a00..eaa5dcfbc 100644 --- a/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml +++ b/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/16" integration = ["aws"] maturity = "production" -updated_date = "2025/10/24" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -24,10 +24,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"] language = "eql" license = "Elastic License v2" name = "AWS EC2 EBS Snapshot Shared or Made Public" -note = """## 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. +note = """## Triage and analysis ### Investigating AWS EC2 EBS Snapshot Shared or Made Public @@ -35,20 +32,24 @@ This rule detects when an Amazon Elastic Block Store (EBS) snapshot is shared wi #### Possible investigation steps: -- **Identify who performed the action**: Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who modified the snapshot’s permissions. Evaluate whether this identity is authorized to share EBS snapshots (check IAM policies for `ec2:ModifySnapshotAttribute`). -- **Analyze the source of the request**: Examine `source.ip` and `source.geo` fields to determine the geographical origin of the request. An unfamiliar or external location may indicate compromised credentials or unauthorized access. Review `user_agent.original` to confirm whether the request originated from an expected administrative tool or host. -- **Examine the scope of the change**: +**Identify who performed the action**: Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who modified the snapshot’s permissions. Evaluate whether this identity is authorized to share EBS snapshots (check IAM policies for `ec2:ModifySnapshotAttribute`). + +**Analyze the source of the request**: Examine `source.ip` and `source.geo` fields to determine the geographical origin of the request. An unfamiliar or external location may indicate compromised credentials or unauthorized access. Review `user_agent.original` to confirm whether the request originated from an expected administrative tool or host. + +**Examine the scope of the change**: - Review `aws.cloudtrail.request_parameters` to determine which AWS account(s) were added to the `createVolumePermission` list. - If the account ID matches the snapshot owner’s account, this is redundant and typically non-malicious. - If another account ID or `group=all` appears, verify whether the target is an approved AWS Organization account or an external party. - Cross-check the affected `snapshotId` in the AWS console or via CLI (`describe-snapshot-attribute`) to confirm current sharing status. - Identify whether other snapshots or AMIs were shared in the same timeframe. -- **Correlate with other activities**: + +**Correlate with other activities**: - Search CloudTrail for related events involving the same actor or `source.ip`. - Look for `CreateSnapshot`, `CopySnapshot`, `ExportImage`, or `PutBucketAcl` events that could indicate broader exfiltration or replication behavior. - Correlate with detections such as `EBS Snapshot Access Removed` or `EBS Encryption Disabled`, which may signal a coordinated campaign involving both exfiltration and impact. - Check GuardDuty and Security Hub for findings related to data exposure, cross-account sharing, or unauthorized data transfer. -- **Evaluate timing and intent**: Compare `@timestamp` against scheduled maintenance or approved change windows. Actions performed outside business hours or without documented change tickets should be prioritized for review. + +**Evaluate timing and intent**: Compare `@timestamp` against scheduled maintenance or approved change windows. Actions performed outside business hours or without documented change tickets should be prioritized for review. ### False positive analysis: @@ -60,20 +61,23 @@ If verified as legitimate, document the event under change management and reconc ### Response and remediation: -**1. Containment and validation** +**Containment and validation** - If unauthorized, immediately remove added permissions using the AWS CLI: `aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-permission "Remove=[{UserId=}]"` - Revoke public sharing (`group=all`) to prevent external access. - Restrict `ec2:ModifySnapshotAttribute` permissions to trusted administrative roles only. -**2. Investigate for data exfiltration or persistence** + +**Investigate for data exfiltration or persistence** - Determine whether the shared snapshot was copied to another account (`CopySnapshot`). - Engage AWS Support if evidence suggests external copying or data theft. - Review subsequent API calls or IAM changes for further persistence or data movement. -**3. Strengthen detection and monitoring** + +**Strengthen detection and monitoring** - Enable AWS Config rules such as `ebs-snapshot-public-restorable-check`. - Implement continuous monitoring for `ModifySnapshotAttribute` and `CopySnapshot` operations. - Correlate future detections by actor, access key, and source IP to identify repeated or automated exfiltration attempts. -**4. Recovery and hardening** + +**Recovery and hardening** - Enable default encryption and validate that all snapshots remain private. - Apply Service Control Policies (SCPs) to prevent public snapshot sharing organization-wide. - Audit existing snapshots to ensure no others have unauthorized permissions. diff --git a/rules/integrations/aws/exfiltration_ec2_export_task.toml b/rules/integrations/aws/exfiltration_ec2_export_task.toml index 9c0b0b31a..0934b06a3 100644 --- a/rules/integrations/aws/exfiltration_ec2_export_task.toml +++ b/rules/integrations/aws/exfiltration_ec2_export_task.toml @@ -2,7 +2,7 @@ creation_date = "2025/10/23" integration = ["aws"] maturity = "production" -updated_date = "2025/10/23" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -27,9 +27,6 @@ license = "Elastic License v2" name = "AWS EC2 Export Task" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - ### Investigating AWS EC2 Export Task The APIs `CreateInstanceExportTask`, `ExportImage`, and `CreateStoreImageTask` allow the export of a running or stopped EC2 instance (or its AMI/image) to external storage (e.g., S3) or image formats. While often used for migration, cloning or backup, adversaries can leverage these actions to copy full VM state or images out of the environment for exfiltration. diff --git a/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml b/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml index 0d19f98af..3b4abe9e0 100644 --- a/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml +++ b/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml @@ -2,7 +2,7 @@ creation_date = "2021/05/05" integration = ["aws"] maturity = "production" -updated_date = "2025/10/23" +updated_date = "2026/01/16" [rule] author = ["Elastic", "Austin Songer"] @@ -26,9 +26,6 @@ license = "Elastic License v2" name = "AWS EC2 Full Network Packet Capture Detected" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - ### Investigating AWS EC2 Full Network Packet Capture Detected This alert fires on a successful `CreateTrafficMirrorSession`, which enables full-packet Traffic Mirroring from a @@ -74,22 +71,22 @@ Look before and after this event (±30–60 minutes) by the same principal / acc ### Response and remediation -**1. Contain** +**Contain** - If unauthorized, terminate the session immediately (use the `TrafficMirrorSessionId` from `aws.cloudtrail.response_elements`) and block creation permissions for the offending principal. - Quarantine or restrict egress from the target if you suspect it is forwarding captured traffic outside approved destinations. -**2. Investigate** +**Investigate** - Enumerate all active sessions in the affected account/region; verify there aren’t additional rogue sessions. - Review related target and filter resources (and recent `Modify*` calls) to understand captured scope and recipients. - Trace the source ENI back to the EC2 instance and validate whether sensitive workloads were mirrored. -**3. Recover & harden** +**Recover & harden** - Remove or lock down unapproved targets/filters; enforce least privilege on `ec2:CreateTrafficMirrorSession/Target/Filter`. - Consider SCPs or IAM conditions limiting who/where sessions can be created (e.g., only into designated monitoring VPCs). - Ensure monitoring targets are controlled, logged, and not internet-reachable. -**4. Improve** +**Improve** - Add correlation logic to automatically surface CreateTrafficMirrorSession alongside Create/Modify Target/Filter calls by the same actor. - Require tags on approved mirroring resources; alert on untagged/unticketed creations. - Update playbooks to include a standard validation checklist (principal, source ENI, target, filter rules, destination path). diff --git a/rules/integrations/aws/exfiltration_rds_snapshot_export.toml b/rules/integrations/aws/exfiltration_rds_snapshot_export.toml index 263cd08a4..a0ba65785 100644 --- a/rules/integrations/aws/exfiltration_rds_snapshot_export.toml +++ b/rules/integrations/aws/exfiltration_rds_snapshot_export.toml @@ -2,7 +2,7 @@ creation_date = "2021/06/06" integration = ["aws"] maturity = "production" -updated_date = "2025/11/24" +updated_date = "2026/01/16" [rule] author = ["Elastic", "Austin Songer"] @@ -27,10 +27,6 @@ license = "Elastic License v2" name = "AWS RDS Snapshot Export" note = """## 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, validate and adapt it to suit your operational needs. - ### Investigating AWS RDS Snapshot Export Exporting an RDS snapshot to Amazon S3 allows the full contents of a database to be written outside the managed diff --git a/rules/integrations/aws/exfiltration_rds_snapshot_shared_with_another_account.toml b/rules/integrations/aws/exfiltration_rds_snapshot_shared_with_another_account.toml index bfd13ca11..4d0007470 100644 --- a/rules/integrations/aws/exfiltration_rds_snapshot_shared_with_another_account.toml +++ b/rules/integrations/aws/exfiltration_rds_snapshot_shared_with_another_account.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/25" integration = ["aws"] maturity = "production" -updated_date = "2025/12/05" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -28,9 +28,6 @@ license = "Elastic License v2" name = "AWS RDS DB Snapshot Shared with Another Account" note = """## 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 RDS DB Snapshot Shared with Another Account Amazon RDS DB snapshots capture full backups of database instances and clusters. Modifying a snapshot’s restore diff --git a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml index 32deea7e7..999b1b4a2 100644 --- a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml +++ b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/17" integration = ["aws"] maturity = "production" -updated_date = "2025/12/04" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -29,9 +29,6 @@ license = "Elastic License v2" name = "AWS S3 Bucket Policy Added to Share with External Account" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - ### Investigating AWS S3 Bucket Policy Added to Share with External Account This rule detects when an S3 bucket policy is modified using the `PutBucketPolicy` API call to include an external AWS account ID. diff --git a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_public_access.toml b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_public_access.toml index c73cfed81..6d7ba2052 100644 --- a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_public_access.toml +++ b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_public_access.toml @@ -2,7 +2,7 @@ creation_date = "2025/10/30" integration = ["aws"] maturity = "production" -updated_date = "2025/10/30" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -29,10 +29,6 @@ license = "Elastic License v2" name = "AWS S3 Bucket Policy Added to Allow Public Access" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. -> While every effort has been made to ensure its quality, we recommend validating the content and adapting it to your specific environment and operational needs. - ### Investigating AWS S3 Bucket Policy Added to Allow Public Access This rule detects modifications to Amazon S3 bucket policies using the `PutBucketPolicy` API where both `Effect=Allow` diff --git a/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml b/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml index 2a247817c..4b6fbec23 100644 --- a/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml +++ b/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml @@ -2,7 +2,7 @@ creation_date = "2021/10/17" integration = ["aws"] maturity = "production" -updated_date = "2025/12/12" +updated_date = "2026/01/16" [rule] author = ["Austin Songer", "Elastic"] @@ -26,9 +26,6 @@ license = "Elastic License v2" name = "AWS EventBridge Rule Disabled or Deleted" note = """## 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 EventBridge Rule Disabled or Deleted EventBridge rules define when events are matched and where they are delivered. Disabling or deleting a rule can interrupt diff --git a/rules/integrations/aws/impact_aws_s3_bucket_enumeration_or_brute_force.toml b/rules/integrations/aws/impact_aws_s3_bucket_enumeration_or_brute_force.toml index 2439ee555..013d9381c 100644 --- a/rules/integrations/aws/impact_aws_s3_bucket_enumeration_or_brute_force.toml +++ b/rules/integrations/aws/impact_aws_s3_bucket_enumeration_or_brute_force.toml @@ -2,7 +2,7 @@ creation_date = "2024/05/01" integration = ["aws"] maturity = "production" -updated_date = "2025/10/01" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -22,9 +22,6 @@ name = "AWS S3 Bucket Enumeration or Brute Force" note = """ ## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - ### Investigating AWS S3 Bucket Enumeration or Brute Force This rule detects when many failed S3 operations (HTTP 403 AccessDenied) hit a single bucket from a single source address in a short window. This can indicate bucket name enumeration, object/key guessing, or brute-force style traffic intended to drive cost or probe for misconfigurations. 403 requests from outside the bucket owner’s account/organization are not billed, but 4XX from inside the owner’s account/org can still incur charges. Prioritize confirming who is making the calls and where they originate. @@ -32,12 +29,17 @@ This rule detects when many failed S3 operations (HTTP 403 AccessDenied) hit a s #### Possible investigation steps - **Investigate in Timeline.** Investigate the alert in timeline (Take action -> Investigate in timeline) to retrieve and review all of the raw CloudTrail events that contributed to the threshold alert. Threshold alerts only display the grouped fields; Timeline provides a way to see individual event details such as request parameters, full error messages, and additional user context. + - **Confirm entity & target.** Note the rule’s threshold and window. Identify the target bucket (`tls.client.server_name`) and the source (`source.address`). Verify the caller identity details via any available `aws.cloudtrail.user_identity` fields. + - **Actor & session context.** In CloudTrail events, pivot 15–30 minutes around the spike for the same `source.address` or principal. Determine if the source is: - **External** to your account/organization (recon/cost DDoS risk is lower for you due to 2024 billing change). - **Internal** (same account/org)—higher cost risk and possible misuse of internal automation. + - **Bucket posture snapshot.** Record S3 Block Public Access, Bucket Policy, ACLs, and whether Versioning/Object Lock are enabled. Capture any recent `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning`, or lifecycle changes. + - **Blast radius.** Check for similar spikes to other buckets/regions, or parallel spikes from the same source. Review any GuardDuty S3 findings and AWS Config drift related to the bucket or principal. + - **Business context.** Contact the bucket/app owner. Validate whether a migration, scanner, or broken job could legitimately cause bursts. ### False positive analysis @@ -47,19 +49,19 @@ This rule detects when many failed S3 operations (HTTP 403 AccessDenied) hit a s ### Response and remediation -**1. Immediate, low-risk actions** +**Immediate, low-risk actions** - **Preserve evidence.** Export CloudTrail records (±30 minutes) for the bucket and source address into an evidence bucket with restricted access. - **Notify owners.** Inform the bucket/application owner and security lead; confirm any maintenance windows. -**2. Containment options** +**Containment options** - **External-origin spikes:** Verify Block Public Access is enforced and bucket policies are locked down. Optionally apply a temporary deny-all bucket policy allowing only IR/admin roles while scoping. - **Internal-origin spikes:** Identify the principal. Rotate access keys for IAM users, or restrict involved roles (temporary deny/SCP, remove risky policies). Pause broken jobs/pipelines until validated. -**3. Scope & hunting** +**Scope & hunting** - Review Timeline and CloudTrail for related events: `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning`, lifecycle changes, unusual `PutObject`/`DeleteObject` volumes, or cross-account access. - Check GuardDuty S3 and Config drift findings for signs of tampering or lateral movement. -**4. Recovery & hardening** +**Recovery & hardening** - If data impact suspected: with Versioning, restore known-good versions; otherwise, recover from backups/replicas. - Enable Versioning on critical buckets going forward; evaluate Object Lock legal hold if enabled. - Ensure Block Public Access, least-privilege IAM policies, CloudTrail data events for S3, and GuardDuty protections are consistently enforced. diff --git a/rules/integrations/aws/impact_cloudtrail_logging_updated.toml b/rules/integrations/aws/impact_cloudtrail_logging_updated.toml index 4e0932610..f19cadad2 100644 --- a/rules/integrations/aws/impact_cloudtrail_logging_updated.toml +++ b/rules/integrations/aws/impact_cloudtrail_logging_updated.toml @@ -2,7 +2,7 @@ creation_date = "2020/06/10" integration = ["aws"] maturity = "production" -updated_date = "2025/11/07" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -26,9 +26,6 @@ license = "Elastic License v2" name = "AWS CloudTrail Log Updated" note = """## 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 CloudTrail Log Updated AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. Trail modifications can be used by attackers to redirect logs to non-approved buckets, drop regions, or disable valuable selectors. This rule identifies a modification on CloudTrail settings using the `UpdateTrail` API. diff --git a/rules/integrations/aws/impact_cloudwatch_log_group_deletion.toml b/rules/integrations/aws/impact_cloudwatch_log_group_deletion.toml index 3a4af0d85..ba258d59d 100644 --- a/rules/integrations/aws/impact_cloudwatch_log_group_deletion.toml +++ b/rules/integrations/aws/impact_cloudwatch_log_group_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/18" integration = ["aws"] maturity = "production" -updated_date = "2025/11/13" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -29,10 +29,6 @@ license = "Elastic License v2" name = "AWS CloudWatch Log Group Deletion" note = """## 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, validate and adapt it to your operational context. - ### Investigating AWS CloudWatch Log Group Deletion CloudWatch Logs is foundational to AWS observability, SIEM ingestion, audit pipelines, and incident response. diff --git a/rules/integrations/aws/impact_cloudwatch_log_stream_deletion.toml b/rules/integrations/aws/impact_cloudwatch_log_stream_deletion.toml index 165c09b71..2ea4f8619 100644 --- a/rules/integrations/aws/impact_cloudwatch_log_stream_deletion.toml +++ b/rules/integrations/aws/impact_cloudwatch_log_stream_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/20" integration = ["aws"] maturity = "production" -updated_date = "2025/11/13" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -27,10 +27,6 @@ license = "Elastic License v2" name = "AWS CloudWatch Log Stream Deletion" note = """## 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, validate and adapt it to your operational context. - ### Investigating AWS CloudWatch Log Stream Deletion CloudWatch log streams contain sequential log events from a single application, service, or AWS resource. diff --git a/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml b/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml index 0e7a0a7f1..0aa53f8fd 100644 --- a/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml +++ b/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml @@ -2,7 +2,7 @@ creation_date = "2020/06/05" integration = ["aws"] maturity = "production" -updated_date = "2025/10/16" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -28,9 +28,6 @@ license = "Elastic License v2" name = "AWS EC2 Encryption Disabled" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - ### Investigating AWS EC2 Encryption Disabled Amazon Elastic Block Store (EBS) encryption ensures that all new EBS volumes and snapshots are encrypted at rest using AWS KMS keys. @@ -45,15 +42,18 @@ This action can have serious security implications as it can weaken the organiza - Validate whether the actor is authorized to modify account-level encryption defaults. - Check `source.ip` and `user_agent.original` to identify the origin of the request and whether it came from a known administrative system, automation process, or an unfamiliar host. - Correlate with recent IAM activity such as `AttachUserPolicy`, `UpdateAccountPasswordPolicy`, or `PutAccountSetting` to identify potential privilege escalation or account misuse. + **Review the timing and scope** - Compare the event `@timestamp` with other CloudTrail management events to determine if the encryption change occurred alongside other administrative modifications. - Investigate if similar actions were executed in other AWS regions, disabling encryption regionally may be part of a broader campaign. - Review AWS Config or Security Hub findings to determine whether compliance controls or data protection standards (e.g., CIS, PCI-DSS, ISO 27001) have been violated. + **Assess data exposure risk** - Identify newly created or modified EBS volumes after the timestamp of this change. - Query CloudTrail for `CreateVolume` or `CreateSnapshot` events without `Encrypted:true`. - Determine whether sensitive workloads, such as production databases or applications, rely on unencrypted EBS volumes. - Check for `CopySnapshot` or `ModifySnapshotAttribute` activity that could indicate data staging or exfiltration. + **Correlate related security events** - Look for concurrent detections or GuardDuty findings involving IAM privilege misuse, credential exposure, or configuration tampering. - Review CloudTrail logs for any `DisableKeyRotation` or `ScheduleKeyDeletion` events related to the KMS key used for EBS encryption. These may indicate attempts to disrupt encryption mechanisms entirely. @@ -69,23 +69,26 @@ If confirmed as expected, document the change request, implementation window, an ### Response and remediation -**1. Containment and restoration** +**Containment and restoration** - Re-enable EBS encryption by default in the affected region to restore protection for new volumes: - Via AWS Console: EC2 → Account Attributes → EBS encryption → Enable by default. - Or via CLI/API: `enable-ebs-encryption-by-default`. - Audit recently created EBS volumes and snapshots. - Identify any unencrypted resources and re-encrypt them using KMS keys or snapshot-copy encryption workflows. - Verify that AWS Config rules and Security Hub controls related to EBS encryption (`ec2-ebs-encryption-by-default-enabled`) are enabled and compliant. -**2. Investigate and scope** + +**Investigate and scope** - Review IAM policies to ensure only designated administrators have the `ec2:DisableEbsEncryptionByDefault` permission. - Check for other regional encryption settings (e.g., S3 default encryption) that may have been modified by the same user or automation role. - Examine whether any new IAM roles or policies were added that allow similar encryption or security modifications. -**3. Long-term hardening** + +**Long-term hardening** - Enable organization-level service control policies (SCPs) to prevent future disabling of encryption-by-default across accounts. - Establish AWS Config conformance packs or Security Hub standards to continuously monitor this setting. - Integrate detection correlation (e.g., link EBS encryption disablement with subsequent unencrypted `CreateVolume` events) for improved alert fidelity. - Educate administrators on data protection implications and require change approvals for encryption-related settings. -**4. Recovery validation** + +**Recovery validation** - After restoring encryption-by-default, validate the change in CloudTrail and AWS Config timelines. - Confirm that subsequent EBS volumes are created with `Encrypted:true`. - Conduct a short post-incident review to document root cause, impact, and lessons learned for compliance audits. diff --git a/rules/integrations/aws/impact_ec2_ebs_snapshot_access_removed.toml b/rules/integrations/aws/impact_ec2_ebs_snapshot_access_removed.toml index 8d45fd949..d63df0a70 100644 --- a/rules/integrations/aws/impact_ec2_ebs_snapshot_access_removed.toml +++ b/rules/integrations/aws/impact_ec2_ebs_snapshot_access_removed.toml @@ -2,7 +2,7 @@ creation_date = "2025/06/02" integration = ["aws"] maturity = "production" -updated_date = "2025/12/18" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -22,9 +22,6 @@ license = "Elastic License v2" name = "AWS EC2 EBS Snapshot Access Removed" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - ### Investigating AWS EC2 EBS Snapshot Access Removed This rule detects when access is removed for an AWS EC2 EBS snapshot. EBS virtual disks can be copied into snapshots, which can then be used as backups for recovery and data retention efforts. Adversaries may attempt to remove access to snapshots in order to prevent legitimate users or automated processes from accessing or restoring from snapshots following data loss, ransomware, or destructive actions. This can significantly delay or even prevent recovery, increasing the impact of the attack. Restricting snapshot access may help adversaries cover their tracks by making it harder for defenders to analyze or recover deleted or altered data. Attackers may remove permissions for all users except their own compromised account, allowing them to maintain exclusive access to backups for future use or leverage. Understanding the context and legitimacy of such changes is crucial to determine if the action is benign or malicious. @@ -32,18 +29,22 @@ This rule detects when access is removed for an AWS EC2 EBS snapshot. EBS virtua #### Possible investigation steps: - **Identify who performed the action**: Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who made the change. Evaluate whether the identity is authorized to manage EBS snapshot permissions (check IAM policies for `ec2:ModifySnapshotAttribute`). + - **Analyze the source of the request**: Examine `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access. Review `user_agent.original` to determine if the request came from an expected administrative tool or host. + - **Examine the scope of the change**: - Review `aws.cloudtrail.request_parameters` to understand which accounts or entities had access removed. - Look for unusual patterns such as `createVolumePermission={remove=all}` or removal of specific external or organizational accounts. - Cross-check the affected `snapshotId` in the AWS console or via CLI to confirm current sharing status and determine if any copies or dependent volumes exist. - Use AWS Config or AWS CLI (`describe-snapshot-attribute`) to verify whether other snapshots were modified within the same timeframe. + - **Correlate with other activities**: - Search CloudTrail for additional activity from the same actor or `source.ip` around the event time. - Pay special attention to subsequent `DeleteSnapshot`, `DeregisterImage`, or `RevokeSnapshotAccess` events, which may signal ongoing destruction. - Check for parallel IAM activity, such as policy changes that grant or revoke permissions. - Correlate with GuardDuty or Security Hub findings related to data exfiltration, destructive actions, or unauthorized configuration changes. - Determine if any high-value or production snapshots were affected, especially those linked to business-critical EBS volumes. + - **Evaluate timing and intent**: Compare `@timestamp` with maintenance windows or known change requests. Actions taken outside approved hours or without associated tickets may indicate compromise or sabotage. If this change coincides with other detections (for example, `EBS encryption disabled` or `root login` events), treat it as part of a coordinated impact campaign. ### False positive analysis: @@ -56,19 +57,22 @@ If the action was expected, document the change approval and reconcile against i ### Response and remediation: -**1. Containment and validation** +**Containment and validation** - Review and, if necessary, restore snapshot permissions using AWS Console or CLI (`modify-snapshot-attribute` with `add` parameters). - Confirm that no additional snapshots or AMIs have had access removed. - Restrict `ec2:ModifySnapshotAttribute` permissions to only trusted administrative roles. -**2. Investigate for data destruction or persistence** + +**Investigate for data destruction or persistence** - Determine if the same actor also deleted or copied snapshots (`DeleteSnapshot`, `CopySnapshot`). - Review subsequent volume creation or image registration events that could indicate snapshot reuse. - Identify whether any snapshot was shared to or copied by an external AWS account. -**3. Strengthen detection and monitoring** + +**Strengthen detection and monitoring** - Enable AWS Config rules and Security Hub controls such as `ebs-snapshot-public-restorable-check`. - Establish continuous monitoring for `ModifySnapshotAttribute` and `DeleteSnapshot` operations. - Correlate future detections with user identity and source IP context to identify recurring behavior. -**4. Recovery and hardening** + +**Recovery and hardening** - Verify that critical snapshots and backups are retained and encrypted. - Implement backup immutability with AWS Backup Vault Lock or S3 Object Lock for long-term protection. - Apply service control policies (SCPs) to prevent unauthorized modification of snapshot sharing attributes. diff --git a/rules/integrations/aws/impact_efs_filesystem_deleted.toml b/rules/integrations/aws/impact_efs_filesystem_deleted.toml index 2bb3c158a..d9c4d4a93 100644 --- a/rules/integrations/aws/impact_efs_filesystem_deleted.toml +++ b/rules/integrations/aws/impact_efs_filesystem_deleted.toml @@ -2,7 +2,7 @@ creation_date = "2021/08/27" integration = ["aws"] maturity = "production" -updated_date = "2025/11/26" +updated_date = "2026/01/16" [rule] author = ["Austin Songer", "Elastic"] @@ -28,10 +28,6 @@ license = "Elastic License v2" name = "AWS EFS File System Deleted" note = """## 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, validate and adapt it to suit your operational needs. - ### Investigating AWS EFS File System Deleted Amazon Elastic File System (EFS) provides scalable, shared file storage used by EC2, container workloads, analytics jobs, and other persistent applications. Deleting an EFS file system (`DeleteFileSystem`) permanently removes all stored data and cannot be recovered. Mount targets must already be deleted, but those operations are common and do not themselves indicate malicious behavior. This rule focuses exclusively on the irreversible destructive event, which may signal intentional data destruction, ransomware preparation, or a post-compromise cleanup effort. diff --git a/rules/integrations/aws/impact_iam_deactivate_mfa_device.toml b/rules/integrations/aws/impact_iam_deactivate_mfa_device.toml index 5107ec413..3f73d82d6 100644 --- a/rules/integrations/aws/impact_iam_deactivate_mfa_device.toml +++ b/rules/integrations/aws/impact_iam_deactivate_mfa_device.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/26" integration = ["aws"] maturity = "production" -updated_date = "2025/11/03" +updated_date = "2026/01/16" [rule] author = ["Elastic", "Austin Songer"] @@ -30,10 +30,6 @@ license = "Elastic License v2" name = "AWS IAM Deactivation of MFA Device" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and validated for accuracy and relevance. Always -> tailor the steps to your organization's environment and operational context. - ### Investigating AWS IAM Deactivation of MFA Device This rule detects successful deactivation of a Virtual MFA device in AWS IAM. diff --git a/rules/integrations/aws/impact_iam_group_deletion.toml b/rules/integrations/aws/impact_iam_group_deletion.toml index f34501ca5..90bdb232f 100644 --- a/rules/integrations/aws/impact_iam_group_deletion.toml +++ b/rules/integrations/aws/impact_iam_group_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/21" integration = ["aws"] maturity = "production" -updated_date = "2025/10/30" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -26,9 +26,6 @@ license = "Elastic License v2" name = "AWS IAM Group Deletion" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - ### Investigating AWS IAM Group Deletion Attackers sometimes remove groups to erase evidence, disrupt operations, or prevent users from receiving needed permissions (Impact). Deletion can also follow malicious cleanup after attaching policies and using the group briefly. This alert fires on `DeleteGroup` API call. Consider intentional disruption or covering tracks, particularly if the group was privileged or recently modified. diff --git a/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml b/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml index 661863508..245d0ffc0 100644 --- a/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml +++ b/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2022/09/21" integration = ["aws"] maturity = "production" -updated_date = "2025/12/05" +updated_date = "2026/01/16" [rule] author = ["Xavier Pich"] @@ -27,10 +27,6 @@ license = "Elastic License v2" name = "AWS KMS Customer Managed Key Disabled or Scheduled for Deletion" note = """## 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 KMS Customer Managed Key Disabled or Scheduled for Deletion AWS KMS keys underpin encryption for S3, EBS, RDS, Secrets Manager, Lambda, and numerous other AWS services. Disabling a KMS key or scheduling its deletion immediately disrupts encryption and decryption workflows, and, once deleted, renders all data encrypted with that key unrecoverable. diff --git a/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml b/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml index 93f752663..4508e3a36 100644 --- a/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml +++ b/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/21" integration = ["aws"] maturity = "production" -updated_date = "2025/11/24" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -27,10 +27,6 @@ license = "Elastic License v2" name = "AWS RDS DB Instance or Cluster Deleted" note = """## 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, validate and adapt it to suit your operational needs. - ### Investigating AWS RDS DB Instance or Cluster Deleted This rule detects the deletion of an RDS DB instance, Aurora DB cluster, or global database cluster. These operations permanently remove stored data and backups unless final snapshots are explicitly retained. Adversaries may delete RDS resources as part of a destructive attack, to eliminate forensic evidence, or to disrupt critical workloads. Because deletions are irreversible without backups, immediate review is required to determine whether the action was authorized and assess potential data loss. diff --git a/rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml b/rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml index 4a9200a7d..6eb2d35a0 100644 --- a/rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml +++ b/rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/28" integration = ["aws"] maturity = "production" -updated_date = "2025/11/24" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -26,10 +26,6 @@ license = "Elastic License v2" name = "AWS RDS DB Instance or Cluster Deletion Protection Disabled" note = """## 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, validate and adapt it to suit your operational needs. - ### Investigating AWS RDS DB Instance or Cluster Deletion Protection Disabled Deletion protection is designed to safeguard RDS DB instances and clusters from accidental or unauthorized deletion. An adversary with privileged access in a compromised environment, can disable this safeguard before issuing a `DeleteDBInstance` or `DeleteDBCluster` action. This rule detects successful attempts to modify deletionProtection and set it to false on any RDS instance or cluster. diff --git a/rules/integrations/aws/impact_rds_snapshot_deleted.toml b/rules/integrations/aws/impact_rds_snapshot_deleted.toml index 13a78c38f..7e6e4313c 100644 --- a/rules/integrations/aws/impact_rds_snapshot_deleted.toml +++ b/rules/integrations/aws/impact_rds_snapshot_deleted.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/29" integration = ["aws"] maturity = "production" -updated_date = "2025/11/24" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -27,10 +27,6 @@ license = "Elastic License v2" name = "AWS RDS Snapshot Deleted" note = """## 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, validate and adapt it to suit your operational needs. - ### Investigating AWS RDS Snapshot Deleted AWS RDS snapshots (manual or automated) and backup retention settings are core to database recovery and incident response. Deleting snapshots or disabling automated backups (`backupRetentionPeriod=0`) can prevent restoration to a known-good state and destroy forensic evidence of attacker actions. diff --git a/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml b/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml index 5f481f3b1..d2aec5fd0 100644 --- a/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml +++ b/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/17" integration = ["aws"] maturity = "production" -updated_date = "2025/09/30" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -24,19 +24,21 @@ name = "Potential AWS S3 Bucket Ransomware Note Uploaded" note = """ ## 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 AWS S3 Bucket Ransomware Note Uploaded This rule detects a successful `PutObject` to S3 where the object key matches common ransomware-note patterns (for example, `readme`, `how_to_decrypt`, `decrypt_instructions`, `ransom`, `lock`). Attackers who obtain credentials or abuse overly-permissive bucket policies can upload ransom notes (often after deleting or encrypting data). #### Possible Investigation Steps: - **Confirm the actor and session details.** Review `aws.cloudtrail.user_identity.*` (ARN, type, access key, session context), `source.ip`, `user.agent`, and `tls.client.server_name` to identify *who* performed the upload and *from where*. Validate whether this principal typically writes to this bucket. + - **Inspect the object key and bucket context.** From `aws.cloudtrail.request_parameters`, capture the exact `key` and `bucketName`. Check whether the key is publicly readable (ACL), whether the bucket is internet-exposed, and whether replication or lifecycle rules could propagate or remove related objects. + - **Pivot to related S3 activity around the same time.** Look for `DeleteObject`/`DeleteObjects`, mass `PutObject` spikes, `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning`, and `PutBucketLifecycleConfiguration` events on the same bucket or by the same actor to determine if data destruction, policy tampering, or guard-rail changes occurred. + - **Assess blast radius across the account.** Search recent CloudTrail for the same actor/IP touching other buckets, KMS keys used by those buckets, and IAM changes (new access keys, policy attachments, role assumptions) that could indicate broader compromise paths consistent with ransomware playbooks. + - **Check protections and recovery posture on the bucket.** Verify whether S3 Versioning and (if in use) Object Lock legal hold are enabled; note prior versions available for the affected key, and whether lifecycle rules might expire them. + - **Correlate with threat signals.** Review other related alerts, GuardDuty S3-related findings, AWS Config drift on the bucket and its policy, and any SOAR/IR runbook executions tied to ransomware triage. ### False Positive Analysis: @@ -46,36 +48,36 @@ This rule detects a successful `PutObject` to S3 where the object key matches co ### Response and Remediation: -**1. Immediate, low-risk actions (safe for most environments)** +**Immediate, low-risk actions (safe for most environments)** - **Preserve context:** Export the triggering `PutObject` CloudTrail record(s), plus 15–30 min before/after, to an evidence bucket (restricted access). - **Snapshot configuration:** Record current bucket settings (Block Public Access, Versioning, Object Lock, Bucket Policy, Lifecycle rules) and any KMS keys used. - **Quiet the spread:** Pause destructive automation: disable/bypass lifecycle rules that would expire/delete object versions; temporarily pause data pipelines targeting the bucket. - **Notify owners:** Inform the bucket/application owner(s) and security leadership. -**2. Containment options (choose the least disruptive first)** +**Containment options (choose the least disruptive first)** - **Harden exposure:** If not already enforced, enable `Block Public Access` for the bucket. - **Targeted deny policy (temporary):** Add a restrictive bucket policy allowing only IR/admin roles while you scope impact. Reconfirm critical workload dependencies before applying. - **Credential risk reduction:** If a specific IAM user/key or role is implicated, rotate access keys; for roles, remove risky policy attachments or temporarily restrict with an SCP/deny statement. -**3. Evidence preservation** +**Evidence preservation** - Export relevant CloudTrail events, S3 server/access logs (if enabled), AWS Config history for the bucket/policy, and the suspicious object plus its previous versions (if Versioning is enabled). - Document actor ARN, source IPs, user agent(s), exact `bucketName`/`key`, and timestamps. Maintain a simple chain-of-custody note for collected artifacts. -**4. Scope and hunting (same actor/time window)** +**Scope and hunting (same actor/time window)** - Look for `DeleteObject(s)`, unusual `PutObject` volume, `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning` changes, `PutBucketLifecycleConfiguration`, and cross-account access. - Cross reference other buckets touched by the same actor/IP; recent IAM changes (new keys, policy/role edits); GuardDuty findings tied to S3/credentials. -**5. Recovery (prioritize data integrity)** +**Recovery (prioritize data integrity)** - If Versioning is enabled, restore last known-good versions for impacted objects. Consider applying Object Lock legal hold to clean versions during recovery if configured. - If Versioning is not enabled, recover from backups (AWS Backup, replication targets). Enable Versioning going forward on critical buckets; evaluate Object Lock for high-value data. - Carefully remove any temporary deny policy only after credentials are rotated, policies re-validated, and no ongoing destructive activity is observed. -**6. Post-incident hardening** +**Post-incident hardening** - Enforce `Block Public Access`, enable Versioning (and MFA-Delete where appropriate), and review bucket policies for least privilege. - Ensure continuous CloudTrail data events for S3 are enabled in covered regions; enable/verify GuardDuty S3 protections and alerts routing. - Add detections for related behaviors (policy tampering, bulk deletes, versioning/lifecycle toggles) and create allowlists for known maintenance windows. -**7. Communication & escalation** +**Communication & escalation** - If you have an IR team/provider: escalate with the evidence bundle and a summary (bucket/key, actor, protections, related activity, business impact). - If you do not have an IR team: designate an internal incident lead, track actions/time, and follow these steps conservatively. Favor reversible controls (temporary deny, key rotation) over invasive changes. diff --git a/rules/integrations/aws/impact_s3_excessive_object_encryption_with_sse_c.toml b/rules/integrations/aws/impact_s3_excessive_object_encryption_with_sse_c.toml index eeb5c02c4..50c47bc15 100644 --- a/rules/integrations/aws/impact_s3_excessive_object_encryption_with_sse_c.toml +++ b/rules/integrations/aws/impact_s3_excessive_object_encryption_with_sse_c.toml @@ -2,7 +2,7 @@ creation_date = "2025/01/15" integration = ["aws"] maturity = "production" -updated_date = "2025/07/10" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -19,58 +19,57 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"] language = "kuery" license = "Elastic License v2" name = "Excessive AWS S3 Object Encryption with SSE-C" -note = """### Triage and Analysis +note = """## Triage and analysis -#### Investigating Excessive AWS S3 Object Encryption with SSE-C +### 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 +### Possible investigation steps -1. **Identify the User and Source**: +**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**: +**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**: +**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**: +**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**: +**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**: +**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 +### 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. +- 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 +### Response and remediation -1. **Immediate Actions**: +**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**: +**Data recovery**: - Attempt to identify and contact the party holding the SSE-C encryption keys if recovery is necessary. -3. **Enhance Monitoring**: +**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**: +**Post-Incident review**: - Audit logs for additional activities by the same user or IP. - Document findings and apply lessons learned to improve preventive measures. """ diff --git a/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml b/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml index df5ae0065..bf1de47eb 100644 --- a/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml +++ b/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml @@ -2,7 +2,7 @@ creation_date = "2024/07/02" integration = ["aws"] maturity = "production" -updated_date = "2025/12/09" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -27,10 +27,6 @@ license = "Elastic License v2" name = "AWS S3 Object Encryption Using External KMS Key" note = """## 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, validate and adapt it to suit your operational needs. - ### Investigating AWS S3 Object Encryption Using External KMS Key This rule detects when an S3 `CopyObject` operation encrypts an object using a KMS key belonging to a different AWS account than the bucket owner. This behavior is unusual and a strong indicator of: diff --git a/rules/integrations/aws/impact_s3_object_versioning_disabled.toml b/rules/integrations/aws/impact_s3_object_versioning_disabled.toml index 36d377834..d48d2e841 100644 --- a/rules/integrations/aws/impact_s3_object_versioning_disabled.toml +++ b/rules/integrations/aws/impact_s3_object_versioning_disabled.toml @@ -2,7 +2,7 @@ creation_date = "2024/07/12" integration = ["aws"] maturity = "production" -updated_date = "2025/10/28" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -22,9 +22,6 @@ license = "Elastic License v2" name = "AWS S3 Object Versioning Suspended" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - ### Investigating AWS S3 Object Versioning Suspended This rule detects when object versioning for an S3 bucket is suspended. S3 object versioning protects against data loss by maintaining prior versions of objects, allowing recovery if they are deleted or overwritten. diff --git a/rules/integrations/aws/impact_s3_unusual_object_encryption_with_sse_c.toml b/rules/integrations/aws/impact_s3_unusual_object_encryption_with_sse_c.toml index 82747595d..aacd3792c 100644 --- a/rules/integrations/aws/impact_s3_unusual_object_encryption_with_sse_c.toml +++ b/rules/integrations/aws/impact_s3_unusual_object_encryption_with_sse_c.toml @@ -2,7 +2,7 @@ creation_date = "2025/01/15" integration = ["aws"] maturity = "production" -updated_date = "2025/12/16" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -19,58 +19,58 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"] language = "kuery" license = "Elastic License v2" name = "Unusual AWS S3 Object Encryption with SSE-C" -note = """### Triage and Analysis +note = """## Triage and analysis + +### Investigating Unusual AWS S3 Object Encryption with SSE-C -#### 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 +### Possible investigation steps -1. **Identify the User and Source**: +**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**: +**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**: +**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**: +**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**: +**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**: +**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 +### 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. +- 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 +### Response and remediation -1. **Immediate Actions**: +**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**: +**Data recovery**: - Attempt to identify and contact the party holding the SSE-C encryption keys if recovery is necessary. -3. **Enhance Monitoring**: +**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**: +**Post-Incident review**: - Audit logs for additional activities by the same user or IP. - Document findings and apply lessons learned to improve preventive measures. """ diff --git a/rules/integrations/aws/initial_access_console_login_root.toml b/rules/integrations/aws/initial_access_console_login_root.toml index 68e9334ab..a8842b975 100644 --- a/rules/integrations/aws/initial_access_console_login_root.toml +++ b/rules/integrations/aws/initial_access_console_login_root.toml @@ -2,7 +2,7 @@ creation_date = "2020/06/11" integration = ["aws"] maturity = "production" -updated_date = "2025/10/10" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -21,9 +21,6 @@ license = "Elastic License v2" name = "AWS Management Console Root Login" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - ### Investigating AWS Management Console Root Login The AWS root user is the original identity with unrestricted privileges over every resource in the account. Because it bypasses IAM boundaries and carries irreversible privileges, any successful root console login should be treated as a critical security event. AWS explicitly recommends locking away the root credentials and only using them for a small number of account-level administrative tasks (for example, closing an account, modifying support plans, or restoring MFA). See [Tasks that require the root user](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root). @@ -34,18 +31,22 @@ This rule detects a successful AWS Management Console login by the root user (`C - **Confirm legitimacy.** Contact the designated root credential custodian or account owner to verify whether this login was expected and approved. Root access should only occur under documented change-control conditions. + - **Review contextual event details.** Examine the CloudTrail fields in the alert: - `source.ip` – does it match known corporate IPs or expected admin VPNs? - `user_agent.original` – browser or automation? - `geo fields` – consistent with normal operations? - `@timestamp` – within a planned maintenance window? + - **Check for prior or subsequent root activity.** Query CloudTrail for the last 30–90 days for any other root logins or root-initiated API calls. Multiple or recent root logins can indicate credential misuse. + - **Correlate follow-on actions.** Look for risky API calls immediately after the login, such as: - `CreateUser`, `CreateAccessKey`, `AttachRolePolicy`, `PutBucketPolicy`, `UpdateAssumeRolePolicy`, `DeleteTrail`, or `StopLogging`. These actions may indicate persistence or cover-up attempts. + - **Cross-account verification.** If the root user is federated through AWS Organizations or linked accounts, confirm no simultaneous logins occurred elsewhere. @@ -58,26 +59,24 @@ This rule detects a successful AWS Management Console login by the root user (`C ### Response and remediation -> The AWS Incident Response Playbooks classify root logins as **Priority-1 events** due to full-environment control. Follow these steps whether or not you have a dedicated IR team. - -**1. Immediate verification and containment** +**Immediate verification and containment** - If the login was not authorized or cannot be confirmed quickly: - Reset the root password using the AWS Management Console. - Rotate or remove any root access keys (root keys should normally not exist). - Ensure MFA is enabled and enforced on the root account. - Notify your security operations or cloud governance team. -**2. Evidence preservation** +**Evidence preservation** - Export the alert’s CloudTrail record and all subsequent events for 1 hour after the login. Store them in a restricted, immutable S3 evidence bucket. - Retain related GuardDuty findings, AWS Config history, and CloudTrail logs for the same period. -**3. Scope and investigation** +**Scope and investigation** - Review additional events under the same `source.ip` to detect resource creation, IAM changes, or billing actions. - Inspect newly created users, roles, or keys since the login time to identify potential persistence mechanisms. - Check for any disabled or deleted CloudTrail trails, Security Hub findings suppression, or logging configuration changes. -**4. Recovery and hardening** +**Recovery and hardening** - Confirm MFA is working and only the authorized owner can access the root credentials. - Store root credentials in an offline vault under dual-custody control. - Enable organization-wide CloudTrail, GuardDuty, and Security Hub across all regions. diff --git a/rules/integrations/aws/initial_access_password_recovery.toml b/rules/integrations/aws/initial_access_password_recovery.toml index c3d94d265..32b17765f 100644 --- a/rules/integrations/aws/initial_access_password_recovery.toml +++ b/rules/integrations/aws/initial_access_password_recovery.toml @@ -2,7 +2,7 @@ creation_date = "2020/07/02" integration = ["aws"] maturity = "production" -updated_date = "2025/10/13" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -18,9 +18,6 @@ license = "Elastic License v2" name = "AWS Sign-In Root Password Recovery Requested" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - ### Investigating AWS Sign-In Root Password Recovery Requested In AWS, a `PasswordRecoveryRequested` event from `signin.amazonaws.com` is only generated for the root user during the “Forgot your password?” workflow. Other identity types (IAM or federated users) do not trigger this event. A root password recovery request is a critical identity security event that could indicate a legitimate recovery by the account owner or a malicious attempt to gain full administrative access. @@ -29,14 +26,18 @@ In AWS, a `PasswordRecoveryRequested` event from `signin.amazonaws.com` is only - **Verify the event details.** Review the alert fields (`source.ip`, `user_agent.original`, `cloud.region`, and `@timestamp`) to confirm when and from where the request originated. + - **Confirm legitimacy.** Contact the account owner or credential custodian to verify whether they initiated the password recovery. AWS will also send an email notification to the root account email address, check whether the owner received and acknowledged this. + - **Check CloudTrail for related events.** Search for any subsequent `ConsoleLogin` events for the root user, or IAM changes (for example, `CreateAccessKey`, `CreateUser`, or `AttachUserPolicy`) shortly after the recovery request. + - **Assess IP reputation and location.** Validate whether the `source.ip` aligns with known admin networks or expected geographies. Suspicious indicators include foreign IPs, anonymization services, or unfamiliar user agents. + - **Correlate with other alerts.** Review other AWS security detections (for example, root logins, MFA disablement, or IAM policy changes) around the same timeframe. @@ -49,7 +50,7 @@ In AWS, a `PasswordRecoveryRequested` event from `signin.amazonaws.com` is only ### Response and remediation -**1. Immediate actions** +**Immediate actions** - **If confirmed legitimate:** - Ensure that MFA is enabled and operational for the root account. - Encourage rotation of the root password if not recently updated. @@ -58,17 +59,17 @@ In AWS, a `PasswordRecoveryRequested` event from `signin.amazonaws.com` is only - Review the AWS account’s email for password-recovery notifications and secure that inbox (change its password, enable MFA). - Check for new successful root logins or unexpected IAM changes since the recovery attempt. -**2. Evidence preservation** +**Evidence preservation** - Export the `PasswordRecoveryRequested` event from CloudTrail (±30 minutes). - Preserve all `signin.amazonaws.com` and root `ConsoleLogin` events for the next 24 hours. - Store this evidence in a restricted S3 bucket with Object Lock enabled. -**3. Scoping and investigation** +**Scoping and investigation** - Review all root-level activities within the past 24–48 hours. Focus on administrative actions such as `CreateAccessKey`, `UpdateAccountPasswordPolicy`, or `DisableMFA`. - Correlate with GuardDuty findings and AWS Config change history for any unauthorized modifications. -**4. Recovery and hardening** +**Recovery and hardening** - Confirm MFA is enforced on the root account. - Rotate all root credentials and ensure no access keys exist for the root user (root keys should never be active). - Secure the associated email account (password reset notifications are sent there). diff --git a/rules/integrations/aws/initial_access_signin_console_login_federated_user.toml b/rules/integrations/aws/initial_access_signin_console_login_federated_user.toml index 47d7323bc..f3f64e84c 100644 --- a/rules/integrations/aws/initial_access_signin_console_login_federated_user.toml +++ b/rules/integrations/aws/initial_access_signin_console_login_federated_user.toml @@ -2,7 +2,7 @@ creation_date = "2024/08/19" integration = ["aws"] maturity = "production" -updated_date = "2025/10/09" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -25,9 +25,6 @@ license = "Elastic License v2" name = "AWS Sign-In Console Login with Federated User" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - ### Investigating AWS Sign-In Console Login with Federated User Federated users in AWS are granted temporary credentials to access resources, often without the need for a permanent account. This setup is convenient but can be risky if not properly secured with multi-factor authentication (MFA). Adversaries might exploit this by using stolen or misconfigured credentials to gain unauthorized access. CloudTrail alone cannot reliably indicate MFA usage for federated logins. This rule surfaces potentially risky access for analyst review and IdP correlation. @@ -37,20 +34,22 @@ Federated users in AWS are granted temporary credentials to access resources, of - **Identify the prinicipal involved** - `aws.cloudtrail.user_identity.arn` (federated session ARN) - `aws.cloudtrail.user_identity.session_context.session_issuer.*` (role ARN/name, account) of the identity that created the federated session. + - Find the corresponding IdP login around the same time and verify MFA was required and passed. If IdP shows **no MFA**, raise severity. + - **Investigate the source context** - examine `source.ip`, ASN, `geo` fields, and `user_agent.original` - Compare against normal IP ranges, known user-agents and expected locations for this identity -#### Correlate to raise/lower priority -- **Check IdP MFA:** Find the corresponding IdP login around the same time and verify MFA was required and passed. If IdP shows **no MFA**, raise severity. + - **Federation token pivot:** Look for a nearby `signin.amazonaws.com` `GetSigninToken` API call. - **More suspicious:** token creation and console login from different public IPs/ASNs/geo fields. - **Less suspicious:** same IP and expected user agents within ~10–15 minutes (typical operator behavior). + - **Rareness/anomaly signals:** new/rare role or session issuer, rare source IP/ASN/geo, unusual time-of-day, multiple ConsoleLogin events from disparate networks in a short window. + - Review recent activity associated with the federated user to identify any unusual or unauthorized actions that may have occurred following the login event. + - Assess the configuration and policies of the Identity Provider (IdP) used for federated access to ensure MFA is enforced and properly configured for all users. -### Related rules -- AWS Sign-In Token Created - f754e348-f36f-4510-8087-d7f29874cc12 ### False positive analysis - Organizations using SSO for console access will routinely see federated `ConsoleLogin` where CloudTrail shows `MFAUsed: "No"` — this is expected due to IdP-side MFA. diff --git a/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml b/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml index 0b0eb2ca4..e8de60750 100644 --- a/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml +++ b/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml @@ -2,7 +2,7 @@ creation_date = "2024/07/24" integration = ["aws"] maturity = "production" -updated_date = "2025/11/05" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -28,9 +28,6 @@ license = "Elastic License v2" name = "AWS EC2 Instance Console Login via Assumed Role" note = """## 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 Instance Console Login via Assumed Role This rule detects successful AWS console or federation logins using temporary credentials tied to EC2 instance profiles. Under normal conditions, EC2 instances use their temporary credentials for programmatic API access — **not** for interactive console sessions. When an attacker gains access to an instance’s IMDS (Instance Metadata Service) or its environment variables, they may retrieve temporary STS credentials and attempt console logins to gain full access to the AWS account. A successful login of this type is rare and high-risk, as it strongly suggests credential theft or unauthorized session hijacking. diff --git a/rules/integrations/aws/persistence_aws_attempt_to_register_virtual_mfa_device.toml b/rules/integrations/aws/persistence_aws_attempt_to_register_virtual_mfa_device.toml index 045e926d2..5dbf2969d 100644 --- a/rules/integrations/aws/persistence_aws_attempt_to_register_virtual_mfa_device.toml +++ b/rules/integrations/aws/persistence_aws_attempt_to_register_virtual_mfa_device.toml @@ -2,7 +2,7 @@ creation_date = "2025/04/11" integration = ["aws"] maturity = "production" -updated_date = "2025/11/03" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -30,10 +30,6 @@ license = "Elastic License v2" name = "AWS IAM Virtual MFA Device Registration Attempt with Session Token" note = """## Triage and Analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and validated for accuracy and relevance. Always -> tailor the steps to your organization's environment and operational context. - ### Investigating AWS IAM Virtual MFA Device Registration Attempt with Session Token Temporary credentials that start with the prefix `ASIA` are generated by the AWS Security Token Service (STS). These diff --git a/rules/integrations/aws/persistence_ec2_network_acl_creation.toml b/rules/integrations/aws/persistence_ec2_network_acl_creation.toml index f5dcee312..37786c113 100644 --- a/rules/integrations/aws/persistence_ec2_network_acl_creation.toml +++ b/rules/integrations/aws/persistence_ec2_network_acl_creation.toml @@ -2,7 +2,7 @@ creation_date = "2020/06/04" integration = ["aws"] maturity = "production" -updated_date = "2025/06/05" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -22,9 +22,6 @@ license = "Elastic License v2" name = "AWS EC2 Network Access Control List Creation" note = """## 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 Network Access Control List Creation AWS EC2 Network ACLs are stateless firewalls for controlling inbound and outbound traffic at the subnet level. Adversaries may exploit ACLs to establish persistence or exfiltrate data by creating permissive rules. The detection rule monitors successful creation events of ACLs or entries, flagging potential unauthorized modifications that align with persistence tactics, aiding in early threat identification. @@ -56,9 +53,7 @@ AWS EC2 Network ACLs are stateless firewalls for controlling inbound and outboun - Escalate the incident to the security operations team or incident response team for further investigation and to determine if additional containment or remediation actions are necessary. - Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of unauthorized changes to network configurations. -## Setup - -The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" +""" references = [ "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/create-network-acl.html", "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateNetworkAcl.html", diff --git a/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml b/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml index 6d898c32d..fd04f7d97 100644 --- a/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml +++ b/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml @@ -2,7 +2,7 @@ creation_date = "2021/05/05" integration = ["aws"] maturity = "production" -updated_date = "2025/07/10" +updated_date = "2026/01/16" [rule] author = ["Elastic", "Austin Songer"] @@ -21,36 +21,33 @@ license = "Elastic License v2" name = "AWS EC2 Security Group Configuration Change" note = """## 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**: +**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**: +**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**: +**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**: +**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**: +**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**: +**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. diff --git a/rules/integrations/aws/persistence_iam_api_calls_via_user_session_token.toml b/rules/integrations/aws/persistence_iam_api_calls_via_user_session_token.toml index 75ed2fbac..046b185aa 100644 --- a/rules/integrations/aws/persistence_iam_api_calls_via_user_session_token.toml +++ b/rules/integrations/aws/persistence_iam_api_calls_via_user_session_token.toml @@ -2,7 +2,7 @@ creation_date = "2025/04/16" integration = ["aws"] maturity = "production" -updated_date = "2025/12/16" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -27,10 +27,6 @@ license = "Elastic License v2" name = "AWS IAM API Calls via Temporary Session Tokens" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. -> While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - ### Investigating AWS IAM API Calls via Temporary Session Tokens Temporary session credentials in AWS (identified by access keys beginning with "ASIA") are typically short-lived tokens diff --git a/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml b/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml index 75cd8a2a3..829f6ade7 100644 --- a/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml +++ b/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml @@ -2,7 +2,7 @@ creation_date = "2024/12/02" integration = ["aws"] maturity = "production" -updated_date = "2025/10/13" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -17,8 +17,7 @@ license = "Elastic License v2" name = "AWS IAM Login Profile Added for Root" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. +### Investigating AWS IAM Login Profile Added for Root This rule detects when a console login profile is created for the AWS root account. A login profile enables password-based console access, and because the root user has unrestricted privileges, creating one is an extremely high-impact event. Adversaries who temporarily gain root-level credentials (for example, through an STS session or credential compromise) may use `CreateLoginProfile` without specifying a `userName` to add a password to the root account. This grants persistent access even if the attacker’s API keys are later rotated or disabled. @@ -68,27 +67,27 @@ For any potential false positive, verify that: > Any unapproved creation of a login profile for the root account is a critical security incident requiring immediate containment and credential rotation. -**1. Containment** +**Containment** - Delete the newly created root login profile if it was not authorized. - Rotate the root account password using AWS’s official password-reset workflow. - Revoke any active sessions, temporary credentials, or tokens associated with this event. - Verify that multi-factor authentication (MFA) is enabled and functioning on the root account. - Check that no root access keys exist — if present, remove them immediately. -**2. Investigation and scoping** +**Investigation and scoping** - Examine CloudTrail logs from 30 minutes before and after this event to identify correlated actions. - Capture and securely store these logs in an isolated S3 bucket with Object Lock enabled to preserve forensic integrity. - Investigate for additional IAM or STS operations by the same `access_key_id` or IP address that may indicate privilege escalation or persistence attempts. - Review whether any new IAM roles, users, or policies were created in proximity to this event. -**3. Recovery and hardening** +**Recovery and hardening** - Reset the root password and distribute the new credentials securely to authorized custodians only. - Ensure MFA is enforced for all administrative and root-level access. - Audit all IAM policies for least-privilege adherence, focusing on `iam:CreateLoginProfile`, `iam:UpdateLoginProfile`, and `iam:CreateAccessKey` permissions. - Enable Cloudtrail, GuardDuty, AWS Config, and Security Hub across all regions for continuous monitoring of root and IAM activity. - Review your organization’s playbooks and detection coverage for root-level persistence techniques, and update procedures as needed. -**4. Post-incident actions** +**Post-incident actions** - Notify AWS account owners and your security operations center of the incident. - Conduct a post-mortem to determine the initial vector of compromise (e.g., stolen credentials, misconfigured role chaining, or insufficient MFA). - Update alerting thresholds and detection logic to minimize mean time to detect (MTTD) and respond (MTTR). diff --git a/rules/integrations/aws/persistence_iam_group_creation.toml b/rules/integrations/aws/persistence_iam_group_creation.toml index 1fcbd470c..1eb39e9cb 100644 --- a/rules/integrations/aws/persistence_iam_group_creation.toml +++ b/rules/integrations/aws/persistence_iam_group_creation.toml @@ -2,7 +2,7 @@ creation_date = "2020/06/05" integration = ["aws"] maturity = "production" -updated_date = "2025/10/30" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -26,9 +26,6 @@ license = "Elastic License v2" name = "AWS IAM Group Creation" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - ### Investigating AWS IAM Group Creation AWS IAM allows organizations to manage user access and permissions securely. Groups in IAM simplify permission management by allowing multiple users to inherit the same permissions. However, adversaries may exploit this by creating unauthorized groups to gain persistent access. This alert fires on `CreateGroup`. New group creation may indicate attacker staging for persistence, especially if followed by policy attachments or user additions. diff --git a/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml b/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml index 4a76a5b3c..cc0704696 100644 --- a/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml +++ b/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/20" integration = ["aws"] maturity = "production" -updated_date = "2025/11/12" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -26,10 +26,6 @@ license = "Elastic License v2" name = "AWS IAM Roles Anywhere Profile Creation" note = """## 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, validate and adapt it to suit your operational needs. - ### Investigating AWS IAM Roles Anywhere Profile Creation AWS IAM Roles Anywhere allows external workloads — such as CI/CD runners, on-premises systems, or third-party services — diff --git a/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml b/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml index e4bfa1dfd..4c23e38b2 100644 --- a/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml +++ b/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/20" integration = ["aws"] maturity = "production" -updated_date = "2025/11/12" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -29,10 +29,6 @@ license = "Elastic License v2" name = "AWS IAM Roles Anywhere Trust Anchor Created with External CA" note = """## 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, validate and adapt it to suit your operational needs. - ### Investigating AWS IAM Roles Anywhere Trust Anchor Created with External CA AWS IAM Roles Anywhere allows workloads outside AWS (such as on-premises servers or CI/CD agents) to assume AWS IAM roles by presenting X.509 certificates. A trust anchor defines which certificate authority (CA) AWS trusts to validate diff --git a/rules/integrations/aws/persistence_iam_user_created_access_keys_for_another_user.toml b/rules/integrations/aws/persistence_iam_user_created_access_keys_for_another_user.toml index f11cdceaa..6a4dcd371 100644 --- a/rules/integrations/aws/persistence_iam_user_created_access_keys_for_another_user.toml +++ b/rules/integrations/aws/persistence_iam_user_created_access_keys_for_another_user.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/13" integration = ["aws"] maturity = "production" -updated_date = "2025/12/09" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -23,10 +23,6 @@ license = "Elastic License v2" name = "AWS IAM User Created Access Keys For Another User" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - - ### Investigating AWS IAM User Created Access Keys For Another User AWS IAM access keys are long-term credentials that grant programmatic access to AWS resources. The `iam:CreateAccessKey` permission allows an IAM principal to generate new access keys for an existing IAM user. @@ -75,27 +71,24 @@ This rule identifies `CreateAccessKey` API calls where the calling user (`aws.cl ### Response and remediation -> AWS IR playbooks classify unauthorized credential creation as a **Priority-1 incident** because it may allow persistence or privilege escalation. -> The following steps scale for organizations with or without a dedicated IR team. - -**1. Immediate containment** +**Immediate containment** - Deactivate or delete the access key from the target IAM user immediately using the AWS Console, CLI, or API (`DeleteAccessKey`). - Rotate or reset credentials for both the calling and target users to eliminate possible compromise. - Restrict risky principals. Temporarily deny `iam:CreateAccessKey` and `iam:UpdateAccessKey` permissions for non-administrative roles while scoping the incident. - Enable or confirm MFA on both accounts involved, if not already enforced. -**2. Evidence preservation** +**Evidence preservation** - Export all related `CreateAccessKey`, `DeleteAccessKey`, and `UpdateAccessKey` events within ±30 minutes of the alert to an evidence bucket. - Preserve CloudTrail, GuardDuty, and AWS Config data for the same period. - Record key event details: caller ARN, target user, `accessKeyId`, `source.ip`, `userAgent`, and timestamps. -**3. Scoping and investigation** +**Scoping and investigation** - Search CloudTrail for usage of the new access key ID after creation. Identify any API activity or data access tied to it. - Review IAM policy changes, group modifications, or new role assumptions around the same time. - Determine if any additional credentials or trust policy changes were made by the same actor. - Check for GuardDuty findings referencing anomalous credential usage or suspicious API behavior. -**4. Recovery and hardening** +**Recovery and hardening** - Remove or disable any unauthorized keys and re-enable only verified credentials. - Implement least-privilege IAM policies to limit which users can perform `CreateAccessKey`. - Monitor for future `CreateAccessKey` events where `userIdentity.arn != request_parameters.userName`. diff --git a/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml b/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml index 7747f5bbf..793fc2111 100644 --- a/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml +++ b/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/30" integration = ["aws"] maturity = "production" -updated_date = "2025/12/11" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -29,10 +29,6 @@ license = "Elastic License v2" name = "AWS Lambda Function Policy Updated to Allow Public Invocation" note = """## 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 Lambda Function Policy Updated to Allow Public Invocation AWS Lambda policies control who can invoke a function. When the `Principal` is set to `*`, the function becomes publicly invokable by any AWS account. Adversaries may modify Lambda permissions to create a stealthy execution backdoor or to maintain persistence inside an AWS environment. This activity is uncommon in most production environments and should receive careful scrutiny when detected. diff --git a/rules/integrations/aws/persistence_rds_db_instance_password_modified.toml b/rules/integrations/aws/persistence_rds_db_instance_password_modified.toml index 90d460590..b814abf8d 100644 --- a/rules/integrations/aws/persistence_rds_db_instance_password_modified.toml +++ b/rules/integrations/aws/persistence_rds_db_instance_password_modified.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/27" integration = ["aws"] maturity = "production" -updated_date = "2025/11/24" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -28,10 +28,6 @@ license = "Elastic License v2" name = "AWS RDS DB Instance or Cluster Password Modified" note = """## 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, validate and adapt it to suit your operational needs. - ### Investigating AWS RDS DB Instance or Cluster Password Modified The RDS master user password controls privileged access to a database instance or cluster. Modifying it can immediately shift access from one operator to another, break application functionality, or allow an adversary to regain control over a compromised DB instance. Because RDS never returns the password via API, this operation is a strong signal of intentional access reconfiguration. diff --git a/rules/integrations/aws/persistence_rds_instance_made_public.toml b/rules/integrations/aws/persistence_rds_instance_made_public.toml index dec6cfe26..1ad7457ad 100644 --- a/rules/integrations/aws/persistence_rds_instance_made_public.toml +++ b/rules/integrations/aws/persistence_rds_instance_made_public.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/29" integration = ["aws"] maturity = "production" -updated_date = "2025/11/24" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -26,10 +26,6 @@ license = "Elastic License v2" name = "AWS RDS DB Instance Made Public" note = """## 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, validate and adapt it to suit your operational needs. - ### Investigating AWS RDS DB Instance Made Public This rule detects when an Amazon RDS DB instance or cluster is created or modified with diff --git a/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml b/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml index 80a9fefa5..7fefa1eda 100644 --- a/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml +++ b/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml @@ -2,7 +2,7 @@ creation_date = "2021/05/10" integration = ["aws"] maturity = "production" -updated_date = "2025/12/10" +updated_date = "2026/01/16" [rule] author = ["Elastic", "Austin Songer"] @@ -26,9 +26,6 @@ license = "Elastic License v2" name = "AWS Route 53 Domain Transfer Lock Disabled" note = """## 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 Route 53 Domain Transfer Lock Disabled This rule detects when the `DisableDomainTransferLock` operation succeeds for a managed Route 53 domain. The transfer lock diff --git a/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml b/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml index c46c8142e..fe21eb457 100644 --- a/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml +++ b/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml @@ -2,7 +2,7 @@ creation_date = "2021/05/10" integration = ["aws"] maturity = "production" -updated_date = "2025/12/10" +updated_date = "2026/01/16" [rule] author = ["Elastic", "Austin Songer"] @@ -28,9 +28,6 @@ license = "Elastic License v2" name = "AWS Route 53 Domain Transferred to Another Account" note = """## 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 Route 53 Domain Transferred to Another Account Transferring a Route 53 domain to another AWS account is a high-impact administrative action. A successful transfer enables the diff --git a/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml b/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml index df804db5c..6a09be1c5 100644 --- a/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml +++ b/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml @@ -2,7 +2,7 @@ creation_date = "2021/07/19" integration = ["aws"] maturity = "production" -updated_date = "2025/12/10" +updated_date = "2026/01/16" [rule] author = ["Austin Songer", "Elastic"] @@ -26,9 +26,6 @@ license = "Elastic License v2" name = "AWS Route 53 Private Hosted Zone Associated With a VPC" note = """## 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 Route 53 Private Hosted Zone Associated With a VPC Route 53 private hosted zones provide internal DNS capabilities accessible only to the VPCs explicitly associated with diff --git a/rules/integrations/aws/persistence_route_table_created.toml b/rules/integrations/aws/persistence_route_table_created.toml index 057fd757c..fe48343e5 100644 --- a/rules/integrations/aws/persistence_route_table_created.toml +++ b/rules/integrations/aws/persistence_route_table_created.toml @@ -2,7 +2,7 @@ creation_date = "2021/06/05" integration = ["aws"] maturity = "production" -updated_date = "2025/09/04" +updated_date = "2026/01/16" [rule] author = ["Elastic", "Austin Songer"] @@ -24,9 +24,6 @@ license = "Elastic License v2" name = "AWS EC2 Route Table Created" note = """## 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 Route Table Created AWS Route Tables are crucial components in managing network traffic within AWS environments, directing data between subnets and internet gateways. Adversaries may exploit route tables to reroute traffic for data exfiltration or to establish persistence by creating unauthorized routes. The detection rule monitors successful creation events of route tables, flagging potential misuse by correlating specific AWS CloudTrail logs, thus aiding in identifying unauthorized network configuration changes. diff --git a/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml b/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml index 56b803292..fefefd677 100644 --- a/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml +++ b/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml @@ -2,7 +2,7 @@ creation_date = "2024/10/25" integration = ["aws"] maturity = "production" -updated_date = "2025/08/20" +updated_date = "2026/01/16" [rule] @@ -22,9 +22,6 @@ license = "Elastic License v2" name = "AWS STS AssumeRole with New MFA Device" note = """## 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 STS AssumeRole with New MFA Device AWS Security Token Service (STS) allows users to assume roles and gain temporary credentials for accessing AWS resources. This process can involve Multi-Factor Authentication (MFA) for enhanced security. However, adversaries may exploit new MFA devices to maintain persistence or escalate privileges. The detection rule identifies successful role assumptions with new MFA devices, flagging potential misuse for further investigation. diff --git a/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_group.toml b/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_group.toml index 339ac8ed5..7a16cf870 100644 --- a/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_group.toml +++ b/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_group.toml @@ -2,7 +2,7 @@ creation_date = "2024/05/31" integration = ["aws"] maturity = "production" -updated_date = "2025/10/13" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -26,9 +26,6 @@ license = "Elastic License v2" name = "AWS IAM AdministratorAccess Policy Attached to Group" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - ### Investigating AWS IAM AdministratorAccess Policy Attached to Group The AWS-managed `AdministratorAccess` policy grants full administrative privileges across all AWS services. @@ -66,22 +63,22 @@ Adversaries can exploit `iam:AttachGroupPolicy` permissions to escalate privileg ### Response and remediation -**1. Immediate containment** +**Immediate containment** - Detach the policy from the affected group (`aws iam detach-group-policy`). - Review and limit group membership. Temporarily remove non-essential users or disable access for impacted accounts. - Rotate credentials for users who inherited admin privileges from the attachment. - Enable MFA on all impacted accounts. -**2. Evidence preservation** +**Evidence preservation** - Export the triggering `AttachGroupPolicy` event and related CloudTrail entries ±30 minutes from the alert. - Preserve AWS Config and GuardDuty records to support forensic analysis. -**3. Scoping and investigation** +**Scoping and investigation** - Review additional IAM operations from the same caller (`CreateAccessKey`, `AttachRolePolicy`, `UpdateAssumeRolePolicy`). - Identify whether new groups or roles were created shortly before or after the event. - Check for subsequent API activity by newly privileged users (for example, S3, EC2, or IAM modifications). -**4. Recovery and hardening** +**Recovery and hardening** - Reinforce least privilege, avoid assigning `AdministratorAccess` to groups. - Use role-based access control with scoped permissions. - Enable CloudTrail, GuardDuty, and Security Hub across all regions. diff --git a/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_role.toml b/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_role.toml index 010cbc4e0..87734bebf 100644 --- a/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_role.toml +++ b/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_role.toml @@ -2,7 +2,7 @@ creation_date = "2024/05/31" integration = ["aws"] maturity = "production" -updated_date = "2025/10/13" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -25,9 +25,6 @@ license = "Elastic License v2" name = "AWS IAM AdministratorAccess Policy Attached to Role" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - ### Investigating AWS IAM AdministratorAccess Policy Attached to Role The `AdministratorAccess` managed policy grants unrestricted privileges. @@ -64,22 +61,22 @@ This rule detects `AttachRolePolicy` events where the `policyName` is `Administr ### Response and remediation -**1. Immediate containment** +**Immediate containment** - Detach the policy. Remove the `AdministratorAccess` policy from the target role. - Restrict access. Temporarily revoke the caller’s IAM privileges until the legitimacy of the action is confirmed. - Audit trust policies. Review the role’s trust relationships to ensure only approved principals can assume it. - Rotate credentials for any principals who assumed the affected role during the period of elevated privileges. -**2. Evidence preservation** +**Evidence preservation** - Export the triggering `AttachRolePolicy` event and related CloudTrail entries ±30 minutes from the alert. - Preserve AWS Config snapshots and GuardDuty findings for traceability. -**3. Scoping and investigation** +**Scoping and investigation** - Identify if the elevated role was subsequently assumed. Correlate by matching `aws.cloudtrail.eventName:AssumeRole` with the target role ARN. - Search for other recent IAM policy attachments or modifications by the same actor or IP. -**4. Recovery and hardening** +**Recovery and hardening** - Apply least privilege policies; limit who can attach or modify administrative policies. - Enforce IAM Conditions such as `aws:PrincipalArn` or `aws:ResourceTag` to limit policy attachment scope. - Enable CloudTrail, GuardDuty, and Security Hub across all regions. diff --git a/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_user.toml b/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_user.toml index 11e6b54cd..f694877d8 100644 --- a/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_user.toml +++ b/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_user.toml @@ -2,7 +2,7 @@ creation_date = "2024/05/30" integration = ["aws"] maturity = "production" -updated_date = "2025/10/13" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -25,9 +25,6 @@ license = "Elastic License v2" name = "AWS IAM AdministratorAccess Policy Attached to User" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - ### Investigating AWS IAM AdministratorAccess Policy Attached to User The AWS-managed `AdministratorAccess` policy grants full access to all AWS services and resources. @@ -66,24 +63,22 @@ This rule detects `AttachUserPolicy` events where the attached policy name is `A ### Response and remediation -> Per AWS IR Playbooks, unauthorized administrative policy attachment represents a Privilege Escalation event. - -**1. Immediate containment** +**Immediate containment** - Detach the policy. Remove the `AdministratorAccess` policy from the affected IAM user immediately (`aws iam detach-user-policy`). - Rotate credentials. Rotate passwords and access keys for both the caller and target users. - Restrict IAM permissions. Temporarily remove `iam:AttachUserPolicy` privileges from non-administrative roles during scoping. - Enable or confirm MFA for affected accounts. -**2. Evidence preservation** +**Evidence preservation** - Export related `AttachUserPolicy` CloudTrail events ±30 minutes from the alert to a secure evidence bucket. - Preserve GuardDuty findings and AWS Config snapshots for correlation. -**3. Scoping and investigation** +**Scoping and investigation** - Search CloudTrail for subsequent use of the affected user’s credentials. Look for newly created keys, S3 access, or changes to IAM trust policies. - Review other accounts for similar policy attachment attempts from the same user or IP. -**4. Recovery and hardening** +**Recovery and hardening** - Reinforce least privilege by granting only role-based admin access instead of direct user-level AdministratorAccess. - Implement IAM service control policies (SCPs) to prevent attachment of `AdministratorAccess` except for trusted roles. - Enable CloudTrail, GuardDuty, and Security Hub across all regions. diff --git a/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml b/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml index 24d743413..4b9ab1316 100644 --- a/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml +++ b/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml @@ -2,7 +2,7 @@ creation_date = "2021/09/22" integration = ["aws"] maturity = "production" -updated_date = "2025/11/05" +updated_date = "2026/01/16" [rule] author = ["Elastic", "Austin Songer"] @@ -28,9 +28,6 @@ license = "Elastic License v2" name = "AWS IAM SAML Provider Updated" note = """## Triage and analysis -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - ### Investigating AWS IAM SAML Provider Updated AWS IAM SAML providers enable federated authentication between AWS and external identity providers (IdPs), diff --git a/rules/integrations/aws/privilege_escalation_sts_assume_root_from_rare_user_and_member_account.toml b/rules/integrations/aws/privilege_escalation_sts_assume_root_from_rare_user_and_member_account.toml index b0b7181de..49cbe18da 100644 --- a/rules/integrations/aws/privilege_escalation_sts_assume_root_from_rare_user_and_member_account.toml +++ b/rules/integrations/aws/privilege_escalation_sts_assume_root_from_rare_user_and_member_account.toml @@ -2,7 +2,7 @@ creation_date = "2024/11/24" integration = ["aws"] maturity = "production" -updated_date = "2025/12/02" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -26,10 +26,6 @@ name = "AWS STS AssumeRoot by Rare User and Member Account" note = """ ## 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, validate and adapt it to suit your operational needs. - ### Investigating AWS STS AssumeRoot by Rare User and Member Account AWS STS `AssumeRoot` issues temporary credentials that grant elevated access into a member account, constrained by the diff --git a/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml b/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml index 93d358070..6e489d34a 100644 --- a/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml +++ b/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml @@ -2,7 +2,7 @@ creation_date = "2024/10/23" integration = ["aws"] maturity = "production" -updated_date = "2025/10/02" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -26,9 +26,6 @@ name = "AWS STS Role Chaining" note = """ ## 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 STS Role Chaining Role chaining occurs when a role assumed with temporary credentials (`AssumeRole`) is used to assume another role. While supported by AWS, chaining can increase risk of Privilege escalation, if the second role grants broader permissions; and Persistence, since each chained AssumeRole refreshes the session with up to 1-hour duration. This new terms rule triggers on the first observed combination of one role (`aws.cloudtrail.user_identity.session_context.session_issuer.arn`) assuming another (`aws.cloudtrail.resources.arn`). @@ -36,10 +33,15 @@ Role chaining occurs when a role assumed with temporary credentials (`AssumeRole ### Possible investigation steps - **Review Alert Context**: Investigate the alert, focusing on `aws.cloudtrail.user_identity.session_context.session_issuer.arn` (the calling role) and `aws.cloudtrail.resources.arn` (the target role). + - **Determine scope and intent.** Check `aws.cloudtrail.recipient_account_id` and `aws.cloudtrail.resources.account_id` fields to identify whether the chaining is Intra-account (within the same AWS account) or Cross-account (from another AWS account). + - **Check role privileges.** Compare policies of the calling and target roles. Determine if chaining increases permissions (for example, access to S3 data, IAM modifications, or admin privileges). + - **Correlate with other activity.** Look for related alerts or CloudTrail activity within ±30 minutes: policy changes, unusual S3 access, or use of sensitive APIs. Use `aws.cloudtrail.user_identity.arn` to track behavior from the same role session, use `aws.cloudtrail.user_identity.session_context.session_issuer.arn` to track broader behavior from the role itself. + - **Validate legitimacy.** Contact the account or service owner to confirm if the chaining was expected (for example, automation pipelines or federated access flows). + - **Geography & source.** Review `cloud.region`, `source.address`, and other `geo` fields to assess if the activity originates from expected regions or network ranges. ### False positive analysis @@ -50,20 +52,20 @@ Role chaining occurs when a role assumed with temporary credentials (`AssumeRole ### Response and remediation -**1. Immediate steps** +**Immediate steps** - **Preserve evidence.** Export triggering CloudTrail events (±30 minutes) into a restricted evidence bucket. Include session context, source IP, and user agent. - **Notify owners.** Contact the owners of both roles to validate intent. -**2. Containment (if suspicious)** +**Containment (if suspicious)** - **Revoke temporary credentials.** [Revoke Session Permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html) if possible, or attach [AWSDenyALL policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html) to the originating role. - **Restrict risky roles.** Apply least-privilege policies or temporarily deny `sts:AssumeRole` for suspicious principals. - **Enable monitoring.** Ensure CloudTrail and GuardDuty are active in all regions to detect further chaining. -**3. Scope and hunt** +**Scope and hunt** - Search for additional AssumeRole activity by the same `issuer.arn` or `resources.arn` across other accounts and regions. - Look for privilege escalation attempts (for example, IAM `AttachRolePolicy`, `UpdateAssumeRolePolicy`) or sensitive data access following the chain. -**4. Recovery & hardening** +**Recovery & hardening** - Apply least privilege to all roles, limiting trust policies to only required principals. - Enforce MFA where possible on AssumeRole operations. - Periodically review role chaining patterns to validate necessity; remove unused or risky trust relationships. diff --git a/rules/integrations/aws/resource_development_sns_topic_created_by_rare_user.toml b/rules/integrations/aws/resource_development_sns_topic_created_by_rare_user.toml index 0ac4f1a40..275e3f821 100644 --- a/rules/integrations/aws/resource_development_sns_topic_created_by_rare_user.toml +++ b/rules/integrations/aws/resource_development_sns_topic_created_by_rare_user.toml @@ -2,7 +2,7 @@ creation_date = "2025/02/11" integration = ["aws"] maturity = "production" -updated_date = "2025/09/09" +updated_date = "2026/01/16" [rule] author = ["Elastic"] @@ -30,60 +30,46 @@ This rule detects the creation of an AWS Simple Notification Service (SNS) topic 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 by a user or role. -#### Possible Investigation Steps +### Possible investigation steps -### Identify the Actor and Context -- **User Identity and Role**: +**Identify the actor and context** - Examine `aws.cloudtrail.user_identity.arn` to determine **who** created the SNS topic. - - Identify whether the actor assumed a **privileged IAM role** (`aws.cloudtrail.user_identity.type: "AssumedRole"`) or used a long term access keys (`aws.cloudtrail.user_identity.access_key_id`). -- **User Agent and Tooling**: + - Identify whether the actor assumed a privileged IAM role (`aws.cloudtrail.user_identity.type: "AssumedRole"`) or used a long term access keys (`aws.cloudtrail.user_identity.access_key_id`). - Check `user_agent.original` to determine if this action was performed via the AWS CLI, SDK, or Console. - If `aws-cli` was used, review whether it aligns with typical automation or administrative behavior. -- **Source IP and Geographic Location**: - - Review `source.ip` and `source.geo` fields to confirm if the request originated from a **trusted** or **unexpected** location. + - Review `source.ip` and `source.geo` fields to confirm if the request originated from a trusted or unexpected location. -### Evaluate the SNS Topic Creation -- **Topic Name and Purpose**: - - Check `aws.cloudtrail.request_parameters` for the **SNS topic name** and determine whether it appears suspicious (e.g., random strings, unusual keywords). -- **Target Region and Account**: - - Verify `cloud.region` and `cloud.account.id` to **ensure the SNS topic was created in an expected environment**. -- **Associated API Calls**: +**Evaluate the SNS topic creation** + - Check `aws.cloudtrail.request_parameters` for the SNS topic name and determine whether it appears suspicious (e.g., random strings, unusual keywords). + - Verify `cloud.region` and `cloud.account.id` to ensure the SNS topic was created in an expected environment. - Identify additional actions **before or after** this event using `event.action` values like: - `Subscribe` - `Publish` - `SetTopicAttributes` - These may indicate follow-up steps taken to misuse the SNS topic. -### Analyze Potential Malicious Intent -- **Is This an Isolated Action or a Pattern?** - - Check if this **user has previously created SNS topics** using historical CloudTrail logs. - - Look for **multiple topic creations in a short period**, which may suggest an automation script or malicious behavior. -- **Unusual Role Usage**: - - If `aws.cloudtrail.user_identity.arn` references an **EC2 instance role**, verify whether that instance typically performs SNS operations. -- **Potential Data Exfiltration or Persistence**: - - Review whether **new subscriptions** were added (`Subscribe` API action) to forward data externally. - - If an SNS topic was configured to trigger **Lambda functions or S3 events**, it may indicate an attempt to persist in the environment. +**Analyze potential malicious intent** + - Check if this user has previously created SNS topics using historical CloudTrail logs. + - Look for multiple topic creations in a short period, which may suggest an automation script or malicious behavior. + - If `aws.cloudtrail.user_identity.arn` references an EC2 instance role, verify whether that instance typically performs SNS operations. + - Review whether new subscriptions were added (`Subscribe` API action) to forward data externally. + - If an SNS topic was configured to trigger Lambda functions or S3 events, it may indicate an attempt to persist in the environment. -## False Positive Analysis -- **Legitimate Usage of SNS**: - - SNS is commonly used for **event-driven notifications** in AWS. - - Check whether the SNS topic creation aligns with known **DevOps, automation, or monitoring activities**. -- **Routine IAM Role Activity**: - - If the user typically interacts with SNS, consider **allowlisting** expected IAM roles for this action. -- **AWS Services Creating Topics Automatically**: - - Some AWS services may **auto-create SNS topics** for alerts and monitoring. Confirm whether the creation was system-generated. +### False positive analysis +- Check whether the SNS topic creation aligns with known DevOps, automation, or monitoring activities. +- If the user typically interacts with SNS, consider allowlisting expected IAM roles for this action. +- Some AWS services may auto-create SNS topics for alerts and monitoring. Confirm whether the creation was system-generated. -## Response and Remediation +### Response and remediation - **Confirm Authorization**: - If the user was not expected to create SNS topics, verify whether their IAM permissions should be restricted. -- **Revoke Unauthorized Access**: - If unauthorized, disable the access keys or IAM role associated with the event. - **Monitor for Further SNS Modifications**: - - Set up additional monitoring for **SNS Publish or Subscription events** (`Publish`, `Subscribe`). -- **Enhance IAM Policy Controls**: - - Consider enforcing **least privilege** IAM policies and enabling **multi-factor authentication (MFA)** where applicable. + - Set up additional monitoring for SNS Publish or Subscription events (`Publish`, `Subscribe`). - **Investigate for Persistence**: - - Check whether the SNS topic is **being used as a notification channel for Lambda, S3, or other AWS services**. + - Check whether the SNS topic is being used as a notification channel for Lambda, S3, or other AWS services. +- **Enhance IAM Policy Controls**: + - Consider enforcing least privilege IAM policies and enabling multi-factor authentication (MFA) where applicable. """ references = [ "https://docs.aws.amazon.com/sns/latest/api/API_CreateTopic.html",