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

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