Hackers Turned Golang into a Malware Tool

H

Hackers Turned Golang into a Malware Tool: BotenaGo, written in Google’s Golang, can exploit more than 30 vulnerabilities. We deep dive into its behavior and how you can defend against the malware.

Discovered by AT&T Alien Labs, the BotenaGo malware exposes over 30 exploits in routers and IoT devices that rely on Google’s open-source coding language, Go.

These exploits allow a remote attack against over 100 types of devices through a command and control server over ports 19412 and 31412 or a related module. Although the threat actor is unknown, the malware has proven effective and has infected a large number of devices.

So how do Hackers Turned Golang into a Malware Tool BotenaGo work and should IoT users be concerned about their device security? Let’s find out.

GoLang: The New Favourite Tool of Cyber-Criminals

Go (also known as GoLang) is a programming language that was created by Google and has seen wide adoption in the security community through organizations like 1Password and Gravwell. The problem is that malicious actors have also seen the value in coding language.

With a 2,000% increase in malware written in Go since 2019, Google has enabled a number of adversaries to easily create malicious scripts that are easily adaptable to affect different operating systems.

Some (in)famous examples of threat actors using Go include:

• A suspected Russian-backed malware gang using a Go version of Zebrocy, first observed in 2015 (although not running via Go)
• The malware team behind WellMess used Go to create a RAT that has both Windows and Linux version
• IPStorm, malware that was originally written for Windows but has now been adapted for Linux

As Go is designed to be adaptable and all code is contained within packages, WellMess and IPStorm are two examples of malware that are now causing some Linux users to panic.

Because of this adaptability, this makes Go the perfect language for affecting a large number of systems with only minor changes to the code overall. For a threat actor wanting to cause large-scale disruption, it’s the hand grenade in their cyber-criminal arsenal.

Hackers Turned Golang into a Malware Tool_BotenaGo: How Does It Work?

Despite BotenaGo being a fairly well-designed piece of malware, it is still not entirely clear how it works. That might sound strange, but I’m not talking about obfuscation or especially complex code – I’m saying that it’s not entirely clear how or even if BotenaGo was able to communicate with the malicious servers that feed it.

In essence, we understand how BotenaGo behaves when it has infected a system, how it creates backdoors in a system, and how it could receive orders from the C&C. What isn’t clear is how the payload is transmitted to the infected system, partly due to the fact that all associated payloads (that have been found in the BotenaGo code so far) have been shut down.

But that’s not to say we don’t understand this piece of malware, simply that some unusual design choices aren’t exactly clear to us yet. With that, let’s look at what we already know about the malware known as BotenaGo.

Hackers Turned Golang into a Malware Tool: Post-Infection Behaviour

After the initial infection, BotenaGo does three things to ensure that the malware successfully installs itself on a compromised device. Loosely speaking, they comprise of

• Check that the device is compatible with the malware

• Report back to the attacker about the successful installation

• Map the exploits contained within the malware to any that are contained within the system

1. Before BotenaGo can start to run the exploits and build backdoors on the system, it must make sure that it is actually compatible with the device in question! The malware runs a scan to find a dlrs folder on the infected systems. If it can’t find it, the malware stops working there and exits.

2. If successful, the malware initializes global infection counters to show successful infection. These then appear to the hacker on the remote end showing that BotenaGo has been successfully loaded.

BotenaGo loader output

At this point, the malware is installed on the system, but it hasn’t run anything yet. In order to do that, BotenaGo needs to build a map of known exploits that can be applied.

3. Here’s where the trouble really starts – using a simple piece of code that accounts for a large number of exploits (shown in the CVE table at the bottom of this article), BotenaGo creates a list of exploits that are relevant to the infected device. BotenaGo maps the functions to a string that links to a targeted system, such as CMS Web Viewer or other obscure firmware types that are less human-readable.

Mapping attack functions to targeted systems

And so the hunt begins…

At this point, the malware has installed itself and identified targets. As you can expect, this is where BotenaGo launches its exploits.

Its Exploits

This next stage is a surprisingly simple piece of coding that kicks off a chain reaction. Through a simple GET request, BotenaGo queries the target and matches the data against the signatures gathered by the mapping attack.

At this point, BotenaGo is linking known exploit types to the infected device. In the example below, the main_infectFunctionGponFiber function has attempted to find out if the affected device is linked with Server: Boa/0.93.15.

Mapping the functions to relevant system strings

And here we meet Server: Boa/0.93.15

Server: Boa/0.93.15 is just one example of the servers that BotenaGo connects to in order to launch the exploit. To be clear, the malware isn’t contained on the server itself – this is simply how the malware identifies the infected device. These Servers support IoT devices and help them connect to the internet – BotenaGo exploits these links to find devices that are vulnerable.

In an effort to find out more about Boa/0.93.15, I searched for it on Shodan. In entering a search for the above-named server, I found that there were over 2 million affected devices all over the world including nearly 400,000 in America and almost 200,000 in Japan.

Shodan report on the number of devices linked to Boa/0.93.15

Here we can see the large number of devices that are linked to the Boa server.

But this isn’t the only server that BotenaGo checks, oh no. This is just one of many, meaning that within the malware’s code, there are instructions for identifying and targeting potentially millions of devices that are used every day.

Now we know that the device is ready to link to the Command & Control server.

Note: There is a full table of all affected vulnerabilities with CVE numbers below. Check for your device on the CVE website as the example affected devices list is not exhaustive.

