CyberWire Daily - WireX BotNet with Justin Paine from Cloudflare. [Research Saturday]

Episode Date: October 21, 2017

In August 2017, multiple Content Delivery Networks (CDNs) and content providers were subject to significant attacks from a botnet dubbed WireX. (The botnet is named for an anagram for one of the delimiter strings in its command and control protocol.) The WireX botnet is primarily made up of Android devices running malicious applications and is designed to create DDoS traffic. The botnet is sometimes associated with ransom notes to targets. Justin Paine is Head of Trust and Safety at Cloudflare, and he joins us to share the WireX story.  https://blog.cloudflare.com/the-wirex-botnet/   Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. of you, I was concerned about my data being sold by data brokers. So I decided to try Delete.me. I have to say, Delete.me is a game changer. Within days of signing up, they started removing my personal information from hundreds of data brokers. I finally have peace of mind knowing my data privacy is protected. Delete.me's team does all the work for you with detailed reports so you know exactly what's been done. Take control of your data and keep your private life Thank you. JoinDeleteMe.com slash N2K and use promo code N2K at checkout. The only way to get 20% off is to go to JoinDeleteMe.com slash N2K and enter code N2K at checkout. That's JoinDeleteMe.com slash N2K, code N2K. 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 threats and vulnerabilities and solving some of the hard problems of protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. 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. We initially noticed this particular botnet when we observed the particular user agent string that was being used as part of this attack. That's Justin Payne. He's the head of trust and safety at Cloudflare. The botnet he's describing is called WireX. And what in particular caught our attention, because we see attacks roughly every three minutes, every day, all day. But this particular botnet was different in that we were seeing this user agent string,

which is not usually something that would be so consistent. It was always 26 characters. It was always seemingly random, although there was some patterns in it, in that it was always alpha characters, but 26 characters every single time. And so that draws your attention. What happens next? Initially, quite frankly, we initially didn't look into it all that much because the attacks were relatively low volume at the time. And this was relatively early on as the bot was starting to grow. But we had heard from some of our friends and other folks who work in the industry at

Akamai that they were seeing similar attacks against their customers. And the attacks that they were seeing against some of their customers were significantly larger and definitely causing some impact in some cases. and definitely causing some impact in some cases. So that certainly made us more interested. And I think the assumption is the person was probably using the botnet to target those customers at that time and hadn't quite turned it against our customers fully yet. So the notion is that when it first came on your radar that perhaps they were just testing it out? that they weren't taking down sites as well as they thought they should be able to when they were spreading it between Cloudflare and Akamai customers.

It looks like they may have then increased the size of the botnet in addition to kind of focusing it on a target versus dispersing it against a handful of targets. I see. So take us through some of the details. How exactly does this botnet work? So the botnet has consisted of the details, how exactly does this botnet work? So the botnet has consisted of Android devices, and that could be almost largely cell phones, but it also could be potentially tablets or other devices that run the Android operating system

that would download one of these infected APK applications. And that is typically going to be through the Google Play Store. However, there are a variety of these third-party websites out there that essentially all they do is clone the Google Play Store. So they'll have the same applications, roughly the same type of design. And you can search for applications in their third-party store versus Google's first-party store. And in both cases, those APKs from this particular developer, and he had multiple accounts, but it seems to be likely one developer, those APKs were malicious in that they included this additional code that could be activated based on commands sent from the command and control server to either launch attacks against website owners or to do other things like click fraud, which is less flashy and impactful, but still obviously

malicious in nature and does cause financial harm. So is this a case where the malicious code is sort of being grafted onto an existing app, or were these apps being spun up for the purpose of carrying this malicious code? That's a great question. As best as we've been able to gather, it does not appear that these applications were compromised in some way. It doesn't seem like they were a legitimate application, which then maybe the developer had their account compromised or something like that. This definitely does appear to be

purely intentionally malicious in that they wrote these applications and used icons in the various app stores to impersonate legitimate applications. And sometimes the names were sort of similar. They weren't that close because I think they wanted to avoid attention of the legitimate app owner. So you're not going to make an app that looks just like YouTube, that has a name like YouTube, because that's going to be easily found and disabled. But they would use an icon that would look like the official YouTube app, for example. But the name would be significantly different.

But, yeah, the app would be intentionally designed in such a way that the command and control server would be called out to from the infected device. And depending on what that command and control server sent, it would take particular actions, whether it's attack a website or conduct this click fraud process. And to the users, the people who have installed these malicious apps, would they notice anything going on on their device or was it happening all in the background? Most of it was in the background. So the possible side effects that someone infected may have noticed would have been their battery life may have significantly drained. The device itself may have actually become warm to the touch because it was the processor and everything else on the phone

