Evasive Monero Miners: Deserting the Sandbox for Profit

Evasive Monero Miners: Deserting the Sandbox for Profit

Authored by: Alexander Sevtsov
Edited by: Stefano Ortolani

Introduction

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.

One, in particular, is the Monero (XMR) cryptocurrency. Besides being efficiently mined on standard CPUs and GPUs, it is also anonymous, or fungible to use the precise Monero term. This means that while it is easy to trace transactions between several Bitcoin wallets, a complex system relying on ring signatures ensures that Monero transactions are difficult if not impossible to trace, effectively hiding the origin of a transaction. Because of this, it should come as no surprise that the Monero cryptocurrency is also used for nefarious purposes, often mined by rogue javascripts or binaries downloaded onto and running on an unsuspecting user’s system.

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.

Dropper

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:

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

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.

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.

Payload

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

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

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

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 (224.0.0.0) 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.

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).

Conclusions

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.

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.

Alexander Sevtsov

Alexander Sevtsov

Alexander Sevtsov is a Malware Reverse Engineer at Lastline. Prior to joining Lastline, he worked for Kaspersky Lab, Avira and Huawei, focusing on different methods of automatic malware detection. His research interests are modern evasion techniques and deep document analysis.
Alexander Sevtsov
Stefano Ortolani

Stefano Ortolani

Stefano Ortolani is Head of Threat Intelligence at Lastline. Prior to that he was part of the research team in Kaspersky Lab in charge of fostering operations with CERTs, governments, universities, and law enforcement agencies. Before that he earned his Ph.D. in Computer Science from the VU University Amsterdam.
Stefano Ortolani