Silentbob: A New Campaign by Team TNT Attacking Cloud Environments
The infrastructure of many organizations has included cloud computing in recent years due to its multiple advantages in terms of scalability, flexibility, and cost-effectiveness. However, as cloud services are used more often, bad actors have begun paying to observe and are continuously coming up with new ways to attack vulnerabilities in cloud systems.
Background:
Security analysts at Aqua Security have issued a warning that the TeamTNT group may be planning a new, extensive anti-cloud operation dubbed “Silent Bob.” Cybercriminal group TeamTNT is well-known for carrying out fatal attacks against cloud computing platforms,+ particularly Docker and Kubernetes deployments. The group focuses on cryptocurrency mining. Aqua Security connected the new campaign to TeamTNT despite TeamTNT ceasing operations at the end of 2021 due to the usage of Tsunami malware, the dAPIpwn function, and a C2 server that responds in German.Attack Details
First, the attacker locates a server that is improperly configured (either through the Docker API or JupyterLab), then either launches a container or uses the Command Line Interface (CLI) to hunt for and locate more victims. The goal of this operation is to spread the malware to more servers. A crypto miner and a backdoor, the latter of which uses the Tsunami virus as its weapon of choice, are included in the attack’s secondary payload.
Relationships among the attacks (Source: Aquasec)
- 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 crypto miner and includes the Tsunami malware, which acts as a backdoor.
shanidmk/jltest2
Three layers make up this container image, one of which has a run.sh script. When the container starts up, the shell script is supposed to run. In order to obtain the required utilities for the environments, it initially downloads a few packages. The ZGrab program is also created and moved to the /bin library, allowing the attacker to perform banner grabbing. Later on, this technique will let the attacker recognize Jupyter Lab and Docker API. The masscan tool then scans and pipes the IP to be used by ZGrab to determine whether there is an exposed Jupyter Lab instance running at ‘http://Currently_found_IP_Address:8888/lab’. The generated data is organized and saved in the JupyterLab.txt file before being sent through a particular command to the attacker’s C2 server.
Curl command used to send the IPs of the exposed Jupyter Lab instances to the C2 server
Last but not least, it starts the loop program to execute each time the C2 server delivers an IP range for scanning. The outcome of a curl call to the attacker’s C2 server, which scans a CIDR range of /8, or around 16.7 million IP addresses, yields the first octet of the IP address. It’s crucial to remember that the attacker first set the HTTP_SOURCE environment variable when the container first started. The attacker can minimize the danger of the infrastructure being shut down by using NGROK to disguise the infrastructure.shanidmk/jltest
It looks to be an older version of the container image used in the attack, as its name would imply. It appears that the attacker created this image using a zgrab binary pre-compiled and customized to the needs of this campaign. This demonstrates a high level of technical proficiency and experience on the part of the attacker, enabling them to modify the binary to their specifications.shanidmk/sysapp
There are six layers in this container image. Parts of the base image, the fundamental filesystem, and different utilities are covered by three layers. One layer contains the ELF system, which VirusTotal categorizes as a cryptominer. The run.sh shell script, which is intended to start as soon as the container starts, is located in another layer, while ZGrab is housed in a different one. This container uses the host filesystem, network, and ‘echo’ command to run a base64 script which allows the attacker to collect AWS keys and secrets by routinely scanning the environment for them.shanidmk/blob
There are seven layers in this container image. The base image and necessary utilities are stored on the first four layers. According to VirusTotal’s classification, the Tsunami malware is hidden between two layers. The shell script docker_entrypoint.sh, which is planned to run when the container begins, is kept in the final layer. The primary function, dAPIpwn, chooses a file name at random and starts a scan. It makes use of the proxychains3 program, which is created to make every TCP connection a client must go via a proxy (or proxy chain).Prevention and safety measures
- Ensure sure you are not running JupyterLab without authentication; in particular, ensure sure the token flag is not left empty when launching JupyterLab.
- Docker daemons and cloud instances should be securely configured and hardened, therefore be sure of this. Implement safe configurations, such as using strong passwords, turning down unnecessary services, and restricting access to just reliable IP ranges or networks. To fix any vulnerabilities, update and patch cloud platforms and Docker often.
- Limit the permissions and capabilities of containers, Docker daemons, and cloud instances by following the concept of least privilege.
- Use minimum rights, such as avoiding root user and privileged mode, to scan the images you use and make sure you are familiar with them and how to utilize them.
SOC Detection
As we navigate the complex landscape of cybersecurity, our Security Operation Center (SOC) employs strategic practices tailored to detect and counter threats such as the alleged operation ‘Silent Bob’ by TeamTNT. Here is an outline of our proactive measures:- Robust anomaly detection systems are operational, designed to flag abnormal behaviors, such as unusual network traffic or suspicious system calls, which may indicate the presence of malware or backdoor.
- Vigilant monitoring of both ingress and egress network traffic is conducted to identify any abnormal activities at the earliest.
- Comprehensive analysis of system and application logs forms an integral part of our detection strategy, aimed at spotting suspicious activities promptly.
- File integrity monitoring tools are utilized to keep track of unexpected changes to system files, a potential sign of system compromise.
- To keep abreast of the evolving threat landscape, threat intelligence platforms are leveraged, providing up-to-date information on the latest threats and vulnerabilities.
- Container-specific monitoring tools for Docker and Kubernetes environments are implemented, aiding the detection of unusual activities, such as unexpected processes, network connections, or unauthorized container launch.
- Monitoring of known Indicators of Compromise (IoC), such as malicious IP addresses, domains, and hashes of malware, is carried out regularly.
- Activities within cloud service accounts are thoroughly scrutinized for any signs of irregularities that could indicate a potential breach.
- In addition, we employ proactive threat hunting practices to search for early signs of potential attacks, guided by known Tactics, Techniques, and Procedures (TTPs) of threat groups like TeamTNT.