CyberWire Daily - Stealthy Zberp Banking Trojan. {Research Saturday]

Episode Date: December 9, 2017

Zberp is a stealthy banking trojan with an unconventional process injection technique. A hybrid of the ZeusVM and Carberp malware, Zberp uses a variety of techniques to prevent detection while it gathers information from infected systems.  Limor Kessem is an executive security advisor for IBM, and she's our guide. 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 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. Oh, it actually happened back in 2014. And maybe it's a good place to mention that IBM Security discovered it when it first emerged.

That's Lamor Kessum. She's an executive security advisor for IBM Security. What she's referring to is the ZBIRP Trojan, a stealthy banking Trojan. So we found it back in 2014, which was apparently a good vintage year for other Trojans like Drydix and Dire that emerged at that time as well. So Zeeburb has an interesting history. It's sort of a combination of a couple of things. Can you describe that for us?

You know, in the cybercrime arena, we've seen multiple times that codes were leaked and eventually reached the hands of the public, other developers, et cetera. You can sometimes find them on public resources online. So firstly, the Zeus code was leaked somewhere in 2012 and a lot of different malware stemmed from it. One of those malware codes was called Zeus VM. And that malware was called that way because it would create a virtual machine type thing on the endpoint. That was Zeus VM. Then there was Carburp, which is a completely other malware that eventually got leaked when its group that was operating it, some of them got arrested. And then you had these two different

codes in the wild and someone apparently picked them up and decided to make a hybrid and they took Zeus VM, they took Carburp and he took some of the best of each world and put them together. Take us through how does Zburp work? So Zburp is a banking trojan of its nature. It's almost like a Swiss army knife where it's modular. It can bring in different capabilities. It can do code injection. It can do web injections and other types of things in order to enable itself to commit financial fraud on online banking sites. This is the overall gist of it. overall gist of it. What we blogged about in terms of Z-Burb in one of the blogs that we did recently was how does it do code injection? Because it was more interesting and different.

Well, let's dive into that. Walk us through the code injection. Let's start with the big picture in the beginning and at the end. So in the beginning, I'll just say code injection is what malware does to grab hold of the endpoint and achieve persistence. It hides inside legitimate processes and it also lets it perform malicious activity ongoing with being undetected. So it's a very common malware tactic. So in general terms, malware will use it in order to run its own code inside the address space of another system process. So it's, of course, of that nature, it's one of the ways for security solutions to look for evil activity on the endpoints.

And it can flag that activity or block it and at least know about it. And it can be automated, the detection by certain rules and heuristics, because a lot of codes, just like Zeeburb did, copy from others. So it's even easier for security solutions to detect some of it. However, not every Black Hat developer can or wishes to reinvent the wheel in that sense. So when they don't, they reuse code, their malware will probably get detected more easily. And when they do, they make changes. protected more easily. And when they do, they make changes. So most of them will use the usual suspect. And the usual suspect is, you know, different API calls and things we're going to discuss in this podcast. And ZBIRP does use the usual suspect, but not for the entire process. It shuffles in some really interesting things. So if we're thinking about what are the usual suspects in malware, typically they will use APIs functions that one of them is called virtual unlock EX to allocate space and write process memory in order to kind of prepare room for the processes they're going to write into. These are two APIs which are used the most in code injection cases

because they let the malware write their stuff into a remote process and then run it. So it's like planting someone in a room inside somebody else's home and then having them do things for you. There's a third API in this specific method, which is called CRTT which is create remote thread and that's used to execute the payload so this is like giving it the command to run the malicious code another very popular tactic is process hollowing where the malware actually hollows

out the existing processes code from the memory space and it replaces it and overwrites it with its own malicious code so that's like replacing somebody in the home, like literally sticking them out and putting the bad stuff in. And these methods are heavily monitored by security solutions. So malware developers who don't want to get detected will try not to use them. But we do see them still in older codes that are being reused, etc. So it gives us some initial context here is why we would research and write a blog about the code injection of the Z-Berb Trojan.

After all, it's not new malware. And it's a hybrid of existing other older malware like Zuzvam Carberb. And they've been around for a while. So why did we think it was such a good idea to talk about in 2017? So there are two reasons. The obvious one is that the injection method is interesting, different, and it has not been studied very much. And also this malware has been around since 2014, but really keeping itself under the radar and using limited campaigns, making its detection even less likely, and its operators are trying not to attract very much attention from law enforcement, let's say, comparing to gangs like Drydex or Gozi and those kind of gangs. So at this point, we're saying, okay, ZBRP obviously doesn't use all the usual APIs.

So let's see what it does do in order to keep the malicious operations it does secret. So firstly, it did borrow quite a bit from the Carbop Trojans, like for their code injection. Those developers dispersed after a wave of cybercrime arrests that broke up their gang. They were not known to be a very quiet bunch. They were very involved in underground dealings, and eventually they got busted.

