Last week everybody talked about the WannaCry ransomware, a non-evasive ransomware which exploited vulnerable servers to propagate, successfully infecting anything from digital billboards to the Russian interior ministry. Here at Minerva we took part in the global effort against evil, releasing a free vaccination tool, explaining how you may vaccinate in enterprise-scale.
WannaCry drew attention to other threats exploiting the very same SMB vulnerability (MS-17-010) using the Shadow Brokers’ ETERNALBLUE-DOUBLEPULSAR combination. Unlike WannaCry, there have been no reports on the number of machines infected by the UIWIX ransomware, neither about the “revenues” generated. We assume that it is a direct result of a single major difference between WannaCry and the UIWIX ransomware family used in these threats. WannaCry did not try to evade detection and some researchers reported that their honeypots were infected only three minutes after they were deployed.
UIWIX however employed basic evasion techniques to stay under the radar:
In this blog post, we describe how the UIWIX ransomware bypasses existing security defenses to target endpoints.
A Step-By-Step Analysis of How UIWIX Evades Detection
UIWIX did not invent any new technique, they relied on simple known techniques – starting with a direct test for the presence of a debugger:
Later moving to detect different sandbox solutions, UIWIX checks the loaded modules against a black list a list of DLLs (see full list below):
Afterwards, the ransomware tests if a Cuckoo sandbox pipe is present:
Ironically, the test for the Cuckoo pipe triggers both a signature and returns false even when executed in a Cuckoo sandbox:
Now, UIWIX tests yet another list of DLLs, this time they are VM related:
Tracking the Evasion Techniques’ Source Code
From our analysis, it is quite clear that the coders of this ransomware relied on existing lists of artifacts to create the above “DetectSandbox()” and “DetectVM()” functions.
We found some candidates for the source of the evasion techniques. In the image below, a snippet of code looks for sandbox solutions by the loaded DLLs:
And in this source shows another list collected for the very same purpose:
It appears that those two lists were appended together in UIWIX (with dbghelp.dll and vmcheck.dll tested in a different function):
Another interesting similarity is in the malware code section which tests for VM pipes:
And this is how they appear in a Russian hacking forum called “FuckAV”:
Note how the order of the artifacts is an exact match to the malware!
This list can also be found in legitimate websites:
Why Minerva Aces Against UIWIX
Minerva Anti-Evasion Platform creates a virtual reality that fools the malware, making it believe that it is in a hostile environment. Clever environmentally aware malware like UIWIX will avoid execution in a Minerva-protected endpoint as we make the malware believe it is in a VM or sandbox.
UIWIX is exploiting unpatched machines to execute its DLL without writing itself to the disk. Luckily, Minerva works against any type of evasive threat, including file-less attacks like this one.
Searched VM related DLLs
Searched Sandbox related DLLs
Searched Sandbox Pipes
Searched VM Pipes
(as published by Lawrence Abrams in BleepingComputer)