nldcsc-elastic-rules 0.0.8__py3-none-any.whl → 0.0.16__py3-none-any.whl

nldcsc_elastic_rules/rules/integrations/aws/defense_evasion_rds_instance_restored.toml

@@ -2,24 +2,130 @@
 creation_date = "2021/06/29"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/12/01"
 
 [rule]
 author = ["Austin Songer", "Elastic"]
 description = """
-An adversary with a set of compromised credentials may attempt to make copies of running or deleted RDS databases in order to evade defense mechanisms or access data. This rule identifies successful attempts to restore a DB instance using the RDS `RestoreDBInstanceFromDBSnapshot` or `RestoreDBInstanceFromS3` API operations.
+Identifies the restoration of an AWS RDS database instance from a snapshot or S3 backup. Adversaries with access to
+valid credentials may restore copies of existing databases to bypass logging and monitoring controls or to exfiltrate
+sensitive data from a duplicated environment. This rule detects successful restoration operations using
+"RestoreDBInstanceFromDBSnapshot" or "RestoreDBInstanceFromS3", which may indicate unauthorized data access or
+post-compromise defense evasion.
 """
 false_positives = [
     """
-    Restoring DB instances may be done by a system or network administrator. Verify whether the user identity, user agent,
-    and/or hostname should be making changes in your environment. Instance restoration by unfamiliar users or hosts
-    should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    Restoring an RDS DB instance may be performed legitimately during troubleshooting, development refresh processes,
+    migrations, or disaster-recovery drills. Validate the user identity, source IP, automation context, and whether the
+    restoration aligns with a known maintenance or testing workflow before treating the event as suspicious. Expected
+    behavior can be exempted through rule exceptions.
     """,
 ]
 index = ["filebeat-*", "logs-aws.cloudtrail-*"]
-language = "eql"
+language = "kuery"
 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. 
