CRITICALData Exposure20-30 min containment15 steps across 5 phases

    RDS Database Exposure

    An RDS database instance has been found publicly accessible, or database credentials have been leaked. Attackers may have already accessed, modified, or exfiltrated data. Common causes: PubliclyAccessible flag enabled with permissive security groups, or database credentials committed to source code.

    Phase 1: Detection

    $ tail -f /var/log/cloudtrail/events.log
    1

    Check if the RDS instance is publicly accessible

    Verify the PubliclyAccessible flag and check whether the security group allows 0.0.0.0/0 on the database port.

    aws rds describe-db-instances \
      --db-instance-identifier <db-instance> \
      --query 'DBInstances[0].{Public:PubliclyAccessible,Endpoint:Endpoint,VpcSecurityGroups:VpcSecurityGroups}'
    # Check the security group rules
    aws ec2 describe-security-groups \
      --group-ids <sg-id> \
      --query 'SecurityGroups[0].IpPermissions'
    2

    Review RDS audit logs for unauthorized access

    If audit logging is enabled, check for connections from unknown IPs, failed auth attempts, or unusual queries.

    aws rds describe-db-log-files \
      --db-instance-identifier <db-instance>
    aws rds download-db-log-file-portion \
      --db-instance-identifier <db-instance> \
      --log-file-name audit/audit.log \
      --starting-token 0
    3

    Check CloudTrail for RDS configuration changes

    Look for recent changes that may have exposed the database.

    CloudTrail:ModifyDBInstanceAuthorizeDBSecurityGroupIngressCreateDBInstance

    Phase 2: Containment

    $ ./containment.sh --isolate --immediate
    1

    Disable public accessibility

    Set PubliclyAccessible to false. This takes a few minutes to apply.

    aws rds modify-db-instance \
      --db-instance-identifier <db-instance> \
      --no-publicly-accessible \
      --apply-immediately
    2

    Restrict the security group

    Remove any 0.0.0.0/0 rules and restrict access to specific application security groups.

    aws ec2 revoke-security-group-ingress \
      --group-id <sg-id> \
      --protocol tcp \
      --port 3306 \
      --cidr 0.0.0.0/0
    3

    Rotate the master password

    Change the database master password immediately.

    aws rds modify-db-instance \
      --db-instance-identifier <db-instance> \
      --master-user-password <new-strong-password> \
      --apply-immediately

    Update all applications that use this database with the new credentials. Store the new password in Secrets Manager.

    Phase 3: Eradication

    $ ./eradicate.sh --purge --verify
    1

    Rotate all application database credentials

    Any credential that was used to access this database should be considered compromised and rotated.

    # If using Secrets Manager, rotate the secret
    aws secretsmanager rotate-secret \
      --secret-id <secret-name>
    2

    Audit database contents for tampering

    Check for new database users, modified data, dropped tables, or inserted backdoor stored procedures.

    3

    Review data access patterns

    If RDS audit logging was enabled, analyze which tables and records were accessed during the exposure window.

    Phase 4: Recovery

    $ ./recovery.sh --restore --validate
    1

    Restore from a pre-compromise snapshot if needed

    If data was tampered with, restore the database from a snapshot taken before the compromise.

    aws rds describe-db-snapshots \
      --db-instance-identifier <db-instance> \
      --query 'DBSnapshots[*].{ID:DBSnapshotIdentifier,Time:SnapshotCreateTime}' \
      --output table
    aws rds restore-db-instance-from-db-snapshot \
      --db-instance-identifier <db-instance>-restored \
      --db-snapshot-identifier <snapshot-id> \
      --no-publicly-accessible
    2

    Enable IAM database authentication

    Migrate from password-based auth to IAM database authentication where supported.

    3

    Assess regulatory notification requirements

    If personal data was exposed, determine notification obligations under GDPR, CCPA, HIPAA, or other regulations.

    Phase 5: Lessons Learned

    $ cat POST_INCIDENT_REVIEW.md
    1

    Deploy Config rule to prevent public RDS instances

    Enable the rds-instance-public-access-check Config rule to continuously monitor.

    aws configservice put-config-rule --config-rule '{
      "ConfigRuleName": "rds-instance-public-access-check",
      "Source": {"Owner": "AWS", "SourceIdentifier": "RDS_INSTANCE_PUBLIC_ACCESS_CHECK"}
    }'
    2

    Use Secrets Manager for credential rotation

    Store database credentials in Secrets Manager with automatic rotation enabled.

    3

    Enable RDS audit logging

    Enable audit logging for MySQL (via option groups) or PostgreSQL (via parameter groups) to capture all database access.

    rdsdatabasepublic-accesscredential-leakdata-breach

    Need Help with Incident Response?

    When an incident strikes, every minute counts. We help AWS teams prepare, detect, and respond to security incidents with proven expertise.