Table of Contents
Share this entry
In the sprawling cloud infrastructure of GlobalTech Inc., a meticulously planned ransomware attack was set in motion by a sophisticated adversary, codenamed Vector. Vector’s objective wasn’t just to encrypt data for a ransom but to navigate through a complex AWS environment with precision, exploiting specific, less obvious permissions to achieve his goals.
Phase 1: Initial Foothold
Vector’s initial entry was through a compromised third-party CI/CD pipeline that had permissions to deploy resources in GlobalTech’s AWS environment. The pipeline was configured with an IAM role, CI_CD_Deployer, which had iam:PassRole permission. This role was intended only to deploy Lambda functions with a predefined execution role, LambdaExecRole, that, crucially, included kms:Encrypt and kms:Decrypt permissions for a set of KMS keys used across GlobalTech’s S3 data lakes.
Phase 2: Privilege Escalation
With access to the CI/CD pipeline, Vector crafted a Lambda function designed to scan and identify S3 buckets containing valuable data. To avoid detection, he used the s3:ListBucket permission from the LambdaExecRole and selectively targeted buckets by parsing bucket tags with s3:GetBucketTagging, looking for tags reminiscent of PII or confidential data. This precision reduced the noise that could trigger security alerts.
Phase 3: Exploitation and Lateral Movement
Upon identifying the targets, Vector deployed another Lambda function with a more sinister purpose. This function used the s3:GetObject and kms:Encrypt permissions to access and encrypt the data. However, Vector knew that simply encrypting the data wouldn’t be enough. To ensure he could also decrypt the data if a ransom was paid, he used kms:GenerateDataKeyWithoutPlaintext, which allowed him to generate encryption keys that were stored securely, without exposing the plaintext key material outside of KMS.
Phase 4: Establishing Persistence
To maintain access and control, Vector needed to ensure persistence within GlobalTech’s environment. He leveraged the events:PutRule and events:PutTargets permissions of the LambdaExecRole to create a CloudWatch Events rule. This rule was designed to trigger his malicious Lambda function periodically, checking for new or updated objects in the targeted S3 buckets to encrypt them, ensuring that even new data would not escape encryption.
Phase 5: Covering Tracks and Exfiltration
Aware that GlobalTech used AWS CloudTrail and Config for monitoring, Vector needed a way to obscure his activities. He created a new Lambda function with logs:CreateLogStream and logs:PutLogEvents permissions to generate a high volume of benign log entries, effectively burying any signs of his malicious activities within a sea of mundane log data. Concurrently, he exfiltrated encryption keys and specific data snippets using lambda:InvokeFunction, calling out to a Lambda function outside GlobalTech’s environment, passing data through API Gateway endpoints he had previously established with apigateway:POST.
Phase 6: Ransom Demand
Finally, with the data encrypted and his tracks sufficiently covered, Vector deployed his ransom demand. He used sns:Publish permission to send an alert to GlobalTech’s SNS topic used for operational alerts, masquerading his ransom note as a system alert, demanding cryptocurrency for the decryption keys.
The Importance of Securing Sensitive Permissions
Some cloud permissions are especially high-value. These are the permissions that can edit, create, and delete elements of the cloud. There are over 42,000 possible permissions across the major clouds, with about 3,000 of them falling into this sensitive bucket.
This story depicted how sensitive permissions could be leveraged by a malicious actor to cause harm, but the reality is, well-intended employees can get into trouble, too.
Building IAM programs centered around these most critical permissions is a more efficient way to secure access. Teams spend their time and resources building policies to secure a lower volume of permissions, but the result is higher-impact risk reduction.
The Sonrai Cloud Permissions Firewall instantly protects your cloud’s most sensitive permissions. Unused permissions, services, regions, and identities are secured with the click of a button. Save time not writing policies, reduce your attack surface, and grant seamless access to developers with ‘Permissions-on-Demand’.
THE ARCHITECT
The Newsletter for Cloud Security Leaders. 1x a month.
Sonrai cloud security platform, products and services are covered by U.S. Patent Nos. 10,728,307 and 11,134,085, together with other domestic and international patents pending. All rights reserved.