The latest research discovered a campaign against cloud environments which is still under development.

This evolving campaign is consistent with an aggressive cloud worm designed to deploy on exposed JupyterLab and Docker APIs to deploy Tsunami malware, cloud credentials hijack, and resource hijack.

Aqua Nautilus researchers discovered this campaign when their Honeyspot with misconfigured Docker API got attacked and shared their report.

As it is still in the developmental phase and is presumed to be the notorious  Team TNT which is known for attacking cloud-based resources.

Attacks Against Cloud Infrastructures

Initially, the attacker identifies a misconfigured server (either Docker API or JupyterLab) and deploys a container or engages with the Command Line Interface (CLI) to scan for and identify additional victims. 

This process is designed to spread the malware to an increasing number of servers. The secondary payload of this attack includes a crypto miner and a backdoor, the latter employing the Tsunami malware as its weapon of choice.

• shanidmk/jltest2 (updated: June 8, 2023): Its purpose is to detect exposed Jupyter Lab instances.
• shanidmk/jltest (updated: June 8, 2023): This image is used to compile Zgrab using the make command.
• shanidmk/sysapp (updated: May 25, 2023): This one seeks out and attacks exposed Docker Daemon instances.
• shanidmk/blob (updated: June 24, 2023): This container image is an updated version of sysapp and is intended to find exposed Docker Daemon instances. It releases a cryptominer and includes the Tsunami malware, which acts as a backdoor.

This container image comprises three layers, one layer includes a run.sh shell script designed to initiate when the container starts up.

Initially it downloads some packages to secure the necessary utilities for the environments. 

In addition to that the ZGrab application is built and relocated to the /bin library,which enables the attacker to perform banner grabbing. 

This function will later assist the attacker in identifying Jupyter Lab and Docker API.

Subsequently, the masscan tool scans and pipes the IP to be utilized by ZGrab for assessing whether there is an exposed Jupyter Lab instance operating at ‘http://Currently_found_IP_Address:8888/lab’.

The resulting information is organized and stored in the JupyterLab.txt file, which is then transmitted to the attacker’s C2 server through a specific command.    

Finally, according to the report shared, it activates the loop set to run whenever the C2 server returns an IP range for scanning. 

The first octet of the IP address is determined by the result of a curl command to the attacker’s C2 server, which subsequently scans a CIDR range of /8, equating to approximately 16.7 million IP addresses.

It’s important to note that the HTTP_SOURCE environment variable was initially set by the attacker at the start of the container.

Through the use of NGROK, the attacker is able to conceal the infrastructure, thereby minimizing the risk of it being shut down.

Prevention

1. Ensure you’re not running JupyterLab without authentication, specifically make sure the token flag when running JupyterLab is not left empty.  
2. Verify that your Docker API isn’t exposed to the world and set to accept requests from 0.0.0.0.
3. Properly configure Docker daemons and cloud instances and  Regularly update and patch Docker and cloud platforms to address any vulnerabilities.
4. Apply the principle of least privilege to limit the permissions and capabilities of containers, Docker daemons, and cloud instances.
5. Scan the images that you use, making sure you are familiar with them and their use, using minimal privileges such as avoiding root user and privileged mode. 
6. Investigate logs, mostly around user actions, look for any anomalous actions.

“AI-based email security measures Protect your business From Email Threats!” – Request a Free Demo.