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.
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 (232) 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.
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.
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 is not only infuriatingly simple, but 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.
5 comments on “Notes from SophosLabs: Dyreza, the malware that discriminates against old computers”
Nice article, but:
“Tunnelling. The virus carries out its dirty work in undocumented or “behind-the-scenes” ways to bypass your virus blocker. ” <- This is true.
"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." <- Hm, really?
Tunnelling is when the virus uses a variety of techniques to find the "real" address of a function/system call and thus bypass the AV "hook".
For example, in the old days, a virus might have single-stepped (by hooking int 1 and setting the TF) through a benign call to int 13h, instruction by instruction, until the current CS became 0xF000 (i.e. the BIOS code segment).
Like you, I first heard and used the word “tunnelling” in the sense of digging past interrupt interceptors, either by active code-tracing techniques like you describe, or by passive techniques such as “knowing” the right address to call. (I used to own an official IBM BIOS printout. I wanted to have hard evidence of all the secret addresses 🙂
I reintepreted “to tunnel” generally, to refer to any technique that bypasses security hooks.
I thought the BAK-to-EXE (write-new-file-and-rename) was a simpler thing to describe and for non-assembler programmers to understand.
You may be right, though, that my example is a step too far. I suppose a BAK-to-EXE trick is more about a _bypass_ (going around) than a _tunnel_ (going under), a word that captures the low-level trickery that assembly-level bypasses usually involve.
Maybe we’ll just leave my description in the article and these comments as an additional explanation…
Oh, I get it — Dyreza is a banking Trojan that loses interest!
Wouldn’t it make a lot of sense here to add a layer of security hardening to the virtualization layer in Windows, so that it runs apps that meet a certain criteria or point system (untrusted, unsigned, cloud-based reputation, etc.) in virtualization and repots back statistics common of a VM (1 CPU, 2 GB RAM, 60 GB HD)?
In its current implementation, my observation has been that the security privilege de-escalation happens on a voluntary, by-request basis from the app (IE, Chrome, Dropbox…) rather than an automated algorithm. It may or may not be a new idea but it seems fairly risk-free for unknown apps that score high on that scale to be placed automatically into virtualization.
The only example I can think of that does something somewhat similar is Kaspersky pulls out certain privileges from Admin Approval Accounts so that critical system processes can’t be compromised without a lot more effort. But there is that precedent of hardening Windows’ built-in security model, at least in that sense.
Those unsigned, unknown apps almost certainly don’t need hyperthreading to perform optimally or if they did they’d chain up to a trusted root for a few bucks a year. Presenting the false info would go a step further and deter these kinds of attacks, which would then deter malware using them, thereby making it easier to detect. Seems like a win all around, unless I’m missing something.