was working pretty hard to push out this traffic as part of the DDoS attacks. And if they were on a cell network, while the bandwidth wasn't really the core of how the attacks were working, it is possible that they may have been seeing significant spikes in bandwidth on their cell plan bill when they received it at the end of the month, for example. But this particular type of botnet wasn't focused on bandwidth exhaustion. It was more application level resource exhaustion. And so what were the types of attacks that you saw being implemented by this particular botnet? The Wirex botnet launched volumetric DDoS application layer attacks. And what that means is

they're not trying to exhaust the bandwidth to whoever it is they're trying to attack. So they're not trying to fill up the pipes with so much bandwidth consumption that you can't get to whoever the victim website is. Instead, what they try and do is each one of these infected devices looks like a legitimate real web browser with a real human behind it. So the way that the botnet was implemented on the Android device, the browser that was accessing this website repeatedly had all the functionality of a real browser. It had JavaScript functionality.

It had local storage. It had cookie handling. It had everything that looked like a real user. And it would repeatedly access particular resources on a given website to try and just eat up CPU on the server. And it did this in a number of ways. So not only did it access particular parts of a website that may be resource-intensive, like a search page,

where it needs to go search a database and retrieve a result and then display it. That takes a lot of resources on the server side. If you're doing that thousands of times a second, that may take down the server or significantly slow it. In addition, they also used HTTPS. So it wasn't a standard HTTP plain text request to the server each time. These were largely encrypted HTTPS connections that would further use additional resources on the server side of things as well. So each one of those packets has to be handled by the server and

decrypted and do all the normal, the handshake that happens as part of a HTTPS request. What does it seem like they were up to? Was there a ransom component to this? We did see a handful of cases, and this was specifically on Akamai's side of things. They saw a handful of cases where a ransom email was sent to some of the organizations that were being attacked. Although it seemed it wasn't, like most of the websites that were attacked didn't receive a ransom email. And the email that some of these folks did receive, it wasn't sent to a standard functional email address. Like it wasn't sent to admin at or knock at or anything like that, where most of these ransom complaints that we do see from these ransom DDoS trends that have been going on lately, they use these functional email accounts,

whether it's support or knock or admin or things that are likely to exist. In these cases, they emailed what appeared to be relatively random email addresses at the places that they were attacking. So it seemed like maybe they were experimenting with this and haven't really fully decided to do it, or something potentially like that. So the distribution of the malware was significant. Yes. We don't have exact volume numbers in terms of how many downloads. Unfortunately, Google was actually too quick, which is a good thing to have.

That's a good problem. They very quickly, once notified, they very quickly began to take action and pull these applications out of the App Store, the Google Play Store. So we weren't able to grab download counts before we noticed that they were already disappearing because Google was doing a fantastic job. We know that the infected apps were in the Play Store for a little under a month, so roughly 30 days, and I would have to only guess at possible download counts, but we saw at peak 120,000 unique IPs that were participating in attacks.

So that doesn't necessarily mean 120,000 infected devices, though, because these were largely mobile devices. So the particularly unique challenge with a botnet that is comprised of mobile devices is some of them are on the cell network. And a mobile device is going to hop from cell tower to cell tower, and each time it does that, it's going to get a different IP address. And if it's participating in an attack, you're going to see one device potentially coming, using, depending on how far they travel, 5, 10, 20, 30 IPs.

So, you know, depending on how far they travel, 5, 10, 20, 30 IPs. So we saw around a maximum of 120,000 unique IPs, but it's really difficult to gauge how many unique devices are behind those IPs. Take us through the process of how you actually track down the software. When we began the process of, we had identified this was an interesting botnet. We had spoken with some folks at Akamai that identified a similar botnet. We started digging into the log files

that we had available of, what signatures does an attack from this botnet really show? And that led us to some particular traits of the attack. A single packet that would be sent from one of these devices that was infected would have a particular tell in it, which I can't unfortunately elaborate on. But there would be a particular tell from that request that would essentially say, hey, I got infected from here, which is really convenient because it basically said, this is the infected Android application that caused this phone, this device to participate in the attack, which once we discovered that,

everyone kind of had that light bulb moment of, is that really the application that may have, you know, led to this infection? And we did a bit of research and searching, and in most cases, the apps had already been pulled from the Google Play Store. But some of these third-party websites that duplicate a lot of the Google Play content still had several of them available and online and able to be downloaded. And that's where we, luckily, were able to grab one of the APKs that we believed to potentially be infected. And we decompiled that APK and were able to identify what appeared to be a call-out to some external domain,

which isn't necessarily malicious in nature, but based on the traits that we were seeing of this APK possibly being involved in a botnet, the assumption was that there was likely to be a command and control server of some sort. So this APK calling out to some external domain was a pretty good indicator that maybe we were on the right track. And that's where we did ultimately find the domain that was the command and control server for this particular botnet. And once we had identified that, we were able to just start querying different subdomains that were available for that domain to see what it might output. And ultimately we found one particular subdomain that when queried,

and this is, you just load it in your browser, you load it at the command line, something like that, it would return what domain should be attacked by the botnet on each request. So that gave us an inside view of, okay, who's currently being attacked by these devices, which was a pretty significant breakthrough for us in terms of, okay, now we know who's being attacked,