But their code was actually pretty good so Z burp as I said does use some of the usual stuff it's called as asynchronous procedure calls APC and they create remote thread API that's done in order to force another thread to execute their custom code by attaching it to the APCQ of the targeted thread. But it has additional tricks. And the additional tricks or overall idea is to do remote API hooking, which is one of the methods that malware would use in order to make certain functions run its code for it from a remote location so that it doesn't look like someone else is running the code. So Zeeburp remotely sets up a hook on a frequently used API. So it took a very, very

common API. In our case, it's called ZW close. This function is a generic routine that operates on any type of object. Its job is to close an object handle after all the handles associated with it are no longer needed. So it's very commonly used by the OS. It does not raise any special suspicion because it's used so much that if you try to zero in on it, it'll just be noise. So they chose that specific function. And they use it so that whenever this API is called from any thread in the targeted process, it's elected beforehand because it has to, in from any thread in the targeted process, it's selected

beforehand because it has to, in the previous, in the CRT phase, actually select which process it wants to go to and invade. And then what they do here is a detour. The hook detours the execution to the malware's shellcode function. In other words, when it's trying to call it, instead of the actual API responding, there is shellcode that's going to get involved here. The shellcode is going to create a new local thread within that ZW close process. And this just, you know, it sounds okay. Well, yeah, there's a shellcode is going to, you know, do some malicious stuff. Sounds simple,

but it's actually not that easy to implement because it can cause conflict in the way the operating system works. And if it does that, then the malware is going to get detected. There's going to be all kinds of trouble. So doing this kind of a detour can mean that two different threads, the malware threads and the original thread, are both working at the same time to modify the hook on the same function. And it can cause a crash, which will terminate the malware's ability to deploy and also draw suspicion because malware doesn't want the user to go looking for what's wrong or go clean up their machine. Right. So to avoid this problem, the malware actually has to implement a thread safety locking mechanism that allows only one thread at a time to modify the code,

where all the other threads are forced to sleep, to stop working for a suspended amount of time. And only after it completes whatever it's doing there, which is called a patching, by the first thread, then all the other threads are finally going to be allowed to resume executing the original ZW close function. So only after it's done, ZBIRP will set the lock flag back to two so that the sleeping threads can wake up and resume execution of that API after it's already been tampered with. Another thing they deal with here is access rights. So this is another part where it's not so simple to do this because memory pages of the code section in the system dynamic link libraries, the DLLs, they have a certain access rights. And in this case, they have page execute read rights. But here the malware wants to do more than just read, right? It wants to

modify, it wants to delete, overwrite, whatever it's doing. So they have to adjust the access rights before ever attempting anything. Because if they don't do that, there's going to be a rights violation that will be raised. And again, there could be a crash and the whole thing of, you know, getting detected or somebody going to go clean their machine and check what's going on. Right. or somebody going to go clean their machine and check what's going on. Right. So the developer solved that.

He found a way around it. Firstly, it shows different functions for the procedure to take place. It begins by calculating the size of another DLL, a very major DLL in the system. It's called NTDLL, and calling the API functions create file mapping and map view of file and giving them the rights that are page execute read write. So they don't only read, they can also write stuff. And from the names of these APIs, create file mapping,

you know they're looking to map address space for what the malware is going to do. And this step creates an empty file mapping with the size of NTDLL that will be mapped to the malware's processes memory space. This is called also a trampoline, which is a loop in the code where the developer can replace the initial part of a defined function code with their own malcode. And upon execution, the function jumps to a hook handler,

which explains that word choice. That's like a jump over. That's what's called a trampoline. So why did they make this choice? Well, actually, a lot of exploits like using NTDLL as a trampoline because it's an easy way for user mode processes to ask for services from the kernel. It's like a double agent type thing. And many processes, if not all, have to load NTDLL, which makes it more likely for the attacker, if they use this, that they will end up getting an address space that corresponds with their desired opcodes, what they want to achieve. They have more choice. So now that the trampoline is set and the file mapping is ready, the malware is ready to actually tamper with ZW close because they already did all the preparation stuff not to get crashed. And the first thing it does is suspends the target process

by calling anti-suspend process. Makes sense. Everything that's anti is more like on the user mode side. And it then uses read process memory to make a replica of a target's processes NTDLL into the file mapping in its own memory space. So before setting the hook itself, the malware needs to calculate two addresses. The address of ZW close in the file mapping. So it'll have the address that need to be patched. And it also needs the address of the shellcode function in the remote process. So it'll know the address that need to be patched. And it also needs the address of the shellcode function in the remote process. So it'll know where the hook should point to. So it says, okay, I'm going to replace stuff here. I need to know where it's coming from and where

it's going to. The next thing it does, it does a couple of technical things where it overwrites six bytes of the address of ZW close in the mapped NTDLL, sets the hook. The first byte is overwritten with the 86-bit assembly code push instruction. The next four bytes are the address of the shellcode function in the remote process. And the last byte is the 86-bit return instruction. So the shellcode address will be pushed onto the stack, and the return instruction will return to it as if it were a return address of a function. So it kind of manipulates things in order to make sure that the hook does everything that they want to do.

