STE WILLIAMS

Notes from SophosLabs is an occasional series looking at some of the tricks and techniques we see (and use) in SophosLabs when we take malware apart.

We hope you enjoy it – if there are any topics you’d like us to cover in future articles, please let us know!

This article thanks to James Wyke of SophosLabs.

Anti-virus research is something of an arms race.

Here’s why.

Rewind 30 years, or close to it.

It’s 1986, maybe 1987, and there are a few of those mysterious programs going around called “viruses,” that spread themselves from disk to disk, and from PC to PC. [↓]

You come up with a defensive strategy by extracting code fragments from viruses you’ve seen, and searching for them; as a result, you are quickly able detect current viruses, and quite a few new ones, too. [↑]

The crooks start finding trickier ways to write their code, so that their new viruses use techniques that don’t match up well with your old signatures; as a result, your proactive detection slips. [↓]

You find more general ways of analysing and evaluating the behaviour of their code, moving beyond signatures so that their new viruses don’t easily evade your detection; their infection rates fall. [↑]

They learn how to scramble their malware, so that all that’s left on the outside is a bland and uncontroversial unscrambling loop. [↓]

You figure out how to peer through their “encryption,” which catapults you ahead because the decryption process automatically makes their malware look more suspicious. [↑]

They learn how to permute their “encryption” with polymorphic (self-changing, shape-shifting) malware, so that every sample of the same virus looks different. [↓]

You respond by working out how to strip off even unknown scrambling systems that you’ve never seen before. [↑]

At this point, we’re still only up to about 1989, maybe 1990.

The threat detection battleground

But the threat detection battleground has changed in this tit-for-tat way ever since.

Indeed, this malware detect-and-evade arms race has spawned a whole bunch of technical jargon, such as:

• Polymorphism. The abovementioned “shape-shifting” trick, where each sample is different. A virus with a random 32-bit decryption key would need 4 four billion (2³²) signatures to detect the old-fashioned way.
• Stealth. Once active, the malware tricks the operating system into showing infected files as clean, so a naive scanner gives a clean bill of health, even if it knows what the malware looks like.
• Rootkit. A malware component responsible for stealth, often running inside the kernel to subvert the operating system itself. Rootkits can not only make malware hard to find, but also shield it from being deleted once you suspect it’s there.
• Tunnelling. The virus carries out its dirty work in undocumented or “behind-the-scenes” ways to bypass your virus blocker. For example, if you have a filter that blocks writes to .EXE files, the virus might write to a .BAK file and later rename it.
• Decoy file. The malware does its dirty work, and then removes its malicious files and replaces them with something legitimate looking, such as a document containing a news article, or a harmless program.
• Anti-anti-virus. The malware includes anti-virus-like code to watch out for your anti-virus running, and then goes to war with it. Perhaps it kills your processes; feeds you masses of fake data; or just temporarily starts playing nice.

Anti-anti-virus

One common anti-anti-virus trick these days is for malware to check if it’s running under virtualisation.

Virtualisation is where you take one physical computer and make it pretend to be one or more pseudo-computers, known as virtual machines (VMs).

Inside those VMs, known as guests, you can then install a range of different operating systems and applications.

The physical computer, known as the host, acts as the overall manager of the virtual guests.

This is extremely handy for malware research, especially for automatic malware testing, replication and analysis.

That’s because you can run lots of malware in parallel, or run one sample of malware in several different environments (e.g. Windows versions) at the same time.

Avoiding virtualisation

In fact, VMs are so handy for malware researchers that cybercriminals frequently program their creations to misbehave, or to do nothing at all, when they spot they’re in a VM.

Unfortunately, there are lots of ways to do this, not least because VMs often have predictable and easily-detected characteristics.

As a researcher, you can pull anti-anti-anti-virus tricks in return, of course.

For example, you could by changing your VM’s defaults, so that the hard disk looked different every time, or the memory size kept changing, or the virtualised hardware switched around, and so on.

The downside of that, however, is that it makes it harder to do repeatable tests, because things keep changing, a bit like trying to compare the fuel consumption of different cars under inconsistent conditions.

So, the arms race continues even inside your malware research VMs.

You can fight back in various ways, such as evading the VM detection in the first place, or by spotting that you’re being tricked and sending that particular malware sample off for a “bare metal” analysis, directly on a physical computer.

Avoid old-fashioned hardware

Amusingly, SophosLabs just told us about a fairly recent anti-VM trick that not only infuriatingly simple, bit also an indication of how powerful even bottom-end computer hardware has become these days.

Dyreza, also known as Dyre and Dyzap, is a banking Trojan (malware that watches out for your online banking transactions to steal your password, or your money, or both).

It’s commonly found along with malware called Upatre; the Upatre component is typically delivered in bulk, via spam, and then used to install the banking Trojan on infected computers.

Anyway, Dyreza simply asks the operating system how many CPUs you have.

If you’ve got an old-school, single-core CPU, the malware instantly loses interest.

Presumably, very few real-world PCs, and even very few real-world VMs, actually have a single processor these days.

Malware that avoids VMs altogether effectively cuts itself off from infecting servers or hosted services, many or most of which use VMs these days.

But by isolating itself only from single-core computers (real or virtual), Dyreza doesn’t lose out on many real-world victims, but presumably evades analysis on at least some researchers’ automated systems.

What to do

What to do if you’re a researcher?

One response might be to bump up all your VMs to 2 or more processors, like this rather peculiar “5 CPU” example we created for no particular reason other than the screenshot.

And then keep your eye out for malware that only works if you have a computer that doesn’t have 2 CPUs. or 5 CPUs, or however many you chose.

Because, remember, it’s an arms race.

Follow @duckblog

Image of an old computer that looks a bit like, well, you know what type it represents, courtesy of Shutterstock.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/MXKDsDM05gk/