{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/tags/snapshot/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_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":["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":["EC2","EBS"],"_cs_severities":["medium"],"_cs_tags":["aws","ebs","snapshot","impact"],"_cs_type":"advisory","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThis 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 \u003ccode\u003eModifySnapshotAttribute\u003c/code\u003e events where access is being removed, specifically looking for changes to \u003ccode\u003eCREATE_VOLUME_PERMISSION\u003c/code\u003e via \u003ccode\u003eremove=\u003c/code\u003e.\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, possibly through compromised credentials or exploiting IAM misconfigurations.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates available EC2 EBS snapshots within the targeted AWS environment to identify potential targets for disruption.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eModifySnapshotAttribute\u003c/code\u003e API call to remove access permissions from the identified EBS snapshots, specifically targeting the \u003ccode\u003eCREATE_VOLUME_PERMISSION\u003c/code\u003e attribute.\u003c/li\u003e\n\u003cli\u003eThe request parameters in the CloudTrail logs indicate the removal of access, observed through the presence of \u003ccode\u003e\u0026quot;attributeType=CREATE_VOLUME_PERMISSION\u0026quot;\u003c/code\u003e and \u003ccode\u003e\u0026quot;remove=\u0026quot;\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eLegitimate users or automated processes attempting to restore data from the affected snapshots will fail, hindering recovery efforts.\u003c/li\u003e\n\u003cli\u003eThe attacker may repeat the process across multiple snapshots to maximize the impact and disrupt the entire recovery strategy.\u003c/li\u003e\n\u003cli\u003eThe attacker may also delete snapshots entirely using \u003ccode\u003eDeleteSnapshot\u003c/code\u003e to ensure complete data loss.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective of disrupting business operations, holding data for ransom, or covering tracks by preventing forensic analysis and recovery.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eAWS EBS Snapshot Access Removal\u003c/code\u003e 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.\u003c/li\u003e\n\u003cli\u003eReview IAM policies and restrict \u003ccode\u003eec2:ModifySnapshotAttribute\u003c/code\u003e permissions to only trusted administrative roles as mentioned in the rule's investigation steps.\u003c/li\u003e\n\u003cli\u003eEnable AWS Config rules and Security Hub controls such as \u003ccode\u003eebs-snapshot-public-restorable-check\u003c/code\u003e to provide continuous monitoring and compliance checks, as recommended in the rule's response section.\u003c/li\u003e\n\u003cli\u003eImplement backup immutability using AWS Backup Vault Lock or S3 Object Lock to protect against unauthorized modifications, as mentioned in the response section.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, examining \u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e and \u003ccode\u003esource.ip\u003c/code\u003e to identify the actor and source of the access removal, as indicated in the rule's triage section.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T15:00:00Z","date_published":"2024-01-09T15:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-aws-ebs-snapshot-access-removed/","summary":"Detection of AWS EC2 EBS snapshot access permissions removal can indicate malicious attempts to disrupt data recovery, evade detection, or maintain exclusive backup access, leading to increased attack impact and incident response complexity.","title":"AWS EC2 EBS Snapshot Access Permissions Removed","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-ebs-snapshot-access-removed/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Azure"],"_cs_severities":["medium"],"_cs_tags":["azure","snapshot","data-destruction","impact"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis 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.\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 Azure account or compromises a user account with sufficient privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates available Azure compute snapshots within the subscription.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates a mass deletion of Azure disk snapshots using the compromised account, often targeting critical system backups.\u003c/li\u003e\n\u003cli\u003eAzure Activity Logs record the snapshot deletion events, capturing details like the user, timestamp, and resource names.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to disable or modify other backup mechanisms to further hinder recovery efforts.\u003c/li\u003e\n\u003cli\u003eWith snapshots deleted, the attacker proceeds with data encryption for ransomware attacks or other malicious activities.\u003c/li\u003e\n\u003cli\u003eThe victim is left without readily available restore points, increasing the likelihood of paying a ransom or experiencing significant data loss.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eAzure Compute Snapshot Deletions by User\u003c/code\u003e to your SIEM to detect suspicious snapshot deletion activity (rule).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the rule, focusing on the user or service principal involved and the number of snapshots deleted (rule).\u003c/li\u003e\n\u003cli\u003eImplement Azure Resource Locks on critical snapshots to prevent accidental or malicious deletion (reference).\u003c/li\u003e\n\u003cli\u003eConfigure Azure Policy to restrict snapshot deletion permissions to only authorized backup administrators (reference).\u003c/li\u003e\n\u003cli\u003eEnable Azure Activity Log alerts and configure notifications to security teams immediately when snapshots are deleted (reference).\u003c/li\u003e\n\u003cli\u003eReview and enhance backup strategies to ensure redundant backup mechanisms exist beyond Azure snapshots, including geo-redundant backups and offline copies (reference).\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-azure-snapshot-deletion/","summary":"The rule detects mass deletion of Azure disk snapshots, which could indicate an adversary attempting to inhibit system recovery capabilities, destroy backup evidence, or prepare for a ransomware attack.","title":"Mass Azure Compute Snapshot Deletion","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-snapshot-deletion/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["EC2"],"_cs_severities":["high"],"_cs_tags":["aws","ec2","snapshot","data exfiltration","cloudtrail"],"_cs_type":"advisory","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThis 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 \u003ccode\u003eModifySnapshotAttribute\u003c/code\u003e events where the \u003ccode\u003ecreateVolumePermission.add.items{}.group\u003c/code\u003e is set to \u003ccode\u003eall\u003c/code\u003e, indicating public sharing.\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 or other means.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing EC2 snapshots within the AWS environment to identify potentially valuable data.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the snapshot's attributes using the \u003ccode\u003eModifySnapshotAttribute\u003c/code\u003e API call.\u003c/li\u003e\n\u003cli\u003eWithin the API request, the attacker sets the \u003ccode\u003ecreateVolumePermission.add.items{}.group\u003c/code\u003e parameter to \u003ccode\u003eall\u003c/code\u003e, making the snapshot publicly accessible.\u003c/li\u003e\n\u003cli\u003eThe CloudTrail logs record this \u003ccode\u003eModifySnapshotAttribute\u003c/code\u003e event, capturing the details of the permission change.\u003c/li\u003e\n\u003cli\u003eThe attacker, or any external party, can now create a volume from the publicly shared snapshot in their own AWS account.\u003c/li\u003e\n\u003cli\u003eThe attacker mounts the volume to an EC2 instance and accesses the data stored within the snapshot.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates sensitive data from the mounted volume, completing the objective of data theft.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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).\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 publicly shared EC2 snapshots based on \u003ccode\u003eModifySnapshotAttribute\u003c/code\u003e events in Amazon Security Lake CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the user (\u003ccode\u003eactor.user.uid\u003c/code\u003e) and source IP address (\u003ccode\u003esrc_endpoint.ip\u003c/code\u003e) associated with the event.\u003c/li\u003e\n\u003cli\u003eReview AWS IAM policies to ensure least privilege and restrict the ability to modify snapshot attributes.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts to reduce the risk of compromised credentials.\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-03-ec2-snapshot-shared-externally/","summary":"Detection of AWS EC2 snapshot shared publicly, indicating potential data exfiltration, by analyzing AWS CloudTrail events.","title":"AWS EC2 Snapshot Shared Externally","url":"https://feed.craftedsignal.io/briefs/2024-01-03-ec2-snapshot-shared-externally/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["EC2"],"_cs_severities":["high"],"_cs_tags":["aws","ec2","snapshot","data_exfiltration","cloudtrail"],"_cs_type":"advisory","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to an AWS account, potentially through compromised credentials or a misconfigured IAM role.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eCreateSnapshot\u003c/code\u003e API call to create a snapshot of a target EC2 volume containing sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003eDescribeSnapshotAttribute\u003c/code\u003e to check the existing attributes and permissions of the created snapshot.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003eModifySnapshotAttribute\u003c/code\u003e 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 \u003ccode\u003ecreateVolumePermission.add.items{}.userId\u003c/code\u003e parameter.\u003c/li\u003e\n\u003cli\u003eThe attacker may repeatedly use \u003ccode\u003eDescribeSnapshotAttribute\u003c/code\u003e and \u003ccode\u003eModifySnapshotAttribute\u003c/code\u003e to refine access permissions or attempt to bypass security controls.\u003c/li\u003e\n\u003cli\u003eThe attacker in the external AWS account creates a volume from the shared snapshot, gaining access to the data contained within.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates the data from the newly created volume to a location outside the victim's AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker may use the \u003ccode\u003eDeleteSnapshot\u003c/code\u003e API call to delete the snapshot in the original AWS account, attempting to remove evidence of the exfiltration.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule (\u003ccode\u003eAWS EC2 Snapshot Exfiltration\u003c/code\u003e) to your SIEM and tune the threshold (distinct API calls \u0026gt;= 2) based on your environment's baseline activity.\u003c/li\u003e\n\u003cli\u003eEnable and monitor AWS CloudTrail logs to capture API calls related to EC2 snapshots, ensuring comprehensive logging of \u003ccode\u003eCreateSnapshot\u003c/code\u003e, \u003ccode\u003eDescribeSnapshotAttribute\u003c/code\u003e, \u003ccode\u003eModifySnapshotAttribute\u003c/code\u003e, and \u003ccode\u003eDeleteSnapshot\u003c/code\u003e events.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the user (\u003ccode\u003euser\u003c/code\u003e), source IP (\u003ccode\u003esrc_ip\u003c/code\u003e), and affected AWS account (\u003ccode\u003evendor_account\u003c/code\u003e) to determine if the activity is legitimate or malicious.\u003c/li\u003e\n\u003cli\u003eReview and enforce strict IAM policies to limit the ability of users and roles to create, modify, or share EC2 snapshots, reducing the attack surface.\u003c/li\u003e\n\u003cli\u003eImplement monitoring and alerting for unusual or unauthorized access to EC2 snapshots from external AWS accounts.\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-03-aws-ec2-snapshot-exfiltration/","summary":"This analytic detects potential exfiltration of data from AWS EC2 instances through the suspicious creation, modification, and deletion of EC2 snapshots within a short timeframe, potentially leading to unauthorized data access.","title":"AWS EC2 Snapshot Exfiltration Attempt","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-ec2-snapshot-exfiltration/"}],"language":"en","title":"CraftedSignal Threat Feed - Snapshot","version":"https://jsonfeed.org/version/1.1"}