There's a final step here to this process. It's called a dynamic DLL replacement. And it's probably the most significant part of this whole runaround of how they use these APIs. After they prepare everything and the rights and all the memory space and everything, the remote hook can be now placed. In other words, making a remote process run the malware.

But since the remote process was previously suspended, the malware has to call other functions. One of them is called anti-unmap view of section with the address of anti-DLL in the remote process, and then anti-map view of section to reactivate it, to map the patched anti-DLL instead. And that replaces it and sets a hook on the ZW close that we started with. Soon as the hook is set, the malware calls what's called flush instruction cache API. It's very self-explanatory. Flush instruction. In other words, clean the cache, make sure the code changes take place,

and then it calls anti-resume process to continue the normal process execution. So, you know, go ahead and run the code. There are a couple other safety nets here. One of those is a memory protection because obviously, you know, the operating system wants to prevent a process from accessing memory that has not been allocated to it. It's not supposed to do that. Right. But this is exactly what the malware wants to do. So it needs to do a couple of things. Zebra manages to bypass that issue. And since the patch was set in the file mapping and anti-map view of section was called with read and write access rights, then they replaced NTDLL already has the extra permissions to do whatever it likes.

And that eliminates the need to adjust permissions for the memory. They just can use virtual protect EX API and they don't have to use it actually because they already have allocated the proper rights. The final idea is creating a local thread to the entry point of the malware's copied module. So then the computer, the OS is just going to run the malware. How successful is ZBURP at evading detection? It could be successful with a lot of security solutions that base detection on static rules and if they're not looking for those specific APIs, because a lot of times they'll catch most of the APIs. And if they're not looking for these specific ways, then it's probably going to be missed. Combined with the way that the campaigns are not very large and not attracting

a lot of attention, it could be that a lot of security solutions just don't care enough about it in order to create special cases for it. You said at the outset that a good bit of this code is borrowed, sourced from other places, but they made their own modifications. Do you have any sense for the sophistication of these folks who put this together, comparing the types of things they did on their own versus what they borrowed, how skilled they actually are? So I think that overall, they're pretty skilled to have taken two pretty sophisticated malware codes and breed them together. It's not an easy task. And especially working with the Carburp code. Carburp was always known to be pretty sophisticated. it has its own stuff that it kind of i'll call it invented you know it has these innovations that it had at the time called

the invisible persistence and um and it has this special uh hooking technique like overall you know the thing itself is already pretty um sophisticated so the person that developed Z burp didn't actually make a lot of changes at the end. He just made, he found the way to put it together, make it work and and I guess maintain the code. So there are no bugs and stuff, but he has not made substantial changes ever since probably because he didn't need to. I do think that whoever maintains this sort of code knows this stuff inside and out. And as you said, this is a banking Trojan. They're going after financial information. Right.

Banking Trojans are very powerful information stealers. Their job is to be spies on the endpoint. They're looking at communication to the internet. And essentially, they can do a lot of things. They can exfiltrate data from the endpoint. They can download other malware into the endpoint. Banking Trojans specifically are looking for ways to automate fraudulent transactions. So when somebody goes to their bank's website, if the malware targets that bank, it'll go into action and start making changes to the session the way the user is seeing it. And because the user is infected, they're going to see a completely different, you know, maybe a completely different

bank page or a different flow of the transaction. And all the while the malware is going to be stealing their access credentials and the operator is going to be stealing their access credentials, and the operator is going to try to initiate a transaction from their account to an account that they control, to a mule account. So looking at the big picture with the information that you've gathered from ZBIRP, what are the takeaways for you? The takeaway here is actually pretty straightforward. Code injection and malware are two inseparable mates. They're always going to be code injection for malware. And since there's so much malware and so many different developers and researchers that work with malware, we're always going to see new and interesting techniques to

achieve the injection itself and also the stealthy motif there. So one of the most recent examples that has emerged not long ago this year actually called atom bombing and the method itself was discovered by researchers but not very long after it was adopted by one of the pretty much worst banking trojans out there called the dried extrojan so now it uses atom bombing in order to do its code injection and it completely renovated what it had before. Another recent example is EarthSniff or Gozi, third version of the smellware, which is a new iteration where we saw the developer took the injection mechanism and modified it in order to evade detection. So he took it, shuffled the elements to make it look different and basically probably evades detection in a lot of places that

don't know it yet. So there's always going to be another clever workaround and something new in the ejection method that we could study and thwart. And that's the sort of stuff that we look at ongoing in order to protect our customers from these evolving malware codes. There's always going to be something that you have to keep on top of. Yeah, it's an endless game of cat and mouse, I guess. In a sense, this kind of stuff, yes, because attackers are also looking constantly at how to break things, how to go around them, how to stay under the radar. And in a sense, when it comes to malware, it's hard to kind of say, okay, how can you whack it on the head once

and for all? It's a little tricky. Our thanks to Lamore Kessum for joining us. You can read the full report, Diving into ZBIRP's Unconventional Process Injection Technique, on the IBM X-Force Research website, securityintelligence.com. Thank you. 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 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, Thanks for listening.