> 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.
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...
> 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.
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.
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.
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.
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.
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 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.
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 )
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.
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.
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
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?
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.
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.
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.
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.
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.
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.
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).
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.
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
This is so simple, it's a one line trick:
> the typical lack of documents in a ... test environment make it easy ... for malware authors to fly under the radarDev environment is dissimilar to prod --> works in dev but not prod. Surprise, surprise.
Original blog: https://sentinelone.com/blogs/anti-vm-tricks/