Hackers Keep it Simple: Malware Evades Detection by Simply Copying a File
- New malware technique evades detection by simply copying a file
- We break it down step-by-step to show you how it works
- Innovative hackers continue to deliver sophisticated malware that evades detection
The Bromium Lab is back to break down a recent outbreak of sneaky malware, shared with us by some of our customers who caught this in their isolated micro-VMs.
For decades, malware has tried to avoid detection in increasingly cunning ways:
- First, files became polymorphic so that simply checking files on disk wouldn’t work.
- Then malware behavior became polymorphic too, so that detection tools would struggle to spot the malware’s activity in the noise and chaos of typical PC operations.
Still, behavior analysis remains the main strategy for the detection-based security industry.
Watch application isolation in action: see Bromium contain malware.
Now we are seeing a simple, obvious way to avoid this sort of detection: copy a file. To fully understand this latest approach, let me provide a quick primer on how detection-based security products work. If you’re already an expert, feel free to scroll down.
In the normal operation of a PC, applications (such as Word) constantly make requests to the operating system (OS), and more specifically to the OS kernel—the most powerful part of the operating system.
Common requests are:
- Open that file
- Display this picture on the screen
- Play that sound
And so on, all day long.
Any malware in a Word application will likely need to ask the kernel to do its evil bidding.
So, the detection industry monitors all these requests from applications (like Word) into the kernel. They hope to spot a pattern of suspicious requests and alert you to malicious activity.
One way to detect suspicious activity is to intercept these requests as they pass through kernel32.dll. That’s a standard part of the Windows OS that allows normal applications (user-space code) to make requests into the kernel (kernel-space), like this:
Detection products aim to separate the wheat from the chaff and spot the pattern of odd behavior that would imply that something dubious is running within Word. Unfortunately for detection-based security, it’s mathematically impossible to do that 100% correctly, but that’s another story. Read more about The Halting Problem.
Returning to this particular flavor of malware, we see a rather simple way to bypass the detection products: it simply copies kernel32.dll.
The copied version is identical and serves to relay requests from Word in to the kernel in precisely the same way; however, the copy name is subtly different. Therefore, some products fail to detect the malware activity as it passes from Word to the kernel.
Once it can talk to the kernel, the malware can launch new processes to begin its reign of terror:
- Does some process hollowing of svchost.exe
- Installs Tor so it can create anonymous connections via the “dark web” to its command-and-control server
- Sits and listens, awaiting instructions from its masters to encrypt your documents, steal your secrets, spy on your staff, or whatever else its commanders want it to do
Detection-based security is flawed.
There are always new ways for the malware authors to outsmart detection tools. In this example, Bromium’s detection engine identified the malware, but that’s not always the case. Bromium doesn’t claim to detect everything; nobody can. For our customers who shared this data with us, the malware played out exactly as the authors intended but it did so in an isolated micro-VM, and the malware was unable to harm or impact the host or the network.
On behalf of the Bromium Lab team, we look forward to capturing the next installment of malware in our micro-VMs and, of course, sharing the details with you.