Snapshot - CraftedSignal Threat Feed

AWS RDS DB Snapshot Shared with Another Account

hello@craftedsignal.io — Fri, 15 Nov 2024 12:00:00 +0000

This 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 "AWS RDS DB Snapshot Shared with Another Account" 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.

Attack Chain

Initial Access: The attacker gains access to an AWS account through compromised credentials or exploiting a misconfiguration.
Discovery: The attacker uses reconnaissance actions such as DescribeDBSnapshots or DescribeDBInstances to identify valuable RDS DB snapshots.
Privilege Escalation (Optional): The attacker may attempt to escalate privileges using techniques like AttachRolePolicy, PutUserPolicy, or AssumeRole to gain the necessary permissions to modify snapshot attributes.
Modify DBSnapshotAttribute: The attacker modifies the snapshot's attributes using the ModifyDBSnapshotAttribute or ModifyDBClusterSnapshotAttribute API calls, adding the attacker's AWS account to the restore permissions.
Snapshot Copying (Optional): The attacker may copy the snapshot using the CopyDBSnapshot event to another region or account under their control.
Snapshot Restoration: The attacker restores the snapshot in their AWS environment. This creates a new DB instance or cluster with the data from the snapshot.
Data Exfiltration: The attacker accesses the restored database instance and extracts the sensitive data.
Cleanup (Optional): The attacker may attempt to cover their tracks by deleting CloudTrail logs or modifying other security configurations.

Impact

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

Recommendation

Deploy the provided Elastic EQL rule "AWS RDS DB Snapshot Shared with Another Account" to your SIEM to detect unauthorized snapshot modifications, tuning it for your environment.
Restrict snapshot sharing using IAM condition keys (kms:ViaService, rds:dbSnapshotArn, aws:PrincipalArn) as noted in the overview, and remediate existing cross-account access.
Enable AWS Config rules and Security Hub controls for public or cross-account snapshot access, based on the recommendation in the overview section.
Monitor AWS CloudTrail logs for ModifyDBSnapshotAttribute and ModifyDBClusterSnapshotAttribute events (as seen in the Attack Chain) to identify suspicious activity.

AWS RDS Snapshot Deletion Detected

hello@craftedsignal.io — Wed, 03 Jul 2024 12:00:00 +0000

This 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 "backupRetentionPeriod=0" 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.

Attack Chain

The 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.
The attacker enumerates available RDS DB instances and snapshots within the target AWS account using AWS CLI or API calls (e.g., DescribeDBSnapshots, DescribeDBInstances).
The attacker identifies target DB instances and their associated snapshots that are critical for recovery or contain valuable forensic data.
The attacker deletes RDS DB snapshots using the DeleteDBSnapshot API call, effectively removing restore points.
Alternatively, the attacker modifies the DB instance configuration using the ModifyDBInstance API call, setting backupRetentionPeriod to 0 to disable automated backups and prevent future restore points.
The attacker may then delete the RDS instance itself using DeleteDBInstance.
The attacker attempts to cover their tracks by deleting relevant CloudTrail logs or disabling CloudTrail logging.
The 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.

Impact

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

Recommendation

Deploy the provided Sigma rule to your SIEM to detect suspicious DeleteDBSnapshot, DeleteDBClusterSnapshot, or ModifyDBInstance events setting backupRetentionPeriod=0 in AWS CloudTrail logs.
Restrict IAM permissions for rds:DeleteDBSnapshot, rds:DeleteDBClusterSnapshot, and rds:ModifyDBInstance (especially backup and deletion-related parameters) to a small set of privileged roles, as described in the remediation steps.
Use AWS Config rules and/or Security Hub controls to detect instances with backupRetentionPeriod=0, as recommended in the hardening and preventive controls section.

AWS EC2 EBS Snapshot Access Permissions Removed

hello@craftedsignal.io — Tue, 09 Jan 2024 15:00:00 +0000

This detection identifies the removal of access permissions from shared AWS EC2 EBS snapshots using AWS CloudTrail logs. EBS snapshots are critical for data retention and disaster recovery. Threat actors may attempt to revoke or modify snapshot permissions to prevent legitimate users or processes from accessing backups, which hinders recovery efforts following data loss or destructive actions. This tactic can also be employed to evade detection or maintain exclusive access to sensitive backups, amplifying the impact of attacks and complicating incident response. This behavior matters because successful removal of access can significantly delay or prevent data recovery, leading to prolonged downtime and potential data loss. The rule focuses on identifying ModifySnapshotAttribute events where access is being removed, specifically looking for changes to CREATE_VOLUME_PERMISSION via remove=.

Attack Chain

