Recently we have seen a re-emergence of polymorphic file infectors, AKA viruses.
Threats like W32.Sality and W32.Xpiro are using some old-school tactics to infect good files and spread through networks. As the former captain of my high school analogy team, I’m writing this informal blog to help de-mystify some of the difficulties around dealing with these kinds of threats.
If we think of our normal run-of-the-mill Trojans and worms like a specific kind of fruit, it helps a little bit. Let’s say we need to create detection for an apple…That’s pretty simple right? We look for common traits that the apple has with other apples of the same kind. Something like this:
IF fruit AND red skin AND white flesh AND black seeds>detect W32.Apple!red
So now we can detect Galas, Pipins and Jonathans, but not detect Goldens, or Grannys, or even cherries.
That’s a simple example of how we detect files that are 100% bad. They were written to be bad and there is no good file inside trying to get out. Once we build the detection and QA it, we can safely remove all the bad red apples, but leave the green apples and other fruit alone.
Ok so far?
Good!
Now we take on the polymorphic file infector. Think of this kind of threat as a parasite that reproduces and burrows in as it moves from fruit to fruit (file to file). Each time it infects a fruit, it looks different. On one green apple it looks like a grub, but on the next it looks like a beetle. Then it moves to a bunch of bananas and burrows in, looking like like a different kind of moth for each banana. Then onto an orange and it looks like a grub again. It can continue to morph itself and burrow into fruit\files 50,000 different ways.
Hopefully this paints a good picture of how a file infector is a much more complex type of threat. They are harder to create than other kinds of threats, which is why they are a lot rarer. Our job has now moved from spotting a red apple to spotting a wide range of parasites and then removing them without harming the fruit, if possible. That’s where the math comes in.
You see, in order to make a super-bug-parasite-nightmare like this you need a lot of math. You need to be able to calculate all the different options and behaviors and combinations that it will take along with the “key” that allows the bug to have the same behavior, even if it looks completely different. This algorithm is like a Rosetta stone to understanding the morphing ability of the threat.
Sadly the author of the threat rarely provides this magical key and so the Security Response engineers have to make their own.
“How do they do that?”
I’m glad you asked!
Sometimes, if the threat is spreading too fast, they start by just going all Sledge-O-Matic on the file. This kills the threat and prevents it from spreading, but has the unfortunate side effect of making puree of the file and possibly spraying the user with bits of broken data. So ideally, they jump directly to creating detection and repair. To do this, they start with a whole bunch of different fruits and place them in a really big tank. Then they throw a few of these parasites and watch to see what they do to each kind of fruit… and they watch.. and they watch. Eventually they will be able to make certain statements about the algorithm the threat\bug uses, and how to kill the little guy without damaging the fruit. As you can imagine, this can take a lot of time depending on how complex the parasite is. And once we have detection and repair created, it doesn’t mean that we are getting all of the versions of this particular critter. So we have to keep working the problem and fine tuning it until we have 100% coverage. There are all sorts of tools and shortcuts that we employ to make this process faster, but it can still be a long process and it has to be done very carefully so we don’t make fruit salad out of your operating system or important applications.
It’s also important to keep in mind that what happens to your fruit is largely dependent on what actions you have set within your Endpoint product. For example, suppose you have set it to try to repair and then, if that doesn’t work, quarantine. You might be taking a piece of fruit out of the hands of a very hungry user. A worse example would be if you set the policy to repair and then delete. Now we are back to Sledge-O-Matic on your fruit\files. Both of these settings have repercussions and you should be aware of them, but they are both better for your security than to repair and then leave alone.
One last disclaimer and I’ll put down the analogy and back away slowly. This blog post is designed to help folks understand why creating repair for viruses might take longer than just creating detection. It's limited in scope and has been simplified in order to make a point.