Investigating a malware sample which sometimes fails to behave maliciously | Hacker News Reader

Investigating a malware sample which sometimes fails to behave maliciously

sentinelone.com

101 pointsJerry263 comments

> evades detection simply by counting the number of documents – or the lack thereof – that reside on a PC and not executing if a certain number are not present.

This is so simple, it's a one line trick:

    Public Function DKTxHE() As Boolean
        DKTxHE = RecentFiles.Count < 3
    End Function

> the typical lack of documents in a ... test environment make it easy ... for malware authors to fly under the radar

Dev environment is dissimilar to prod --> works in dev but not prod. Surprise, surprise.

Original blog: https://sentinelone.com/blogs/anti-vm-tricks/

This is not novel, it's same general technique on a much more simplistic level as those that red pill uses.

edit: I don't really care about the downvote, but would have preferred a reply as to how it is that fundamentally different from silly stuff like checking device names, or even checking IDT location/ITLB contents/timing attacks This is clever-ish userspace stuff, but it's the same general idea and it's not new.

The funny thing about these is that the obfuscator leaves a billion clues that can tip you off that the macro is malicious, without even having to run it. Any human being can tell you that DKTxHE is a bogus name for a function, so the only trick is to implement that detection in code...

> Any human being can tell you that DKTxHE is a bogus name for a function, so the only trick is to implement that detection in code...

Don't people run code obfuscators on macros?

> the only trick is to implement that detection in code

String entropy scoring works surprisingly well for problems like this: build a corpus of function names (scrape it from github?), generate a markov model, see how probable the candidate function name is according to the markov model.

Then I'll just run a prettifyer with the same sample data and name functions in my malicious macros from that.

Like a lot of things, it's an arms race. For the most part people aren't doing that yet because it's easier, and almost as effective, to just generate them at random.

Malware which simply doesn't do anything for the first few weeks, or even hours, is hard to detect by running it in a VM box. Some "advanced persistent threats" are like that.

I can imagine that someday viruses can be written to have no signature to detect at all

Polymorphic viruses.[1] No two instances are the same. In some cases, not even the same length.

[1] https://en.wikipedia.org/wiki/Polymorphic_code

Yeah, I recall polymorphic malware toolkits being sold in mid-level marketplaces back in 2010.

This has been done (relatively) long ago.

It's called metamorphism - the entire code of the virus is continuously changed. They're incredibly complex pieces of code; in at least one case, 95% of the code was devoted to the metamorphic engine.

Note the difference with polymorphism, where only the decryption routine[s] change.

Two notable viruses have been Zmist and Simile.

This has become really common. Most modern malware sandboxes attempt to greatly accelerate the system clock to account for this, in addition to trying to detect and intercept long sleep (or equivalent) calls.

Like most long cat-and-mouse games, modern malware families all use a combination of many different tricks and anti-sandbox/analysis techniques. The sandboxes play whack-a-mole at the same rate as malware keeps adding more moles.

If the malware attempts a CPU test that maxes out the host CPU, will it be obvious that the system clock is sped up?

So… only speedup the clock while the software under test is sleeping (waiting on a muted, timer,…) . Stealthy software shouldnt have excessive cpu consumption, otherwise people will investigate.

It's obviously a cat & mouse game.

I propose a scorched earth tactic. Refuse to run unsigned code.

This reminds me of some software which would refuse to run if it detected you had a debugger like SoftICE installed, the irony being that those who do would also be the most likely to know how to defeat those checks. (See also: https://www.gnu.org/philosophy/right-to-read.en.html )

I seem to recall games that refused to run if you had Daemontools installed...

Similarly, there were a few PlayStation games that would refuse to run if the console had a modchip, which was a pretty big footbullet when you consider that only licensed discs were likely to retain this check, meaning that it mostly stopped people who obtained the game legally.

Sounds exactly like what VW did for emission testing, score another one for the bad guys.

> If no [other, existing documents] are found [on the system], the [code] terminates

I almost missed it while scanning the article. This is what the headline mentions. Interesting yes, but "novel"? I'm not sure.

> Interesting yes, but "novel"? I'm not sure.

It's not. And I don't know anything about SentinelOne so maybe they're amazing, but being stymied by dynamic analysis of VBScript malware seems, um, odd.

How do the researchers detect anything when I assume every virus has Anti-VM or anti-sandbox checks

When I was trying to crack some certification software, I've noticed it is querying from VirtualBox and other string literals in WMI service. I suppose its not too difficult to spoof that, though I am sure there is certain feature detection techniques virus could use too.

You can buy a laptop for $200 on amazon. Burner laptops could make good sandboxes, no?

It's about as powerful as an iphone https://www.amazon.com/gp/aw/d/B01F4ZG68A/ref=mp_s_a_1_5?ie=...

Yes but they don't scale, and you still have a problem of figuring out what the malware does you can't attach a debugger to it, and in circuit debuggers for modern machines are non-existent (unless you are Intel/NSA).

You can record the contents of the disk before you run the malware and after, and then do a diff. You can also sniff network traffic.

I'm not sure how long you'd want to wait to give it a green light, if it doesn't do anything obviously bad, though. Maybe this could be combined with forwarding the clock to trick the malware in to thinking a lot of time has passed?

Diffing the disk won't do you much good, the malware does it's interesting things in memory. Overall as I said this doesn't scale.

Viruses can spread copies of themselves and infect other programs, and can leave trails on the disk. They can also infect the mbr. Then there's ransomware which encryptes files on disk. These are all examples of malware that could be detected by diffing the disk. Of course, if it doesn't touch the disk, then you're left with network traces.

I'm not saying they don't it just not the most interesting thing you may want to look at ;) Anyhow don't bother with even trying to use physical machines as your primary platform, VM or better instruction level emulation is the way to go, not foolproof but it is at least scalable and flexible enough.