The attacker gains unauthorized access to an AWS account, possibly through compromised credentials or exploiting IAM misconfigurations.
The attacker enumerates available EC2 EBS snapshots within the targeted AWS environment to identify potential targets for disruption.
The attacker uses the ModifySnapshotAttribute API call to remove access permissions from the identified EBS snapshots, specifically targeting the CREATE_VOLUME_PERMISSION attribute.
The request parameters in the CloudTrail logs indicate the removal of access, observed through the presence of "attributeType=CREATE_VOLUME_PERMISSION" and "remove=".
Legitimate users or automated processes attempting to restore data from the affected snapshots will fail, hindering recovery efforts.
The attacker may repeat the process across multiple snapshots to maximize the impact and disrupt the entire recovery strategy.
The attacker may also delete snapshots entirely using DeleteSnapshot to ensure complete data loss.
The attacker achieves their objective of disrupting business operations, holding data for ransom, or covering tracks by preventing forensic analysis and recovery.

Impact

Successful removal of EBS snapshot access can have significant consequences. Organizations may face extended downtime, data loss, and reputational damage. Depending on the criticality of the affected systems, financial losses and regulatory penalties may also occur. The number of victims and sectors targeted can vary, but any organization relying on AWS for data storage and backup is potentially at risk. If the attack succeeds, the organization's ability to recover from data loss events like ransomware or accidental deletion is severely compromised, potentially leading to irreversible data loss.

Recommendation

Deploy the Sigma rule AWS EBS Snapshot Access Removal to detect unauthorized modification of snapshot access permissions in your AWS environment. Enable AWS CloudTrail logging and ensure logs are ingested to your SIEM (Security Information and Event Management) to enable the rule.
Review IAM policies and restrict ec2:ModifySnapshotAttribute permissions to only trusted administrative roles as mentioned in the rule's investigation steps.
Enable AWS Config rules and Security Hub controls such as ebs-snapshot-public-restorable-check to provide continuous monitoring and compliance checks, as recommended in the rule's response section.
Implement backup immutability using AWS Backup Vault Lock or S3 Object Lock to protect against unauthorized modifications, as mentioned in the response section.
Investigate any alerts generated by the Sigma rule, examining aws.cloudtrail.user_identity.arn and source.ip to identify the actor and source of the access removal, as indicated in the rule's triage section.

Mass Azure Compute Snapshot Deletion

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This brief focuses on the detection of mass Azure compute snapshot deletions, a tactic used by threat actors to impede system recovery and potentially pave the way for ransomware attacks. The behavior is identified through Azure Activity Logs when a single user or service principal deletes multiple Azure disk snapshots within a short timeframe. The source research indicates that adversaries target snapshots to prevent victims from recovering data without paying ransom or to eliminate forensic evidence of their activities. Mass deletion of snapshots eliminates restore points, significantly impacting disaster recovery capabilities, and is a critical indicator of potentially malicious activity. The activity is detectable via Azure Activity Logs. This activity has been associated with groups like Storm-0501.

Attack Chain

The attacker gains unauthorized access to an Azure account or compromises a user account with sufficient privileges.
The attacker enumerates available Azure compute snapshots within the subscription.
The attacker initiates a mass deletion of Azure disk snapshots using the compromised account, often targeting critical system backups.
Azure Activity Logs record the snapshot deletion events, capturing details like the user, timestamp, and resource names.
The attacker may attempt to disable or modify other backup mechanisms to further hinder recovery efforts.
With snapshots deleted, the attacker proceeds with data encryption for ransomware attacks or other malicious activities.
The victim is left without readily available restore points, increasing the likelihood of paying a ransom or experiencing significant data loss.

Impact

Successful mass deletion of Azure compute snapshots can have severe consequences. Organizations may lose critical restore points, making data recovery difficult or impossible without paying a ransom. This can lead to significant downtime, financial losses, and reputational damage. Affected sectors include any organization relying on Azure for compute and storage services. The number of victims depends on the scope of the attack, but even a single successful incident can have a major impact.

Recommendation

Deploy the Sigma rule Azure Compute Snapshot Deletions by User to your SIEM to detect suspicious snapshot deletion activity (rule).
Investigate any alerts generated by the rule, focusing on the user or service principal involved and the number of snapshots deleted (rule).
Implement Azure Resource Locks on critical snapshots to prevent accidental or malicious deletion (reference).
Configure Azure Policy to restrict snapshot deletion permissions to only authorized backup administrators (reference).
Enable Azure Activity Log alerts and configure notifications to security teams immediately when snapshots are deleted (reference).
Review and enhance backup strategies to ensure redundant backup mechanisms exist beyond Azure snapshots, including geo-redundant backups and offline copies (reference).

