Database master credentials changed

Threat snapshot

The master user credential for an AWS RDS instance is the highest-privilege database account available on that instance. It has full administrative access to every database hosted on the instance: it can read, modify, or delete all data, create or drop databases, manage other database users, and alter the engine configuration. In a well-run environment, the master password is set at instance creation, stored in a secrets management system, rotated on a defined schedule, and changed only through a documented administrative process.

When an attacker who has gained sufficient IAM permissions changes the RDS master password, they are not just resetting a credential. They are locking out the application and every database user whose access depends on the master account, while simultaneously granting themselves exclusive control over the database instance. This is both a takeover and a disruption: the attacker gains database access while the legitimate owners lose it. Log360 detects this activity through the AWS RDS Master Password Change rule, which fires on the ModifyDBInstance API call when the MasterUserPassword parameter is present in the request. Any master password change that cannot be attributed to a documented, authorised rotation warrants immediate investigation.

At a glance

How this attack works

The RDS master password is changed via the ModifyDBInstance API call with the MasterUserPassword parameter. This call can be made through the AWS Management Console, the AWS CLI, the AWS SDK, or any IAM-authenticated API client with the rds:ModifyDBInstance permission on the target instance. The change takes effect immediately on most RDS engine types, though some engines apply it at the next maintenance window unless ApplyImmediately is set to true.

An attacker who has obtained IAM credentials with the rds:ModifyDBInstance permission, either through a compromised IAM user, a stolen access key, or privilege escalation within the AWS account, can change the master password with a single API call. The original password is not required. There is no confirmation step, no notification to the database owner, and no grace period. Once the API call completes, the old password is invalid and the new one set by the attacker is the only credential that can authenticate as the master user.

The impact is twofold. First, the attacker gains exclusive database access. With the master user credential they can connect to the database engine directly, read all stored data, exfiltrate entire tables or databases, create backdoor database users for persistent access, modify stored data, or drop databases entirely. Second, every application or service that authenticates to the database using the master credential or a credential derived from it is immediately broken. Connection pools time out, application health checks fail, and the service goes offline. This creates operational pressure to restore access quickly, potentially distracting the incident response team and creating urgency to accept the attacker's demands if this is part of a ransomware or extortion campaign.

The account lockout dimension

An RDS master password change is not only a credential theft. It is simultaneously an account access removal event. The moment the change completes, every user whose database access path runs through the master credential loses access. For many RDS deployments, this includes the primary application database user, which means the production application loses its database connection immediately and begins throwing errors. The operational impact is visible and urgent, which can cause teams to focus on restoring service rather than treating the password change as a security incident requiring investigation.

Attack chain

The table below maps each stage of a database master credentials attack to the corresponding MITRE ATT&CK technique.

Real-world scenario

An e-commerce company runs its order management system on an application backed by an Amazon RDS MySQL instance. The master credential for the instance is stored in AWS Secrets Manager, and the application authenticates using a separate application-level database user. A developer on the team has an IAM user with broad permissions, including rds:ModifyDBInstance, granted as part of a legacy permission policy that was never scoped down after initial setup.

The developer's IAM access key, which was committed to a public GitHub repository six months earlier and never rotated, is discovered by an attacker using an automated credential scanning tool. The attacker uses the access key to enumerate the AWS account. Finding the RDS instance, they call DescribeDBInstances to confirm the instance identifier and the master username, then call ModifyDBInstance with ApplyImmediately set to true and a new MasterUserPassword value.

Within 90 seconds, the application's connection pool begins throwing authentication errors. Orders stop processing. The operations team receives database connectivity alerts and begins investigating what appears to be a database failure. While the operations team is focused on restoring connectivity, the attacker uses the new master credential to connect directly to the RDS endpoint and begins exporting the customer orders table, which contains names, addresses, and partial payment card numbers for 180,000 customers.

Log360 fires the AWS RDS Master Password Change alert simultaneously with the application connectivity failure. The SOC analyst who reviews the alert identifies the API call, the IAM user that made it, and the timing. Cross-referencing with the operations team's incident, they confirm that the password change and the application failure are the same event. The access key is revoked, the RDS master password is reset to a known-good value, and the incident response process begins. The data exfiltration had been running for 11 minutes before the database connection was severed.

Why this happens

