CyberWire Daily - HinataBot focuses on DDoS attack. [Research Saturday]

Episode Date: April 29, 2023

This week our guests are, Larry Cashdollar, Chad Seaman and Allen West from Akamai Technologies, and they are discussing their research on "Uncovering HinataBot: A Deep Dive into a Go-Based Threat." The team discovered a new Go-based, DDoS-focused botnet. They found it was named after the popular anime show "Naruto," they are calling it "HinataBot" In the research it says "HinataBot was seen being distributed during the first three months of 2023 and is actively being updated by the authors/operators." Akamai was able to get a deep look into the malware works by using a combination of reverse engineering the malware and imitating the command and control (C2) server. The research can be found here: Uncovering HinataBot: A Deep Dive into a Go-Based Threat Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. data products platform comes in. With Domo, you can channel AI and data into innovative uses that deliver measurable impact. Secure AI agents connect, prepare, and automate your data workflows, helping you gain insights, receive alerts, and act with ease through guided apps tailored to your role. Data is hard. Domo is easy. Learn more at ai.domo.com. That's ai.domo.com. Hello, everyone, and welcome to the CyberWire's Research Saturday. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down the threats and vulnerabilities,

solving some of the hard problems of protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. Yeah, so we were looking through our honeypot logs, specifically for results for a certain vulnerability in YarnHadoop. And Larry was talking about how Go binaries are so much bigger than all the other ones that we're seeing. And so I started filtering by megabytes, and then we found some pretty interesting samples.

That's Alan West. The research we're discussing today comes from Akamai and is titled Uncovering Hinatabat, a deep dive into a Go-based threat. Joining us are Larry Cashdaller, Chad Seaman, and Alan West. Chad Seaman, and Alan West. Well, let's go through it together here. I mean, what exactly is going on under the hood here? What are we talking about?

Chad, do you want to take us through this? We haven't heard from you yet. So, yeah, HanadaBot comes in through a couple of known CVEs and one Hadoop misconfiguration. A lot of people stick Hadoop out there, Hadoop Yarn, and they leave it exposed to the internet, probably due to an oversight. And through this mechanism, they can achieve code execution. So it's spreading through those three primary mechanisms that we found also through SSH brute forcing. From there, the malware, once it gets a foothold, it phones home to a C2. A big part of this research was actually, since the C2 was down at the time of discovery, was reverse engineering the command and control protocol so we could actually cause the binary to stage

attacks against a controlled victim and see what that traffic looked like. It has two primary attacks. There's a UDP attack and an HTTP attack at this point. There's been some historical attacks that we've seen in previous samples that have been removed, but we're not really sure. And its primary goal is to push either volumetric UDP or Layer 7 HTTP and HTTPS attacks. Do you have any sense of the history behind this or where it may have come from or been influenced by? Yeah, so in looking back through the logs, the IP that we found distributing these samples originally, which also turned out to be the command and control IP, we looked back and sort of used that as a pivot and saw that it had for a while been distributing a bunch of different Mirai variants for a while.

It was about a month at the beginning of the year. And then about halfway through the month, we started seeing them distributing the Kanata bot. About halfway through the month, we started seeing them distributing the Hanatabot. And when we looked up the historical DNS resolve of the IP as well, we also saw that it was Mirai lovers or HiHi Mirai lovers for a little bit there. So we definitely could see some influence from Mirai. And obviously now they're trying to make their own thing. And who are they targeting here? Who are they trying to infect? Who's the primary victim here? So there's targeting in two senses. One sense, we have no visibility as of yet. Because the C2 was down at the time of the discovery, we haven't been able to see them launch attacks and figure out what their primary motive is as far as victimization goes.

From the exploit stuff, it looks like they're targeting low-hanging fruit, to be honest. There's nothing novel or new about the infection vectors that we saw them using. The Huawei exploit is old and well-known. We've seen it used to spread Mirai and Gafget and other samples that are competing in this space. The SSH brute forcing was a primary tenant of Mirai spreading back in the day. It was Telnet and SSH brute forcing campaigns that really got a foothold for that one before they moved into some of these other RCE variants or exploits. So I think at this stage, it's just they're victimizing low-hanging fruit in general. And I wouldn't be surprised to see them continue down that path because it's easy.

