Malware Authors Learn Market Segmentation From the Best

Earthquake Retrofit writes "The Register has a rather funny story about the Zeus botnet: 'The latest version of the Zeus do-it-yourself crimeware kit goes to great lengths to thwart would-be pirates by introducing a hardware-based product activation scheme similar to what's found in Microsoft Windows. ... They've also pushed out multiple flavors of the package that vary in price depending on the capabilities it offers. Just as Windows users can choose between the lower-priced Windows 7 Starter or the more costly Windows 7 Business, bot masters have multiple options for Zeus.'"

Comments

hmm

[theheadlessrabbit]

but will these malware authors be able to cause as much harm to your computer as windows does?

Version 1.4

[Manip]

I'm a little surprised Zeus is only adding dynamic executables with version 1.4. This malware kit has been around a while and software has been doing this kind of thing since the very beginning. Maybe it tells us that a lot of Zeus' victims lack any kind of working AV? Or maybe it tells us that with things like Security Essentials being free and popular they're more worried about AV as a threat to their business?

I will say that a binary that changes its self every execution becomes very hard to detect unless your software really understands how a program is running from a mechanical standpoint. Even then you could still embed a dynamically encrypted package into another process's address space and decrypt it there.

Ultimately however it still comes down to the simple fact that there is one layer of defence on modern PCs and once that is bypassed you might have well reinstall your OS.

Re:Version 1.4

[Sycraft-fu]

Plenty of virus scanners can pick up on dynamic executables (also called polymorphic). One problem you run in to is that you have to pass the scanner before you get to execute, so that means that even if your thing can really scramble itself upon execution, if they have info on the versions that are being distributed online, those can be blocked and you don't get a chance to change. However as a practical matter, your code is still there no matter what, has to be to run, and the advanced scanner can pick up on that. They also can perk up and look harder when you do uncommon things like self-modify and so on.

What it really comes down to though is that these kind of programs are going after low hanging fruit. The botnet authors aren't trying to bypass every defense, they just want to get a big net of infected PCs and there are plenty of choices with crap defense. Besides, the ones without defenses are ones more likely to not clean up the infection. If someone goes through the trouble to secure their system, they may also watch it and will notice problems if you infect it. That doesn't do you much good if they just clean it up after a couple hours. You want a system you can hang on to.

Re:Version 1.4

[maxwell demon]

Finally, I think you may be a bit confused. In x86 (and x64) assembly at least, there's no such thing as a partial op-code. Each instruction is one or more bytes and the CPU doesn't just skip over invalid data as some did (like some 6502 variants). So you can't change any bit in an op-code or you'll change what that op-code is and thus what it does. For example 74 is JZ, jump to the address (specified afterward) if the zero flag is set. 75 is JNZ, jump to the address if the zero flag is NOT set. Change one bit, changes the whole meaning of the instruction. You can't fiddle with parts and have a different op-code that does the same thing.

All the following sequences do an unconditional jump:

; sequence 0
JMP dest
 
; sequence 1
JZ dest
JNZ dest
 
; sequence 2
JNZ dest
JZ dest
 
; sequence 3
JC dest
JNC dest
 
; sequence 4
JNC dest
JC dest
 
; sequence 5
JB dest
JE dest
JA dest
 
; sequence 6
PUSH dest
RET

Note that any difference in length can be made up with either preceding (effective) NOPs (there are many possibilities there, too) or with following junk (it's an unconditional jump; anything directly following isn't executed anyway). Also note that the destination address can be varied if the destination starts with some (effective) NOPs, or if you have jump instructions to that address at other positions.

And all that is just what I could immediately think of. I'm sure someone who spends considerable time on designing such stuff would find many more ways to vary the code.