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.arnandaws.cloudtrail.user_identity.access_key_id. - Inspect
user.name,source.ip, anduser_agent.originalto determine whether the modification originated from expected networks, automation roles, or unusual sources.
- Review
-
Determine what was modified
- Examine
aws.cloudtrail.request_parametersto 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.
- Examine
-
Reconstruct timing and associated actions
- Use
@timestampto 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).
- Recent configuration changes such as
- Check for signs of credential misuse leading up to the event (e.g.,
DescribeDBInstances,GetCallerIdentity, unauthorized console logins).
- Use
-
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.
- Confirm with DBAs, platform engineers, and application owners whether the password change:
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
manageMasterUserPasswordis toggled or Secrets Manager rotates passwords, a modification event may occur. Validate whether an automation pipeline triggered the change.
- When
- 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.
- If activity is suspicious:
-
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.
- Review CloudTrail to identify:
-
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:ModifyDBInstanceandrds: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.
- Limit permissions for
Additional information
- AWS IR Playbooks
- AWS Customer Playbook Framework
- Security Best Practices: AWS Knowledge Center – Security Best Practices.
References
Related rules
- AWS RDS DB Instance Made Public
- AWS STS Role Chaining
- AWS First Occurrence of STS GetFederationToken Request by User
- AWS RDS DB Instance Restored
- AWS RDS DB Instance or Cluster Deletion Protection Disabled