Security News Clever Malware Is Clever, Adds New Anti-Detection Tricks

[Exterminator]

Recent versions of the Ursnif banking trojan have added a new series of tricks that allows the malware to detect when it's being analyzed in a virtual machine or a sandbox environment.

These recent Ursnif samples have been seen recently, in the month of September, spread via macro-laced Office files attached to spam emails.

Before downloading and installing the malware, these macro scripts would perform a series of checks to determine if the PC they landed on is a real computer or a virtual machine or sandbox environment.

Proofpoint researchers identified four checks, of which, two were new, never seen before.

Checking files names for only decimal characters
The first new check was a lookup for unique characters in the names of local files. The macro script was specifically looking to see if local files contained only hexadecimal characters in their names.

Files submitted to analysis in sandbox environments and VMs are often renamed based on their SHA256 or MD5 hash, in order for researchers to keep track of the exact payload. SHA256 and MD5 hashes are only made up of the hexadecimal character set: 0123456789ABCDEFabcdef.

If the macro script found files with other types of characters, such as "w," "=," or "#," then it knew this was a regular PC and not a researcher's box, and go on with its installation procedure.

Second check looks for bloaty PCs
The second check is even more clever, with the macro script using the Application.Tasks.Count function to query the local OS for the presence of running processes with a graphical interface.

If the script found less than 50, the macro script would stop, thinking this was a test box for detecting malware.

"A quick check of a real system shows that it is common to have more than 50 tasks, while sandbox systems are optimized to have as few as possible," the Proofpoint staff explained this check.

Former "new" anti-VM tricks become old anti-VM tricks
Besides these two new checks, the macro script also employed two checks that are relatively new but have been before. The macro script would first check for the presence of process names that included blacklisted terms, such as the names of VM vendors or reverse engineering software.

Then, the macro script would use the Maxmind API to detect the user's IP address, and compare the IP to a list of known IP ranges assigned to security firms and data centers, where VMs and malware analysis toolkits are often hosted.

Anti-VM tricks trickles down from top-shelf banking trojans to low-level keyloggers
This last trick was seen before this past June, by both Proofpoint and Zscaler. Along with the Maxmind-powered query, the Proofpoint and Zscaler teams also detected macro scripts querying the local computer for the list of recently opened files.

If the number was less than three, the macro script would know this was a freshly installed VM, just for the purpose of analyzing malware and stop the installation process.

In June, Proofpoint detected the Dridex banking trojan employing these tricks (Recent Files check and Maxmind query), while Zscaler detected these two with the Matsnu backdoor trojan, the Nitol backdoor trojan, and the Nymaim ransomware.

These two checks appeared to have become standard practice now, with SentinelOnereporting in September that basic keyloggers were also using these anti-VM techniques.

 

[_CyberGhosT_]

This is not very surprising seeing that it is becoming
ever more popular for malware to be Sandbox & VM aware.
This does not bode well for testers in the future as more malware authors
adopt this ability into their malware coding
Cool Share Exterminator

 

[frogboy]

Way to clever for my liking.

 

[hjlbx]

Some variants of Ursnif are fileless malware; it resides in the registry. It abuses powershell.exe to obtain persistence on the system.

Whether you use a sandbox or not, unknown\untrusted files should be executed with restricted access rights.

Powershell should be disabled by default user-created policy. If you must have powershell enabled on your system, then it should be run with restricted access rights.

 

[jamescv7]

Usually those anti-VM techniques are only kill itself or not continue the process; however it makes a trap also in order to confuse users to test more outside the environment.

 

[Solarquest]

I think we should add a thread in the Hub on how to make different VMs less detectable.
I saw many samples that don't do anything in the HUB reports but that are classified as malware by many AVs, they are VM aware.
Now we got some good infos..open many files, install some programs, rename detection tools etc...thanks for sharing!

 

[_CyberGhosT_]

I think we should add a thread in the Hub on how to make different VMs less detectable.
I saw many samples that don't do anything in the HUB reports but that are classified as malware by many AVs, they are VM aware.
Now we got some good infos..open many files, install some programs, rename detection tools etc...thanks for sharing!

Extremely good idea Solar

 

[Xtwillight]

Some time ago.
haben sich Malware analysts to the theme written.

• There are possibilities Virtual Systems in front Malware to protect
  in front retrieval if the Malwareware in a Virtual Systems is.
  

 

[LabZero]

Old story, but now more and more malware use anti-virtualization routines or methods.
The physical system just for this purpose is the best alternative.

 

