Delivering a malicious payload to infect an end user system should be difficult – for years the security industry has worked to improve protection technology to reduce the number of compromised endpoints security teams need to address. But what happens when that payload doesn’t fit the mold we’re used to, typically an executable form of malware? As our Labs team found in their recent research, so called “fileless” malware is becoming increasingly prevalent, and much more difficult to detect once on an endpoint than traditional malware.
Vincent Weafer, who leads our Labs team, wrote a great blog explaining this trend and how the fileless malware they studied works. I suggest you read that now or in conjunction with this post. I want to dive deeper however into the problem of detecting these payloads, and what you can do to reduce your exposure to them.
Many organizations today rely on the classic model of signature-based detection to pick up these files either in transit through email or web traffic, or even at the endpoint itself. Some of these attacks will be stopped that way – we update our threat intelligence quickly enough to stop many for our customers as soon as they’re discovered. From a prevention perspective, what we’re looking for here is the initial dropper that then writes code to Windows Registry or thumbnail cache (just two examples) and then deletes or hides itself to then make the attack “fileless”.
The challenge here is that if nothing picks up the dropper, once it’s on the endpoint it will likely persist because there is no static binary to detect. So what can you do to prevent that? Stop the dropper.
Again using malware signatures isn’t going to detect every dropper. It’s too easy these days for an attacker to pick up an exploit kit and run an attack where every click on their malicious link or advertisement is set up to deliver a slightly altered (see polymorphism) payload that won’t be detected by AV, often referred to as zero-day malware.
So if you can’t pick up on the payload, what else can you do? Malware payloads aren’t just downloaded per se, they need a way in. And the way in often looks well, suspicious. If you spotted someone trying to pick the lock to your front door at night, you would know there is a high probability they intend to commit burglary.
To deliver a dropper through the internet for the eventual “fileless” malware, an attacker needs to take advantage of a vulnerability and exploit it. Often this will be a vulnerability in the browser environment, such as flash player or adobe reader. Then using malicious code inserted on the destination website, the vulnerability can be exploited, letting the attacker deliver whatever they want to the endpoint. In this case, the dropper file.
The process of exploiting vulnerabilities in the browser environment is the definition of suspicious behavior. But you don’t want to shoot the locksmith right? What if you could take a peek into the future and watch the burglar finish picking the lock, and see what he does next? If he barges in, fully armed, you know you’re in trouble. In the threat protection space, the most efficient way to do this is through a process called emulation. Instead of waiting for a dropper file to compare against a threat signature, we look at the malicious code itself attempting to exploit vulnerabilities, and let it play out so we can detect small behavioral cues, like the burglar revealing a lock-pick device or pulling a mask over his face. If the cumulation of behaviors we see in the emulation environment looks malicious, we’ll block the code execution outright before it even has a chance to deliver a payload. We’ll stop the dropper.
Sounds like a lot to do right? In reality, this process of emulation takes about the same time as comparing a file against millions of signatures, right in the range of 5-10 milliseconds. That means we’re able to emulate code behavior in real-time as websites are accessed, with no noticeable impact to the end-user. With less payloads reaching an endpoint, like the “fileless” malware droppers discussed here, security teams can focus on the more critical activities of detecting and correcting existing breaches.