The problem is that it's also a very competitive landscape. So it's hard to really get a foothold there. also a very competitive landscape. So it's hard to really get a foothold there. In the article, we allude to, we hope that they stay on this path. And without trying to give them any ideas or credit, we would not like to see them be more successful than they are, put it that way. So if they continue for low-hanging fruit where there's a lot of competition, So if they continue for low-hanging fruit where there's a lot of competition, that's good news for everyone. Larry, I'm curious. They're using the Go language here.

What is the appeal of that? It strikes me that we're seeing more and more attention there. I think because Go is portable and it's fast, I think a lot of malware authors are sort of gravitating towards it. You know, you have the ability to cross-compile it to other architectures. And we saw an Autobot had a lot of compiled binaries for many different architectures. Ones that I was surprised, I think there was some binaries for Solaris. I think we saw some Solaris SonOS binaries in there. So I thought that was pretty wild. But it's also static, statically compiled. So it won't need any libraries or anything linked to it because the binary is a ball of everything it needs.

So you can just stick it on a machine and it should run. So I think that's the other appeal. And I think Go is an up-and-coming language, and I think a lot of developers are also gravitating towards it. So the Malol authors will follow in turn. And as you mentioned, I mean, does all those things lead to it having a larger file size? You know, typically with an IoT binary that's been compiled for MIPS or ARM, and it's written in C, they're dynamically linked. They're between, I'd say, 40 and 200 kilobytes. A Golang malware binary is usually between like 4 and like 30 megabytes.

And that's because it's so self-contained? No, I think it's also in part because of how the Golang binaries work. As far as it being able to be deployed in multiple places, the Go binary typically generates a five meg or more binary because I believe it ships the interpreter inside of the Golang binary itself, which is in part why it's so much easier for cross compilation to function because they really need to compile to underpinnings for OS. to underpinnings for OS, but then the core code that the author would be writing is operating through that Golang level

where it's more abstracted against the various OSs and platforms that they're compiling for. Just for my own understanding here, and please pardon my ignorance, but is this similar to, like on macOS, you hear about fat binaries

where something's been compiled, for example, for both Intel and the M-series chips. Is it that sort of thing where it has everything it needs regardless of where it's deployed? No, they still compile into platform-specific packs, but I think each one of those platform-specific packs, but I think each one of those platform-specific packs ships a Go interpreter or some kind of bytecode

that will take the Golang and operate it on that platform, if it makes sense. Each one of them is large because each one of them is shipping an architecture-specific interpreter or environment for Go to execute it. Part of what you all cover here

is the process you all went through to map out the C2 communications. Can you take us through that process? As far as the reversing of the protocol was concerned, we kind of started with not really knowing what the binary or how to speak with it. Because of the sample that we had and it not being stripped, we did have some hints about what the function names were. So we knew that at some level, there's an HTTP flood capability. At some level there's a UDP flood capability.

And the problem became, okay, so in the code, how do we get to where those functions are going to be executed? So it became a process of basically patching the binary. So the C2 that was down, we overwrote the location of that C2 to an IP that we can control. From there, we spun up a socket and started communicating into that binary when it would phone home to us thinking that we were the C2. At that stage, it's really just kind of trying to navigate and see where you land in the binary at what stage, and then figuring out, you know, at this point in code, we're either going to go left or right, you know, we're going to venture into different parts of the code based on what input we're providing it. And then it's just kind of mapping that out. So at this point, it's expecting a hex 30 or a hex 31, which translates to the ASCII character for a 0 or a 1.

And if we go 0, it goes this way. If we go 1, it goes this way. And if it's neither, it goes this way. So we'll want to end up on this side, and we can kind of map out that once we get down that fork of the code, and we can kind of map out that once we get down that fork of the code, ultimately we get to the UDP or the HTTP flood, and then it starts mapping out, okay, so how many args are we expecting to be passed into that function? What arg in position one, where is it going to end up in the final payload? Is it going to become the IP address that we're attacking?

Is it going to become a packet length directive? Is it going to trigger some other fork of code that we're not familiar with yet? So it's really just a pretty feedback loopish experience. I'll put it that way. And now, a message from our sponsor, Zscaler, the leader in cloud security. Enterprises have spent billions of dollars on firewalls and VPNs, yet breaches continue to rise by an 18% year-over-year increase in ransomware attacks and a $75 million record payout in 2024. These traditional security tools expand your attack surface with public-facing IPs that are exploited by bad actors more easily than ever with AI tools. It's time to rethink your security.

