Threat Alert: Attack Vector Uses Containers to Methodically Target Cloud Resources

The Aqua Research team has identified a new attack vector that points to an evolution in attacks’ techniques and capabilities. In these attacks, the attackers leverage containers as an entry point to discover and spread to other resources used within cloud accounts. The attackers deployed a clean Ubuntu container, mounted the host file system, which enabled them to execute code on the host, then downloaded a cryptomining binary file, stole data, and scanned IP ranges of various cloud providers.

This attack is different than previous ones we investigated, because of the malware the attackers deployed, their use of a socks proxy, the evasion techniques they applied, and the actions they took to scan and expand to instances running in the cloud.

The Anatomy of the Evolved Attack Vector

Before they could launch the attack, the attackers identified hosts with a public Docker Engine API port, and then executed the following command:

The command binds the file system of the host to the container and executes the payload – a bash script named alduro.

While delivering the main attack payload, additional files were downloaded from numerous public file sharing websites and executed.

The attackers downloaded a packed binary file used as a backdoor for the attackers. The file was downloaded from http[:]//205.185.113.35/files/lifxvf. VirusTotal identifies this file as a malicious file:

There are several important factors to notice:

• Researching the file using IDA reveals similarities to the behavior described in several blog posts, for example:
  – Playing PING-PONG with the C&C server
  – The process name was manipulated using the syscall prctl(PR_SET_NAME) to appear legitimate. The fabricated name is /usr/sbin/dropbear which is actually an SSH server and client software.
• The blog posts we have seen were published as early as 2014. It appears that the attackers didn’t create the malware from scratch and used a template that they modified with added capabilities.
• At the time of the attack the C&C server was down.

The infected host connected through a socket to a C&C on port 81. After the connection was established, the targeted host waited for further commands from the C&C server.

Following are the commands and capabilities that we identified:

Take a look at the different Possible Commands the binary can process

Examples to some parts of the attack chain:

• Deploying a container with the Docker Engine API
• Downloading and executing the malicious file
• Downloading the cryptomining file and configuration file
• Writing the cronjobs as persistence technique Sesa.txt script periodically runs and disables applications and security mechanisms that cloud have disclosed and compromised the attack
• Removing threats and security mechanisms

The cryptominer configuration file

Applying Evasion Techniques

Here we can see an evolution of the attacks, as we notice several evasion techniques which were not in use in early attacks. One of them is the use of a socks proxy that was used as a tunneling method between the attacker to the host’s internal network.

This tunneling method allows the attackers to do the following:

• Access the organization’s applications, databases and websites that are blocked from outside the network
• Mask Inbound and outbound traffic in the network to appear legitimate when querying and performing actions on other hosts in the network

One of the evasion techniques that was used attempted to remove a directory /usr/sandfly-filescan which is a utility that scans files entropy.

Entropy in files is the measurement of randomness in the files’ data. Compressed or encrypted files will usually have higher entropy values. All the binary executables downloaded in this attack chain are packed with a “UPX packer”, meaning that they have high entropy.

Discovery and Lateral Movement

This stage of the attack supports our claims that the new generation of attacks, such as the one we’re discussing, targets not only a single host, but attempts to continue and spread inside the target’s network.

To spread inside the network, additional packages and binaries were downloaded and executed in the following order:

1 – An open source banner grabber binary executable that extracted as much information about the network as possible, identify weaknesses, and spread throughout the network. The executable scanned the network, ran DNS lookups, and generated device modeling and vulnerabilities assessment reports.

2 – The executable installed the following packages:

• Masscan – an IP addresses scanner.
• Jq – a package for handling structured data.
• Screen – a package used for running tasks in the background.

Text files containing IP address ranges of public cloud providers such as Amazon AWS, Google Cloud Platform and Microsoft Azure were downloaded. Next, the Masscan utility scans these IP address ranges to check if the current host can access misconfigured machines on other public cloud platforms. If successful, the code ran on the open Docker engine API socket, to spread the attack to as many hosts as possible.

3 – The attackers gathered IP addresses, SSH keys, host names, and user account details from various files such as “bash_history” and “.ssh/config”. Next, the attackers attempted to connect and continue the attack using the information that was gathered by attempting to spread by SSH with the gathered credentials.

At this stage the crypto mining image is running on the host, and the attackers can now manually connect to the host and retrieve more information and credentials.

To sum it all up

As we can see from our analysis, this attack is an example to the evolution and maturity that attacks can get to. Scanning and penetrating deep inside the network, even all the way to the public cloud accounts, thus putting an organization at greater risks.

To show just how closely this attack follows the MITRE attack matrix, we summarized the attack components in the following table, mapping each component of the attack with the corresponding MITRE matrix: