BendyBear: difficult to detect and downloader of malicious payloads.

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.

Jen Miller-Osborn: So, at a very high level, it is one of the most sophisticated, well-engineered, and difficult-to-detect samples of shellcode that we've seen employed by an APT.

Dave Bittner: That's Jen Miller-Osborn. She's Deputy Director of Threat Intelligence at Palo Alto Networks' Unit 42. The research we're discussing today is titled, "BendyBear: Novel Chinese Shellcode Linked With Cyber Espionage Group BlackTech."

Jen Miller-Osborn: It's also an upgraded variant of WaterBear, which was for 32-bit systems, and this one is designed for modern 64-bit systems. So it shows as well that there's developers behind this that are consistently updating this as operating systems and things like that progress. One of the final notes that makes this unique and somewhat challenge – definitely challenging, is that the shellcode exists only in-memory, and it can load additional payloads directly into memory and not on disk, which is another component of making it very difficult to detect.

Dave Bittner: Well, let's go through some of the capabilities together, here. I mean, what is it able to do?

Jen Miller-Osborn: So, in terms of capability, what it can do on a system, it's limited to downloading other payloads. So, in that perspective, it's not particularly interesting. What is interesting is the way it does both its communications and the way its polymorphic code ensures that its runtime state varies every time it launches. So that makes it very difficult to detect because typically things and patterns that you would signature on, you can't, because every time this is launching, it is looking different. Every time it pings for a C2 domain, it will clear the host cache – the host DNS cache – so it forces it to resolve every time, which also can impede investigation because there's no cache logs showing that that domain was looked for. But it also implies that the attackers own those domains so they can change the IP they're resolving to if necessary, if for some reason one of them was being detected.

Jen Miller-Osborn: And then it also encrypts and decrypts function blocks while it's running only as needed, which is another way to avoid detection. And finally, it also looks for what would be static debugging kind of things before it runs. If it detects those, it won't run, because those are a classic sign that it's in an analysis environment. So, the author spent quite a bit of time ensuring that this would be incredibly difficult to detect within a network, but its only actual functionality outside of that is to download additional malicious payloads.

Dave Bittner: Hmm. So, how would someone find themselves with this on their system? What's the mechanism by which it installs itself?

Jen Miller-Osborn: We actually don't know. That's one of the things we noted in our research. It does require a loader, but we were not able to find a copy of that, what that is. So our analysts actually had to build a custom loader to get the shellcode to run.

Dave Bittner: So, once you find this on your system, can we walk through together what it does, how it reaches out to that C2 server?

Jen Miller-Osborn: Sure. So it does some level of time evasion, and that's, again, to avoid typical static or dynamic runtime analysis. Typically, most virtual environments, they only wait a set amount of time for a program to do something before determining whether it's malicious or not malicious, which makes sense because they're processing thousands or millions of files at volume, and they can't afford for any network to have a particular file sitting there for an hour, two hours, two weeks waiting for a file to do something. So, in this number of the more advanced things, we'll see a component where they'll just add that in, and this is the same way. They did a number of things to defeat that kind of runtime analysis where they would wait.

Jen Miller-Osborn: In addition, they hid their traffic into it within port 443 SSL traffic, and they were encrypting it. It wasn't SSL encrypted, but it was still encrypted, so it wouldn't necessarily throw any flags just from a casual kind of look. But then it did a number of things to authenticate between the malware itself and the C2 to confirm that it was talking to the correct family, if that makes sense. There were a number of encryption components when things were transmitted back-and-forth that were also used for the encryption, which makes it difficult to detect or break. They're calculating the session keys and challenges, but they're doing them per request. And then they're basing the encrypted chunk of the payload that's sent back on those – the challenge and the response. So it's confirming the two families are talking together, but it also means that you needed the session keys when they were created, really to be able to decrypt anything and detect it. So it's an easy – it's a good way of hiding traffic inside legitimate traffic and just kind of sneaking in under the radar, if you could say that. And then once it decrypts it, then it has whatever that malicious payload was.

