Fidelis Cybersecurity
Fidelis Blog
Arad Inbar
Arad Inbar
Security Researcher

Arad Inbar is a security researcher at Fidelis Cybersecurity, specializing in Deception. He has been analyzing network traffic & malware for over 5 years. ... Read More


Using Deception Technology in Cloud Environments

Cloud Deception

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

For instance, to connect to AWS using programmatic access, the account administrator needs to generate an access key and an access key secret for a specific AWS user. This is common when working with AWS Command Line Interface (CLI). An attacker with access to those keys will gain access to the AWS environment of that user.

If the victim machine is using AWS CLI, these credentials are usually saved in clear text on that machine. They are typically easy to find in one of these locations:

  • When downloading the credentials from AWS, they are saved in a CSV format file. The default file name is: <USER>_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.



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.

Alert 1 – EC2 enumeration

Alert 2 – Assume Role

Alert 3 – EC2 connect

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 catching these attacks. Deception technology provides protection 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.

Sound too good to be true? Learn more about Fidelis Deception or schedule a demo.








Stay up to date on all things security

Subscribe to the Threat Geek Blog