Remediating a potentially compromised database
GuardDuty generates RDS Protection finding types that indicate potentially suspicious and anomalous login behavior in your Supported databases after you enable RDS Protection. Using RDS login activity, GuardDuty analyzes and profiles threats by identifying unusual patterns in login attempts.
Note
You can access the full information about a finding type by selecting it from the GuardDuty active finding types.
Follow these recommended steps to remediate a potentially compromised Amazon Aurora database in your AWS environment.
Topics
Remediating potentially compromised database with successful login events
Remediating potentially compromised database with failed login events
Remediating potentially compromised database with anomalous exfiltration activity
Remediating potentially compromised database with anomalous destructive activity
Remediating potentially compromised database with successful login events
The following recommended steps can help you remediate a potentially compromised Aurora database that exhibits unusual behavior related to successful login events.
-
Identify the affected database and user.
The generated GuardDuty finding provides the name of the affected database and the corresponding user details. For more information, see Finding details.
-
Confirm whether this behavior is expected or unexpected.
The following list specifies potential scenarios that may have caused GuardDuty to generate a finding:
-
A user who logs in to their database after a long time has passed.
-
A user who logs in to their database on an occasional basis, for example, a financial analyst who logs in each quarter.
-
A potentially suspicious actor who is involved in a successful login attempt potentially compromises the database.
-
-
Begin this step if the behavior is unexpected.
-
Restrict database access
Restrict database access for the suspected accounts and the source of this login activity. For more information, see Remediating potentially compromised credentials and Restrict network access.
-
Assess the impact and determine what information was accessed.
-
If available, review the audit logs to identify the pieces of information that might have been accessed. For more information, see Monitoring events, logs, and streams in an Amazon Aurora DB cluster in the Amazon Aurora User Guide.
-
Determine if any sensitive or protected information was accessed or modified.
-
-
Remediating potentially compromised database with failed login events
The following recommended steps can help you remediate a potentially compromised Aurora database that exhibits unusual behavior related to failed login events.
-
Identify the affected database and user.
The generated GuardDuty finding provides the name of the affected database and the corresponding user details. For more information, see Finding details.
-
Identify the source of the failed login attempts.
The generated GuardDuty finding provides the IP address and ASN organization (if it was a public connection) under the Actor section of the finding panel.
An Autonomous System (AS) is a group of one or more IP prefixes (lists of IP addresses accessible on a network) run by one or more network operators that maintain a single, clearly-defined routing policy. Network operators need Autonomous System Numbers (ASNs) to control routing within their networks and to exchange routing information with other internet service providers (ISPs).
-
Confirm that this behavior is unexpected.
Examine if this activity represents an attempt to gain additional unauthorized access to the database as follows:
-
If the source is internal, examine if an application is misconfigured and attempting a connection repeatedly.
-
If this is an external actor, examine whether the corresponding database is public facing or is misconfigured and thus allowing potential malicious actors to brute force common user names.
-
-
Begin this step if the behavior is unexpected.
-
Restrict database access
Restrict database access for the suspected accounts and the source of this login activity. For more information, see Remediating potentially compromised credentials and Restrict network access.
-
Perform root-cause analysis and determine the steps that potentially led to this activity.
Set up an alert to get notified when an activity modifies a networking policy and creates an insecure state. For more information, see Firewall policies in AWS Network Firewall in the AWS Network Firewall Developer Guide.
-
Remediating potentially compromised database with anomalous exfiltration activity
The following recommended steps can help you remediate a potentially compromised Aurora database that exhibits unusual behavior related to data exfiltration events.
-
Identify the affected database and user.
The generated GuardDuty finding provides the name of the affected database and the corresponding user details. For more information, see Finding details.
-
Identify the scope of data accessed.
Review available RDS data activity logs to determine which tables and rows were accessed by the anomalous user during the time window indicated by the finding. Assess the sensitivity of the data that was potentially exfiltrated.
-
Confirm that this behavior is unexpected.
Examine whether this activity represents legitimate operational behavior as follows:
-
If the source is internal, examine whether a scheduled ETL job, reporting tool, or backup process may account for the elevated query volume.
-
If this is an external actor or previously unseen database attribute, examine whether the corresponding database credentials may have been exposed or shared externally.
-
Review whether the combination of volume and unseen attributes (IP address, ASN, application name) aligns with any known operational change.
-
-
Begin this step if the behavior is unexpected.
Revoke access and rotate credentials.
Immediately change the password of the affected database user and revoke active sessions. If the user has elevated privileges, temporarily restrict their permissions to read-only or remove access entirely until investigation is complete.
-
Assess the business impact.
Identify the data that was accessible to the affected user, determine if any sensitive or regulated data (PII, financial, healthcare) was potentially exfiltrated, and follow your organization's data breach notification procedures if applicable.
-
Restrict network access.
Restrict database access for the suspected accounts and the source of this activity. Place the database in a private VPC if not already configured, and limit the security group rules to allow traffic only from the necessary sources. For more information, see Restrict network access.
-
Perform root-cause analysis and determine the steps that potentially led to this activity.
Set up an alert to get notified when an activity modifies a networking policy and creates an insecure state. For more information, see Firewall policies in AWS Network Firewall in the AWS Network Firewall Developer Guide.
Remediating potentially compromised database with anomalous destructive activity
The following recommended steps can help you remediate a potentially compromised Aurora database that exhibits unusual behavior related to destructive DELETE or DROP events.
-
Identify the affected database and user.
The generated GuardDuty finding provides the name of the affected database and the corresponding user details. For more information, see Finding details.
-
Identify the scope of destructive operations.
Review available RDS data activity logs to determine which tables, rows, or database objects were deleted or dropped by the anomalous user during the time window indicated by the finding. Determine whether the data loss is recoverable from existing backups or snapshots.
-
Confirm that this behavior is unexpected.
Examine whether this activity represents legitimate operational behavior as follows:
-
If the source is internal, examine whether a scheduled maintenance job, cleanup script, or migration process may account for the
DELETEorDROPoperations. -
If this is an external actor or previously unseen database attribute, examine whether the corresponding database credentials may have been exposed or compromised.
-
Review whether the combination of destructive operations and unseen attributes (IP address, ASN, application name) aligns with any known operational change.
-
-
Begin this step if the behavior is unexpected.
Revoke access and rotate credentials.
Immediately change the password of the affected database user and revoke active sessions. Remove the user's
DROPandDELETEprivileges until investigation is complete to prevent further data destruction. -
Initiate data recovery.
If data loss is confirmed, initiate point-in-time recovery from automated backups or restore from the most recent snapshot. For Amazon Aurora, you can use backtrack to rewind the database to a time before the destructive activity occurred. For Amazon RDS, use point-in-time recovery to restore to a point before the event.
-
Restrict network access and harden permissions.
Restrict database access for the suspected accounts and the source of this activity. Place the database in a private VPC if not already configured, and limit the security group rules to allow traffic only from the necessary sources. Review IAM policies and database user privileges to enforce least-privilege access, and enable deletion protection on the RDS instance if not already enabled. For more information, see Restrict network access.
-
Perform root-cause analysis and determine the steps that potentially led to this activity.
Set up an alert to get notified when an activity modifies a networking policy and creates an insecure state. For more information, see Firewall policies in AWS Network Firewall in the AWS Network Firewall Developer Guide.
Remediating potentially compromised credentials
A GuardDuty finding may indicate that the user credentials for an affected database have been
compromised when the user identified in the finding has performed an unexpected database
operation. You can identify the user in the RDS DB user details section
within the finding panel in the console, or within the resource.rdsDbUserDetails of
the findings JSON. These user details include user name, application used, database accessed, SSL
version, and authentication method.
-
To revoke access or rotate passwords for specific users that are involved in the finding, see Security with Amazon Aurora MySQL, or Security with Amazon Aurora PostgreSQL in the Amazon Aurora User Guide.
-
Use AWS Secrets Manager to securely store and automatically rotate the secrets for Amazon Relational Database Service(RDS) databases. For more information, see AWS Secrets Manager tutorials in the AWS Secrets Manager User Guide.
-
Use IAM database authentication to manage database users' access without the need for passwords. For more information, see IAM database authentication in the Amazon Aurora User Guide.
For more information, see Security best practices for Amazon Relational Database Service in the Amazon RDS User Guide.
Restrict network access
A GuardDuty finding may indicate that a database is accessible beyond your applications, or
Virtual Private Cloud (VPC). If the remote IP address in the finding is an unexpected connection
source, audit the security groups. A list of security groups attached to the database is
available under Security groups in the https://console.aws.amazon.com/rds/resource.rdsDbInstanceDetails.dbSecurityGroups of the findings JSON. For more
information on configuring security groups, see Controlling access with
security groups in the Amazon RDS User Guide.
If you're using a firewall, restrict network access to the database by reconfiguring the Network Access Control Lists (NACLs). For more information, see Firewalls in AWS Network Firewall in the AWS Network Firewall Developer Guide.
