Todd Moore | Vice President, Data Security Products, Thales
More About This Author >
Todd Moore | Vice President, Data Security Products, Thales
More About This Author >
A sophisticated ransomware gang, Codefinger, has a cunning new technique for encrypting data stored in AWS S3 buckets without traditional ransomware tools. Instead, they exploit the AWS server-side encryption with customer-provided keys (SSE-C), extorting payment in exchange for the encryption key.
Unlike conventional ransomware, the malicious actors don’t exfiltrate any data. Instead, they mark the encrypted files for deletion within seven days, putting organizations under pressure to pay the ransom or lose their data for good.
Before we discuss the specifics of the attack, it is important to note that similar attacks could occur in any cloud environment outside your control; therefore, the lessons learned apply to all your cloud deployments.
How the Attack Works
The attack begins with the malefactor gaining access to compromised AWS credentials—which may have been stolen or inadvertently leaked— providing the necessary permissions to read and write objects in the victim’s S3 buckets. This is a critical entry point because improperly secured or over-permissioned keys grant bad actors the foothold they need to carry out their attacks.
Once inside, the gang initiates the encryption process by exploiting the x-amz-server-side-encryption-customer-algorithm header within AWS. Specifically, they generate a custom Advanced Encryption Standard (AES-256) key, which is stored locally by the attackers and not shared with AWS. This makes it completely inaccessible to the targeted entity.
When the threat actors invoke the AWS server-side encryption with the customer-provided keys (SSE-C) feature, the encryption process unfolds entirely within the AWS environment.
Here’s where the attack becomes particularly insidious: AWS processes the encryption request using the provided key but does not retain the key itself. Instead, it logs a hash-based message authentication code (HMAC) in AWS CloudTrail, which verifies the encryption request that happened but cannot be used to reconstruct the encryption key.
Instilling a Sense of Urgency
As a result, the company loses access to its data unless it has a backup. To instill a sense of urgency, the criminals mark encrypted files for deletion within seven days, turning the encryption process into a ticking time bomb.
Adding to the complexity, during ransom negotiations, Codefinger explicitly warns victims not to alter account permissions or attempt countermeasures, as any changes could result in the bad actors cutting off communications and leaving the victim with encrypted data and no decryption key.
What makes this method particularly effective is its lack of data exfiltration. Relying solely on encryption allows the fraudster to bypass all the detection mechanisms and limit their activity to the victim’s AWS environment, limiting the chance of external alerts.
Avoid Becoming a Victim
Entities that depend on AWS S3 buckets must take proactive measures to mitigate the risks of attacks of this nature before they gain traction.
Entities should implement robust security measures to mitigate the risk of this type of attack. Restricting IAM policies using the Condition element can prevent unauthorized use of SSE-C, limiting this feature to specific users and data.
Strengthening key management practices is equally essential. AWS key permissions should be reviewed regularly to ensure they grant only the minimum required access. Disabling unused keys and rotating active ones frequently limits the risk of compromise.
Enabling detailed logging and monitoring for all S3 operations also helps detect unusual activity early, allowing firms to respond quickly and reduce potential damage.
A Dangerous Gamble
Businesses are also advised to use the AWS built-in protections, with the caveat that these are not foolproof alone. AWS quarantines publicly exposed customer keys to limit their usability, but extra safeguards are also needed.
If anything, this recent attack underscores a critical lesson: relying on cloud providers' built-in security provisions, assuming they’re “good enough,” is a dangerous gamble. Organizations are legally responsible for the security of their data, wherever it's stored, and they must start acting like it.
Storing encryption keys externally, separate from the data they protect, dramatically reduces the risk of unauthorized access. Even if a server is compromised, the keys remain secure in an external hardware security module (HSM) or key management system. Many regulations and standards mandate strict control over encryption keys. Utilizing external key management helps organizations meet these compliance requirements by ensuring keys are managed and stored securely.
It’s Never “Good Enough”
Organizations should never take a “good enough” approach to security. This notion is flawed and assumes the threat landscape is static. Cyber threats are constantly evolving, and security measures must be robust and adaptable to address new vulnerabilities. Organizations often mistakenly believe that CSPs fully protect their data. However, CSPs typically offer basic security measures and assume no responsibility for the protection of their customers' data—only for access to it. That falls to the organization.
Effective security requires an end-to-end approach, integrating security measures at every stage of data handling. Relying solely on the CSP’s security can leave gaps that attackers can exploit – and organizations are liable.
Thales Key Management offerings streamline and strengthen key management in cloud and enterprise environments across a diverse set of use cases. Leveraging FIPS 140-2-compliant virtual or hardware appliances, Thales key management tools and solutions deliver high security to sensitive environments and centralize key management for your home-grown encryption and third-party applications. This gives you greater command over your keys while increasing your data security.