rds:ModifyDBInstance is a permission that is commonly granted as part of broad developer or DevOps IAM policies because it is needed for legitimate tasks such as resizing instances, modifying parameter groups, and enabling encryption. The ability to change the master password is a side effect of this permission rather than an explicit grant. Most teams do not separately consider that rds:ModifyDBInstance includes master password modification. Long-lived access keys that are not rotated and are inadvertently exposed in code repositories are the primary credential vector that makes this attack possible.

Business impact: What can go wrong

An unauthorised RDS master password change causes simultaneous operational disruption and data security consequences:

• Immediate service outage: applications that depend on the master credential or on database users managed through it lose connectivity immediately when the password changes. For production workloads, this means immediate service degradation or complete outage, with the associated customer impact and revenue loss.
• Full database content exposure: the attacker who changes the master password gains unrestricted read access to all databases on the instance. Every table, stored procedure, and configuration value is accessible. For databases containing personal data, payment records, or health information, this represents a complete data breach.
• Persistent backdoor access: an attacker with master user access can create a new database user with a known password as a persistent access mechanism that survives a master password reset. If the backdoor user is not identified and removed during remediation, the attacker retains database access after the incident appears to be resolved.
• Data integrity risk: master user access allows modification of stored data. An attacker can alter transaction records, modify financial figures, change application configuration stored in the database, or corrupt data in ways that are not immediately visible and that may not be detected until a downstream process reveals the inconsistency.
• Regulatory breach notification: databases containing personal data, payment card data, or health records are subject to breach notification requirements under GDPR, PCI DSS, and HIPAA. Unauthorised access to an RDS instance containing regulated data triggers mandatory notification obligations regardless of whether data exfiltration can be confirmed.
• Compounded incident response cost: the combination of a live service outage and an active security incident creates competing operational and security priorities. The pressure to restore database access quickly can lead to shortcuts in the security investigation, potentially allowing the attacker to maintain a foothold while the team focuses on service restoration.

Indicators of compromise and detection signals

Prerequisites for detection using Log360

Before the AWS RDS Master Password Change rule can fire reliably, ensure the following are in place:

• AWS CloudTrail is enabled for all regions in the monitored account with a trail that captures management events including write API calls. ModifyDBInstance is a management event and is logged by CloudTrail. Verify that the trail is active and that RDS API events are appearing in Log360 before enabling the rule.
• CloudTrail logs are being forwarded to Log360 via the S3 bucket integration or the direct CloudTrail ingestion method. Confirm that recent RDS-related events such as DescribeDBInstances or CreateDBSnapshot are visible in Log360 log search, which confirms the ingestion pipeline is functioning for RDS events specifically.
• The AWS account or accounts hosting RDS instances are configured as log sources in Log360 under Settings > Log Source Configuration. If RDS instances are distributed across multiple AWS accounts, each account must be independently configured as a log source to ensure the rule fires on master password changes in any account.
• CloudTrail log delivery latency is accounted for in the response workflow. ModifyDBInstance takes effect immediately when ApplyImmediately is true, but the CloudTrail event may arrive in Log360 with a delay of up to 15 minutes. Design the SOC response procedure to assume the password change has already taken effect by the time the alert arrives, not that it is still pending.

Note: The AWS RDS Master Password Change rule fires on the API call itself, not on a successful database connection using the new password. This means the alert provides immediate warning at the moment the change is made. However, because CloudTrail delivery can be delayed by up to 15 minutes, the application outage caused by the password change may be reported by the operations team before the Log360 alert fires. If an unexplained RDS connectivity failure is reported, check CloudTrail for a recent ModifyDBInstance call with MasterUserPassword as part of the initial triage, before the Log360 alert arrives.

Detecting database master credential changes using Log360

Once log collection is configured, follow these steps to enable and tune detection in Log360:

Step 1: Enable the detection rule

Navigate to Security > Manage Rules > Rule Library in the Log360 console. Install and enable the rule: AWS RDS Master Password Change. Configure an alert profile for the same. Set the severity to Critical. An RDS master password change outside a documented rotation window has no legitimate explanation in most environments, and the combination of immediate service disruption and potential data exposure warrants the highest alert priority.

Step 2: Read the alert

When the rule fires, the alert will display the AWS account ID, the RDS instance identifier affected, the IAM principal that made the API call, the source IP address, the ApplyImmediately parameter value, and the timestamp. Review the IAM principal first against your documented list of authorised principals. Then review the source IP: an external IP or an IP that does not match a known administrative tool is high confidence. Check the ApplyImmediately value: true indicates the change has already taken effect and the database is already inaccessible to applications using the old credential.

