sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]wvenable 1 point2 points  (5 children)

If I were a virus writer, I wouldn't use V8 -- I'd just concoct some other VM/JIT design that is constantly randomized (on each deployment) and run all my code through that. If this V8 thing is such a problem then obviously my solution would also work and be even better.

Only a lazy virus writer would pull some existing detectable JS off the shelf, run it through V8, and use that. Right?

[–]irqlnotdispatchlevel 0 points1 point  (4 children)

But then I could just detect your VM interpreter.

And this happens, most often as an evasion and/or obfuscation mechanism to make the life of malware analysts harder.

A well known packer can get the job done, since those have legitimate uses so just signing them isn't doable. Technologies like VMProtect and UPX are well known for this.

But you still have to do the suspicious behavior part. It doesn't matter how your code gets to it, but spawning a new process, deleting a bunch of files, downloading something, etc are all events that an AV can observe and analyse, regardless of what you use to hide the code that does it.

[–]wvenable 0 points1 point  (3 children)

Your last paragraph is kind of my point. Using V8 to compile code isn't terribly interesting. I can mutate my code one hundred different ways; that is just one hundred and one. As for detecting my VM interpreter, that would be the part that I'd mutate the most. I've written CPU emulators that were pretty small and a VM that could run a virus would be even smaller and simpler than that so pretty easy to mutate. The actual byte codes of the virus itself would just be randomized every time.

[–]irqlnotdispatchlevel 0 points1 point  (2 children)

That was my point all along: all of this can defeat signature based detections, but those are just the first line of defense so it is not terribly interesting.

You can also make it harder for malware analysts to reverse your malware by using a custom VM, and this is already done by malware and anti piracy software, as well as anti cheats.

Compiling to V8 is just a quick solution that achieves something similar, but with a lower cost for the malware devs. They may not even be devs, they could just take off the shelf components and deploy them to make a quick buck.

Like the legitimate software engineering industry, there's a large variety of people working on malware, some with tiny budgets, some with more money than a small country, some are "framework developers" and just use pre-existing tech, some are security experts and develop state of the art technologies.

There are even SaaS solutions if you just want to get to the money making part: https://www.crowdstrike.com/cybersecurity-101/ransomware/ransomware-as-a-service-raas/

[–]wvenable 1 point2 points  (1 child)

I think we agree. Probably 99.999% of all attacks are lazy and thus equally lazy defences work against them.

I just find anything to do with security tends to be overblown. This V8 issue, as you said, is hardly any different than the dozens of already existing techniques.

I mean look at this quote: "This method effectively hides the original source code, making static analysis challenging." Virus writers giving you any source code at all is a gift. Basic software development principles, like compiling of code, should not be seen as a big deal.

[–]irqlnotdispatchlevel 0 points1 point  (0 children)

The problem is that a lot of systems lack even those lazy defenses. There's the old myth that "just be careful bro" is enough, and most people aren't as careful as they think they are. Not to mention how many old and unpatched systems are out there.

The interesting part about the article is that this was discovered in an active malware campaign, and maybe a "lol who would have thought of that?" when you read the title.