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

nldcsc_elastic_rules/rules/integrations/aws/persistence_iam_user_created_access_keys_for_another_user.toml

@@ -0,0 +1,215 @@
+[metadata]
+creation_date = "2024/06/13"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/10/13"
+
+[rule]
+author = ["Elastic"]
+description = """
+An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by creating a
+new set of credentials for an existing user. This rule looks for use of the IAM `CreateAccessKey` API operation to
+create new programmatic access keys for another IAM user.
+"""
+false_positives = [
+    """
+    While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity
+    should be using the IAM `CreateAccessKey` for the targeted user.
+    """,
+]
+from = "now-6m"
+language = "esql"
+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.  
+While this operation can be legitimate (for example, credential rotation), it can also be abused to establish persistence or privilege escalation if one user creates keys for another account without authorization.
+
+This rule identifies `CreateAccessKey` API calls where the calling user (`aws.cloudtrail.user_identity.arn`) differs from the target user (`aws.cloudtrail.request_parameters.userName`), indicating one IAM identity creating credentials for another.
+
+#### Possible investigation steps
+
+- **Confirm both user identities and intent.**  
+  Identify the calling user (who performed `CreateAccessKey`) and the target user (whose access key was created). Contact both account owners or application teams to confirm if this operation was expected.
+
+- **Review CloudTrail event details.**  
+  Check the following fields directly in the alert or corresponding CloudTrail record:  
+  - `source.ip` — does it align with expected corporate ranges or known admin automation?  
+  - `user_agent.original` — AWS Console, CLI, SDK, or custom client? Unexpected user agents (for example, non-SDK scripts) may indicate manual or unauthorized use.  
+  - `source.geo` fields — verify the location details are expected for the identity.
+
+- **Correlate with related IAM activity.**  
+  In CloudTrail, search for subsequent or nearby events such as:  
+  - `AttachUserPolicy`, `AttachGroupPolicy`, `UpdateAssumeRolePolicy`, or `CreateUser`.  
+  These can indicate privilege escalation or lateral movement.  
+  Also review whether the same principal recently performed `CreateAccessKey` for multiple users or repeated this action across accounts.
+
+- **Inspect the new access key’s usage.**  
+  Search for the newly created key ID (`aws.cloudtrail.response_elements.accessKey.accessKeyId`) in CloudTrail events following creation. Determine if it was used from unusual IP addresses, geographies, or services.  
+
+- **Assess the risk of credential compromise.**  
+  If you suspect malicious behavior, consider the following indicators:  
+  - A non-admin user invoking `CreateAccessKey` for another user.  
+  - Creation outside of normal automation pipelines.  
+  - Use of the new key from a different IP or AWS account soon after creation.
+
+- **Scope related activity.**  
+  Review all activity from the calling user in the past 24–48 hours, focusing on `iam:*` API calls and resource creation events.  
+  Correlate any S3, EC2, or KMS access attempts made using the new key to identify potential impact or data exposure.
+
+### False positive analysis
+
+- **Expected credential rotation.**  
+  Some environments delegate credential rotation responsibilities to centralized automation or specific admin roles. Confirm if the calling user is authorized for such actions.  
+- **Administrative workflows.**  
+  Account provisioning systems may legitimately create keys on behalf of users. Check for standard tags, automation tools, or user agents that indicate managed operations.  
+- **Service-linked roles or external IAM automation.**  
+  Some AWS services create or rotate credentials automatically. Validate if the caller is a service-linked role or an automation IAM role used by a known deployment process.
+
+### Response and remediation
+
+> AWS IR playbooks classify unauthorized credential creation as a **Priority-1 incident** because it may allow persistence or privilege escalation.  
+> The following steps scale for organizations with or without a dedicated IR team.
+
+**1. Immediate containment**
+- Deactivate or delete the access key from the target IAM user immediately using the AWS Console, CLI, or API (`DeleteAccessKey`).  
+- Rotate or reset credentials for both the calling and target users to eliminate possible compromise.  
+- Restrict risky principals. Temporarily deny `iam:CreateAccessKey` and `iam:UpdateAccessKey` permissions for non-administrative roles while scoping the incident.  
+- Enable or confirm MFA on both accounts involved, if not already enforced.
+
+**2. Evidence preservation**
+- Export all related `CreateAccessKey`, `DeleteAccessKey`, and `UpdateAccessKey` events within ±30 minutes of the alert to an evidence bucket.  
+- Preserve CloudTrail, GuardDuty, and AWS Config data for the same period.  
+- Record key event details: caller ARN, target user, `accessKeyId`, `source.ip`, `userAgent`, and timestamps.
+
+**3. Scoping and investigation**
+- Search CloudTrail for usage of the new access key ID after creation. Identify any API activity or data access tied to it.  
+- Review IAM policy changes, group modifications, or new role assumptions around the same time.  
+- Determine if any additional credentials or trust policy changes were made by the same actor.  
+- Check for GuardDuty findings referencing anomalous credential usage or suspicious API behavior.
+
+**4. Recovery and hardening**
+- Remove or disable any unauthorized keys and re-enable only verified credentials.  
+- Implement least-privilege IAM policies to limit which users can perform `CreateAccessKey`.  
+- Monitor for future `CreateAccessKey` events where `userIdentity.arn != request_parameters.userName`.  
+- Ensure Cloudtrail, GuardDuty and Security Hub are active across all regions.  
+- Educate administrative users on secure key rotation processes and the risk of cross-user key creation.  
+
+### Additional information
+
+- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/):** Reference “Credential Compromise” and “IAM Misuse” procedures for containment and recovery.  
+- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/):** See “Identity Access Review” and “Unauthorized Access Key Creation” for example response flows.  
+- **AWS Documentation:** [Best practices for managing access keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html).  
+- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).  
+"""
+references = [
+    "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/#iamcreateaccesskey",
+    "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence",
+    "https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud",
+    "https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html",
+]
+risk_score = 47
+rule_id = "696015ef-718e-40ff-ac4a-cc2ba88dbeeb"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS IAM",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Privilege Escalation",
+    "Tactic: Persistence",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "esql"
+
+query = '''
+from logs-aws.cloudtrail-* metadata _id, _version, _index
+| where event.dataset == "aws.cloudtrail"
+    and event.provider == "iam.amazonaws.com"
+    and event.action == "CreateAccessKey"
+    and event.outcome == "success"
+    and user.name != user.target.name
+| keep
+    @timestamp,
+    cloud.account.id,
+    cloud.region,
+    event.provider,
+    event.action,
+    event.outcome,
+    event.dataset,
+    user.name,
+    source.address,
+    source.ip,
+    user.target.name,
+    user_agent.original,
+    aws.cloudtrail.request_parameters,
+    aws.cloudtrail.response_elements,
+    aws.cloudtrail.user_identity.arn,
+    aws.cloudtrail.user_identity.type,
+    aws.cloudtrail.user_identity.access_key_id,
+    source.geo.*
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1098"
+name = "Account Manipulation"
+reference = "https://attack.mitre.org/techniques/T1098/"
+[[rule.threat.technique.subtechnique]]
+id = "T1098.001"
+name = "Additional Cloud Credentials"
+reference = "https://attack.mitre.org/techniques/T1098/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1098"
+name = "Account Manipulation"
+reference = "https://attack.mitre.org/techniques/T1098/"
+[[rule.threat.technique.subtechnique]]
+id = "T1098.001"
+name = "Additional Cloud Credentials"
+reference = "https://attack.mitre.org/techniques/T1098/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+
+[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",
+    "user.target.name",
+    "event.action",
+    "event.outcome",
+    "cloud.region",
+    "cloud.account.id",
+    "aws.cloudtrail.request_parameters",
+    "aws.cloudtrail.response_elements",
+]
+

nldcsc_elastic_rules/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml

@@ -0,0 +1,100 @@
+[metadata]
+creation_date = "2024/04/30"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when an AWS Lambda function policy is updated to allow public invocation. This rule specifically looks for
+the `AddPermission` API call with the `Principal` set to `*` which allows any AWS account to invoke the Lambda function.
+Adversaries may abuse this permission to create a backdoor in the Lambda function that allows them to execute arbitrary
+code.
+"""
+false_positives = ["Lambda function owners may legitimately update the function policy to allow public invocation."]
+from = "now-60m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+interval = "10m"
+language = "kuery"
+license = "Elastic License v2"
+name = "AWS Lambda Function Policy Updated to Allow Public Invocation"
+note = """## Triage and analysis
+
+### Investigating AWS Lambda Function Policy Updated to Allow Public Invocation
+
+This rule detects when an AWS Lambda function policy is updated to allow public invocation. It specifically looks for the `AddPermission` API call with the `Principal` set to `*`, which allows any AWS account to invoke the Lambda function. Adversaries may abuse this permission to create a backdoor in the Lambda function that allows them to execute arbitrary code. Understanding the context and legitimacy of such changes is crucial to determine if the action is benign or malicious.
+
+#### Possible Investigation Steps:
+
+- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Verify if this actor typically performs such actions and if they have the necessary permissions.
+- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific changes made to the Lambda function policy. Look for any unusual parameters that could suggest unauthorized or malicious modifications.
+- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access.
+- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the change occurred. Modifications during non-business hours or outside regular maintenance windows might require further scrutiny.
+- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in other potentially suspicious activities.
+
+### False Positive Analysis:
+
+- **Legitimate Administrative Actions**: Confirm if the update to allow public invocation aligns with scheduled updates, development activities, or legitimate administrative tasks documented in change management systems.
+- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.
+- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the change was successful and intended according to policy.
+
+### Response and Remediation:
+
+- **Immediate Review and Reversal if Necessary**: If the change was unauthorized, update the Lambda function policy to remove the public invocation permission and restore it to its previous state.
+- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive functions or permissions.
+- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning Lambda function management and the use of permissions.
+- **Audit Lambda Functions and Policies**: Conduct a comprehensive audit of all Lambda functions and associated policies to ensure they adhere to the principle of least privilege.
+- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.
+
+### Additional Information:
+
+For further guidance on managing Lambda functions and securing AWS environments, refer to the [AWS Lambda documentation](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) and AWS best practices for security. Additionally, consult the following resources for specific details on Lambda persistence techniques:
+- [AWS Lambda Persistence](https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence)
+- [AWS Lambda Backdoor Function](https://stratus-red-team.cloud/attack-techniques/AWS/aws.persistence.lambda-backdoor-function/)
+- [AWS API AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html)
+
+
+"""
+references = [
+    "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence",
+    "https://stratus-red-team.cloud/attack-techniques/AWS/aws.persistence.lambda-backdoor-function/",
+    "https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html",
+]
+risk_score = 47
+rule_id = "151d8f72-0747-11ef-a0c2-f661ea17fbcc"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS Lambda",
+    "Use Case: Threat Detection",
+    "Tactic: Persistence",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset: aws.cloudtrail
+    and event.provider: lambda.amazonaws.com
+    and event.outcome: success
+    and event.action: AddPermission*
+    and aws.cloudtrail.request_parameters: (*lambda\:InvokeFunction* and *principal=\**)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1546"
+name = "Event Triggered Execution"
+reference = "https://attack.mitre.org/techniques/T1546/"
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+