Command & Control

Hackers Turned Golang into a Malware Tool: When the malware is deep in the system, it creates backdoors for the C&C system to exploit on ports 19412 and 31412. The former is actually more important to the malware – the information about the victim’s IP is received through 19412 and then starts feeding exploit functions (which were identified during the mapping stage) through the backdoor.

Netstat showing BotenaGo backdoors

As you can see, ports 19412 and 31412 are essential for BotenaGo.

Note that the malware is also adaptable enough to work around virtual machines, meaning that there is a great deal of complexity hidden inside this seemingly simple piece of malware.

Alien Labs found that the malware uses system IO input to receive a target from the C&C, circumventing the virtualized environment and attacking through a different vector. In that particular experiment, the command was received over telnet and allowed CL interaction that circumvented the virtual machine.

Dropping the Payload

Hackers Turned Golang into a Malware Tool: Depending on the infected device, the system will be connected to a variety of different servers. Sadly, the payloads that were stored on these servers and there is no evidence to explain exactly how BotenaGo worked, presumably in order to stop security and malware researchers from discovering more about the team behind the malware.

Although we don’t know for certain why BotenaGo doesn’t seem to be able to communicate back with the C&C server, here are some possible ideas for how the malware functioned despite its lack of obvious communication methods:

• It’s only a piece of the puzzle. BotenaGo is only one module of an attack suite, meaning that other modules communicate on behalf of the malware. This is an interesting idea, but as of yet, there has been no evidence of concurrent malware infections.
• Mirai is using the devices remotely. Because the attacks look similar to the modus operandi of Mirai, some experts suspect that the malware gang is usually similar tactics to their past exploits. This could possibly include remote access and control to the routers and IoT devices.
• It was an accident. Just like Tesla leaked the full self-driving beta software, maybe the BotenaGo team accidentally leaked the malware before it was ready to go. That’s not to say that this has all been a big misunderstanding, but rather that they weren’t ready to use it offensively.

It’s entirely possible that a couple of the above suggestions are true when taken together – for example, it’s plausible that the BotenaGo team did not intend to release this piece of malware yet as this code alone is not the entire malware suite. In essence, the leak saved countless IoT systems from being infected by additional malicious programs that would interact with the BotenaGo malware code.

Whatever the truth is, the patches that should protect affected systems are now in place. Good luck trying this trick again, whoever you are.

Am I Vulnerable to BotenaGo?

Thanks to AT&T Alien Labs, the vulnerable devices have had ample time to create patches for BotenaGo. That’s why you should follow the single best practice for malware avoidance:

Update all software on potentially vulnerable devices!

Keeping your devices up to date is the best way to defend against malware and vulnerabilities – the manufacturers should have released patches for known threats as soon as possible in order to stop infections and the spread of harmful malware.

But sometimes that isn’t enough and you need to do more in order to stop threat actors. For people that want to harden their defenses further than simply applying patches and updates, here are two easy best practices:

• Cut off exposure to the internet to all IoT devices and Linux servers, preferably with the use of a firewall; this practice will limit the attack vector that the adversary can target, stopping infections before they can even reach your systems
• Using a traffic monitoring tool to scan for unusual traffic, strange bandwidth usage, and any activity over affected ports; using a tool like Wireshark can help you find suspicious activity so that you can identify new ways to stop that traffic from leaving your system.

When you’ve followed these three simple rules, your system will be safe and hardened against the threat of BotenaGo. Remember, IoT devices are infamously prone to weak security standards – the number of IoT devices you use should be carefully managed and given limited exposure to the internet and the rest of your network.

Otherwise, you’re asking for trouble from malware gangs like Mirai and others who can create potent threats like BotenaGo.

Below you will find a non-exhaustive list of the devices that are affected by the BotenaGo malware. Please visit the CVE website to find more affected devices in order to ensure that you are protected in the event of a potential infection.

Vulnerability	Example Affected Devices
CVE-2020-8515	DrayTek Vigor2960 1.3.1_Beta
CVE-2015-2051	D-Link DIR-645 Wired/Wireless Router Rev. Ax with firmware 1.04b12
CVE-2016-1555	Netgear WN604 before 3.3.3
CVE-2017-6077	NETGEAR DGN2200 devices
CVE-2016-6277	NETGEAR R6250 before 1.0.4.6.Beta
CVE-2018-10561	GPON home routers
CVE-2018-10562	GPON home routers
CVE-2013-3307	Linksys X3000 1.0.03 build 001
CVE-2020-9377	D-Link DIR-610
CVE-2016-11021	D-Link DCS-930L devices before 2.12
CVE-2018-10088	XiongMai uc-httpd 1.0.0
CVE-2020-10173	Comtrend VR-3033 DE11-416SSG-C01_R02.A2pvI042j1.d26m
CVE-2013-5223	D-Link DSL-2760U Gateway
CVE-2020-8958	Guangzhou 1GE ONU V2801RW 1.9.1-181203 through 2.9.0-181024
CVE-2019-19824	TOTOLINK Realtek SDK based routers
CVE-2020-10987	Tenda AC15 AC1900 version 15.03.05.19
CVE-2020-9054	Multiple ZyXEL network-attached storage (NAS) devices running firmware version 5.2
CVE-2017-18368	ZyXEL P660HN-T1A v1 TCLinux Fw $7.3.15.0 v001
CVE-2014-2321	ZTE F460 and F660 cable modems
CVE-2017-6334	NETGEAR DGN2200 devices