You also seem to conflict what detection means, detection can be easy "is this a known binary" if not > malware can be a pretty easy (if unrealistic) classification, when researchers talk about detecting malware we are talking about understanding what it does.

Diffing disks isn't really going to get you far.

I can assure you, usb or pci DMA debuggers exist. You raise an interrupt and dump all memory with it.

Depends on your threat model. Whilst a bare-metal solution is preferable for analyzing malware, I wouldn't procure my laptop from Amazon. See this: https://www.reddit.com/r/onions/comments/301itv/buying_your_...

After the Snowden revelations, I am highly skeptical of the trustworthiness of any computer hardware ordered online. Even if I don't fall into the bucket of somebody especially interesting or worth targeting. I mean really we should have a database of xray scans of motherboards so we can diff them, and compare store-bought laptops with ones shipped via mail, but until then I will be persistently buying up all the store-bought Thinkpads I can find and modifying them to prevent evil maid attacks.

By taking anti-anti-VM and anti-anti-sandbox measures, obviously ;-)

A stock VM is extremely easy to detect because most VM software today doesn't even try to make it look like a physical machine (e.g. would a physical machine have hardware named "VMware virtual SVGA"?), but there are certainly patches you can do to change this, often at the cost of performance. (The 80-20 rule applies: the majority of software won't notice the difference and making the VM "perfect" to cater to the rest becomes increasingly difficult.) And a sandbox lets you control to varying degress of precision the exact environment an application sees.

Besides, these researchers presumably know reverse-engineering. They can just inspect the malware for such checks and force them to go the way they want.

You underestimate the complexity of malware these days.

Obfuscated to hell, encrypted blocks, tons of loops and rabbit holes that can lead you to dead ends, in addition to malware being more of a bootstrap these days than a self contained application which means it will download additional modules based on the configuration of the machine it has infected and what the mothership tells it to do.

While this might be considered anecdotal I've seen malware that would detect a VM and not disable itself but would pretty bog standard run of the mill post infection modules and perform pretty bog standard post infection tasks (registry entries, auto-run, register a service etc.).

These things are intended to "fool" the researcher into both not understanding the malware and missing its purpose completely and to create false signatures for the file paths, registry entries and binaries all while thinking they've done a great job and call it a day.

The checks that malware does is way beyond simply looking for the usual signs it goes way above dmidecode or systeminfo | grep "insert_hypervisor_name_here".

I've seen malware trying to do a full dump of the bios, access the TPM, try to call various API's that won't really work well in a VM like directx 11, try to get DMA access to various devices, do some timing analysis on IRQ stuff, access the SUPERIO/BIOS functionality for controlling the fans and check if it can control them and what effects it has on the thermals, enumerate how many USB devices are connected pretty much anything you can think off.

So overall I'm pretty amused by the fact that "counting the amount of documents" is considered a "novel evasion technique", it might not even be an evasion technique but just a simple check if this PC is worth infecting or not. I've seen quite a few cryptolockers infect a machine and only encrypt everything once a certain milestone of "valuable documents" has been reached, some really nasty/cynical ones wait for dates like holidays etc. and wait until you fill your machine with 1000's of photos, or wait for the end of the financial year and wait for you to fill it with tax returns and accounting docs.

P.S. The cream of the crop isn't malware that is designed to attack users/endpoints, but malware designed to attack servers, so in this case you have to be able to come up with a pretty clever heuristic and or statistical models to figure out if you are running in a researcher's VM or inside a valid target ;)

At least one malware crew even setup a specific C&C server for researchers. The malware still would install correctly if detected a VM but it would use a different domain generation algorithm that would connect to a completely different infrastructure than the one used for regular infections. This is very difficult to notice as the behavior is no different than what you would expect from a regular infection. http://malware.dontneedcoffee.com/2016/04/bedepantiVM.html