nldcsc_elastic_rules/rules/integrations/aws/persistence_rds_cluster_creation.toml

@@ -0,0 +1,110 @@
+[metadata]
+creation_date = "2020/05/20"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/11/21"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the creation of a new Amazon Relational Database Service (RDS) Aurora DB cluster or global database spread
+across multiple regions.
+"""
+false_positives = [
+    """
+    Valid clusters may be created by a system or network administrator. Verify whether the user identity, user agent,
+    and/or hostname should be making changes in your environment. Cluster creations by unfamiliar users or hosts should
+    be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    """,
+]
+from = "now-60m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+interval = "10m"
+language = "kuery"
+license = "Elastic License v2"
+name = "Deprecated - AWS RDS Cluster 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 Deprecated - AWS RDS Cluster Creation
+
+Amazon RDS facilitates database management by automating tasks like hardware provisioning and backups. Adversaries may exploit RDS by creating unauthorized clusters to exfiltrate data or establish persistence. The detection rule monitors successful creation events of RDS clusters, flagging potential misuse by correlating specific actions and outcomes, thus aiding in identifying unauthorized activities.
+
+### Possible investigation steps
+
+- Review the event details in AWS CloudTrail to confirm the event.dataset is 'aws.cloudtrail' and the event.provider is 'rds.amazonaws.com', ensuring the alert is based on the correct data source.
+- Verify the identity of the user or service account that initiated the CreateDBCluster or CreateGlobalCluster action by examining the user identity information in the event logs.
+- Check the event time and correlate it with any other suspicious activities or alerts in the same timeframe to identify potential patterns or coordinated actions.
+- Investigate the source IP address and geolocation associated with the event to determine if it aligns with expected access patterns or if it indicates unauthorized access.
+- Assess the configuration and settings of the newly created RDS cluster, including security groups, network settings, and any associated IAM roles, to identify potential security misconfigurations or vulnerabilities.
+- Review the AWS account's recent activity for any other unusual or unauthorized actions that might indicate broader compromise or misuse.
+
+### False positive analysis
+
+- Routine maintenance or testing activities by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles known to perform these tasks regularly.
+- Automated scripts or tools used for infrastructure management might create RDS clusters as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific tags or identifiers.
+- Scheduled deployments or updates that involve creating new RDS clusters can be mistaken for unauthorized activity. Document these schedules and configure the detection rule to ignore events during these timeframes.
+- Development or staging environments often involve frequent creation and deletion of RDS clusters. Exclude these environments from monitoring by filtering based on environment-specific tags or naming conventions.
+- Partner or third-party integrations that require creating RDS clusters should be reviewed and whitelisted if deemed non-threatening, ensuring that their actions do not generate false positives.
+
+### Response and remediation
+
+- Immediately isolate the newly created RDS cluster to prevent any unauthorized access or data exfiltration. This can be done by modifying the security group rules to restrict inbound and outbound traffic.
+- Review CloudTrail logs to identify the IAM user or role responsible for the creation of the RDS cluster. Verify if the action was authorized and if the credentials have been compromised.
+- Revoke any suspicious or unauthorized IAM credentials and rotate keys for affected users or roles to prevent further unauthorized actions.
+- Conduct a thorough audit of the RDS cluster configuration and data to assess any potential data exposure or integrity issues. If sensitive data is involved, consider notifying relevant stakeholders and following data breach protocols.
+- Implement additional monitoring and alerting for RDS-related activities, focusing on unusual patterns or actions that align with persistence tactics, to enhance detection capabilities.
+- Escalate the incident to the security operations 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 RDS cluster creation in the future.
+
+## 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/rds/create-db-cluster.html",
+    "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html",
+    "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/create-global-cluster.html",
+    "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateGlobalCluster.html",
+]
+risk_score = 21
+rule_id = "e14c5fd7-fdd7-49c2-9e5b-ec49d817bc8d"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS RDS",
+    "Use Case: Asset Visibility",
+    "Tactic: Persistence",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:(CreateDBCluster or CreateGlobalCluster) and event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1133"
+name = "External Remote Services"
+reference = "https://attack.mitre.org/techniques/T1133/"
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/aws/persistence_rds_db_instance_password_modified.toml

@@ -0,0 +1,116 @@
+[metadata]
+creation_date = "2024/06/27"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/01/10"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the modification of the master password for an AWS RDS DB instance or cluster. DB instances may contain sensitive data that can be abused if accessed by unauthorized actors. Amazon RDS API operations never return the password, so this operation provides a means to regain access if the password is lost. Adversaries with the proper permissions can take advantage of this to evade defenses and gain unauthorized access to a DB instance or cluster to support persistence mechanisms or privilege escalation.
+"""
+false_positives = [
+    """
+    Master password change is a legitimate means to regain access to a DB instance in the case of a lost password. Ensure that the instance should not be modified in this way before taking action.
+    """,
+]
+from = "now-6m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "AWS RDS DB Instance or Cluster Password Modified"
+note = """
+## Triage and analysis
+
+### Investigating AWS RDS DB Instance or Cluster Password Modified
+
+This rule identifies when an RDS DB instance or cluster password is modified. While changing the master password is a legitimate means to regain access in the case of a lost password, adversaries may exploit this feature to maintain persistence or evade defenses in a compromised environment.
+
+#### Possible Investigation Steps
+
+- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Verify if this actor typically performs such actions and if they have the necessary permissions.
+- **Review the Modification Event**: Identify the DB instance involved and review the event details. Look for `ModifyDBInstance` actions where the masterUserPassword parameter was changed.
+    - **Request and Response Parameters**: Check the `aws.cloudtrail.request_parameters` field in the CloudTrail event to identify the DB Instance Identifier and any other modifications made to the instance.
+- **Verify the Modified Instance**: Check the DB instance that was modified and its contents to determine the sensitivity of the data stored within it.
+- **Contextualize with Recent Changes**: Compare this modification event against recent changes in RDS DB or Cluster configurations and deployments. Look for any other recent permissions changes or unusual administrative actions.
+- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in other potentially suspicious activities.
+- **Interview Relevant Personnel**: If the modification was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing DB instances.
+### False Positive Analysis
+
+- **Legitimate Instance Modification**: Confirm if the DB instance modification aligns with legitimate tasks.
+- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.
+
+### Response and Remediation
+
+- **Immediate Review and Reversal**: If the change was unauthorized, update the instance password. If the master user password was managed with AWS Secrets Manager, determine whether the `manageMasterUserPassword` attribute was changed to false and revert if necessary.
+- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions.
+- **Audit Instances and Policies**: Conduct a comprehensive audit of all instances and associated policies to ensure they adhere to the principle of least privilege.
+- **Policy Update**: Review and possibly update your organization’s policies on DB instance access to tighten control and prevent unauthorized access.
+- **Incident Response**: If malicious intent is confirmed, consider it a data breach incident and initiate the incident response protocol. This includes further investigation, containment, and recovery.
+
+### Additional Information:
+
+For further guidance on managing DB instances and securing AWS environments, refer to the [AWS RDS documentation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_RDS_Managing.html) and AWS best practices for security. Additionally, consult the following resources for specific details on DB instance security:
+- [AWS RDS ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)
+- [Amazon RDS and Secrets Manager](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-secrets-manager.html)
+"""
+references = [
+    "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html",
+    "https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html",
+    "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc#rds-modifydbinstance",
+]
+risk_score = 47
+rule_id = "f2015527-7c46-4bb9-80db-051657ddfb69"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS RDS",
+    "Resources: Investigation Guide",
+    "Use Case: Threat Detection",
+    "Tactic: Persistence",
+    "Tactic: Privilege Escalation",
+    "Tactic: Defense Evasion",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+any where event.dataset == "aws.cloudtrail"
+    and event.provider == "rds.amazonaws.com"
+    and event.action in ("ModifyDBInstance", "ModifyDBCluster")
+    and event.outcome == "success"
+    and stringContains(aws.cloudtrail.request_parameters, "masterUserPassword=*")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1098"
+name = "Account Manipulation"
+reference = "https://attack.mitre.org/techniques/T1098/"
+[[rule.threat.technique.subtechnique]]
+id = "T1098.001"
+name = "Additional Cloud Credentials"
+reference = "https://attack.mitre.org/techniques/T1098/001/"
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"

