Malware Author's Mindset

Question

I'm studying common malware characteristics, and I'm having a bit of difficulty understanding the design choices the malware authors make. Many of said choices seem to revolve around making life difficult for a human analyst to pick apart the malware, while potentially making the malware very easy for an automated system to flag as "probably malicious." I'm curious to see if anyone can tell me what the rationale is behind such design choices.

For example, some anti-reverse engineering tactics. Yes, they may make it more difficult for the analyst to reverse the malware, but tactics like TLS callbacks could easily be flagged as suspicious, especially since the malware is almost never signed, whereas most legitimate software that uses such techniques for anti-RE purposes is.

Another example would be anti-VM tactics. Most AV emulators time out after a short period. There's no need to detect the emulator. Just do something for a few seconds (other than something obviously delaying, such as calling sleep()), as opposed to doing extremely noisy checks like trying to open a bunch of VMWare and VirtualBox registry keys. The only case where you can't just outlast the VM is when there's a human analyzing the sample, and if a sufficiently motivated human is analyzing a program, they're going to be able to reverse it eventually, so why even bother?

Maybe I'm just not knowledgeable enough in the field of making malware to understand the purpose for all this, but it would seem to me that the kind of systems a malware author would be trying to bypass would mostly be automated systems. For example, antivirus engines or automated sandboxes that AV companies use to analyze new, potentially malicious samples that sort said samples into "definitely not malicious; discard" and "potentially malicious; send for human review" piles. The main goal of the malware author would seem to be keeping those automated systems from flagging the program as suspicious to reduce the chance of the malware ending up in front of a human analyst to begin with, not slightly frustrating the human analyst who will eventually be able to analyze the malware anyway.

I know that some malware authors are just script kiddies, but I'd assume at least some of them put effort into making software development choices. I'd assume they know more than I do about the subject, since they do malware development for a living. But I can't understand some of the design decisions they make. Can anyone explain to me the rationale behind these decisions?

Answer 1

They make these design choices for 1 of 2 primary reasons:

1) They are directed to because they or their superiors have intelligence on how to design and implement for a particular campaign, operation, or objective. Maybe they know something that you do not know.

2) They've been making money, so they want to keep making money. They make more money than us, and they just keep making it. It's not going to change, so their formula is working. If it ain't broke, why fix it?

Rarely is malware both full-featured and bug-free, such as Moker, but it happens. I would say that Moker is perhaps an uncommon outlier to your criteria, but it is one. It definitely meets the bar for both anti-RE and AV-bypass capabilities.

I would say that:

A) Your conclusion that this malware concept you have in mind that overfocuses on anti-RE and underfocuses on AV-bypass is perhaps broken from the start. I would say that any malware author clearly wants both and that these concepts do not work against each other. In fact, I would say that they are logarithmically-sound, i.e., they're scalable in all directions. What I think you are not including in your thinking is that it's just easy to catch malware features and behavior once they are known -- once they are elicited... and then it goes into every AV in existence (or maybe 20 of the 30 on VirusTotal... but at least 3 or more). The shelf life of most malware doesn't last beyond 3 months and most malware families don't make it past 3 years. However, you do see some Vawtrak in your Dridex in our current 3rd-gen (4th-gen?) Geodo. There's code reuse, but it's often hard-to find and not clear cut.

B) Malware authors, these days, need to come up with ideas Beyond-the Dropper in most situations. That means that they need their malicious logic to hide in plain sight. Their focus is actually maybe on neither AV-bypass nor anti-RE techniques, but rather on Process Injection techniques. That's where they can spend their most time, bang-for buck wise. The rest of their code can be pretty copypasta by comparison. Throw a few different crypters on the wall and see what sticks.

Answer 2

I think you're maybe giving too much credit to malware authors in terms of understanding *anti-reverse-engineering(and maybe also too much credit to professional software devs;). In my experience most malware authors each use their own 'favorite' set of techniques with small variations(lots of times based on code from other authors or researchers), the same way a webdev might use mostly the same input sanitization code each time they write a password field, irregardless of the underlying application code.

Also, in regards to saying, "why doesn't it account for x tactic": malware is cat-and-mouse; even if you created the "best" anti-re code, if it's used enough it'll eventually become a detection signature.

Lastly, keep in mind that no malware is impervious to analysis, so it's more akin to DRM on games; try to get as many infections as possible before it's cracked. You could spend months crafting fancy anti-re schemes for a single piece of malware just to see it broken and turned into a signature in a couple days anyways, so it's probably better to go for quantity of malware over quality of anti-re defenses.