Increasingly, companies are using cloud services for storage, virtual machines, containers, serverless functions, and more. With the growing popularity of cloud services, cyber attackers’ interest has gained accordingly. Because of how easy it is for anyone to set up a cloud instance – and not always in accordance with IT security protocols – attackers are taking advantage of new ways to gain access to organizational data and assets. When we talk about cloud services in general, and AWS specifically, one cannot ignore the connection from the on-premises environment to the cloud. Using deception technology in the cloud is vital to protecting today’s rapidly growing environments.
As your network moves to the cloud, your deception layer should also. There are many ways to deploy decoy resources in the cloud. Let’s look at an attack scenario and show some of the alerts triggered from our deception layer.
In this attack scenario, we’ll start with a cyber adversary who has already accessed your network and show different ways credentials to AWS can be retrieved. We’ll then show some enumeration scripts that can be used by attackers to gather reconnaissance information on the cloud environment to escalate privileges and connect to some of the cloud instances.
Zero-day exploits are discovered frequently, and they surface when you least expect them. Deploying a deception solution allows you to proactively prepare your network for cyber attackers. Once deployed, the decoys will wait for any advance attackers that find their way into your environment – whether on-premises or in the cloud.
Scenario: Cyber Attacks in Cloud Environments Without Deception Technology
Every big attack starts with a single, small step. In reality, there are many ways an attacker can get access to your network. Just recently, two zero-day attacks were published that allow remote code execution (RCE) and quick access to vulnerable machines: Log4j and Spring4shell. In our recent blog, we showed how such attacks can be used to quickly fetch AWS credentials. Many such attacks give access to victim machines, and once inside, attackers can gain the AWS credentials that open the doors for lateral movement through the cloud.
Here is how cyber adversaries gain such access:
Initial Access: AWS Credentials
- When downloading the credentials from AWS, they are saved in a CSV format file. The default file name is:
_credentials.csv.
- In most cases, automatic tools (e.g. AWS CLI or Python’s boto3) will use a credentials file located in the “.aws” directory. In Linux machines, this file will be here: ~/.aws/credentials and in Windows machines, here: C:\Users\USERNAME\.aws\credentials
- Rather than saving them in files, some configurations will store the keys in the environment variables on the machine: AWS_ACCESS_KEY_ID & AWS_SECRET_ACCESS_KEY. These can easily be fetched using Windows or Linux environment commands.
- In rare cases, the credentials will be written and hard coded in the code or scripts that use them. It is bad practice to save the keys in code, but it is done, especially during the initial code writing.
The above locations and attack vectors are the tip of iceberg. There are many more ways of accessing and stealing access keys. It is important to secure your credentials. Additionally, be prepared for a scenario where your access keys are breached. Let’s look now at the next phase and how quickly an attack can progress once an attacker gets his hands on your keys.
Expanding Foothold: Enumeration and Escalation
The access keys give the adversary some access to your cloud environment. The goal of the attacker is to use that key to get deeper and deeper into your environment. The level of access (s)he can now reach will depend on how that specific user was configured, the configuration of your cloud environment, and of course, the skills of your cyber adversary.
To accelerate access, let’s use two cloud enumeration scripts we recently published. One enumerates EC2 instances and the other enumerates AWS roles. These two together can be used to collect information, escalate privileges, and attempt to connect to running instances. With access to these keys, the enumeration and escalation phase does not need to happen from within your network. The attacker can do this from the comfort of home – or anywhere else.
Script 1 – ec2_enumeration
This script has two modes: enumeration and connect. The enumeration mode will enumerate the EC2 instances in the target AWS environment. It will list the accessible instances, and it will show to which of those instances we have permissions to connect. The connect mode will open an SSH connection to the instance. For the connect mode, we use Amazon’s “EC2 Instance connect” option that allows users to open a connection to an instance without dealing with public or private keys. This script is mainly based on the AWS SDK for phyton, Boto3, and the AWS EC2 instance connect CLI. For more details, check out this script in our GitHub.
Script 2 – role_enumeration
The role script has three modes: enumeration, details, and assume. The enumeration mode will enumerate the roles, summarize details on each of them, and mark which roles can be assumed with existing permissions. The details mode will show more details on the role and its policies. The assume mode will attempt to assume the chosen role. This script is mainly based on the AWS SDK for phyton, Boto3. For more details, check out this script in our GitHub.
We will use the two scripts together to enumerate and escalate the privileges we initially have. Let’s first check which instances and roles we can access with the original user we connect to. Then, we will assume the roles we have access to and attempt the enumeration again to identify additional roles and instances that are now exposed. Finally, we will use the instances script to get shell access to one of the instances and perform actions on it.
Step 1: Enumeration
In this step, we enumerate the accessible EC2 instances and the roles. It shows which instances can be connected to and which roles can be assumed. When we find a role that is assume-able and has interesting permissions, we can describe it with more details.
Image step 1.1 – enumeration of instances – none of the instances can be connected to with our credentials
Image step 1.2 – enumeration of roles – 3 roles can be assumed by our user, one of them has permissions to EC2 and S3.
Image step – 1.3 – describing the role: Iam_role_1
Step 2: Assume Role
Next, let’s use the “Assume Role” option in the script. The script will assume that role and give us a valid token that can be used for the next iterations.
Image step 2 – receiving credentials after Assume Role
Step 3: Enumeration
Use the new token and re-execute the enumeration commands to identify additional instances. We can see in the images below that new EC2 instances were identified, including ones that allow us to use the credentials we have for connection.
Image step 3 – enumeration of instances – 7 instances can be connected to with our new credentials
Step 4: Connect to Instance
Finally, based on the instances identified, we will choose which we want to connect to using the connect mode of the script. Connect to that instance.
We will leave it to the readers imagination what the next steps can be at this point. Attackers usually like to mine bitcoins or encrypt data files.
Image step 4 – connect to instance
Deploying Deception Technology for Proactive Cyber Defense
A deception technology solution, such as Fidelis Deception®, enables users to quickly and easily spread decoy resources within a real cloud environment. All activity to these resources will then be constantly monitored and high fidelity, actionable alerts given.
In this sample environment, we spread the following decoy resources.
- EC2 instances – we deployed 2 EC2 decoy instances.
- IAM Roles – we deployed 3 decoy roles with different policies
- S3 – we deployed two S3 buckets with several decoy documents
We also created links between the decoy resources. For example, the decoy role has permissions to the decoy EC2 instances and the decoy S3 files.
Just like how the network deception environment should match your on-premises terrain, your cloud decoy resources should blend seamlessly into your cloud environment. Your attacker should not realize that they’ve been led to decoys via deception technology, and should, instead, believe that they are interacting with valuable assets.
In the alerts shown below, we will see the alerts triggered during the enumeration phase and the privilege escalation phases described above.
Protect Your Cloud with Detection Technology To keep your organization secure, you must protect your cloud terrain as rigorously as your network terrain. We outlined several ways in which an attacker could gain access in the absence of deception technology.
Cyber adversaries can perform these actions from anywhere and certainly do not need to be inside your network. However, attacks can come from insider threats as well. Traditional network security tools will not be effective in catching these attacks. Deception technology protects against outside threats and malware, as well as offering protection against insider threats.
With the right tools, you can shift to a proactive cyber defense with a deception solution that is agnostic to how the attacker got in. The goal of deception technology is to quickly detect attackers that found their way into your environment and lure them away from production assets.
Fidelis Deception has several layers of deception that can be deployed in your cloud environment. We covered in this blog the deployment of decoy cloud resources. Additional layers are decoys that can be deployed in servers in the cloud or decoys that can be deployed as pods on containers. You can further extend your protection in cloud environments by ensuring visibility across these dynamic, distributed, and diverse systems.
A made for the cloud posture management, workload protection, and container security platform like Fidelis CloudPassage Halo®, coupled with Fidelis Network®, can give you the deep cloud visibility you need, along with real-time risk assessment of your cloud assets so that you can continually improve your defenses.
