Could REvil have a copycat?

Dave Bittner: 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, solving some of the hard problems of protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us.

Larry Cashdollar: We were notified by one of our customers. They were seeing an attack that had a specific message in the attack traffic, which drew their attention. 

Dave Bittner: That's Larry Cashdollar. He's a principal security intelligence response engineer at Akamai Technologies. The research we're discussing today is titled "REvil Resurgence? Or a Copycat?" 

Larry Cashdollar: And they asked us, sir, to investigate. So I hopped on a call with them, and we were looking at the attack traffic, and it's not stuff that we normally see. You know, typically the type of attack traffic we see is just more - it's not so specific. But the requests were - had a specific message, which is kind of uncommon. And the message was part of the path in the GET request for HTP (ph). So we thought that was kind of unique and interesting, so we investigated further. And that's pretty much how we ended up writing up this blog post. 

Dave Bittner: Yeah. Well, let's walk through it together. Can you give us some of the details about the attack, itself? 

Larry Cashdollar: Sure. The attack was originating from a widely distributed IP ranges. So these IP addresses were in U.S. territory. They were in Argentina, Brazil, the U.K., Russia, Iran. They were just really widely distributed across the globe. And initially, you know, we thought it's likely going to be either infected IoT devices or proxy servers. And upon investigating further, we noticed that these IP addresses were MikroTik routers - a lot of the - which was part of the Meris botnet. A few - what was it? - months ago, I believe, that the Meris botnet was utilizing MikroTik routers to proxy attack traffic through. Thinking of this, you know, we thought, perhaps, it was someone utilizing part of the Meris botnet, but we couldn't really prove that. If somebody was either borrowing a part of it or just reusing the devices that Meris had used, it was unclear to us, you know, during the investigation. 

Larry Cashdollar: The attack, itself, was pretty simple. It was a GET request. And as I had mentioned earlier, the path in the GET request had a specific message for our customer to comply with a certain demand, and then provide some bitcoin in order for the attack to stop. The attack itself wasn't very sophisticated. They were using some cache-busting techniques where the query string in the GET request was, like, an eight randomized character string. And that's, you know, that's something where, when a web server or a caching web server sees the request, it thinks it's unique, and it doesn't try and pull it from cache. It tries to pull it from the origin directly, increasing load on the origin server and bypassing, you know, any load balancing or caching systems. So, you know, it wasn't a supersophisticated attack, yet it wasn't a very sophisticated attack. It was sort of low-level and with basic just attack techniques. 

Larry Cashdollar: We noticed that the User-Agent string was also the same. It was the same User-Agent string across all IP addresses that were attacking the system. So that was another interesting tidbit that we noticed that it was unique in that fashion, too. Usually, they use different User-Agent strings and things like that, so... 

Dave Bittner: REvil is not generally known for DDoS attacks. I mean, they're kind of famous for being a ransomware-as-a-service organization. So did that throw into question the plausibility of this being from them? 

Larry Cashdollar: We kind of question that because we don't know if they were attempting to pivot into a different monetization method because typically, you know, as you mention, they use ransomware. They're the ransomware as a service, and there is no ransomware present in this attack. So we're not sure if they're trying a new model of making money or if there's actually someone in - a copycat attacker who is attempting to piggyback on their notoriety. You know, folks are aware of REvil and they've been in the news and, you know, this adversary could be attempting to use their publicity to threaten and intimidate the target. So we're not exactly sure which one it is, but it's definitely something of interest. 

Dave Bittner: Kind of a Dread Pirate Roberts situation, where the... 

Larry Cashdollar: Exactly. 

Dave Bittner: ...The name is (laughter) - the name is important, right? 

Larry Cashdollar: Right. 

Dave Bittner: What about the messaging that you said was in the headers themselves? I mean, the specificity of that - that strikes me as being interesting in itself. 

Larry Cashdollar: Yes, it was - the message was asking for compliance against a specific court order. And it had something to do with a government court order, and it was very political, which isn't like anything we've seen from REvil before. So it was something that was not - it didn't seem like it was something that would be in their wheelhouse. So again, we weren't sure if somebody was just attempting to use their notoriety to get their message across or get their demands no matter what. So it was still unclear. 

Dave Bittner: What about the DDoSing itself? I mean, what level of traffic are we talking about here? 

Larry Cashdollar: We saw at peak, it was about 15,000 requests per second, which isn't super high. It's not insignificant, but it's, you know - the Meris botnet was producing way more traffic than that. So this didn't seem like it was a full-bore capability of the Meris botnet. This seemed like it was either somebody building on top of the vulnerable devices or, you know, as I had mentioned earlier, were using part of a botnet that they might have either purchased or possibly got permission to use. We're not exactly sure, but it didn't - it wasn't a big amount of attack traffic. 

Dave Bittner: Well, how long did it last, and what sort of things did your customer do to parry against it? 

Larry Cashdollar: The attack lasted about an hour, and then there was a small burst of traffic after that attack that was less significant than the first attack. And then the attack disappeared. And we didn't see any more traffic after that. The customers, our systems, the rate controls are handling it. So it - because of the initial burst, our systems were able to just ignore the attack traffic, and the customer was able to say, hey, what's going on? Why are we seeing this? And, you know, they were able to further pivot and fix their - or shore up their defenses in case another more intense attack occurred. 

Dave Bittner: Where do we stand right now when it comes to being able to do that sort of thing, to defend against these sorts of DDoS attacks? Is it becoming almost routine to be able to have this - not really have a great effect on organizations if they're properly prepared? 

Larry Cashdollar: Yes. You know, if organizations can prepare for this type of attack in advance, then they likely won't even notice the attack traffic. Unless they're checking their web traffic logs and things like that, you know, they probably won't even notice. So it's always a good idea to try and shore up your defenses before you find out that you, you know, should have shored them up, and then you get an attack and then suddenly your origin server's down or your backend databases crash because of so many connections to your website. 

Dave Bittner: So what are your recommendations for organizations then to properly prepare themselves against the possibility of this sort of thing? 

Larry Cashdollar: I would definitely look at having your - if your website - if you think you might be a target or you expect to be, you know, handling a lot of traffic, then look at, you know, content delivery networks such as Akamai or definitely have load balancing, traffic filtering, things like that. You know, if you're only expecting inbound traffic on Port 80 and 443 for web traffic, then why would you allow UDP traffic on Port 53 for DNS on your network? You know, it's making sure that your systems are locked down and, you know, the traffic that you're expecting is allowed in, and anything unknown or is odd is automatically blocked by your defense system. 

Dave Bittner: Our thanks to Larry Cashdollar from Akamai for joining us. The research is titled "REvil Resurgence? Or a Copycat?" We'll have a link in the show notes. 

Dave Bittner: The CyberWire podcast 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 Rachel Gelfand, Liz Irvin, Elliott Peltzman, Tre Hester, Brandon Karpf, Eliana White, Puru Prakash, Justin Sabie, Tim Nodar, Joe Carrigan, Carole Theriault, Ben Yelin, Nick Veliky, Gina Johnson, Bennett Moe, Chris Russell, John Petrik, Jennifer Eiben, Rick Howard, Peter Kilpe, and I'm Dave Bittner. Thanks for listening. We'll see you back here next week.