Loading

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.

Rule type: eql
Rule indices:

  • filebeat-*
  • logs-aws.cloudtrail-*

Rule Severity: medium
Risk Score: 47
Runs every:
Searches indices from: now-6m
Maximum alerts per execution: ?
References:

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

Version: ?
Rule authors:

  • Elastic

Rule license: Elastic License v2

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.

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.

  • 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.
  • 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.

  • 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.
info 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=*")

Framework: MITRE ATT&CK

Framework: MITRE ATT&CK

Framework: MITRE ATT&CK