AWS RDS DB Instance or Cluster Password Modified

Identifies the modification of the master password for an AWS RDS DB instance or cluster. Changing the master password is a legitimate recovery action when access is lost, but adversaries with sufficient permissions may modify it to regain access, establish persistence, bypass existing controls, or escalate privileges within a compromised environment. Because RDS does not expose the password in API responses, this operation can meaningfully alter access pathways to sensitive data stores.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2024/06/27"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2025/11/24"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies the modification of the master password for an AWS RDS DB instance or cluster. Changing the master password
 11is a legitimate recovery action when access is lost, but adversaries with sufficient permissions may modify it to regain
 12access, establish persistence, bypass existing controls, or escalate privileges within a compromised environment.
 13Because RDS does not expose the password in API responses, this operation can meaningfully alter access pathways to
 14sensitive data stores.
 15"""
 16event_category_override = "event.type"
 17false_positives = [
 18    """
 19    Master password modification may occur during legitimate administrative recovery (e.g., a lost password, rotation
 20    event, or Secrets Manager reassociation). Validate whether the change was expected, approved, and performed by
 21    authorized personnel. If known workflows routinely perform this action, consider adding targeted exceptions.
 22    """,
 23]
 24from = "now-6m"
 25index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 26language = "eql"
 27license = "Elastic License v2"
 28name = "AWS RDS DB Instance or Cluster Password Modified"
 29note = """## Triage and analysis
 30
 31> **Disclaimer**:
 32> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance.  
 33> While every effort has been made to ensure its quality, validate and adapt it to suit your operational needs.
 34
 35### Investigating AWS RDS DB Instance or Cluster Password Modified
 36
 37The 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.
 38
 39This rule detects successful password-modification events via `ModifyDBInstance` or `ModifyDBCluster`. Such changes may indicate credential loss recovery—or malicious actions related to persistence, privilege escalation, or defense evasion.
 40
 41#### Possible investigation steps
 42
 43- **Identify the actor and execution context**  
 44  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`.  
 45  - Inspect `user.name`, `source.ip`, and `user_agent.original` to determine whether the modification originated from expected networks, automation roles, or unusual sources.
 46
 47- **Determine what was modified**  
 48  - Examine `aws.cloudtrail.request_parameters` to identify:  
 49    - The DB instance or cluster identifier.  
 50    - Whether other parameters were modified in the same call (e.g., `manageMasterUserPassword`, engine version, instance class, parameter group).  
 51  - Review instance metadata in AWS to understand the sensitivity level, environment (prod/stage/dev), and potential business impact.
 52
 53- **Reconstruct timing and associated actions**  
 54  - Use `@timestamp` to compare the event against:  
 55    - Recent configuration changes such as `ModifyDBInstance`, `ModifyDBCluster`, or networking/security group updates.  
 56    - Other access-related operations (e.g., `AddRoleToDBInstance`, changes to Secrets Manager associations, disabling deletion protection).  
 57  - Check for signs of credential misuse leading up to the event (e.g., `DescribeDBInstances`, `GetCallerIdentity`, unauthorized console logins).
 58
 59- **Correlate with broader activity**  
 60  - Pivot in CloudTrail using the same access key, principal ARN, or source IP.  
 61  - Look for:  
 62    - Privilege-escalating or persistence-related behavior (IAM policy changes, role modifications, STS session creation).  
 63    - Subsequent DB-impacting operations, such as snapshot deletion, backup retention changes, or cluster deletion.  
 64    - Evidence of data access anomalies (backup exports, data snapshot copies, cross-region actions).
 65
 66- **Validate intent with operational owners**  
 67  - Confirm with DBAs, platform engineers, and application owners whether the password change:  
 68    - Was requested or scheduled.  
 69    - Aligns with pending migrations, credential rotations, or recovery actions.  
 70  - If not recognized, treat this as a high-risk event requiring deeper containment.
 71
 72### False positive analysis
 73
 74- **Recovery or maintenance tasks**  
 75  - Password resets occur during lost-credential scenarios or planned rotations. Confirm if this aligns with a documented workflow.
 76- **Secrets Manager integration changes**  
 77  - When `manageMasterUserPassword` is toggled or Secrets Manager rotates passwords, a modification event may occur. Validate whether an automation pipeline triggered the change.
 78- **Non-production workloads**  
 79  - Development or staging environments may see frequent password resets. Consider tuning exceptions based on tags, instance identifiers, or IAM roles tied to automation.
 80
 81### Response and remediation
 82
 83- **Contain unauthorized access**  
 84  - If activity is suspicious:  
 85    - Immediately rotate the master password again using a secure, validated workflow.  
 86    - Verify whether Secrets Manager integration was disabled (`manageMasterUserPassword=false`) and restore it if necessary.  
 87    - Restrict inbound DB access by tightening associated security group rules or isolating the instance temporarily.
 88
 89- **Investigate surrounding activity**  
 90  - Review CloudTrail to identify:  
 91    - Who accessed the instance after the password change.  
 92    - Whether any destructive or data-exfiltrating RDS actions occurred.  
 93    - Other IAM or STS activity tied to the same user or session.
 94
 95- **Restore guardrails and enhance monitoring**  
 96  - Ensure deletion protection, backup retention, and networking controls are correctly configured.  
 97  - Add real-time alerts for password-related modifications and high-risk RDS API actions.
 98
 99- **Strengthen IAM and operational controls**  
100  - Limit permissions for `rds:ModifyDBInstance` and `rds:ModifyDBCluster`, especially when modifying authentication parameters.  
101  - Require MFA and role-based access for DB administrators.  
102  - Tighten SCPs or Config rules to restrict unauthorized DB configuration changes.
103
104### Additional information
105
106- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
107- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
108- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
109"""
110references = [
111    "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html",
112    "https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html",
113    "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc#rds-modifydbinstance",
114]
115risk_score = 47
116rule_id = "f2015527-7c46-4bb9-80db-051657ddfb69"
117severity = "medium"
118tags = [
119    "Domain: Cloud",
120    "Data Source: AWS",
121    "Data Source: Amazon Web Services",
122    "Data Source: AWS RDS",
123    "Resources: Investigation Guide",
124    "Use Case: Threat Detection",
125    "Tactic: Persistence",
126    "Tactic: Privilege Escalation",
127    "Tactic: Defense Evasion",
128]
129timestamp_override = "event.ingested"
130type = "eql"
131
132query = '''
133info where event.dataset == "aws.cloudtrail"
134    and event.provider == "rds.amazonaws.com"
135    and event.action in ("ModifyDBInstance", "ModifyDBCluster")
136    and event.outcome == "success"
137    and stringContains(aws.cloudtrail.request_parameters, "masterUserPassword=*")
138'''
139
140
141[[rule.threat]]
142framework = "MITRE ATT&CK"
143[[rule.threat.technique]]
144id = "T1098"
145name = "Account Manipulation"
146reference = "https://attack.mitre.org/techniques/T1098/"
147[[rule.threat.technique.subtechnique]]
148id = "T1098.001"
149name = "Additional Cloud Credentials"
150reference = "https://attack.mitre.org/techniques/T1098/001/"
151
152
153
154[rule.threat.tactic]
155id = "TA0003"
156name = "Persistence"
157reference = "https://attack.mitre.org/tactics/TA0003/"
158[[rule.threat]]
159framework = "MITRE ATT&CK"
160
161[rule.threat.tactic]
162id = "TA0004"
163name = "Privilege Escalation"
164reference = "https://attack.mitre.org/tactics/TA0004/"
165[[rule.threat]]
166framework = "MITRE ATT&CK"
167
168[rule.threat.tactic]
169id = "TA0005"
170name = "Defense Evasion"
171reference = "https://attack.mitre.org/tactics/TA0005/"
172
173[rule.investigation_fields]
174field_names = [
175    "@timestamp",
176    "user.name",
177    "user_agent.original",
178    "source.ip",
179    "aws.cloudtrail.user_identity.arn",
180    "aws.cloudtrail.user_identity.type",
181    "aws.cloudtrail.user_identity.access_key_id",
182    "target.entity.id",
183    "event.action",
184    "event.outcome",
185    "cloud.account.id",
186    "cloud.region",
187    "aws.cloudtrail.request_parameters",
188    "aws.cloudtrail.response_elements",
189]

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.

This rule detects successful password-modification events via ModifyDBInstance or ModifyDBCluster. Such changes may indicate credential loss recovery—or malicious actions related to persistence, privilege escalation, or defense evasion.

Possible investigation steps

  • Identify the actor and execution context

    • Review aws.cloudtrail.user_identity.arn and aws.cloudtrail.user_identity.access_key_id.
    • Inspect user.name, source.ip, and user_agent.original to determine whether the modification originated from expected networks, automation roles, or unusual sources.
  • Determine what was modified

    • Examine aws.cloudtrail.request_parameters to identify:
      • The DB instance or cluster identifier.
      • Whether other parameters were modified in the same call (e.g., manageMasterUserPassword, engine version, instance class, parameter group).
    • Review instance metadata in AWS to understand the sensitivity level, environment (prod/stage/dev), and potential business impact.
  • Reconstruct timing and associated actions

    • Use @timestamp to compare the event against:
      • Recent configuration changes such as ModifyDBInstance, ModifyDBCluster, or networking/security group updates.
      • Other access-related operations (e.g., AddRoleToDBInstance, changes to Secrets Manager associations, disabling deletion protection).
    • Check for signs of credential misuse leading up to the event (e.g., DescribeDBInstances, GetCallerIdentity, unauthorized console logins).
  • Correlate with broader activity

    • Pivot in CloudTrail using the same access key, principal ARN, or source IP.
    • Look for:
      • Privilege-escalating or persistence-related behavior (IAM policy changes, role modifications, STS session creation).
      • Subsequent DB-impacting operations, such as snapshot deletion, backup retention changes, or cluster deletion.
      • Evidence of data access anomalies (backup exports, data snapshot copies, cross-region actions).
  • Validate intent with operational owners

    • Confirm with DBAs, platform engineers, and application owners whether the password change:
      • Was requested or scheduled.
      • Aligns with pending migrations, credential rotations, or recovery actions.
    • If not recognized, treat this as a high-risk event requiring deeper containment.

False positive analysis

  • Recovery or maintenance tasks
    • Password resets occur during lost-credential scenarios or planned rotations. Confirm if this aligns with a documented workflow.
  • Secrets Manager integration changes
    • When manageMasterUserPassword is toggled or Secrets Manager rotates passwords, a modification event may occur. Validate whether an automation pipeline triggered the change.
  • Non-production workloads
    • Development or staging environments may see frequent password resets. Consider tuning exceptions based on tags, instance identifiers, or IAM roles tied to automation.

Response and remediation

  • Contain unauthorized access

    • If activity is suspicious:
      • Immediately rotate the master password again using a secure, validated workflow.
      • Verify whether Secrets Manager integration was disabled (manageMasterUserPassword=false) and restore it if necessary.
      • Restrict inbound DB access by tightening associated security group rules or isolating the instance temporarily.
  • Investigate surrounding activity

    • Review CloudTrail to identify:
      • Who accessed the instance after the password change.
      • Whether any destructive or data-exfiltrating RDS actions occurred.
      • Other IAM or STS activity tied to the same user or session.
  • Restore guardrails and enhance monitoring

    • Ensure deletion protection, backup retention, and networking controls are correctly configured.
    • Add real-time alerts for password-related modifications and high-risk RDS API actions.
  • Strengthen IAM and operational controls

    • Limit permissions for rds:ModifyDBInstance and rds:ModifyDBCluster, especially when modifying authentication parameters.
    • Require MFA and role-based access for DB administrators.
    • Tighten SCPs or Config rules to restrict unauthorized DB configuration changes.

Additional information

References

Related rules

to-top