Investigating an alert

When the AWS RDS Master Password Change rule fires, an L2 analyst should work through the following steps:

• Determine immediately whether the change was authorised. Check the change management system for a documented, approved password rotation for the affected RDS instance at the current time. Check whether the IAM principal that made the call is the documented Secrets Manager rotation role or a named DBA with an approved change ticket. If neither condition is met, treat the event as confirmed unauthorised and proceed to containment while continuing the investigation.
• Assess the current application impact. Contact the operations team or check application monitoring to determine whether the password change has already caused a service outage. If applications are failing due to database authentication errors, the change has taken effect with ApplyImmediately. The service outage confirms the change is active and provides the timeline for when legitimate access was lost.
• Review the IAM principal's recent activity. Query Log360 for all CloudTrail events from the IAM user or role that made the ModifyDBInstance call in the preceding 60 minutes. Look for preceding DescribeDBInstances calls that confirm the attacker was enumerating databases before the change, other resource modifications or enumeration calls that reveal the scope of the attacker's access, and any IAM modifications that may have expanded permissions before the RDS change.
• Check for subsequent direct database connections. Query CloudTrail and any available VPC flow log data for connections to the RDS endpoint from IP addresses not associated with known application servers or administrative hosts in the period following the master password change. A connection from an unrecognised external IP to the RDS port (typically 3306, 5432, 1433, or 1521 depending on the engine) shortly after the change confirms the attacker is actively using the new credential.
• Check for backdoor database user creation. If the attacker connected to the database using the new master credential, they may have created a new database user with a known password for persistent access. This activity occurs at the database engine level and is not captured in CloudTrail. Check RDS Enhanced Monitoring logs, database audit logs if enabled, or query the database's user table directly once access is restored to identify any users created after the master password change.
• Review the source of the IAM credentials used. Identify how the IAM principal that made the ModifyDBInstance call obtained its credentials. For IAM users, check whether the access key was recently created, when it was last rotated, and whether there are any CloudTrail events showing the key being used from unusual locations before this incident. For assumed roles, identify the trust policy and what authenticated to assume the role.

Escalation trigger

Escalate immediately to L3 if the ModifyDBInstance call cannot be attributed to a documented, authorised rotation; if direct connections to the RDS endpoint from unrecognised IPs are confirmed after the password change; if the RDS instance hosts personal data, payment card data, or health records subject to breach notification requirements; or if the IAM principal that made the call has also made other modifications to the AWS environment suggesting a broader account compromise. Initiate database incident response procedures in parallel with the cloud security investigation.

Responding and remediating

Immediate containment

• Reset the RDS master password to a known-good value immediately using an authorised IAM identity. Generate a strong random password, store it in AWS Secrets Manager, and call ModifyDBInstance with ApplyImmediately to restore application connectivity. Do not reuse any password that may have been visible to the attacker.
• Revoke or disable the IAM credentials used to make the unauthorised ModifyDBInstance call. For IAM users, disable the access key using aws iam update-access-key with status Inactive. For assumed roles, revoke the role session using an inline deny policy or delete the role if it is confirmed to be attacker-created.
• Modify the RDS instance's security group to temporarily restrict inbound connections to only the known application server IP ranges and administrative host IPs. This blocks any direct connections the attacker may have established using the compromised master credential, even if they have stored the new password.
• If the attacker may have connected to the database during the window between the password change and containment, treat the full database contents as potentially exfiltrated and initiate breach assessment procedures.

Forensic preservation

• Export all CloudTrail events for the affected AWS account covering the full period from the first suspicious activity to the time of containment. Preserve the ModifyDBInstance event, all preceding API calls from the same IAM principal, and all subsequent calls made from the compromised identity.
• If RDS database activity logging or enhanced monitoring was enabled, export the database logs for the period during which the attacker may have had master user access. These logs may reveal what queries were run, which tables were accessed, and whether a backdoor database user was created.
• Document the time window during which the attacker held the master credential: from the time of the ModifyDBInstance call to the time the password was reset. This window defines the maximum possible scope of database access and is required for the breach impact assessment.

Eradication and recovery