Zscaler Zero Trust plus AI stops attackers by hiding your attack surface, making apps and IPs invisible, eliminating lateral movement, connecting users only to specific apps, not the entire network, continuously verifying every request based on identity and context, simplifying security management with AI-powered automation, and detecting threats using AI to analyze over 500 billion daily transactions. Hackers can't attack what they can't see.

Protect your organization with Zscaler Zero Trust and AI. Learn more at zscaler.com slash security. And what did that reveal as you went down that pathway? How were things uncovered for you? Did it get easier as you went along? It was a little more frustrating than I think any of us would like to admit. Fair enough. Yeah.

So, you know, because when you see the final product, it's such a simple and fairly straightforward protocol that it becomes frustrating that it was such a pain to kind of map it out. what was the prefix that we needed to pass in order to get to where we would even start processing the command arguments. Before that, there was a handshake and it expected certain things to be responded to from itself and from the C2 to send back a certain response before it would even go into the attacking functions and start checking for the

next stage of payloads. So I won't say it was easy. It wasn't insanely difficult, but it was just a lot of back and forth and tinkering to figure out like, okay, we got here and now what? What happens here? And sometimes it it was why did this crash because that was one of the things is as we started to add more parameters you know you start out and you're just thinking like okay we'll put we'll put a numbered argument or something we can identify in memory in each one of these different offsets as we go into that binary to try and map out where it's going to land in memory. Is it going to be passed?

These were x64. So what register is it going to end up in? Going back into Golang's own function documentation and looking at Golang internals to figure out what is this function going to be called and what parameters are expected into this library function. So there was just a lot of back and forth with that before we finally got it done. I think all in all, I don't remember how many days. It took at least a couple to a few days to get everything mapped out before we felt confident that we had all the fields mapped and could control everything we wanted to control.

I'm curious, Alan, can you give us some insights? What is that collaborative process like for you and your colleagues there? Are you tossing things back and forth? Are you asking each other questions? Are you documenting things along the way? What is the process that you all use? Sure. Yeah. So originally, one of us finds a sample and we start tearing it apart by ourselves and we find something that's particularly interesting about it. Maybe I'll message Larry and I'll be like, hey, is this normal to you? Like, have you seen anything like this? And then, you know, spin up a document, start documenting as you go so you don't have to remember everything you did a week ago in detail just basically overtaking notes and then um as you get stuck phone a friend and then everybody working on their own side will um you're kind of in a meeting talking together and somebody has a breakthrough you tell everybody else and you just keep going that way until uh until you're fried for the day

yeah i'll i'll get stuck and i'll be like all right i'm gonna see what chad thinks then chad will be like what are you guys looking at and he's like oh you should try this and then he'll fire up a a terminal and he'll start poking at it and then we'll sort of watch what he's doing and it's and then we'll sort of throw ideas around at each other. So it's definitely a major collaboration when we get something like this and one of us gets stuck or the other one gets stuck and we sort of just pass the ball around. Well, let's dig into the two attack types here. As you mentioned, there's HTTP flood and then also there's a UDP flood. Can you describe to us exactly what it's doing? Sure.

So like you said, there's two primary attack functions. There's a UDP flood and an HTTP flood. The UDP flood is pretty straightforward. In both cases, the attack functions spin up a pool of 512 worker threads. This is super easy to do in Golang. It's a pretty common technique for high performance, parallelized data processing, any kind of thing that's going to be quicker

if you do it in parallel, obviously. So it's no surprise to see that used here. It's cheap, it's fast, it's easy. and I don't know why you wouldn't do it. It's going to give you more throughput and more various workers. And the workers run through a loop. They have a duration. They're given a duration as part of the attack directive. And they basically check a timer. And for each iteration of their loop, they're checking that timer. And if the timer is older than the time that they expect to be done with the attack, then they exit.

is older than the time that they expect to be done with the attack, then they exit. Otherwise, they're going to just continue to shove a big fat null padded UDP packet through that socket. The other attack, the HTTP attack, same kind of deal. We get 512 workers, but it's actually using Golang's native HTTP client. So this is a very well-built client. I'll put it that way. It handles a lot of edge cases. It handles redirection, DNS resolving, a lot of stuff that we see less advanced bots kind of struggle with or not do properly. It has no problem. It can handle HTTP, HTTPS. no problem. It can handle HTTP, HTTPS. I believe it was hard-coded to HTTP 1.1 or 1.0. It did not do HTTP 2 by default. Supports a few different headers. Some of them are randomized. Some of them aren't. With the HTTPS support, it will get through a TLS or SSL handshake no problem. So it's a pretty thorough and functional HTTP attack platform for sure.