[LabZero]

I think we should add a thread in the Hub on how to make different VMs less detectable.
I saw many samples that don't do anything in the HUB reports but that are classified as malware by many AVs, they are VM aware.
Now we got some good infos..open many files, install some programs, rename detection tools etc...thanks for sharing!

You can't make VM less detectable by their nature.
VM through a process of virtualization, create a virtual environment that emulates typically the behavior of a physical machine by assigning hardware resources but specific malware detects this behavior in many ways.

 

[Xtwillight]

Old story, but now more and more malware use anti-virtualization routines or methods.
The physical system just for this purpose is the best alternative.

That is true what you write"The physical system just for this purpose is the best alternative"!
That is true what you write in: https://malwaretips.com/threads/cle...-new-anti-detection-tricks.63742/#post-546681

Exactly this requests Are Tried, in the VMs from Malware analysts (producers from AV) to control.
It is a cat and mouse game.

 

[Solarquest]

I think we can make VM less detectable as suggested above and I remember reading some changes you could make in the VM config to make it this way, I have it somewhere (but it said it might make the VM "weaker")...of course APT will be smarter than us..but we probably won't test these.. and we just want to get more of the no -apt ones.
http://blog.michaelboman.org/2014/01/making-virtualbox-nearly-undetectable.html?m=1

http://handlers.sans.org/tliston/ThwartingVMDetection_Liston_Skoudis.pdf

 

[askmark]

Not sure if any other software does this, but *Hitman Pro.Alert actually uses the malware's anti-VM detection against itself to help prevent the pc being infected. It does this by fooling the malware into believing its running in a virtual environment even when it's not.

*beta version.

 

[exCode]

This is pretty cool. Not in a good way, but it's interesting that malware developers have discovered new ways to hide their viruses.

 

[Tony Cole]

Scary stuff - then HSBC wonders why (even calls me!) I no longer use mobile or internet banking.

 

[Solarquest]

I was googling in the last days a little bit and got some infos.
Apparently a good programmer is able to detect the VM/it is not possible to hide a VM, at least not for "normal users"...but there are ways to "harden the VM" to make it a little harder to be detected.
Vmware is easier to be "hardened" than Virtualbox.
I'll keep looking "around" and maybe post a summary of my findings.

If someone has infos, links, pls let me know.

http://www.unibia.com/unibianet/sys...-virtual-machine-detection-vmware-workstation

https://blog.malwarebytes.com/threa...ok-at-malware-with-virtual-machine-detection/

An easy way to harden a little the detection of VM is also to change name of the executables used, e.g. to launch the VM, of all detection tools used inside the VM, Process explorer, tcpview, autoruns...

 

[LabZero]

Sure you can use tweaks (some of them are quite old) for this purpose, but we have no certainty that these changes can be effective against the latest malware and their variants.
We do not forget that virtualization is primarily used in the business environment where it offers a easy way to manage data, financial transactions and all applications necessary to the company.
The fact that many malware are written to recognize the VM is not only oriented to avoid malware research or AV testing but especially for bypass systems companies to attack them.

This feature makes virtual environments very interesting for criminals, who then look to virtualization with greater commitment and obviously a malware that uses specific/advanced anti-virtualization routines, can put itself in sleep mode even on our home VM.

A simple example:

One of the main differences between the physical system and a virtualized one is the execution speed.
Some malware use temporal metrics to verify the processor clock.
Fool these malware by falsifying the info on the clock is very difficult.

 

[Solarquest]

All we can do is reasearch, impkement and test...even if we get 10-20% more, I ' m happy...then we try to do better...at the end somehow it's possible, if not AV, MW analysts etc wouldn't be able to do their job.
Of course we'll never be able to get a VM/sandboxed environment as they have and this is not my objective.
I just want to improve my knowledge , to learn more and to be able to detect and maybe analyze more MW samples.

 

[LabZero]

All we can do is reasearch, impkement and test...even if we get 10-20% more, I ' m happy...then we try to do better...at the end somehow it's possible, if not AV, MW analysts etc wouldn't be able to do their job.
Of course we'll never be able to get a VM/sandboxed environment as they have and this is not my objective.
I just want to improve my knowledge , to learn more and to be able to detect and maybe analyze more MW samples.

Yeah, I agree with that and I got your point, we can do research and definitely improve, also because this context is poorly documented.
@Solarquest, I think you should open a specific thread where we can post and comment about this

 

[NekoHr]

For those interested there is a topic about VirtualBox hardening on Kernelmode.info.