Protecting your AWS infrastructure against CodeFinger ransomware

If you’ve kept up with recent cybersecurity news, you may have encountered CodeFinger ransomware, which utilizes AWS infrastructure to encrypt S3 buckets with customer-managed keys (CMKs). The ransomware cleverly uses AWS’s own infrastructure to manage the encryption. Although AWS oversees the encryption process, it is unable to retrieve the CMK, rendering organizations powerless without the key.

The role of customer-managed keys

Customer-managed keys offer enhanced security by providing an additional level of control and segregation for encrypting data. However, they are typically required only in highly regulated environments or for specific assurance-driven use cases. For most organizations, AWS-managed encryption is sufficient to secure data at rest while minimizing operational complexity.

Unfortunately, CodeFinger exploits the flexibility of CMKs to lock down data. To mitigate this, we recommend restricting the use of CMKs with S3. By disallowing new CMKs or enforcing stricter access controls, organizations can effectively reduce the risk of this attack vector.

The policy to restrict CMKs for S3

Below is a sample service control policy (SCP) that explicitly disallows the use of customer-managed keys for S3. It ensures that new CMKs cannot be created for S3 encryption, prevents the creation of S3 buckets that use unauthorized keys, and still allows the use of AWS-managed encryption keys:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNewCMKForS3",
      "Effect": "Deny",
      "Action": ["kms:CreateKey", "kms:CreateReplica"],
      "Resource": "*",
      "Condition": {
        "StringEquals": { "kms:ViaService": "s3.amazonaws.com" }
      }
    },
    {
      "Sid": "DenyNewS3BucketWithNewCMK",
      "Effect": "Deny",
      "Action": [
        "s3:CreateBucket",
        "s3:PutEncryptionConfiguration",
        "s3:PutBucketEncryption"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-server-side-encryption": ["AES256", "aws:kms"]
        },
        "StringNotLike": {
          "s3:x-amz-server-side-encryption-aws-kms-key-id": [
            "arn:aws:kms:*:*:key/aws/s3",
            "arn:aws:kms:*:*:key/existing-key-id-1",
            "arn:aws:kms:*:*:key/existing-key-id-2"
          ]
        }
      }
    }
  ]
}

Deploying the policy

1. Attach it to your AWS organization at the root, or to specific organizational units.
2. Test thoroughly in a non-production environment to ensure no legitimate operations are impacted.
3. Deploy with the AWS Management Console or the CLI:

aws organizations create-policy \
    --name "DenyNewCMKAndS3BucketEncryption" \
    --type "SERVICE_CONTROL_POLICY" \
    --content file://deny_cmk_s3_policy.json

aws organizations attach-policy \
    --policy-id <policy-id> \
    --target-id <ou-id>

Simplifying security with guardrails

While SCPs are a powerful tool, they come with complexity and a steep learning curve. A misconfigured SCP can lead to unintended service disruptions, leaving organizations scrambling to troubleshoot. This is where guardrails come in.

Rapticore’s guardrails enforce critical security policies without the operational complexity of SCPs — maintaining compliance, enforcing best practices, and holding the secure state of a cloud environment. With guardrails in place, an organization can proactively prevent threats like CodeFinger while focusing on its core business. Guardrails are part of ActiveFlux, Rapticore’s agentic cloud security product.