Freigeben über

How malware likes to hide

  • Artikel

Well, technically, how malware writers like to hide malware. In my last post, I talked about subversion – hacking the OS not to see the malware. That is part of the rootkit. Not all malware uses a rootkit and all malware has to avoid detection by signature based anti-malware tools like standard anti-virus solutions and anti-spyware solutions. The way that the first AV solutions worked was that they looks for the precise pattern of bytes or the MD5 hash of the file. Polymorphic viruses were built to defeat this although polymorphism is not limited to viruses. We habitually see it in Trojans as well. There are several ways that this can work.

The first and simplest is to include random junk data in the binary image and change it when you write a copy of the executable to a location. There are two good things about this approach. The good thing for the BlackHats is that it is really easy to do this. The good thing for the Whitehats is that it is pretty much ineffective if we are looking for byte patterns in files rather than just hashing the file. AV solutions that used signature files to look for matching patterns became the norm.

The next generation tried to alter the code in ways that didn’t much matter. Add a NOP here. Have multiple code fragments which do the same job and are the same length (easy enough if you pad with NOPs) or in the case of the terminally clever, moving things around into different “slots” within the code segment. This was a bit harder to counter but there are still a limited number of possible forms and so it just requires a LOT of different signatures. Annoying and it means that malware checks take a lot longer but still possible. Typically polymorphic code that works this way doesn’t want to change the length of a section of code because then they effectively have to relink themselves “on the fly” because the relative jumps will be off. That is fairly tricky to do and it would be difficult to write a re-linker that was itself polymorphic. Fixed code makes malware easier for automated systems to find.

What we see a lot of now is packed malware – it has a decryption engine built in to the malware and if you look at the malware in a disassembler, you see the code of the unpacking tool and not of the malware – it has become an encrypted payload deployed by the packer. This makes it very hard for an investigator to work out quite what the malware is doing. However, it doesn’t have quite the effect that the malware writers want. There are only a few packers available on the underground economy. Remember that I said that fixed code is easier for automated systems to find? If we find a packer designed to hide malware, we can assume that the file is malware. Thanks for the help, guys!

The war is far from won, of course. The botnets get ever larger and the varieties of malware multiply. Most botnets just spew SPAM of course – “pump and dump” schemes AKA boiler-room SPAM, adverts for V-I-A-G-Я-A or some other spelling of counterfeit drugs or the scam-du-jour. At the moment, we are seeing a lot of mails looking to recruit machines into botnets via social engineering – “run this trojan dropper to see your ecard”. Some attacks are smarter than others and some end users are better informed than others.

We are doing the best we can to make our SPAM filtering better, our code more secure and taking what legal measures we can to shut down the bad guys. The bad guys are throwing everything that they have at us and our users… just like every day.

Until next time

Mark

Comments