Dave Bittner: And that payload goes right into memory, so it's not being written anywhere where it could be flagged there?

Jen Miller-Osborn: Yep. And it will also write itself, whatever it is, directly into memory.

Dave Bittner: I see.

Jen Miller-Osborn: It's a really well-done stage-zero downloader. It's very stealthy and it's very difficult to reverse engineer. The RE that worked on this has been doing this for quite a while and is very experienced, and he noted that this was one of the most complicated pieces of shellcode that he's ever looked at.

Dave Bittner: Wow. Now, there are some things that it's doing in terms of the encryption here, when it's sending – when data is being transferred, it's breaking it down into certain size blocks, and those blocks are each getting encrypted separately?

Jen Miller-Osborn: Mm-hmm. We've seen that with other malware where they do that in an attempt to make it more difficult to reassemble the actual payload so you can understand what it's doing. So they'll encrypt them in bytes and then move them around, essentially. So what you need to be able to do is you have to figure out what the routine was that they used to be able to reverse it. And in this case, they modified RC4, which made it just that much a little more difficult because it wasn't traditional RC4. And then they would do that, and then they would XOR the results as well. So it's an effective way of making it very difficult to reassemble, even for a researcher.

Dave Bittner: And do you have any sense for what sort of payloads are being delivered here? Has there been any follow-up on that?

Jen Miller-Osborn: Unfortunately, we were not able to find any of the follow-on malware associated with this. We would love to talk to someone if they have anything, so if anyone that's listening has anything else on it, please feel free to reach out. This appears to be a very sophisticated group that is well-resourced and technical. They understand what they're doing and they have developers. So it's definitely something that people should be concerned about if you are the type of organization that they would target.

Dave Bittner: And what sort of conclusions have you drawn in terms of who might be behind this and who they may be targeting?

Jen Miller-Osborn: So, all of the attribution or such attribution that's been published has tied this back to the Chinese government. The article that the Taiwanese Department of Justice published along with the C2 domains also gave that same attribution. And then the Cyber Command CNMF team actually retweeted us and kept in the tie to BlackTech, and it is generally – it is widely assessed that BlackTech is tied to the Chinese government. So, we can't say with one-hundred percent certainty, but there seems to be a lot of people in agreement on that.

Dave Bittner: Right, right. What are the recommendations in terms of protecting yourself against this? 

Jen Miller-Osborn: For this, if you are the kind of target they would go for – so, this group historically has focused a lot just in the East Asian region, specifically against government and industries like semiconductors, things like that, with a technical nature. I would talk to my – whoever your security provider is, I would have a conversation with them about whether or not you were able to detect this and what that looks like, because it's potentially an indicator of, if you find it in your environment and it's been there a while, you probably are going to have to start doing a more thorough investigation of what's going on. So I would recommend organizations confirm that they're protected from this.

Dave Bittner: And do you all have indication that the command-and-control servers are active right now, that this is an active campaign out there running?

Jen Miller-Osborn: That I would have to double check. I haven't – we haven't looked at the domains recently, but the last indication we had a few weeks ago, they were still active.

Dave Bittner: I see. OK. Well, the blog posts that you all put up here has a lot of the indicators of compromise and so on, so there's lots of information that folks can use to determine whether or not it's something they should be concerned about. Really interesting research here. Is there anything that I've missed, anything I haven't asked you that you think it's important to share?

Jen Miller-Osborn: Nope, I don't think so, just really want to highlight that this is a very stealthy and sophisticated piece of shellcode, so if you're a potential target, please ensure that you are protected from this.

Dave Bittner: Our thanks to Jen Miller-Osborn from Palo Alto Networks' Unit 42 for joining us. The research is titled, "BendyBear: Novel Chinese Shellcode Linked With Cyber Espionage Group BlackTech." We'll have a link in the show notes.

Dave Bittner: 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 are amazing. CyberWire team is Elliott Peltzman, Puru Prakash, Kelsea Bond, 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.