{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/tags/rds/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[{"cvss":10,"id":"CVE-2026-46840"}],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["REST Data Services (24.2.0-26.1.0)"],"_cs_severities":["critical"],"_cs_tags":["oracle","rds","rest","vulnerability","cve-2026-46840","takeover"],"_cs_type":"advisory","_cs_vendors":["Oracle"],"content_html":"\u003cp\u003eCVE-2026-46840 is a highly critical vulnerability affecting Oracle REST Data Services (ORDS), specifically the Backend-as-a-Service component. The vulnerability impacts versions 24.2.0 through 26.1.0. An unauthenticated attacker with network access via HTTPS can exploit this flaw to completely compromise an ORDS instance. Successful exploitation leads to full control of the ORDS instance and may also cause significant impact on other products that rely on the compromised ORDS instance due to the scope change aspect of the vulnerability. This presents a substantial risk to organizations utilizing affected versions of Oracle REST Data Services, potentially allowing attackers to gain unauthorized access to sensitive data, modify system configurations, or disrupt critical services.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker identifies a vulnerable Oracle REST Data Services instance accessible via HTTPS.\u003c/li\u003e\n\u003cli\u003eAttacker sends a specially crafted HTTPS request to the vulnerable Backend-as-a-Service component.\u003c/li\u003e\n\u003cli\u003eThe malicious request exploits a flaw within the ORDS application, bypassing authentication checks.\u003c/li\u003e\n\u003cli\u003eThe vulnerability allows the attacker to execute arbitrary code within the ORDS instance.\u003c/li\u003e\n\u003cli\u003eAttacker leverages the code execution to escalate privileges within the ORDS environment.\u003c/li\u003e\n\u003cli\u003eAttacker gains complete control over the ORDS instance, achieving full administrative access.\u003c/li\u003e\n\u003cli\u003eThe attacker can now access sensitive data, modify configurations, or disrupt the ORDS service.\u003c/li\u003e\n\u003cli\u003eDue to the scope change impact, the attacker pivots to compromise other products or services that rely on the now-compromised ORDS instance, expanding the impact of the attack.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-46840 can result in a complete takeover of Oracle REST Data Services. This can lead to unauthorized access to sensitive data, modification of critical system configurations, and disruption of essential services. The vulnerability's potential to impact additional products amplifies the risk, potentially exposing a wider range of systems and data to compromise. Given the CVSS base score of 10.0, the impact is considered critical, affecting confidentiality, integrity, and availability.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the patch provided by Oracle to address CVE-2026-46840 on all affected Oracle REST Data Services instances (versions 24.2.0-26.1.0).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026quot;Detect CVE-2026-46840 Exploitation Attempt via Malicious HTTPS Request\u0026quot; to identify exploitation attempts in web server logs.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit the scope of potential compromise in case of successful exploitation, mitigating the \u0026quot;scope change\u0026quot; impact mentioned in the overview.\u003c/li\u003e\n\u003cli\u003eMonitor outbound network connections originating from ORDS servers for unusual activity after patching, which could indicate post-exploitation activity.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-28T21:19:02Z","date_published":"2026-05-28T21:19:02Z","id":"https://feed.craftedsignal.io/briefs/2026-05-cve-2026-46840-ords/","summary":"CVE-2026-46840 is a critical vulnerability in Oracle REST Data Services (ORDS) that allows an unauthenticated attacker with network access to achieve complete takeover of the service, potentially impacting additional products due to scope change.","title":"CVE-2026-46840 - Oracle REST Data Services Takeover Vulnerability","url":"https://feed.craftedsignal.io/briefs/2026-05-cve-2026-46840-ords/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["AWS RDS"],"_cs_severities":["medium"],"_cs_tags":["aws","rds","snapshot","exfiltration"],"_cs_type":"advisory","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThis threat focuses on the exfiltration of data from AWS RDS DB snapshots. Adversaries with valid credentials or through misconfigurations may modify snapshot attributes to grant access to accounts they control, bypassing existing security measures. This allows the attacker to restore the snapshot in an environment they control, enabling unauthorized access, offline analysis, or data exfiltration. The attack starts when modifications are made to snapshot attributes adding one or more additional AWS accounts to the snapshot's restore permissions. The rule \u0026quot;AWS RDS DB Snapshot Shared with Another Account\u0026quot; from Elastic detects these successful modifications. This is a critical issue, as DB snapshots contain complete backups of database instances, including schemas, table data, and sensitive application content.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker gains access to an AWS account through compromised credentials or exploiting a misconfiguration.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery:\u003c/strong\u003e The attacker uses reconnaissance actions such as \u003ccode\u003eDescribeDBSnapshots\u003c/code\u003e or \u003ccode\u003eDescribeDBInstances\u003c/code\u003e to identify valuable RDS DB snapshots.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation (Optional):\u003c/strong\u003e The attacker may attempt to escalate privileges using techniques like \u003ccode\u003eAttachRolePolicy\u003c/code\u003e, \u003ccode\u003ePutUserPolicy\u003c/code\u003e, or \u003ccode\u003eAssumeRole\u003c/code\u003e to gain the necessary permissions to modify snapshot attributes.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eModify DBSnapshotAttribute:\u003c/strong\u003e The attacker modifies the snapshot's attributes using the \u003ccode\u003eModifyDBSnapshotAttribute\u003c/code\u003e or \u003ccode\u003eModifyDBClusterSnapshotAttribute\u003c/code\u003e API calls, adding the attacker's AWS account to the restore permissions.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSnapshot Copying (Optional):\u003c/strong\u003e The attacker may copy the snapshot using the \u003ccode\u003eCopyDBSnapshot\u003c/code\u003e event to another region or account under their control.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSnapshot Restoration:\u003c/strong\u003e The attacker restores the snapshot in their AWS environment. This creates a new DB instance or cluster with the data from the snapshot.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration:\u003c/strong\u003e The attacker accesses the restored database instance and extracts the sensitive data.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCleanup (Optional):\u003c/strong\u003e The attacker may attempt to cover their tracks by deleting CloudTrail logs or modifying other security configurations.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows the attacker to exfiltrate sensitive data contained within the RDS DB snapshot. The number of potential victims is dependent on how widely these snapshots are shared and on the value of the data contained within. Sectors that rely heavily on cloud databases are at increased risk. Consequences of successful attacks include data breaches, financial loss, reputational damage, and legal liabilities.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Elastic EQL rule \u0026quot;AWS RDS DB Snapshot Shared with Another Account\u0026quot; to your SIEM to detect unauthorized snapshot modifications, tuning it for your environment.\u003c/li\u003e\n\u003cli\u003eRestrict snapshot sharing using IAM condition keys (\u003ccode\u003ekms:ViaService\u003c/code\u003e, \u003ccode\u003erds:dbSnapshotArn\u003c/code\u003e, \u003ccode\u003eaws:PrincipalArn\u003c/code\u003e) as noted in the overview, and remediate existing cross-account access.\u003c/li\u003e\n\u003cli\u003eEnable AWS Config rules and Security Hub controls for public or cross-account snapshot access, based on the recommendation in the overview section.\u003c/li\u003e\n\u003cli\u003eMonitor AWS CloudTrail logs for \u003ccode\u003eModifyDBSnapshotAttribute\u003c/code\u003e and \u003ccode\u003eModifyDBClusterSnapshotAttribute\u003c/code\u003e events (as seen in the Attack Chain) to identify suspicious activity.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-11-15T12:00:00Z","date_published":"2024-11-15T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-11-aws-rds-snapshot-shared/","summary":"An AWS RDS DB snapshot is shared with another AWS account or made public, potentially enabling unauthorized access, offline analysis, or data exfiltration by allowing adversaries to restore the snapshot in their controlled infrastructure.","title":"AWS RDS DB Snapshot Shared with Another Account","url":"https://feed.craftedsignal.io/briefs/2024-11-aws-rds-snapshot-shared/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["AWS RDS"],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","rds","datadestruction"],"_cs_type":"advisory","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThis alert identifies instances where the deletionProtection feature of an AWS RDS DB instance or cluster is disabled. Deletion protection is a security mechanism that prevents accidental or unauthorized deletion of RDS resources. An adversary with sufficient permissions within a compromised AWS environment may disable this protection to pave the way for destructive activities, including the deletion of databases that hold sensitive or business-critical information. The detection focuses on explicit modifications setting \u003ccode\u003edeletionProtection\u003c/code\u003e to \u003ccode\u003efalse\u003c/code\u003e on RDS DB instances or clusters. This activity is often a precursor to a \u003ccode\u003eDeleteDBInstance\u003c/code\u003e or \u003ccode\u003eDeleteDBCluster\u003c/code\u003e action.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe adversary gains access to an AWS account with sufficient privileges to modify RDS instances or clusters, potentially through compromised credentials or an insider threat.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the AWS Management Console, CLI, or API using the compromised credentials or assumed role.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eModifyDBInstance\u003c/code\u003e or \u003ccode\u003eModifyDBCluster\u003c/code\u003e API call to target a specific RDS DB instance or cluster.\u003c/li\u003e\n\u003cli\u003eWithin the \u003ccode\u003eModifyDBInstance\u003c/code\u003e or \u003ccode\u003eModifyDBCluster\u003c/code\u003e API call, the attacker sets the \u003ccode\u003edeletionProtection\u003c/code\u003e parameter to \u003ccode\u003efalse\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eAWS CloudTrail logs the \u003ccode\u003eModifyDBInstance\u003c/code\u003e or \u003ccode\u003eModifyDBCluster\u003c/code\u003e event with \u003ccode\u003edeletionProtection=false\u003c/code\u003e in the \u003ccode\u003erequestParameters\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker may then initiate a \u003ccode\u003eDeleteDBInstance\u003c/code\u003e or \u003ccode\u003eDeleteDBCluster\u003c/code\u003e API call to remove the targeted RDS resource.\u003c/li\u003e\n\u003cli\u003eThe database instance or cluster is deleted, resulting in data loss and potential disruption of services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eDisabling deletion protection on AWS RDS instances or clusters can lead to the unauthorized or accidental deletion of critical databases. Successful execution of this attack can result in significant data loss, business disruption, and potential financial repercussions. The impact can range from temporary service outages to permanent data loss, depending on the affected systems and backup policies.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eAWS RDS Deletion Protection Disabled via CloudTrail\u003c/code\u003e to your SIEM and tune for your environment to detect when deletion protection is disabled (refer to the rule definition below).\u003c/li\u003e\n\u003cli\u003eReview \u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e to determine the IAM principal that made the change, and validate whether this principal normally performs RDS lifecycle operations as outlined in the investigation guide.\u003c/li\u003e\n\u003cli\u003eImmediately re-enable deletion protection (\u003ccode\u003edeletionProtection=true\u003c/code\u003e) on the affected DB instance or cluster if the change was unauthorized, as described in the remediation steps in the overview.\u003c/li\u003e\n\u003cli\u003eRestrict who can modify \u003ccode\u003eModifyDBInstance\u003c/code\u003e or \u003ccode\u003eModifyDBCluster\u003c/code\u003e destructive settings, such as deletion protection, backup retention, and public accessibility.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-07-03T14:30:00Z","date_published":"2024-07-03T14:30:00Z","id":"https://feed.craftedsignal.io/briefs/2024-07-aws-rds-deletion-protection-disabled/","summary":"An adversary may disable deletion protection on an AWS RDS DB instance or cluster as a precursor to destructive actions, such as deleting databases containing sensitive data.","title":"AWS RDS DB Instance or Cluster Deletion Protection Disabled","url":"https://feed.craftedsignal.io/briefs/2024-07-aws-rds-deletion-protection-disabled/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Amazon RDS"],"_cs_severities":["medium"],"_cs_tags":["aws","rds","snapshot","backup","datadestruction"],"_cs_type":"advisory","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThis rule detects the deletion of AWS RDS DB snapshots or configuration changes that effectively remove backup coverage for a DB instance. RDS snapshots contain full backups of database instances, and disabling automated backups by setting \u0026quot;backupRetentionPeriod=0\u0026quot; has a similar impact by preventing future restore points. A threat actor with sufficient AWS permissions may delete snapshots or disable backups to inhibit recovery, destroy forensic evidence, or prepare for follow-on destructive actions such as instance or cluster deletion. The rule focuses on successful snapshot deletions and backup disabling events within AWS RDS. The scope includes any AWS environment utilizing RDS for database services.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains access to an AWS account with sufficient permissions to manage RDS instances and snapshots, possibly through compromised credentials or an IAM role with excessive privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates available RDS DB instances and snapshots within the target AWS account using AWS CLI or API calls (e.g., \u003ccode\u003eDescribeDBSnapshots\u003c/code\u003e, \u003ccode\u003eDescribeDBInstances\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker identifies target DB instances and their associated snapshots that are critical for recovery or contain valuable forensic data.\u003c/li\u003e\n\u003cli\u003eThe attacker deletes RDS DB snapshots using the \u003ccode\u003eDeleteDBSnapshot\u003c/code\u003e API call, effectively removing restore points.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker modifies the DB instance configuration using the \u003ccode\u003eModifyDBInstance\u003c/code\u003e API call, setting \u003ccode\u003ebackupRetentionPeriod\u003c/code\u003e to 0 to disable automated backups and prevent future restore points.\u003c/li\u003e\n\u003cli\u003eThe attacker may then delete the RDS instance itself using DeleteDBInstance.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to cover their tracks by deleting relevant CloudTrail logs or disabling CloudTrail logging.\u003c/li\u003e\n\u003cli\u003eThe attacker's objective is to prevent restoration to a known-good state and destroy forensic evidence of attacker actions, potentially as part of a ransomware attack or data exfiltration attempt.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful deletion of RDS snapshots or disabling of backups can lead to significant data loss and prolonged downtime, making recovery from security incidents or operational failures difficult or impossible. This can impact business continuity, data integrity, and regulatory compliance. The precise impact depends on the criticality of the affected databases and the availability of alternative backup mechanisms. If successful, this can result in total data loss for the organization.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect suspicious \u003ccode\u003eDeleteDBSnapshot\u003c/code\u003e, \u003ccode\u003eDeleteDBClusterSnapshot\u003c/code\u003e, or \u003ccode\u003eModifyDBInstance\u003c/code\u003e events setting \u003ccode\u003ebackupRetentionPeriod=0\u003c/code\u003e in AWS CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eRestrict IAM permissions for \u003ccode\u003erds:DeleteDBSnapshot\u003c/code\u003e, \u003ccode\u003erds:DeleteDBClusterSnapshot\u003c/code\u003e, and \u003ccode\u003erds:ModifyDBInstance\u003c/code\u003e (especially backup and deletion-related parameters) to a small set of privileged roles, as described in the remediation steps.\u003c/li\u003e\n\u003cli\u003eUse AWS Config rules and/or Security Hub controls to detect instances with \u003ccode\u003ebackupRetentionPeriod=0\u003c/code\u003e, as recommended in the hardening and preventive controls section.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-07-03T12:00:00Z","date_published":"2024-07-03T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-07-aws-rds-snapshot-deletion/","summary":"The deletion of AWS RDS DB snapshots or disabling backups via configuration changes can inhibit recovery, destroy forensic evidence, and prepare for destructive actions by adversaries.","title":"AWS RDS Snapshot Deletion Detected","url":"https://feed.craftedsignal.io/briefs/2024-07-aws-rds-snapshot-deletion/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["AWS RDS"],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","rds","persistence","defense_evasion"],"_cs_type":"advisory","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThis detection identifies the creation or modification of an Amazon RDS DB instance or cluster with the \u003ccode\u003epubliclyAccessible\u003c/code\u003e attribute set to \u003ccode\u003etrue\u003c/code\u003e. While legitimate use cases exist, unexpected public exposure of a database to the internet introduces significant security risks. An adversary with access to AWS credentials might modify a DB instance's public accessibility to exfiltrate data, establish persistence, or bypass internal network restrictions. The rule focuses on \u003ccode\u003eModifyDBInstance\u003c/code\u003e, \u003ccode\u003eCreateDBInstance\u003c/code\u003e, and \u003ccode\u003eCreateDBCluster\u003c/code\u003e events within AWS CloudTrail logs. Defenders should investigate any unexpected changes to RDS instance accessibility. This activity can indicate compromised credentials or insider threats, and might be correlated with other IAM and network configuration changes to assess the overall impact.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to AWS credentials (e.g., via phishing or credential stuffing).\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to authenticate to the AWS Management Console or via the AWS CLI/API.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target RDS DB instance or cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker executes a \u003ccode\u003eModifyDBInstance\u003c/code\u003e API call, setting the \u003ccode\u003ePubliclyAccessible\u003c/code\u003e parameter to \u003ccode\u003etrue\u003c/code\u003e in the \u003ccode\u003erequest_parameters\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker executes a \u003ccode\u003eCreateDBInstance\u003c/code\u003e or \u003ccode\u003eCreateDBCluster\u003c/code\u003e API call with the \u003ccode\u003ePubliclyAccessible\u003c/code\u003e parameter set to \u003ccode\u003etrue\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies associated security groups using \u003ccode\u003eAuthorizeSecurityGroupIngress\u003c/code\u003e to allow inbound traffic from \u003ccode\u003e0.0.0.0/0\u003c/code\u003e or other broad IP ranges.\u003c/li\u003e\n\u003cli\u003eThe now publicly accessible RDS instance is used to exfiltrate data or as a pivot point to attack other internal resources.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the publicly exposed database for persistent access and further reconnaissance.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eIf an attacker successfully makes an RDS DB instance publicly accessible, they can potentially exfiltrate sensitive data, pivot to other internal resources, or establish persistent access to the environment. The number of affected instances depends on the scope of the credential compromise. Sectors that heavily rely on cloud infrastructure, such as finance, healthcare, and technology, are at higher risk. The impact can range from data breaches and compliance violations to significant financial losses and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026quot;AWS RDS DB Instance Made Public\u0026quot; to your SIEM using \u003ccode\u003efilebeat-*\u003c/code\u003e and \u003ccode\u003elogs-aws.cloudtrail-*\u003c/code\u003e indices to detect modifications to RDS instance accessibility.\u003c/li\u003e\n\u003cli\u003eReview \u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e and \u003ccode\u003eaws.cloudtrail.user_identity.type\u003c/code\u003e in the SIEM to identify the IAM principal that made the change and validate its legitimacy.\u003c/li\u003e\n\u003cli\u003eMonitor for \u003ccode\u003eAuthorizeSecurityGroupIngress\u003c/code\u003e events in CloudTrail logs that allow inbound traffic from \u003ccode\u003e0.0.0.0/0\u003c/code\u003e to associated security groups of RDS instances.\u003c/li\u003e\n\u003cli\u003eImplement AWS Config rules (e.g., \u003ccode\u003erds-instance-public-access-check\u003c/code\u003e) to automatically detect and remediate publicly accessible RDS instances.\u003c/li\u003e\n\u003cli\u003eEnforce Service Control Policies (SCPs) to prevent the creation of publicly accessible RDS instances.\u003c/li\u003e\n\u003cli\u003eRefer to the provided AWS IR Playbooks and AWS Customer Playbook Framework documentation for incident response guidance.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-07-03T12:00:00Z","date_published":"2024-07-03T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-07-aws-rds-public/","summary":"An attacker with compromised AWS credentials may modify an Amazon RDS DB instance or cluster to be publicly accessible for persistence, data exfiltration, or to bypass network restrictions.","title":"AWS RDS DB Instance Made Public","url":"https://feed.craftedsignal.io/briefs/2024-07-aws-rds-public/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["RDS"],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","rds","persistence"],"_cs_type":"advisory","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThis threat brief focuses on the modification of master passwords for AWS RDS DB instances or clusters. While password changes can be legitimate for recovery actions, attackers with sufficient permissions can exploit this to regain access, establish persistence, bypass existing controls, or escalate privileges within a compromised environment. The primary concern arises because RDS does not expose passwords in API responses, making any such modification a meaningful change to access pathways, potentially impacting sensitive data stores. This activity is detected via \u003ccode\u003eModifyDBInstance\u003c/code\u003e or \u003ccode\u003eModifyDBCluster\u003c/code\u003e events in AWS CloudTrail.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS account through compromised credentials, exploiting a vulnerable application, or other means.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing RDS DB instances and clusters using AWS CLI or API calls, such as \u003ccode\u003eDescribeDBInstances\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target RDS DB instance or cluster containing sensitive data or critical functionality.\u003c/li\u003e\n\u003cli\u003eThe attacker executes \u003ccode\u003eModifyDBInstance\u003c/code\u003e or \u003ccode\u003eModifyDBCluster\u003c/code\u003e via the AWS CLI or API, changing the master user password. This requires appropriate IAM permissions.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly modified password to authenticate to the database and gain privileged access.\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious actions within the database, such as exfiltrating data, modifying data, or creating new accounts with elevated privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker may disable deletion protection or modify backup retention policies to further ensure persistence or cover their tracks.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of RDS master passwords can lead to significant data breaches, service disruption, and financial losses. While specific victim numbers and sectors aren't available, the impact of a compromised RDS instance can be severe. If an attacker successfully modifies the password, they can gain complete control over the database, potentially leading to the exfiltration of sensitive information, modification or deletion of critical data, and the compromise of applications relying on the database.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026quot;AWS RDS DB Instance or Cluster Password Modified\u0026quot; to detect unauthorized password modifications (rule).\u003c/li\u003e\n\u003cli\u003eReview \u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e and \u003ccode\u003eaws.cloudtrail.user_identity.access_key_id\u003c/code\u003e in AWS CloudTrail logs to identify the source of password modification events (log source).\u003c/li\u003e\n\u003cli\u003eLimit IAM permissions for \u003ccode\u003erds:ModifyDBInstance\u003c/code\u003e and \u003ccode\u003erds:ModifyDBCluster\u003c/code\u003e, especially when modifying authentication parameters (reference).\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) and role-based access control (RBAC) for DB administrators (reference).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-07-03T10:00:00Z","date_published":"2024-07-03T10:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-07-aws-rds-password-modified/","summary":"The modification of the master password for an AWS RDS DB instance or cluster can indicate malicious activity used for persistence, privilege escalation, or defense evasion.","title":"AWS RDS DB Instance or Cluster Password Modification","url":"https://feed.craftedsignal.io/briefs/2024-07-aws-rds-password-modified/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["RDS"],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","rds","defense-evasion","data-collection"],"_cs_type":"advisory","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThis rule detects the restoration of an AWS RDS database instance, a technique that can be abused by adversaries for defense evasion or data collection. Attackers may restore databases from snapshots or S3 backups to bypass logging and monitoring, create shadow environments for data exfiltration, or access older data. The activity is triggered by the successful execution of \u003ccode\u003eRestoreDBInstanceFromDBSnapshot\u003c/code\u003e or \u003ccode\u003eRestoreDBInstanceFromS3\u003c/code\u003e events within AWS CloudTrail logs. Defenders should monitor for unexpected RDS restores to identify potential malicious activity and data compromise. This activity can occur post-compromise after an attacker gains access to AWS credentials with sufficient privileges to manage RDS instances.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains access to an AWS account through compromised credentials or privilege escalation.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates available RDS snapshots and S3 backups using AWS CLI or API calls (\u003ccode\u003eDescribeDBSnapshots\u003c/code\u003e, \u003ccode\u003eDescribeDBInstances\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target RDS database instance containing sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates a \u003ccode\u003eRestoreDBInstanceFromDBSnapshot\u003c/code\u003e or \u003ccode\u003eRestoreDBInstanceFromS3\u003c/code\u003e operation to create a new RDS instance from a snapshot or backup.\u003c/li\u003e\n\u003cli\u003eA new RDS instance is created with the data from the snapshot or backup.\u003c/li\u003e\n\u003cli\u003eThe attacker accesses the restored database instance, bypassing monitoring on the original instance.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates sensitive data from the restored instance.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to delete the restored instance and snapshots to remove traces of their activity.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to bypass existing security controls and gain unauthorized access to sensitive data stored within the RDS database. This can lead to data breaches, financial loss, and reputational damage. If the attacker gains access to a production database copy, the impact can be significant, potentially affecting thousands of users. The sectors most likely impacted include those that rely heavily on cloud-based database solutions, such as finance, healthcare, and technology.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026quot;AWS RDS DB Instance Restored\u0026quot; to your SIEM, tuned for your specific environment, to detect unauthorized RDS instance restorations.\u003c/li\u003e\n\u003cli\u003eEnforce least privilege for \u003ccode\u003erds:RestoreDBInstanceFromDBSnapshot\u003c/code\u003e and \u003ccode\u003erds:RestoreDBInstanceFromS3\u003c/code\u003e actions using IAM policies, restricting restore actions by network, principal, or region.\u003c/li\u003e\n\u003cli\u003eEnable AWS CloudTrail logging and monitor for unexpected RDS events, focusing on \u003ccode\u003eRestoreDBInstanceFromDBSnapshot\u003c/code\u003e and \u003ccode\u003eRestoreDBInstanceFromS3\u003c/code\u003e actions.\u003c/li\u003e\n\u003cli\u003eImplement AWS Config and Security Hub controls for monitoring unapproved RDS restores and misconfigured restored instances.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the user identity, source IP, and the snapshot or S3 location used for the restore.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T12:00:00Z","date_published":"2024-01-09T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-09-aws-rds-restore/","summary":"Detection of AWS RDS database instance restoration from a snapshot or S3 backup, potentially indicating unauthorized data access, defense evasion, or data collection by adversaries recreating database environments to bypass controls or exfiltrate sensitive data.","title":"AWS RDS DB Instance Restored for Defense Evasion or Data Collection","url":"https://feed.craftedsignal.io/briefs/2024-01-09-aws-rds-restore/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["RDS","S3"],"_cs_severities":["medium"],"_cs_tags":["aws","rds","s3","exfiltration","cloudtrail"],"_cs_type":"advisory","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThe exporting of RDS (Relational Database Service) snapshots to Amazon S3 buckets can be a legitimate operation for analytics, migration, or backup purposes. However, adversaries can abuse this functionality by exporting sensitive database snapshots to S3 buckets they control or can access, bypassing RDS's built-in security controls. This poses a significant risk of data exfiltration, as the exported snapshot is essentially a portable copy of the database contents. The activity is triggered via the \u003ccode\u003eStartExportTask\u003c/code\u003e API call. The scope of targeting is broad, as any organization utilizing AWS RDS is potentially vulnerable, with the impact being dependent on the sensitivity of the data stored in the RDS instances.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains unauthorized access to an AWS account with sufficient privileges to interact with RDS and S3 services. This can be achieved through compromised credentials, privilege escalation, or exploiting misconfigured IAM roles.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates available RDS instances and identifies those containing sensitive data using \u003ccode\u003eDescribeDBSnapshots\u003c/code\u003e or similar API calls.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates a snapshot of the target RDS instance, creating a point-in-time copy of the database.\u003c/li\u003e\n\u003cli\u003eThe attacker calls the \u003ccode\u003eStartExportTask\u003c/code\u003e API to export the RDS snapshot to a specified S3 bucket. This involves specifying the snapshot identifier, the destination S3 bucket name and path, and optionally a KMS key for encryption.\u003c/li\u003e\n\u003cli\u003eThe exported snapshot is stored in the S3 bucket as a set of data files.\u003c/li\u003e\n\u003cli\u003eThe attacker configures the S3 bucket's access controls (ACLs or bucket policies) to allow access from an external AWS account or identity they control.\u003c/li\u003e\n\u003cli\u003eThe attacker downloads the exported snapshot files from the S3 bucket to their local system or a different cloud environment.\u003c/li\u003e\n\u003cli\u003eThe attacker imports the snapshot into a database instance they control, gaining access to the sensitive data contained within the RDS instance. The end objective is successful exfiltration of the database contents to a location outside the organization's control.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to the exfiltration of sensitive data, including personally identifiable information (PII), financial data, or trade secrets. The number of affected victims depends on the scope of the compromised AWS environment. Organizations in highly regulated sectors like finance and healthcare are at particularly high risk. The compromise can result in significant financial losses, reputational damage, legal repercussions, and loss of customer trust.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eAWS RDS Snapshot Export to S3\u003c/code\u003e to your SIEM to detect unauthorized RDS snapshot exports by monitoring \u003ccode\u003eStartExportTask\u003c/code\u003e events in CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eImplement IAM least-privilege policies to restrict the ability to call \u003ccode\u003eStartExportTask\u003c/code\u003e to authorized users and roles only, as mentioned in the overview.\u003c/li\u003e\n\u003cli\u003eContinuously monitor and review S3 bucket ACLs and policies to ensure that access is restricted to authorized principals, as described in the remediation steps.\u003c/li\u003e\n\u003cli\u003eEnable AWS Config or Security Hub controls to monitor snapshot policy changes and alert for exports to buckets outside approved accounts, per the hardening and preventive controls advice.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:00:00Z","date_published":"2024-01-03T18:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-aws-rds-snapshot-exfiltration/","summary":"An adversary may export RDS snapshots to Amazon S3 to exfiltrate sensitive data outside of RDS-managed storage, potentially bypassing database access controls and leading to unauthorized data theft.","title":"AWS RDS Snapshot Export to S3 for Potential Data Exfiltration","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-rds-snapshot-exfiltration/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Amazon RDS","Amazon Aurora"],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","rds","datadestruction"],"_cs_type":"advisory","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThe deletion of Amazon RDS DB instances, Aurora clusters, or global database clusters can lead to permanent data loss and major service disruption. This activity is often carried out by adversaries who have gained sufficient permissions within an AWS environment. The motivation behind such actions can range from impeding recovery efforts following a ransomware attack, destroying critical evidence to hinder forensic investigations, or directly inflicting operational impact on the targeted environment. Defenders should be aware that these actions are irreversible without backups, making swift detection and validation essential to mitigate potential damage.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn adversary gains initial access to the AWS environment, potentially through compromised credentials or an IAM role with excessive permissions.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing RDS DB instances, Aurora clusters, or global database clusters within the target AWS account to identify valuable targets.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the deletionProtection setting on the target RDS resource to \u003ccode\u003efalse\u003c/code\u003e to allow deletion.\u003c/li\u003e\n\u003cli\u003eThe attacker may disable or modify backup configurations to prevent recovery options, such as setting backupRetentionPeriod to \u003ccode\u003e0\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003eDeleteDBInstance\u003c/code\u003e, \u003ccode\u003eDeleteDBCluster\u003c/code\u003e, or \u003ccode\u003eDeleteGlobalCluster\u003c/code\u003e API call to initiate the deletion process.\u003c/li\u003e\n\u003cli\u003eIf configured, the attacker may attempt to delete any final snapshots created during the deletion process to further hinder recovery.\u003c/li\u003e\n\u003cli\u003eThe targeted RDS resource is permanently deleted, resulting in data loss and potential service disruption.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to cover their tracks by deleting relevant CloudTrail logs or modifying IAM policies.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe deletion of RDS DB instances or clusters can lead to significant data loss, disrupting critical business operations. Depending on the size and importance of the deleted resources, organizations may face substantial financial losses, reputational damage, and regulatory penalties. If backups are unavailable or have also been compromised, data recovery may be impossible, leading to long-term business disruption. The impact can affect organizations of any size that rely on AWS RDS for data storage and retrieval.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eAWS RDS DB Instance or Cluster Deleted\u003c/code\u003e to your SIEM and tune for your environment to detect unauthorized RDS resource deletions.\u003c/li\u003e\n\u003cli\u003eEnable deletionProtection on all critical RDS instances and clusters to prevent accidental or malicious deletion.\u003c/li\u003e\n\u003cli\u003eEnforce MFA for IAM users with RDS privileges to reduce the risk of compromised credentials (reference the additional information links).\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for changes to deletionProtection settings and backup retention policies.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit IAM policies to ensure that users and roles have only the necessary permissions.\u003c/li\u003e\n\u003cli\u003eImplement a process for validating unexpected RDS resource deletions with the service owner or database administrator.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process-creation logging to correlate with CloudTrail logs in case CLI or SDK tools are used for deletion.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-aws-rds-deletion/","summary":"An adversary with sufficient permissions may delete RDS resources such as DB instances or clusters to impede recovery, destroy evidence, or inflict operational impact on the environment.","title":"AWS RDS DB Instance or Cluster Deleted","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-rds-deletion/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Amazon RDS"],"_cs_severities":["high"],"_cs_tags":["cloud","aws","credential-access","rds"],"_cs_type":"advisory","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThis analytic detects the resetting of the master user password for an Amazon RDS DB instance. The detection leverages AWS CloudTrail logs ingested via Amazon Security Lake to identify events where the \u003ccode\u003eModifyDBInstance\u003c/code\u003e or \u003ccode\u003eModifyDBCluster\u003c/code\u003e API calls include a new \u003ccode\u003emasterUserPassword\u003c/code\u003e parameter. This activity is significant because unauthorized password resets can grant attackers access to sensitive data stored in production databases, which may contain sensitive information such as credit card numbers, PII, or protected health information. If the password reset is confirmed to be malicious, it could lead to data breaches, regulatory non-compliance, and significant reputational damage. This detection is based on version 8 of the Splunk Security Content analytic \u0026quot;ASL AWS Credential Access RDS Password reset\u0026quot; published on April 15, 2026.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS account, potentially through compromised credentials (T1110) or phishing (T1586.003).\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the AWS Management Console or AWS CLI to interact with the RDS service.\u003c/li\u003e\n\u003cli\u003eThe attacker issues a \u003ccode\u003eModifyDBInstance\u003c/code\u003e or \u003ccode\u003eModifyDBCluster\u003c/code\u003e API call.\u003c/li\u003e\n\u003cli\u003eWithin the \u003ccode\u003eModifyDBInstance\u003c/code\u003e or \u003ccode\u003eModifyDBCluster\u003c/code\u003e API call, the attacker includes the \u003ccode\u003emasterUserPassword\u003c/code\u003e parameter.\u003c/li\u003e\n\u003cli\u003eThe RDS service processes the request and resets the master user password for the specified database instance or cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly reset master user password to authenticate to the RDS database instance.\u003c/li\u003e\n\u003cli\u003eThe attacker gains access to sensitive data stored within the RDS database.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates or manipulates the data for malicious purposes.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack resulting in unauthorized password reset can lead to a complete compromise of the RDS database instance. This could result in data breaches with millions of records exposed, regulatory fines for non-compliance (e.g., GDPR, HIPAA), and severe reputational damage affecting customer trust and stock prices. Sectors heavily reliant on RDS databases, such as finance, healthcare, and e-commerce, are particularly vulnerable.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eAWS RDS Master User Password Reset\u003c/code\u003e to your SIEM and tune for your environment using AWS CloudTrail logs ingested via Amazon Security Lake.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of \u003ccode\u003eModifyDBInstance\u003c/code\u003e or \u003ccode\u003eModifyDBCluster\u003c/code\u003e API calls containing the \u003ccode\u003emasterUserPassword\u003c/code\u003e parameter by pivoting to the originating IP address (\u003ccode\u003esrc_endpoint.ip\u003c/code\u003e) and user agent (\u003ccode\u003ehttp_request.user_agent\u003c/code\u003e) from the Sigma rule.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts, especially those with permissions to manage RDS instances, to mitigate compromised credential attacks (T1110).\u003c/li\u003e\n\u003cli\u003eReview and enforce the principle of least privilege for IAM roles, ensuring that users only have the necessary permissions to perform their job functions.\u003c/li\u003e\n\u003cli\u003eMonitor AWS CloudTrail logs for other suspicious API calls related to RDS, such as modifications to security groups or network ACLs.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T10:00:00Z","date_published":"2024-01-03T10:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-rds-password-reset/","summary":"Detection of unauthorized master user password resets for Amazon RDS DB instances via AWS CloudTrail logs, potentially leading to sensitive data access and data breaches.","title":"AWS RDS Master User Password Reset Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-rds-password-reset/"}],"language":"en","title":"CraftedSignal Threat Feed - Rds","version":"https://jsonfeed.org/version/1.1"}