Aqua Nautilus researchers discovered a new variant of Gafgyt botnet. This campaign is targeting machines with weak SSH passwords, executing 2 binaries from memory to increase the Gafgyt botnet and mine crypto currency with GPU power, indicating that the IoT botnet is targeting more robust servers running on cloud native environments. In this blog we explain about the campaign, the techniques used and how to detect and protect your environments.
Previously on Gafgyt
Gafgyt, also known as Bashlite or Lizkebab, is a botnet malware that targets Internet of Things (IoT) devices. It emerged around 2014 and primarily exploits weak or default credentials to gain control of devices such as routers, cameras, and DVRs. Once infected, these devices become part of a botnet used to launch distributed denial-of-service (DDoS) attacks, overwhelming targets with massive amounts of traffic. Gafgyt spreads by scanning for vulnerable devices and has seen various iterations and enhancements over the years. Its source code has been leaked, leading to numerous variants and adaptations, further complicating cybersecurity efforts.
Attack Flow
In this attack we see a successful brute force attempt on our SSH honeypot which is configured with a very weak password. The attacking server (a part of the botnet) executes some shell commands via the SSH connection and transfers the main payloads. Next, a crypto mining attack is executed, and the honeypot becomes a part of the botnet, scanning the internet, seeking to detect a weakly configured SSH user and password and initiate similar attack.
Figure 1: Gafgyt attack flow
Initial Access
The initial access is gained by brute forcing to an internet connected SSH with weak password. Once access is gained a few commands to inspect and prepare the server are executed and 2 payloads are passed via the newly established SSH connection.
System Discovery
A few checks are conducted mainly to determine if the machine has already been infected by this variant of Gafgyt and to check if another malware is running and if so to kill it.
Establishing if the malware is running:
Figure 2: Checking if the malware is already running
Killing competition:
Figure 3: Killing competing malware
Next the two binaries are executed in memory.
Executing the cryptominer:
Figure 4: Executing the XMRIG cryptominer
Executing the worm:
Figure 5: Executing Gafgyt malware
Configuration alteration:
Figure 6: Modifying configurations
/etc/sysctl.conf is a configuration file in Unix-like operating systems used to modify kernel parameters at runtime. It allows system administrators to tune system performance, enhance security, and customize kernel behavior. The file specifies parameters in the format parameter = value, such as enabling IP forwarding (net.ipv4.ip_forward = 1) or reducing the tendency to swap (vm.swappiness = 10). Changes are applied using the command sudo sysctl -p. This file is essential for optimizing system performance and security, enabling dynamic adjustments to various kernel settings like networking, memory management, and filesystem behavior.
Lastly history and logs files are deleted to evade detection.
History deletion:
Figure 7: History deletion
ld-musl-x86 and systemd-net analysis
During runtime there were two ELF files dropped to memory (/dev/shm). The first one is ld-musl-x86 (MD5: ee929477b6144874974b1dc0b77e57a1) it is detected in Virus Total (VT) as Gafgyt SSH scanner, and the second one is systemd-net (MD5: b5b96a1bec4829501b85e6fe1c5044f5) and it is detected in VT as an XMR cryptominer.
The names of these binaries indicate that the threat actors are putting emphasis on defense evasion as these names are masquerading as legitimate components related to the Linux operating system environment.
ld-musl-x86 refers to the dynamic linker for the musl libc implementation on the x86 architecture. The reference to musl is interesting as it is lightweight, fast, and simple implementation of the standard library for Linux-based operating systems, often available in alpine for instance. Musl is usually present in embedded systems or containers, this supports the broad view that Gafgyt is targeting IoTs but also our understanding that this variant of Gafgyt is also targeting cloud native environments.
systemd-net is likely referring to components related to network management within the systemd suite of system and service managers for Linux operating systems.
This ELF binary ld-musl-x86 is a Go-compiled executable. It contains various functionalities based on the Gafgyt source code including generating IP addresses and ports, scanning the internet for exposed SSH and Telnet services, conducting brute force, inspecting the findings and initiating infection.
In the inspection phase the malware is using various checks to establish that this is a real server with the service running probably to avoid infecting low interaction honeypots.
The function backgroundlogic in the malware is set to download from the threat actor’s server (at 107.189.5.210) the file 1.txt, which is a brute force configuration file containing 179 sets of users and passwords.
Figure 8: C2 IP address hard coded in Gafgyt
An analysis of this list may shed a brighter light on the targets of this botnet.
Figure 9: Downloading an updated credentials list for brute force
While historically Gafgyt variants target IoT devices, in this case our classification of the users shows another objective. In the general purpose you can see usernames such as admin, app, ftp and others which can fall under any purpose to target Linux systems.
Under the gaming classification you can observe usernames such as counterstrike or minecraft.
Under IoTs you can see nvidia, raspberrypi and others.
In the cloud native category, we observe Hadoop, AWS, Azure, Ansible, devops and many other usernames which indicate that this botnet is putting cloud native environments in sight.
Figure 10: Distribution of targets as appears in the credentials list (pie chart)
In the binary there’s a telnet function that deploys this:
Figure 11: Old dead IP in the Gafgyt binary
While this IP address is inactive at the moment. A short search in our honeypots database and over the internet reveals that this was used in the past as part of the Gafgyt campaign.
This is the sora.sh script:
Figure 12: The sora.sh script content
The fact that the IP address is inactive may strengthen the code and impact the repurposing of this Gafgyt variant.
The cryptominer in use is XMRIG, a Monero cryptocurrency miner. As illustrated in Figure 4 above, the execution code of the miner includes the flags --cuda and --opencl. IoT devices are generally characterized by their low power consumption, modest computational power, and capability to operate with limited memory and storage. However, in this case, the threat actor is seeking to run a cryptominer using the --opencl and --cuda flags, which leverage GPU and Nvidia GPU computational power. This, combined with the fact that the threat actor’s primary impact is cryptomining rather than DDoS attacks, supports our claim that this variant differs from previous ones. It is aimed at targeting cloud-native environments with strong CPU and GPU capabilities.
Potential Exposure in the Wild
Shodan, the search engine for Internet-connected devices, was utilized to identify servers with exposed SSH. By querying Shodan for publicly accessible SSH, we uncovered more than 30 million internet connected instances. This highlights the critical need for securing your server against brute force attacks and potential exploitation, when using these network protocols.
Figure 13: Shodan data for exposed SSH
Detection and Remediation with Aqua’s CNAPP
In this blog we covered an attack against a server with an exposed to the internet port using SSH protocol. Utilizing SSH protocol to manage remote servers is extremely popular and adopted by many organizations and individuals. While best practice suggests using RSA keys many still use user and password to protect the access to the server.
In this case, we show a possible scenario of a misconfiguration, namely a weak username and password that were easily guessed by the attacker. Our honeypot had Utilized Aqua’s advanced Runtime Protection solution to detect malicious and suspicious behavior in runtime.
In Figure 14 below, you can observe how Aqua Runtime Protection detected the attack in real time and alerted on the intrusion.
Figure 14: Aqua’s platform, runtime detection for this attack
As you can see above, there were 7 alerts, indicating Fileless execution and cryptomining execution. On the right pane you can see that the binary ld-musl-x86 was executed in the path /dev/shm, namely from memory. The low number of alerts, illustrate the precision of Aqua’s runtime logic, as it is set to invoke in the events of a real attack based on behavioral analysis of millions of attacks that were caught in Aqua’s honeypots and thoroughly analyzed by the Nautilus.
In case you wish to further understand what happened before the fileless execution and which events are linked to this execution and relevant, you can press the timeline button and observe the relevant history, related to this alert. In this case, we can see that the binary was dropped to the container during runtime.
Figure 15: Aqua’s platform, incident timeline breakdown
Lastly as you can see in Figure 16 below, Aqua Runtime Protection also generates audit logs. In this case, your SOC analysts or IR teams wish to further investigate the intrusion. Mind that in this attack there were over 96,000 audit logs, that can be filtered based on numerous filters such as container name, container ID, MITRE Technique, Enforce group, Cloudfoundry organization and many more. Enabling to isolate the malicious events and focus on the investigation.
Figure 16: Audit log indicate of events in the container level, during the Gafgyt attack