nldcsc_elastic_rules/rules/integrations/aws/persistence_rds_group_creation.toml

@@ -0,0 +1,103 @@
+[metadata]
+creation_date = "2021/06/05"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/11/21"
+
+[rule]
+author = ["Elastic", "Austin Songer"]
+description = """
+Identifies the creation of an Amazon Relational Database Service (RDS) Security group. Modern RDS deployments run in a
+VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on
+legacy CloudTrail data. We recommend relying on "AWS EC2 Security Group Configuration Change" rule for network-control
+changes impacting RDS in VPC-based deployments.
+"""
+false_positives = [
+    """
+    An RDS security group may be created by a system or network administrator. Verify whether the user identity, user
+    agent, and/or hostname should be making changes in your environment. Security group creations by unfamiliar users or
+    hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    """,
+]
+from = "now-60m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+interval = "10m"
+language = "kuery"
+license = "Elastic License v2"
+name = "Deprecated - AWS RDS Security 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 Deprecated - AWS RDS Security Group Creation
+
+Amazon RDS Security Groups control access to RDS instances, acting as virtual firewalls. Adversaries may exploit this by creating unauthorized security groups to maintain persistence or exfiltrate data. The detection rule monitors successful creation events of RDS security groups, flagging potential misuse by correlating specific AWS CloudTrail logs, thus aiding in identifying unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs for the event.action:CreateDBSecurityGroup to identify the user or role responsible for the creation of the RDS security group.
+- Check the event.provider:rds.amazonaws.com logs to gather additional context about the RDS instance associated with the newly created security group.
+- Investigate the event.outcome:success logs to confirm the successful creation and assess if it aligns with expected administrative activities.
+- Analyze the associated AWS account and user activity to determine if there are any anomalies or unauthorized access patterns.
+- Cross-reference the security group details with existing security policies to ensure compliance and identify any deviations.
+- Evaluate the permissions and rules associated with the new security group to assess potential risks or exposure to sensitive data.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule when authorized personnel create new RDS security groups for legitimate purposes. To manage this, establish a list of known IP addresses or user accounts that frequently perform these tasks and create exceptions for them.
+- Automated deployment tools or scripts that create RDS security groups as part of infrastructure provisioning can lead to false positives. Identify these tools and their associated accounts, then configure the rule to exclude these specific actions.
+- Scheduled maintenance or updates that involve creating new security groups might be flagged. Document these scheduled activities and adjust the rule to recognize and exclude them during the specified time frames.
+- Testing environments where security groups are frequently created and deleted for development purposes can generate alerts. Implement tagging or naming conventions for test environments and exclude these from the rule's scope.
+
+### Response and remediation
+
+- Immediately review the AWS CloudTrail logs to confirm the unauthorized creation of the RDS security group and identify the source IP and user account involved in the action.
+- Revoke any unauthorized security group rules associated with the newly created RDS security group to prevent further unauthorized access or data exfiltration.
+- Temporarily disable or delete the unauthorized RDS security group to contain the threat and prevent persistence.
+- Conduct a thorough audit of all AWS IAM roles and permissions to ensure that only authorized users have the ability to create or modify RDS security groups.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised.
+- Implement additional monitoring and alerting for any future RDS security group creation events to quickly detect and respond to similar threats.
+- Review and update AWS security policies and access controls to prevent unauthorized security group creation, ensuring alignment with best practices for least privilege.
+
+## Setup
+
+The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = ["https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBSecurityGroup.html"]
+risk_score = 21
+rule_id = "378f9024-8a0c-46a5-aa08-ce147ac73a4e"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS RDS",
+    "Tactic: Persistence",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:CreateDBSecurityGroup and event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1136"
+name = "Create Account"
+reference = "https://attack.mitre.org/techniques/T1136/"
+[[rule.threat.technique.subtechnique]]
+id = "T1136.003"
+name = "Cloud Account"
+reference = "https://attack.mitre.org/techniques/T1136/003/"
+
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+