AWS EC2 Snapshot Shared Externally

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This analytic detects when an EC2 snapshot is shared publicly by analyzing AWS CloudTrail events. The detection method leverages CloudTrail logs ingested into Amazon Security Lake to identify modifications in snapshot permissions, specifically when the snapshot is shared outside the originating AWS account. This activity is significant as it may indicate an attempt to exfiltrate sensitive data stored in the snapshot. A threat actor could gain unauthorized access to the snapshot's data, potentially leading to data breaches or further exploitation of the compromised information. The rule focuses on ModifySnapshotAttribute events where the createVolumePermission.add.items{}.group is set to all, indicating public sharing.

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised credentials or other means.
The attacker enumerates existing EC2 snapshots within the AWS environment to identify potentially valuable data.
The attacker modifies the snapshot's attributes using the ModifySnapshotAttribute API call.
Within the API request, the attacker sets the createVolumePermission.add.items{}.group parameter to all, making the snapshot publicly accessible.
The CloudTrail logs record this ModifySnapshotAttribute event, capturing the details of the permission change.
The attacker, or any external party, can now create a volume from the publicly shared snapshot in their own AWS account.
The attacker mounts the volume to an EC2 instance and accesses the data stored within the snapshot.
The attacker exfiltrates sensitive data from the mounted volume, completing the objective of data theft.

Impact

A successful attack could lead to the exfiltration of sensitive data stored within the EC2 snapshot. The shared snapshot could be accessed by unauthorized individuals, leading to a data breach. This could result in financial losses, reputational damage, and legal liabilities. Depending on the data contained within the snapshot, the impact could range from exposure of proprietary business information to personally identifiable information (PII).

Recommendation

Deploy the provided Sigma rule to your SIEM to detect publicly shared EC2 snapshots based on ModifySnapshotAttribute events in Amazon Security Lake CloudTrail logs.
Investigate any alerts generated by the Sigma rule, focusing on the user (actor.user.uid) and source IP address (src_endpoint.ip) associated with the event.
Review AWS IAM policies to ensure least privilege and restrict the ability to modify snapshot attributes.
Implement multi-factor authentication (MFA) for all AWS accounts to reduce the risk of compromised credentials.

AWS EC2 Snapshot Exfiltration Attempt

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This threat brief focuses on the detection of potential data exfiltration from AWS EC2 instances using EC2 snapshots. Attackers might attempt to exfiltrate sensitive data by creating snapshots of EC2 volumes, modifying snapshot attributes to share them externally, and then deleting the snapshot to cover their tracks. This activity can occur rapidly, within a 5-minute timeframe. This technique allows unauthorized individuals to gain access to the data stored in the EC2 volumes, leading to potential data breaches and compliance violations. The detection strategy leverages AWS CloudTrail logs, focusing on API calls related to snapshot manipulation. The exfiltration technique is further detailed in reports from Nettitude, bleemb.medium.com, and Stratus Red Team.

Attack Chain

Attacker gains initial access to an AWS account, potentially through compromised credentials or a misconfigured IAM role.
The attacker uses the CreateSnapshot API call to create a snapshot of a target EC2 volume containing sensitive data.
The attacker uses DescribeSnapshotAttribute to check the existing attributes and permissions of the created snapshot.
The attacker uses ModifySnapshotAttribute to modify the snapshot's attributes, specifically granting access to an external AWS account controlled by the attacker. This is done by adding the attacker's AWS account ID to the createVolumePermission.add.items{}.userId parameter.
The attacker may repeatedly use DescribeSnapshotAttribute and ModifySnapshotAttribute to refine access permissions or attempt to bypass security controls.
The attacker in the external AWS account creates a volume from the shared snapshot, gaining access to the data contained within.
The attacker exfiltrates the data from the newly created volume to a location outside the victim's AWS environment.
The attacker may use the DeleteSnapshot API call to delete the snapshot in the original AWS account, attempting to remove evidence of the exfiltration.

Impact

Successful exploitation leads to the exfiltration of sensitive data stored within EC2 volumes. The number of victims and sectors targeted can vary. The exfiltration may include customer data, financial records, or intellectual property, leading to significant financial losses, reputational damage, and legal liabilities. Data breaches resulting from this technique can also trigger compliance violations and regulatory scrutiny.

Recommendation

Deploy the provided Sigma rule (AWS EC2 Snapshot Exfiltration) to your SIEM and tune the threshold (distinct API calls >= 2) based on your environment's baseline activity.
Enable and monitor AWS CloudTrail logs to capture API calls related to EC2 snapshots, ensuring comprehensive logging of CreateSnapshot, DescribeSnapshotAttribute, ModifySnapshotAttribute, and DeleteSnapshot events.
Investigate any alerts generated by the Sigma rule, focusing on the user (user), source IP (src_ip), and affected AWS account (vendor_account) to determine if the activity is legitimate or malicious.
Review and enforce strict IAM policies to limit the ability of users and roles to create, modify, or share EC2 snapshots, reducing the attack surface.
Implement monitoring and alerting for unusual or unauthorized access to EC2 snapshots from external AWS accounts.