• Audit all database users on the affected RDS instance for accounts created after the time of the unauthorised master password change. Remove any user that cannot be attributed to a documented application or administrative account. Pay particular attention to users created with elevated privileges or with names that mimic legitimate application accounts.
• Rotate the credentials for all database users on the affected instance, not only the master user. If the attacker had master user access, they could have viewed or modified other user passwords stored in the database engine. Treat all database credentials on the instance as potentially compromised.
• Review and remediate the IAM permission that allowed the attacker to call ModifyDBInstance. Implement a least-privilege policy that separates rds:ModifyDBInstance rights for routine database administration from the specific permission to change the master password. Consider using an IAM permission boundary or a Service Control Policy to prevent master password changes except from a designated rotation role.
• Enable AWS Secrets Manager automatic rotation for the RDS master password if not already in use. Secrets Manager rotation ensures the master credential is regularly refreshed, reduces the value of any credential that was observed during the incident, and provides an auditable rotation history.

False positive guidance

Legitimate RDS master password changes are infrequent and attributable to a documented process. The following scenarios may produce false positive alerts:

• Scheduled Secrets Manager rotation: if AWS Secrets Manager is configured to automatically rotate the RDS master password, the rotation Lambda function will call ModifyDBInstance with MasterUserPassword on the configured rotation schedule. These events will come from the Secrets Manager rotation Lambda execution role, occur on a predictable schedule, and target the specific RDS instances configured for rotation. Create a scoped exclusion for the rotation role and verify the rotation schedule aligns with the alert timing before adding the exclusion.
• Authorised manual password rotation: database administrators who manually rotate the RDS master password as part of a documented security hygiene schedule will trigger this rule. Verify the IAM identity matches a documented DBA account, the change aligns with a rotation schedule or change ticket, and the source IP matches the administrator's known workstation or jump host. Document the manual rotation in the incident record and close the alert.
• Infrastructure provisioning automation: CI/CD pipelines and infrastructure-as-code tools that provision or reprovision RDS instances may call ModifyDBInstance with a new master password as part of an environment rebuild. These will originate from the CI/CD service role or an infrastructure automation account, occur during documented deployment windows, and affect non-production instances. Verify the pipeline run matches the alert timing and the affected instance is not a production database.

Key differentiator

Legitimate RDS master password changes are made by a documented IAM role or user, during a scheduled rotation window or in response to an approved change ticket, from a known source IP associated with the rotation system or administrative workstation. An attacker-initiated change will be made by an IAM identity that is not associated with a documented rotation process, will often originate from an unrecognised source IP, and will almost always include ApplyImmediately set to true. The combination of an unrecognised IAM principal, an external source IP, and an immediate application effect is a confirmed incident until proven otherwise.

Hardening and prevention

The following controls reduce the risk of unauthorised RDS master password changes in your AWS environment:

• Implement a least-privilege IAM policy that separates rds:ModifyDBInstance permission from the ability to change the master password. Use an IAM condition to restrict MasterUserPassword modifications to a specific designated rotation role: aws:RequestedRegion or aws:PrincipalARN conditions can scope the permission so that only the Secrets Manager rotation role can call ModifyDBInstance with MasterUserPassword.
• Enable AWS Secrets Manager automatic rotation for all RDS master passwords. Automated rotation using Secrets Manager ensures the credential is regularly refreshed, eliminates long-lived static passwords as an attack surface, and provides an auditable rotation history that makes unauthorised changes immediately visible as deviations from the rotation schedule.
• Rotate all IAM access keys on a regular schedule, at maximum every 90 days. Long-lived access keys that are not rotated are the primary credential vector for unauthorised RDS modifications. Enforce key rotation using an IAM policy that denies actions for access keys older than 90 days.
• Implement AWS CloudTrail alerting for DescribeDBInstances calls from IAM principals that do not normally enumerate RDS resources. Database enumeration immediately before a master password change is a consistent preparatory step. Detecting the enumeration provides an earlier warning than the modification event itself.
• Enable RDS database activity streams or Enhanced Monitoring with database audit logging for production instances. These features capture database-level events including queries, user management operations, and connection attempts, providing visibility into what an attacker did after obtaining master user access that CloudTrail alone cannot provide.
• Restrict network access to RDS instances using security groups that allow inbound database connections only from documented application server security groups and administrative host IPs. A security group that does not permit direct connections from external IP addresses prevents the attacker from using the compromised master credential to connect from outside the VPC even if they successfully change it.