My Stratus Red Team feature, a new attack scenario aws.exfiltration.ec2-share-ebs-volume was merged and released in version v2.37.2!
A few weekends ago, I found myself with a bit of free time and began looking for an open source project where I could make a small contribution. So I started combing back through the notes of things I’ve found interesting over the years and stumbled upon the open issue #967 in Stratus Red Team, an OSS tool produced and maintained by Datadog.
Having been involved in the development of CloudGoat and Pacu a few years ago during my time at Rhino Security Labs, I felt this was a familiar but, fresh take on offensive tooling centered around cloud security.
What is Stratus Red Team
Stratus Red Team is “Atomic Red Team™” for the cloud, providing granular and self-contained emulation of offensive attack techniques.
https://github.com/DataDog/stratus-red-team
Without rehashing all the docs they have, it’s a way to simulate adversarial attacks in the cloud in a controlled and reproducible way. It’s great for Blue Teams to tune and test detection logic, and for Red Teamers to learn TTPs.
My Addition
aws.exfiltration.ec2-share-ebs-volume emulates how a threat actor can use a new AWS feature, EBS volume clones across accounts, to exfiltrate EC2 EBS volumes without creating or sharing a volume snapshot, which are API calls / features that are commonly associated with this type of exfiltration.
https://aws.amazon.com/blogs/aws/introducing-amazon-ebs-volume-clones-across-aws-accounts
The old way
Exfiltrating an EBS volume to another account isn’t new. The well-known approach is to take a snapshot of a volume and share it with an attacker-controlled account using ModifySnapshotAttribute. Because this technique has been around for a while, it’s well understood and commonly detected.
The new way
With AWS’s new feature, you can share an EBS volume directly with another account by adding it to an AWS Resource Access Manager (RAM) resource share. The receiving account can then clone the volume into its own account. No snapshot is created, and no calls are made to ModifySnapshotAttribute.
It’s a small twist on an existing TTP, where the APIs commonly used for detection of the old method aren’t involved, giving a potentially fresh API surface.
Side note: IMO the AWS feature blog is a bit overstated, AWS kinda just created a link in the EC2 console that forwards you to the RAM service where they added support for EC2 volumes. But hey, a feature is a feature.
Detection
Regardless of how AWS markets it, it’s a new way to exfil data, and it’s good to be aware and be able to detect it.
Keep an eye on these CloudTrail events:
AssociateResourceShare(event sourceram.amazonaws.com): a user added a new resource to a RAM resource share. This applies to all RAM-supported resource types, not just EBS volumes.CopyVolumes(event sourceec2.amazonaws.com): this even triggers when a shared ec2 volume is cloned into a new account, which includes what account cloned it.
{
"eventSource": "ram.amazonaws.com",
"eventName": "AssociateResourceShare",
"awsRegion": "us-east-1",
"userAgent": "stratus-red-team_93185f1c-9296-435a-aa81-8081b35e87f2",
"requestParameters": {
"principals": [
"999999999999"
],
"resourceArns": [
"arn:aws:ec2:us-east-1:111111111111:volume/vol-0c741433d3ddb73c7"
],
"resourceShareArn": "arn:aws:ram:us-east-1:111111111111:resource-share/24048254-7629-41e0-ba73-f129af0cc68d"
},
"readOnly": false,
"managementEvent": true,
"recipientAccountId": "111111111111"
}
{
"userIdentity": {
"type": "AssumedRole",
"accountId": "999999999999"
},
"eventSource": "ec2.amazonaws.com",
"eventName": "CopyVolumes",
"awsRegion": "us-east-1",
"requestParameters": {
"CopyVolumesRequest": {
"SourceVolumeId": "vol-0c741433d3ddb73c7"
}
},
"readOnly": false,
"managementEvent": true,
"recipientAccountId": "111111111111"
}