It would be really nice to have physical hardware that identifies the same as the VMware / VirtualBox hardware.

Seems like a pretty decent anti-malware approach! Make my machine appear to be a sandboxed machine -> get left alone.

It is even easier to just do your work on a VM. If malware actually does not work on a VM you are instantaneously protected.

They use heuristics.

https://en.wikipedia.org/wiki/Heuristic_analysis

Heuristics require you to be able to monitor what the malware does, malware detects monitoring techniques such as debugging and sandboxing/emulation.

Heuristic analysis can help you determine if a binary is doing something fishy before you can figure out exactly what it does, it won't help you bypass evasion.

That said an application that doesn't run in a VM is a telltale sign of malware, which is why malware that truly wants to hide would still run but do something completely different.

Most Sandbox solutions do their detection inside the VM so can be beaten by these techniques. Good sandboxes do their detection lower in the stack - typically in the CPU using full system emulation. I use Lastline to protect my networks and it does it this way.

Lastline doesn't only do CPU emulation, I don't know if it's still the case but their "OSX emulation" was a bunch of iMac mini's in a rack not that long ago ;) There are also quite a few ways of detecting Lastline's sandboxing, and there is malware that does this in the wild.

Yes, my understanding is they don't emulate OSX as such - they run code on the Mac Minis. More to do with Apples licensing model requiring hardware for each OSX license than anything else. I'd be interested to know what malware avoids Lastline, I wasn't aware of any and they scored 100% with no false positives in this years NSS Labs test which impressed me.

>I'd be interested to know what malware avoids Lastline

The one you don't hear about unless it ends up as front page news ;)

NSS is hardly a benchmark for directed threats.

Manual analysis to mock out the anti-vm checks.

There is a large body of academic research on the topic. Here's a few to get you started:

Emulating Emulation-Resistant Malware https://people.eecs.berkeley.edu/~dawnsong/papers/2009%20emu...

Detecting Environment-Sensitive Malware http://www.syssec-project.eu/m/page-media/3/disarm-raid11.pd...

Revolver: An Automated Approach to the Detection of Evasive Web-based Malware https://www.usenix.org/system/files/conference/usenixsecurit...

MalGene: Automatic Extraction of Malware Analysis Evasion Signature: https://www.cs.ucsb.edu/~vigna/publications/2015_CCS_MalGene...

The solution is quite lovely - uninstall MS Office /s

Or just have a Mac. Even lovelier by same definition.

People will often say: yeah but business! I work with very large corps and never needed MS office. I use Ubuntu mostly. The only occassios I need proprietary software is when working with some proprietary hardware but I usually can get it working under Linux with some effort.

What do you usually use for document editing then, out of curiosity? Google docs? Libreoffice?

Google docs, Libreoffice and, VIM. I usually type everything in vim first; I use Ubuntu with I3 on second hand X220. With xterm + vim (and other terminal apps), I have 18 hours battery life. When a browser or Libre kicks in, the battery drops to < 7 immediately. But after that I copy it to docs or Libre and add images, styling etc. Then I usually export to PDF and send. But as doc works fine. When I get documents from others, Libre office works fine. Never had issues so far (and it's been quite a few years).

This sounds like Luckystrike.

http://www.shellntel.com/blog/2016/9/13/luckystrike-a-databa...

Seriously, the amount of malware that is missed by virus scanners is getting ridiculous. If you run MalwareBytes it seems to catch a lot of stuff that Symantec and McAfee misses entirely.

Considering McAfee goes berserk with the CPU and disk regularly, I'm surprised that it is still unable to do the job properly.

Would anyone here be interested in a Q&A with the author of this article? I may or may not be able to hook that up if there's enough interest.

Why bother opening 3 word documents when you could modify the predicate to only terminate the program if less than 0?

Malware might be designed to run a kind of self-test to see if it's been tampered with, in order to A) prevent detection and reverse-engineering and B) discourage code reuse by other malware writers

Original link, rather than threatpost blogspam: https://sentinelone.com/blogs/anti-vm-tricks/

Thanks. We've changed the URL to that from https://threatpost.com/malware-evades-detection-with-novel-t..., and the title to a representative phrase from the article.

Submitters: HN prefers original sources. This is in the site guidelines (https://news.ycombinator.com/newsguidelines.html).

This is such a clickbaity title, and it's absolutely nothing new.

It seems that the only new thing according to the article is that "less sophisticated" malware is using a "more sophisticated" technique.

Seconded. The headline calls it a "novel technique" and then the article goes on to explain how no part of it is actually novel.

We do clickbait now?

Old news. Lastline has been beating this evasion technique for a while now.

Reply on news.ycombinator.com