+
+This rule detects successful invocation of `RestoreDBInstanceFromDBSnapshot` and `RestoreDBInstanceFromS3`, both of which may indicate attempts to rehydrate old datasets, bypass deletion protection, or establish a shadow environment for further malicious actions.
+
+#### Possible investigation steps
+
+- **Identify the actor and execution context**
+  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id`.
+  - Check `user.name`, `source.ip`, and `user_agent.original` to determine how the restore was executed (console, CLI, automation, SDK).
+
+- **Understand what was restored and why**
+  - Inspect `aws.cloudtrail.request_parameters` to identify:
+    - Snapshot identifier or S3 location used as the restore source.
+    - The new DB instance identifier and configuration parameters.
+  - Determine:
+    - Whether the snapshot/backup used for the restore contains sensitive or high-value data.
+    - Whether this restore created a publicly accessible instance, changed security groups, or used unusual storage/instance classes.
+
+- **Reconstruct the activity flow**
+  - Use `@timestamp` to correlate the restore event with:
+    - Snapshot creation, copy, or export events.
+    - IAM policy changes or privilege escalations.
+    - Deletion or modification of the original database.
+    - Other RDS lifecycle actions such as `ModifyDBInstance`, `DeleteDBInstance`, or backup configuration changes.
+  - Look for signs of attacker staging:
+    - Prior enumeration activity (`DescribeDBSnapshots`, `DescribeDBInstances`).
+    - Recent logins from unusual IPs or federated sessions without MFA.
+
+- **Correlate with broader behavior**
+  - Pivot in CloudTrail on:
+    - The same snapshot identifier.
+    - The same actor or access key ID.
+    - The newly created DB instance identifier.
+  - Examine:
+    - Whether the restored DB was modified immediately after (e.g., security groups opened, deletion protection disabled).
+    - Whether there were large-volume read operations or export actions following the restore.
+    - Whether the restore is part of a pattern of parallel suspicious activity (snapshot copying, S3 backups, cross-account actions).
+
+- **Validate intent with owners**
+  - Confirm with the application/database/platform teams:
+    - Whether the restore was requested or part of an authorized operational workflow.
+    - Whether this restore corresponds to migration, testing, DR drill, or another planned activity.
+    - Whether the restored environment should exist (and for how long).
+
+### False positive analysis
+
+- **Legitimate maintenance and DR workflows**
+  - Many teams restore databases for patch testing, DR validation, schema testing, or migration.
+- **Automated restore workflows**
+  - CI/CD pipelines or internal automation may restore DBs to generate staging or dev environments.
+- **Third-party tooling**
+  - Backup/DR solutions, migration tools, or observability platforms may restore DB instances for operational reasons. Tune based on `user_agent.original` or known service roles.
+
+### Response and remediation
+
+- **Contain the restored environment**
+  - If unauthorized:
+    - Apply restrictive security groups to block access.
+    - Disable public accessibility if enabled.
+    - Evaluate whether deletion protection or backup retention is misconfigured.
+
+- **Assess data exposure and intent**
+  - Work with data owners to evaluate:
+    - The sensitivity of the restored environment.
+    - Whether any reads, dumps, or exports occurred post-restore.
+    - Whether the restore enabled the attacker to access older or deleted data.
+
+- **Investigate scope and related activity**
+  - Review CloudTrail for:
+    - Additional restores, exports, or copies.
+    - IAM changes allowing expanded privileges.
+    - Unusual authentication events or federated sessions without MFA.
+    - Related destructive actions (snapshot deletion, backup disabled, instance deletion).
+
+- **Hardening and preventive controls**
+  - Enforce least privilege for `rds:RestoreDBInstanceFromDBSnapshot` and `rds:RestoreDBInstanceFromS3`.
+  - Use IAM conditions to restrict restore actions by network, principal, or region.
+  - Add AWS Config and Security Hub controls for monitoring:
+    - Unapproved restores.
+    - Public or misconfigured restored instances.
+  - Consider SCPs that prevent RDS restores in production accounts except through controlled roles.
+
+- **Post-incident improvements**
+  - Rotate credentials for affected IAM users/roles.
+  - Update change management processes to ensure restore actions are tracked and approved.
+  - Adjust rule exceptions sparingly and ensure high-risk restores continue to generate alerts.
+
+### Additional information
+
+- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
+- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
+- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
+"""
 references = [
     "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html",
     "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html",
@@ -39,49 +145,15 @@ tags = [
     "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
-type = "eql"
+type = "query"
 
 query = '''
-any where event.dataset == "aws.cloudtrail"
-    and event.provider == "rds.amazonaws.com"
-    and event.action in ("RestoreDBInstanceFromDBSnapshot", "RestoreDBInstanceFromS3")
-    and event.outcome == "success"
+event.dataset: "aws.cloudtrail"
+    and event.provider: "rds.amazonaws.com"
+    and event.action: ("RestoreDBInstanceFromDBSnapshot" or "RestoreDBInstanceFromS3")
+    and event.outcome: "success"
 '''
-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 Instance Restored
-
-Amazon RDS (Relational Database Service) allows users to set up, operate, and scale databases in the cloud. Adversaries may exploit RDS by restoring DB instances from snapshots or S3 to access sensitive data or bypass security controls. The detection rule identifies successful restoration attempts, signaling potential unauthorized access or data exfiltration activities, by monitoring specific API operations and outcomes.
-
-### Possible investigation steps
 
-- Review the CloudTrail logs to identify the user or role associated with the successful `RestoreDBInstanceFromDBSnapshot` or `RestoreDBInstanceFromS3` API call by examining the `user.identity` field.
-- Check the source IP address and location from which the API call was made using the `sourceIPAddress` field to determine if it aligns with expected or known locations.
-- Investigate the timing of the restoration event by looking at the `@timestamp` field to see if it coincides with any other suspicious activities or anomalies in the environment.
-- Examine the specific DB instance details restored, such as the DB instance identifier, to assess the sensitivity of the data involved and potential impact.
-- Verify if there are any associated alerts or logs indicating unauthorized access or data exfiltration attempts around the same time frame.
-- Contact the user or team responsible for the credentials used, if legitimate, to confirm whether the restoration was authorized and intended.
-
-### False positive analysis
-
-- Routine database maintenance or testing activities may trigger the rule. Organizations should identify and document regular restoration activities performed by authorized personnel and exclude these from alerts.
-- Automated backup and restore processes used for disaster recovery or data migration can result in false positives. Users should configure exceptions for known automated processes by filtering based on specific user accounts or roles.
-- Development and staging environments often involve frequent restoration of databases for testing purposes. Exclude these environments by identifying and filtering out specific instance identifiers or tags associated with non-production environments.
-- Scheduled tasks or scripts that restore databases as part of regular operations can be mistaken for unauthorized activity. Ensure these tasks are well-documented and create exceptions based on the source IP or IAM role used for these operations.
-- Third-party services or integrations that require database restoration for functionality may trigger alerts. Verify these services and exclude their associated actions by identifying their unique user agents or API keys.
-
-### Response and remediation
-
-- Immediately isolate the restored RDS instance to prevent unauthorized access. This can be done by modifying the security group rules to restrict inbound and outbound traffic.
-- Conduct a thorough review of CloudTrail logs to identify the source of the compromised credentials and any other suspicious activities associated with the same user or account.
-- Revoke the compromised credentials and issue new credentials for the affected user or service account. Ensure that multi-factor authentication (MFA) is enabled for all accounts.
-- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized restoration and any potential data exposure.
-- Perform a security assessment of the restored RDS instance to identify any unauthorized changes or data exfiltration. This includes checking for unusual queries or data exports.
-- Implement additional monitoring and alerting for similar API operations to detect future unauthorized restoration attempts promptly.
-- Review and update IAM policies to ensure that only authorized users have the necessary permissions to restore RDS instances, reducing the risk of future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
@@ -93,14 +165,34 @@ reference = "https://attack.mitre.org/techniques/T1578/"
 id = "T1578.002"
 name = "Create Cloud Instance"
 reference = "https://attack.mitre.org/techniques/T1578/002/"
+
 [[rule.threat.technique.subtechnique]]
 id = "T1578.004"
 name = "Revert Cloud Instance"
 reference = "https://attack.mitre.org/techniques/T1578/004/"
 
 
+
 [rule.threat.tactic]
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
 
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "user.name",
+    "user_agent.original",
+    "source.ip",
+    "aws.cloudtrail.user_identity.arn",
+    "aws.cloudtrail.user_identity.type",
+    "aws.cloudtrail.user_identity.access_key_id",
+    "target.entity.id",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+    "aws.cloudtrail.response_elements",
+]
+

nldcsc_elastic_rules/rules/integrations/aws/discovery_iam_principal_enumeration_via_update_assume_role_policy.toml

@@ -0,0 +1,152 @@
+[metadata]
+creation_date = "2020/07/16"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/11/25"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects repeated failed attempts to update an IAM role’s trust policy in an AWS account, consistent with role and user
+enumeration techniques. In this technique, an attacker who controls credentials in the current account repeatedly calls
+UpdateAssumeRolePolicy on a single role, cycling through guessed cross-account role or user ARNs as the principal. When
+those principals are invalid, IAM returns MalformedPolicyDocumentException, producing a burst of failed
+UpdateAssumeRolePolicy events. This rule alerts on that brute-force pattern originating from this account, which may
+indicate that the account is being used as attack infrastructure or that offensive tooling (such as Pacu) is running
+here. Note: this rule does not detect other accounts enumerating roles, because those API calls are logged in the
+caller’s account, not the target account.
+"""
+from = "now-6m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+language = "kuery"
+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.  
+Adversaries who have obtained valid AWS credentials may attempt to identify roles or accounts that can be assumed by repeatedly modifying a role’s trust relationship using guessed `Principal` ARNs.  
+When these principals are invalid, IAM rejects the request, creating a recognizable sequence of failed `UpdateAssumeRolePolicy` events.
+
+Because this is a threshold rule, it triggers when the number of failures exceeds a defined count within a short period. This pattern suggests brute-force-style enumeration rather than normal misconfiguration.
+
+#### Possible investigation steps
+
+- **Validate the context of the threshold trigger**
+  - Review the `@timestamp` range for when the burst occurred and the number of failed attempts in the threshold window.
+  - Identify whether all failures targeted the same `RoleName` or multiple roles — targeting a single role is often indicative of brute-force enumeration.
+  - Confirm the source identity and IP address (`aws.cloudtrail.user_identity.arn`, `source.ip`, `user_agent.original`) to determine whether these calls originated from a known automation process or an unexpected host.
+
+- **Correlate with other IAM activity**
+  - Look for any subsequent successful `UpdateAssumeRolePolicy` or `AssumeRole` calls, which may indicate the attacker eventually discovered a valid principal.
+  - Search for reconnaissance-related API calls (`ListRoles`, `ListUsers`, `GetCallerIdentity`) before the threshold event — these often precede enumeration bursts.
+  - Investigate whether other suspicious role- or identity-related actions occurred near the same timeframe, such as `CreateRole`, `PutRolePolicy`, or `AttachRolePolicy`.
+
+- **Identify infrastructure patterns**
+  - Examine the `user_agent.original` field — the presence of automation frameworks or penetration tools (e.g., “Boto3”, “Pacu”) may signal offensive tooling.
+  - Review the `source.ip` or `cloud.account.id` fields to see whether this account may be acting as attacker-controlled infrastructure attempting to enumerate roles in other environments.
+
+- **Validate authorization**
+  - Confirm with your DevOps or Cloud IAM teams whether any expected testing, migration, or cross-account role configuration changes were planned for this time period.
+  - If the identity performing these actions does not typically manage IAM roles or trust relationships, escalate for investigation as a possible credential compromise.
+
+### False positive analysis
+
+- **Legitimate automation retries**
+  - Continuous integration or configuration management systems may retry failed IAM API calls during deployment rollouts.  
+    If the same IAM role was being updated as part of a known change, validate the timing and source identity before closing as benign.
+- **Misconfigured scripts or infrastructure drift**
+  - Scripts that deploy trust policies using outdated or invalid ARNs can cause repetitive failures that mimic brute-force patterns.  
+    Review the `RoleName` and `Principal` ARNs included in the failed requests to confirm if they correspond to known but outdated configurations.
+
+### Response and remediation
+
+- **Immediate review and containment**
+  - Investigate whether the source account is being used for offensive operations or compromised automation.
+  - Disable or suspend the IAM user or access key responsible for the enumeration burst.
+  - If activity originated from a workload or CI/CD system, audit its access keys and environment variables for compromise.
+
+- **Investigation and scoping**
+  - Review CloudTrail logs for other IAM or STS actions from the same source in the preceding and following 24 hours.
+  - Check for any successful privilege changes (`PutRolePolicy`, `AttachRolePolicy`, or `AssumeRole`) by the same identity.
+  - Determine if other roles in the same account experienced similar failed updates or bursts.
+
+- **Recovery and hardening**
+  - Rotate credentials for any identities involved.
+  - Limit permissions to modify trust policies (`iam:UpdateAssumeRolePolicy`) to a small set of administrative roles.
+  - Enable AWS Config rule `iam-role-trust-policy-check` to detect overly permissive or unusual trust relationships.
+  - Use AWS GuardDuty or Security Hub to monitor for subsequent privilege escalation or reconnaissance findings.
+  - Review the event against AWS Incident Response Playbook guidance (containment > investigation > recovery > hardening).
+
+### Additional information
+  - **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
+  - **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
+  - **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)
+"""
+references = [
+    "https://www.praetorian.com/blog/aws-iam-assume-role-vulnerabilities",
+    "https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/",
+]
+risk_score = 47
+rule_id = "ea248a02-bc47-4043-8e94-2885b19b2636"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS IAM",
+    "Use Case: Identity and Access Audit",
+    "Resources: Investigation Guide",
+    "Tactic: Discovery",
+    "Tactic: Credential Access",
+]
+timestamp_override = "event.ingested"
+type = "threshold"
+
+query = '''
+event.dataset: "aws.cloudtrail" 
+    and event.provider: "iam.amazonaws.com" 
+    and event.action: "UpdateAssumeRolePolicy" 
+    and aws.cloudtrail.error_code: "MalformedPolicyDocumentException" 
+    and event.outcome: "failure"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1087"
+name = "Account Discovery"
+reference = "https://attack.mitre.org/techniques/T1087/"
+[[rule.threat.technique.subtechnique]]
+id = "T1087.004"
+name = "Cloud Account"
+reference = "https://attack.mitre.org/techniques/T1087/004/"
+
+
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1110"
+name = "Brute Force"
+reference = "https://attack.mitre.org/techniques/T1110/"
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+
+[rule.threshold]
+field = ["cloud.account.id", "user.name", "source.ip"]
+value = 25
+

nldcsc_elastic_rules/rules/integrations/aws/discovery_multiple_discovery_api_calls_via_cli.toml

@@ -0,0 +1,242 @@
+[metadata]
+creation_date = "2024/11/04"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/12/04"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects when a single AWS resource is running multiple read-only, discovery API calls in a 10-second window. This
+behavior could indicate an actor attempting to discover the AWS infrastructure using compromised credentials or a
+compromised instance. Adversaries may use this information to identify potential targets for further exploitation or to
+gain a better understanding of the target's infrastructure.
+"""
+false_positives = [
+    """
+    Administrators or automated systems may legitimately perform multiple `Describe`, `List`, `Get` and `Generate` API calls in a short
+    time frame. Verify the user identity and the purpose of the API calls to determine if the behavior is expected.
+    """,
+]
+from = "now-6m"
+language = "esql"
+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.  
+High volumes of diverse “read-only” API calls in such a short period can indicate scripted reconnaissance, often an early phase of compromise after credential exposure or access to a compromised EC2 instance.  
+
+#### Possible Investigation Steps
+
+**Identify the actor and session context**
+- **Actor ARN (`aws.cloudtrail.user_identity.arn`)**: Determine which IAM user, role, or service principal performed the actions.  
+  - Check whether this identity normally performs enumeration activity or belongs to automation infrastructure.  
+- **Identity type (`Esql.aws_cloudtrail_user_identity_arn_type`)**: Validate if the caller is a human IAM user, assumed role, or federated identity. Unusual types (e.g., temporary credentials from an unfamiliar role) may indicate lateral movement.  
+- **Access key (`Esql.aws_cloudtrail_user_identity_access_key_id_values`)** – Identify which specific access key or temporary credential was used.  
+  - If multiple suspicious keys are found, use AWS IAM console or `aws iam list-access-keys` to determine when they were last used or rotated.  
+- **Account (`Esql.cloud_account_id_values`)** – Confirm which AWS account was affected and whether it matches the intended operational context (e.g., production vs. sandbox).
+
+**Assess the API call pattern and intent**
+- **Distinct action count (`Esql.event_action_count_distinct`)**: Note how many unique API calls occurred within each 10-second window. Counts far above normal operational baselines may indicate scripted reconnaissance.  
+- **API actions (`Esql.event_action_values`)**: Review which discovery APIs were invoked.  
+  - Focus on services such as EC2 (`DescribeInstances`), IAM (`ListRoles`, `ListAccessKeys`), S3 (`ListBuckets`), and KMS (`ListKeys`), which adversaries frequently query to map assets.  
+- **Service providers (`Esql.event_provider_values`)**: Identify which AWS services were targeted.  
+  - Multi-service enumeration (IAM + EC2 + S3) suggests broad discovery rather than a specific diagnostic task.  
+- **Time window (`Esql.time_window_date_trunc`)**: Verify whether activity occurred during normal maintenance windows or outside expected hours.
+
+**Analyze the source and origin**
+- **Source IP (`Esql.source_ip_values`)**: Check the originating IPs to determine whether the calls came from a known internal host, an EC2 instance, or an unfamiliar external network.  
+  - Compare with known corporate CIDR ranges, VPC flow logs, or guardrail baselines.  
+- **Source organization (`Esql.source_as_organization_name_values`)**: Review the associated ASN or organization.  
+  - If the ASN belongs to a commercial ISP or VPN service, investigate possible credential compromise or remote attacker usage.
+
+**Correlate with additional events**
+- Search CloudTrail for the same `aws.cloudtrail.user_identity.arn` or `aws_cloudtrail_user_identity_access_key_id_values` within ±30 minutes.  
+  - Look for follow-on actions such as `GetCallerIdentity`, `AssumeRole`, `CreateAccessKey`, or data access (`GetObject`, `CopySnapshot`).  
+  - Correlate this enumeration with authentication anomalies or privilege-related findings.  
+- Cross-reference `Esql.cloud_account_id_values` with other alerts for lateral or privilege escalation patterns.
+
+### False positive analysis
+
+Legitimate, high-frequency API activity may originate from:
+- **Inventory or compliance automation**: Scripts or tools such as AWS Config, Cloud Custodian, or custom CMDB collection performing periodic Describe/List calls.  
+- **Operational monitoring systems**: DevOps pipelines, Terraform, or deployment verifiers enumerating resources.  
+- **Security tooling**: Security scanners performing asset discovery across services.
+
+Validate by confirming:
+- Whether the `aws.cloudtrail.user_identity.arn` corresponds to a documented automation or monitoring identity.  
+- That the observed `Esql.event_action_values` match known inventory or cost-reporting workflows.  
+- Timing alignment with approved maintenance schedules.
+
+### Response and remediation
+
+If the activity is unexpected or originates from unrecognized credentials, follow AWS’s incident-handling guidance:
+
+**1. 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**
+- 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**
+- 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**
+- 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.
+
+### Additional information
+
+- **AWS Documentation**
+  - [CloudTrail Event Reference](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html)
+  - [AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.pdf)
+- **AWS Playbook Resources**
+  - [AWS Incident Response Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks)
+  - [AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework)
+
+"""
+references = ["https://stratus-red-team.cloud/attack-techniques/AWS/aws.discovery.ec2-enumerate-from-instance/"]
+risk_score = 21
+rule_id = "74f45152-9aee-11ef-b0a5-f661ea17fbcd"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: AWS EC2",
+    "Data Source: AWS IAM",
+    "Data Source: AWS S3",
+    "Data Source: AWS Cloudtrail",
+    "Data Source: AWS RDS",
+    "Data Source: AWS Lambda",
+    "Data Source: AWS STS",
+    "Data Source: AWS KMS",
+    "Data Source: AWS SES",
+    "Data Source: AWS Cloudfront",
+    "Data Source: AWS DynamoDB",
+    "Data Source: AWS Elastic Load Balancing",
+    "Use Case: Threat Detection",
+    "Tactic: Discovery",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "esql"
+
+query = '''
+from logs-aws.cloudtrail-* metadata _id, _version, _index
+// create time window buckets of 10 seconds
+| eval Esql.time_window_date_trunc = date_trunc(10 seconds, @timestamp)
+
+| where
+    event.dataset == "aws.cloudtrail"
+    // filter on CloudTrail audit logs for IAM, EC2, S3, etc.
+    and event.provider in (
+      "iam.amazonaws.com",
+      "ec2.amazonaws.com",
+      "s3.amazonaws.com",
+      "rds.amazonaws.com",
+      "lambda.amazonaws.com",
+      "dynamodb.amazonaws.com",
+      "kms.amazonaws.com",
+      "cloudfront.amazonaws.com",
+      "elasticloadbalancing.amazonaws.com", 
+      "cloudtrail.amazonaws.com",
+      "sts.amazonaws.com",
+      "ses.amazonaws.com"
+    )
+    // ignore AWS service actions
+    and aws.cloudtrail.user_identity.type != "AWSService"
+    // filter for aws-cli specifically
+    and user_agent.name == "aws-cli"
+    // exclude DescribeCapacityReservations events related to AWS Config
+    and event.action != "DescribeCapacityReservations"
+
+// filter for Describe, Get, List, and Generate API calls
+| where true in (
+    starts_with(event.action, "Describe"),
+    starts_with(event.action, "Get"),
+    starts_with(event.action, "List"),
+    starts_with(event.action, "Generate")
+)
+
+// extract owner, identity type, and actor from the ARN
+| dissect aws.cloudtrail.user_identity.arn "%{}::%{Esql_priv.aws_cloudtrail_user_identity_arn_owner}:%{Esql.aws_cloudtrail_user_identity_arn_type}/%{Esql.aws_cloudtrail_user_identity_arn_roles}"
+
+| where starts_with(Esql.aws_cloudtrail_user_identity_arn_roles, "AWSServiceRoleForConfig") != true
+
+// keep relevant fields (preserving ECS fields and computed time window)
+| keep 
+    @timestamp, 
+    Esql.time_window_date_trunc, 
+    event.action, 
+    aws.cloudtrail.user_identity.arn, 
+    aws.cloudtrail.user_identity.type, 
+    aws.cloudtrail.user_identity.access_key_id, 
+    source.ip, 
+    cloud.account.id, 
+    event.provider, 
+    user_agent.name, 
+    source.as.organization.name, 
+    cloud.region,
+    data_stream.namespace
+
+// count the number of unique API calls per time window and actor
+| stats
+    Esql.event_action_count_distinct = count_distinct(event.action),
+    Esql.event_action_values = VALUES(event.action),
+    Esql.event_timestamp_values = VALUES(@timestamp),
+    Esql.aws_cloudtrail_user_identity_type_values = VALUES(aws.cloudtrail.user_identity.type),
+    Esql.aws_cloudtrail_user_identity_access_key_id_values = VALUES(aws.cloudtrail.user_identity.access_key_id),
+    Esql.source_ip_values = VALUES(source.ip),
+    Esql.cloud_account_id_values = VALUES(cloud.account.id),
+    Esql.event_provider_values = VALUES(event.provider),
+    Esql.user_agent_name_values = VALUES(user_agent.name),
+    Esql.source_as_organization_name_values = VALUES(source.as.organization.name),
+    Esql.cloud_region_values = VALUES(cloud.region),
+    Esql.data_stream_namespace_values = VALUES(data_stream.namespace)
+  by Esql.time_window_date_trunc, aws.cloudtrail.user_identity.arn
+
+// filter for more than 5 unique API calls per 10s window
+| where Esql.event_action_count_distinct > 5
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1580"
+name = "Cloud Infrastructure Discovery"
+reference = "https://attack.mitre.org/techniques/T1580/"
+
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+
+[rule.investigation_fields]
+field_names = [
+  "Esql.event_action_count_distinct", 
+  "Esql.time_window_date_trunc", 
+  "aws.cloudtrail.user_identity.arn", 
+  "Esql.aws_cloudtrail_user_identity_type_values",
+  "Esql.aws_cloudtrail_user_identity_access_key_id_values", 
+  "Esql.source_ip_values", 
+  "Esql.source_as_organization_name_values", 
+  "Esql.event_provider_values", 
+  "Esql.event_action_values", 
+  "Esql.cloud_account_id_values",
+  "Esql.cloud_region_values",
+  "Esql.data_stream_namespace_values"
+  ]
+