and if they happen to be an Akamai or a Cloudflare customer, we could very easily attribute that to this exact botnet versus potentially some other attack that may, purely by coincidence, happen to target that customer. Is the botnet still up and running? It is largely dismantled. And by that, I mean, there are still efforts. Law enforcement is engaged and is actively working on the case. And I can't elaborate on that point. But the vast majority of the functionality of this botnet has been neutralized. The Google Play Store has removed the apps that would cause the infection.

Most of the applications from these third-party websites have also, we've gone through the process of submitting effectively abuse reports and kind of complaints about those applications on those sites, and they've been largely taken down. And the command and control server that is hard-coded into any applications that may still be out there, so even if a device happens to be still infected, the command and control server itself is also dealt with at this point. So a device that may still be infected won't get any commands to launch an attack.

So it should be largely neutralized at this point. Is there anything you can share with us in terms of attribution of where it was coming from or who might be responsible? I wish I could say with confidence, you know, we knew who this was and where they were located. However, you know, that is remarkably difficult to say with any real confidence. So unfortunately, it would be a guess at most, and I'd rather not speculate. One of the points that you make in the report is the success in sharing information among many of the players, among those who sort of sorted this out.

Can you take us through that, how that was a real sort of force multiplier for you all? So most of the companies that were involved in this particular process, many of us are in the same industry. So Cloudflare and Akamai, we provide very similar types of application delivery platforms. Some of the other organizations who are involved, though, such as Flashpoint and RiskIQ, they don't directly have an obvious crossover in terms of where our companies live. But that being said, these are organizations who have been working together for quite some time to address significant events that impact the Internet.

And by that I mean these groups largely began to get together consistently when Mirai began to be a pretty significant problem middle of last year, middle to late of last year. And these companies at that time, you know, this was a significant problem that everyone saw. And it wasn't, you know, that's my network, that's or that's your network. That's not my problem. These were internet scale concerns that really drew together individuals from across company. And, you know, some of them may normally be competitors, but at the end of the day, you day, you're not going to be a competitor if the Internet's down. So we've largely become friends over time.

But many of these relationships initially began as it made the most sense to work together to try and pool resources, pool intelligence. of very smart employees, but also pooling information about the attacks we were seeing in a way that still strongly holds true to our commitment of privacy to our customers. But there's still ways you can share anonymized information that may ultimately still be useful, but doesn't necessarily impact the privacy of either company's customer base. Would a standard antivirus installation detect this? At the time that we were looking at these particular APK files, some of the antivirus vendors were identifying these particular APKs as being malicious. So there was certain indicators within the application code that these antivirus vendors

had a sense that something strange was going on. Most of them didn't pinpoint the specific DDoS attack functionality that were in the applications. specific DDoS attack functionality that were in the applications, they were largely identifying the click fraud related behavior that seemed to be kind of the initial purpose of these applications. In terms of general advice for people who want to protect their devices from inadvertently becoming part of a botnet, what kinds of things would you want to share? I would say it's a good rule of thumb to stick to only acquiring applications from the first party stores for your particular platform.

So the Google Play Store, if you're on some type of Android device, the Apple App Store, if you're on an iOS device, they have significant resources dedicated to scanning applications that get submitted to those app stores to ensure that they are reasonably safe. Sometimes things still do slip through the cracks, but they have far more resources dedicated to securing those platforms versus these third-party websites who appear to clone the legitimate app stores. However, there is no independent confirmation that the application you're downloading is really the application you think you're downloading. There's no fingerprint on the application that shows it hasn't been modified. So you really are taking a significant risk if you're downloading from a third-party

app store. Yeah, stay out of bad neighborhoods, right? Absolutely. You wouldn't take candy from a stranger. You shouldn't be taking third-party applications from a stranger either. Our thanks to Justin Payne from Cloudflare for joining us. You can find the research about the Wirexbotnet on Cloudflare's website. It's in their blog section. Cyber threats are evolving every second, and staying ahead is more than just a challenge.

It's a necessity. That's why we're thrilled to partner with ThreatLocker, a cybersecurity solution trusted by businesses worldwide. ThreatLocker is a full suite of solutions designed to give you total control, stopping unauthorized applications, securing sensitive data, and ensuring your organization runs smoothly and securely. Visit ThreatLocker.com today

to see how a default-deny approach can keep your company safe and compliant. The CyberWire Research Saturday is proudly produced in Maryland out of the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technologies. Our amazing CyberWire team is

Elliot Peltzman, Puru Prakash, Stefan Vaziri, Kelsey Bond, Tim Nodar, Joe Kerrigan, Carol Terrio, Ben Yellen,

Nick Valecki, Gina Johnson, Bennett Moe, Chris Russell, John Petrick, Jennifer Iben, Rick Howard, Peter Kilpie,

and I'm Dave Bittner. Thanks for listening.