Authored by: Alexander Sevtsov
Edited by: Stefano Ortolani
It’s not news that the cryptocurrency industry is on the rise. Mining crypto coins offers to anybody a lucrative way to exchange computation resources for profit: every time a miner guesses the solution of a complex mathematical puzzle, he is awarded with a newly minted crypto coin. While some cryptocurrencies are based on puzzles that are efficiently solved by special-purpose devices (such as Bitcoin on ASICs), others are still mined successfully on commodity hardware.
Recent statistics show that 5% of all Monero coins are mined by malware. While the security industry is responding to this cryptojacking phenomenon by introducing new improved detection techniques, developers of these binaries began to replicate the modus operandi of ransomware samples: they started embedding anti-analysis techniques to evade detection as long as possible. In this blog article, we highlight some of our findings when analyzing a variant of the XMRig miner, and share insights about some evasion tricks used to bypass dynamic analysis systems.
The sample (sha1: d86c1606094bc9362410a1076e29ac68ae98f972) is an obfuscated .Net application that uses a simple crypter to load an embedded executable at runtime using the Assembly.Load method. The following XOR key is used for its decryption:
50 F5 96 DF F0 61 77 42 39 43 FE 30 81 95 6F AF
Execution is later transferred via the EntryPoint.Invoke method to its entry point, after which another binary resource is decrypted. Figure 1 shows the encryption (AES-256) and the key derivation (PBKDF2) algorithms used to decrypt the binary.
Figure 1. AES decryption routine of the embedded file; note the PBKDF2 key derivation.
The decrypted data consists of yet another executable. We can see it in Figure 2 surrounded by some strings already giving away some of the functionalities included (in particular, note the CheckSandbox and CheckVM strings, most likely indicating routines used to detect whether the sample is run inside an analysis environment).
Figure 2. Decrypted binary blob with an embedded executable file.
As the reader can imagine, we are always interested in discovering novel evasion techniques. With piqued curiosity, we decided to dive into the code a bit further.
After peeling off all encryption layers, we finally reached the unpacked payload (see Figure 3). As expected, we found quite a number of anti-analysis techniques.
Figure 3. The unpacked payload (sha1: 43f84e789710b06b2ab49b47577caf9d22fd45f8) as found in VT.
The most classic trick (shown in Figure 4) merely checked for known anti-analysis processes. For example, Process Explorer, Process Monitor, etc., are all tools used to better understand which processes are running, how they are spawned, and how much CPU resources are consumed by each executing thread. This is a pretty standard technique to hide from such monitoring tools, and it has been used by other crypto miners as well. As we will see, others were a bit more exotic.
Figure 4. Detecting known process monitoring tools via GetWindowTextW.
Evasion Technique – Lack of User Input
This technique specifically targets dynamic analysis systems. It tries to detect whether it is executing on a real host by measuring the amount of input received by the operating system. Admittedly, this is not that rare, and we indeed covered it before in a previous article describing some evasion techniques as used by ransomware.
Figure 5. Detecting sandbox by checking the last user input via GetLastInputInfo.
Figure 5 shows the logic in more details: the code measures the time interval between two subsequent inputs. Anything longer than one minute is considered an indicator that the binary is running inside a sandbox. Note that besides being prone to false positives, this technique can easily be circumvented simulating random user interactions.
Evasion Technique – Multicast IcmpSendEcho
The second anti-analysis technique that we investigated delays the execution via the IcmpCreateFile and IcmpSendEcho APIs. As it is further detailed in Figure 6, they are used to ping a reserved multicast address (22.214.171.124) with a timeout of 30 seconds. Ideally, as no answer is meant to be returned (interestingly enough we have knowledge of some devices erroneously replying to those ICMP packets), the IcmpSendEcho API has the side effect of pausing the executing thread for 30 seconds.
Figure 6. Delaying the execution via IcmpSendEcho API.
It’s worth noticing that a similar trick has been previously used by some infected CCleaner samples. In that case, the malicious shellcode was even going a step further by checking if the timeout parameter was being patched in an attempt to accelerate execution (and thus counter the anti-analysis technique).
Any dynamic analysis system wishing to cope with advanced evasive malware must be able to unpack layers of encryption and counter basic anti-analysis techniques. In Figure 7 we can see all the behaviors extracted when fully executing the original sample: the final payload is recognized as a variant of the XMRig Monero CPU Miner, and its network traffic correctly picked up and marked as suspicious.
Figure 7. Lastline analysis of the XMRig CPU miner.
Nevertheless it is quite worrying that anti-analysis techniques are becoming this mainstream. So much so that they started to turn into a standard feature of potentially unwanted applications (PUA) as well, including crypto-miners. Hopefully, it is just an isolated case, and not the first of a long series of techniques borrowed from the ransomware world.
Appendix – IOCs
Attached below the reader can find all the hashes related to this analysis, including the mutex identifying this specific strain, and the XMR wallet.
Sha1 (sample): d86c1606094bc9362410a1076e29ac68ae98f972
Sha1 (payload): 43f84e789710b06b2ab49b47577caf9d22fd45f8
The post Evasive Monero Miners: Deserting the Sandbox for Profit appeared first on Lastline.