I was going to say, how does this compare to other botnet tools that you all have analyzed before? Do these folks seem to be up to the task? Do they know what they're doing? Yes and no. I mean, there's difficulties in operating with raw sockets in Golang in general. From a standpoint of like, I don't suspect we'll see a send flood come out of this. I'll put it that way. It's possible, but I doubt it just because of using truly raw sockets in Golang is a little bit more difficult. I would say that the two attacks that we see in there, the UDP flood and how it's tooled in the HTTP flood and how it's tooled are both pretty straightforward attacks to get wired up. And that's in part because Go is a

great language, in my opinion. It's pretty easy to get a UDP socket up and running and start sending data over it and receiving data from it. And same for the HTTP library. They didn't have to go down and start figuring out, okay, we've got our socket. Now we need to build our HTTP request. And now from that, we've got to do this. We've got our socket. Now we need to build our HTTP request. And now from that, we've got to do this. We've got to redirect. We need to follow it. The DNS resolution, all of that is handled because the underlying Golang libraries are solid. So I wouldn't say it's incredibly advanced. A lot of the underlying code that would empower this, you could probably find on GitHub or Stack Exchange with a handful of Googles,

and it's just a process of slapping it together, really. What are your recommendations, then, for organizations to best protect themselves against this? Let's start with infection. How do you prevent this from taking hold on your network? Yeah, most of all, the standard security procedures that you would recommend in general, like updating your applications and using strong passwords.

As we saw, brute-forcing SSH credentials, they were not complex credentials, the ones that we saw. They were like admin, admin kind of stuff. And then on top of that, these are very old CVEs that are being targeted or old misconfigurations that have been known for a long time. So yeah, just keeping up to date with the common vulnerabilities and updating your applications.

Larry, I'm curious with the C2 being down, I mean, is that a typical thing in the playbook here that it would not be active until it's needed? Or what does that generally indicate? It could indicate that the malware was up at one point and then the C2 was either found by someone, like it was on a network and somebody saw malicious traffic and they shut the C2 down, or it's possible that the actors shut down the C2 and moved it somewhere else or they're relocating their operations. We've seen it before where we get a malware sample and the C2 is offline.

I'm actually analyzing a piece of malware right now where the C2 is also down. And the malware that I'm looking at is only a few days old. So I'm, I'm assuming that the, the either starts, you know, started up the malware and then tested it and then shut the C2 down and managed to, to get a sample caught by us is, is my guess. But, started up the malware and then tested it and then shut the C2 down and managed to

get a sample caught by us is my guess, but it happens. Yeah, hard to know for sure. To ride on that as well, in the past we've seen other authors engaged in this kind of activity. And typically, and it's the same for this piece of malware, if the C2 is not up, the malware doesn't die. It just waits. And it's going to phone home every so many seconds if it can establish a successful connection. So what we've seen in the past is the authors will bring the C2 up, they'll let it sit for five or ten minutes and

make sure all the bots have phoned home. Once they have a pool of functional attackers, they'll issue their attack command and then they'll turn it back down. You know, it's kind of a decent technique, I'll say, because if you're a researcher and you're looking at it and you think the c2 is down you're less prone to look into that and also if if you have adversarial concerns from researchers or law enforcement or whatever appearing to to have gone away is a technique that you could debate the merits of it, I'll guess. Our thanks to Larry Cashdaller, Chad Seaman, and Alan West from Akamai for joining us. The research is titled

Uncovering Hinatabat, a deep dive into a Go-based threat. We'll have a link in the show notes. And now a message from Black Cloak. Did you know the easiest way for cyber criminals to bypass your company's defenses is by targeting your executives and their families at home? Black Cloak's award-winning digital executive protection platform secures their personal devices, home networks, and connected lives. Because when executives are compromised at home, your company is at risk. In fact, over one-third of new members discover they've already been breached. Protect your executives and their families 24-7,

365, with Black Cloak. Learn more at blackcloak.io. The Cyber Wire Research Saturday podcast is a production of N2K Networks, proudly produced in Maryland out of the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technologies. This episode was produced by Liz Ervin and senior producer Jennifer Iben. Our mixer is Elliot Peltzman. Our executive editor is Peter Kilby, and I'm Dave Bittner. Thanks for listening.