TeamTNT didn’t waste any time getting up and running for 2021. In the beginning of January, for instance, TrendMicro spotted an attack campaign in which the threat group used shell scripts developed in Bash to perform malicious activities.
Those functions included searching for sensitive information like Docker API credentials, uploading that data to a command-and-control (C&C) server and downloading greyware tools for the purpose of scanning the network and mapping other vulnerable container APIs. Not long after that, AT&T Alien Labs witnessed the adversary group using a new tool called “libprocesshider” to hide the group’s malicious bot from process information programs, thereby helping it to evade detection.
Now it looks like TeamTNT is adding a new malware strain called “Hildegard” to its arsenal for specifically going after organizations’ Kubernetes environments.
According to Threatpost, an attack involving Hildegard begins when TeamTNT gains initial access via a misconfigured kubelet. This Kubernetes component functions as the primary “node agent” that runs on each node. It’s capable of registering each node with the Kubernetes API server, an element which facilitates communication between all elements of a cluster.
The issue is whether requests to the kubelet’s HTTPS endpoint are allowed to be unauthenticated. Many managed Kubernetes services do not allow this to be the case. But standard Kubernetes deployments do by default, per the platform’s documentation. It’s through these so-called “anonymous requests” that TeamTNT’s attackers gained access to the kubelet’s run command API and began executing commands on running containers.
Specifically, TeamTNT used those commands to create a tmate reverse shell. (The username of the tmate account was “Hildegard,” hence the name for the malware.) That reverse shell helped the attackers to drop Peirates and BOtB, two tools which enabled them to move laterally to other containers and to access cloud resources for the purpose of launching a Monero-mining attack at the hands of XMRig malware.
Evaluating Hildegard’s Evasion Techniques
Over the course of the attack, Hildegard employed several different techniques in order to evade detection. First, the malware hid its IRC agent built with the open-source ziggystartux project by encrypting the ELF and packing it in a binary called “ziggy.” Upon execution, the ziggy binary used a hardcoded Advanced Encryption Standard (AES) key to decrypt the ziggystartux ELF and execute it in memory. This execution flow helped to shield the ELF from detection by automated static analysis tools.
Speaking of the IRC process, Hildegard named it “bioset” after the established Linux kernel process. This tactic helped to further disguise the malicious process by making it appear as if it were a legitimate process.
Third, the malware hijacked the dynamic linker used to load libraries. Specifically, it modified the /etc/ld.so.preload file to intercept shared libraries’ imported functions and to overwrite two of those functions responsible for returning directory entries of the file system. Those modifications caused the /proc function to omit queries with keywords pertaining to the attack such as “tmate,” “xmrig” and “ziggy,” thereby rendering Linux process information programs incapable of using individual processes to detect the malware’s presence.
Finally, Hildegard modified the system DNS resolvers to avoid detection by DNS monitoring tools, deleted all scripts immediately after it used them and cleared the shell log in every script via “history -c.”
Where that Leaves Organizations
Hildegard represents the first time that security researchers observed TeamTNT specifically targeting Kubernetes environments. The attackers registered their C&C domain for the malware on December 24, 2020, updated some of their malicious scripts and brought their IRC server online in early January.
Even so, they still needed to finish Hildegard’s codebase and infrastructure at the time of analysis, which could indicate that the threat was still in the reconnaissance and weaponization stage and not yet activating its cryptojacking features.
This possibility doesn’t leave organizations with any time to waste. Indeed, it highlights the importance of organizations working to correctly configuring their kubelets. Otherwise, they could leave themselves open to attack.
As StackRox put it in a blog post:
The kubelet is the main “node agent” running on each node. Misconfiguring kubelet can expose you to a host of security…. You can either use arguments on the running kubelet executable or a kubelet config file to set the configuration of your kubelet.
Admins can specifically defend against Hildegard by running the command “ps -ef | grep kubelet” on each node and then specifically checking that the output for --anonymous-auth argument is false. Recall that TeamTNT initially gained access by using anonymous requests to gain access to the kubelet and then execute malicious commands. By running the command above, admins will disallow anonymous requests and thereby prevent malicious actors like TeamTNT from misusing the kubelet to engage in malicious activities.
That’s just one of the ways by which admins can harden the security of their organization’s Kubernetes environment. For more recommendations, click here.
About the Author: David Bisson is an information security writer and security junkie. He’s a contributing editor to IBM’s Security Intelligence, Tripwire’s The State of Security Blog, and a contributing writer to Bora. He also regularly produces written content for Zix and a number of other companies in the digital security space.