EverythingIsLife: A Masquerading Cryptocurrency Mining Campaign
Cryptocurrency mining is the process of solving complex algorithms to mine a particular cryptocurrency. This requires a lot of processing power to make substantial profits. Cybercriminals use cryptocurrency mining malware to distribute these processing requirements by having compromised systems mine the cryptocurrency for them.
This is something that has been leveraged by nation-states as a way to soften the blow of international sanctions.
The Awake Labs team identified a cryptocurrency mining campaign across multiple customers and industries, where the same tools and techniques were used, and the same domains were used over an extended period of time. The first observed instance of this was September 01, 2021, the most recent was March 21, 2022. Unfortunately, in each instance, the impacted devices were already infected prior to their connecting to the network.
Below we walk through the detection and analysis, including analysis of the network traffic and files associated with the activity. This analysis, coupled with the similarities observed across all three customers, leads to our conclusion that this is a non-targeted cryptocurrency mining campaign.
Arista NDR Adversarial Model Detections
In each of the above cases, the Awake Labs Managed Network Detection and Response (MNDR) team was alerted to the same detection model: Defense Evasion: Communication To Domains Attempting To Conceal Identity. This activity was observed in three different customer environments, all detecting connections to the same domain.
This detection model alerts when a device makes an HTTP or HTTPS connection to a domain whose name includes one or more joining symbols combined with another potential domain as a sub-string; for example good.com-bad[.]com.
The model also leverages Arista’s AVA, our AI-driven autonomous virtual assistant, to check domain reputation based on various sources of intelligence and only alerts if the domain is found to be risky.
In this case, the domain was categorized by AVA under Phishing and Other Frauds and was given a risk score of Medium (out of Low, Medium, and High).
In each instance observed by the MNDR team, the fully qualified domain name (FQDN) that generated the alert was very similar to www[.]google[.]com[.]682139237721761[.]windows-display-service[.]com. The only difference is that the number in the middle is changeable and random.
As can be seen, FQDN contains google[.]com and a reference to Windows, which could lead some to believe this domain is legitimate and would fall under the MITRE ATT&CK® tactic Defense Evasion, with the specific technique being Masquerading.
Navigating to the site via a web browser presents the below:
However, when the team inspected the page source this suspicious-looking code was spotted, which creates a hidden iFrame if certain conditions are met:
This then goes on to make a connection to hxxps[://]www[.]<long_random_number>[.]best-system-tools[.]com. The long random string is generated as part of the iFrame’s creation.
In attempting to navigate to the domain best-system-tools[.]com via a web browser, there was a failure to connect. Given this apparent dead end, the team turned to VirusTotal search results for the domain windows-display-service[.]com which showed multiple Visual Basic (VB) files; identified as malicious and seen communicating with the domain. Nearly all the files are called “Windows Updates Service.vbs” or “Windows Updates Service.vbe”:
Figure 3: Files communicating with the windows-display-service[.]com domain, according to VirusTotal
Upon analysis of one of the sample files, it was found to use ping to check the status of the variable website, which contains the windows-display-service[.]com FQDN. It then attempts to launch Chrome “headlessly” (i.e. in the background without the UI) to connect to the specified remote host with remote debugging enabled on port 9222. If this fails, it will try to do similar to Firefox but will create a Firefox profile “user” first.
Knowing that the script uses Headless Chrome also lines up with the observations on the user agent observed for the alerting activity within the Arista NDR platform:
Figure 4: User-agent observed in the connections as shown in the Arista NDR platform
Pivoting in the Arista NDR Platform
Based on the above, the team created a search to run across the specific user agent string provided. The first one used was for this specific user-agent:
However, to detect more broadly, the scope was widened to the below query:
This looks for the string “headless” (case insensitive) within the user agent string, but only on connections towards external destinations. The results of this search were quite interesting. Not only did this query return results for connections to windows-display-service[.]com, but also another domain being connected to from the same device, much more frequently: donttbeevils[.]de (more on this later):
Figure 5: Results of the user agent query above – note the CONNECT requests occurred because this was going through a customer’s proxy
When searching for this domain on ThreatCrowd, the relationship graph indicates this activity is highly likely related to cryptocurrency mining (also note the relationship to the domain trustiseverything[.]de):
Figure 6: ThreatCrowd graph indicating this connection is likely related to cryptocurrency mining
Dynamic File Analysis
In order to determine the functionality of the suspected malicious VB script, the team performed some dynamic analysis to observe it in action.
While reviewing Windows Task Manager, it shows multiple Google Chrome instances were spawned, combined to use a significant amount of memory. It should also be noted that no Chrome windows were visible at this time, each of the Chrome instances shown in the below screenshot is running in the background as a result of the script being launched.
Using Wireshark to monitor the network traffic, a connection to the windows-display-service[.]com FQDN was observed, the user agent again showing that this was using Headless Chrome, which matched with the activity observed in the Arista NDR platform, as shown above in Figure 4.
This was followed by a DNS request for the following FQDN at best-system-tools[.]com, with the expected format based on the analysis of the iFrame shown in Figure 2.
Figure 8: DNS requests for best-system-tools[.]com
Following this response, we also see the HTTP GET request being made for the URL referenced in the “script src” section of the code snippet above.
The pit.js file pulled down is obfuscated but appears to be related to mining and contains a reference to the string “EverythingIsLife”.
An online search for this string brings us to the site crypto-webminer[.]com, further emphasizing the connection to cryptocurrency mining:
Figure 10: Screenshot of the crypto-webminer[.]com domain
When inspecting the source code for this page, the string “EverythingIsLife” is commonplace throughout and is associated with the address of the wallet for the particular cryptocurrency being mined. We again see reference to the trustiseverything[.]de domain which ties in with the relational graph shown in Figure 6:
Figure 11: Inspecting the source code, we see the references to EverythingIsLife and trustiseverything[.]de domain
Going back to the PCAP, this was followed by DNS requests for donttbeevils[.]de, which, as referenced earlier in Figure 5, was also seen in our customer’s environment:
The IP used in this instance was 89[.]58[.]15[.]169. The connections were made towards port 4444, which, although a default port for Metasploit, is also commonly observed being utilized by cryptocurrency mining malware.
A reverse DNS lookup for this IP shows this is likely the case, based on associated domain names. We also see dontbeevils[.]de, as well as our previously noted domain trustiseverything[.]de:
Summary and Conclusions
Cryptocurrency mining malware does not have the same level of impact as a ransomware attack, as it does not typically disrupt an entire network. From the adversary’s perspective since the profits can be generated across many different sources, it does not have to be done in the same network. This could arguably make this a more attractive way for cybercriminals to make money, especially given the lack of focus on it as a “legitimate threat” and the minimal victim impact caused. Moreover, there is potentially more resilience as the victims are spread far and wide.
This is demonstrated here, as we can see that the same infrastructure and IOCs are being observed for this campaign across several of our MNDR customers, but only on a very small number of victim devices per customer. The malware was also found only on user devices and there was no observed attempt to move laterally once infected.
In this article, we have detailed how this particular mining malware campaign works, primarily to provide knowledge to the community so that if somebody identifies the same IOCs on their system, they can understand the threat and remediate it as appropriate.
Thanks to Andrew Callow, Jyotsna Saxena, and Patrick Olsen for contributing to the research and blog post.
|SHA256 hash for pit.js file||97075509E581EB9DF0E5676C254E2A5BD3EC51FFD3ABF3316FB0CF3834458D3F|
|Filename||Windows Updates Service.vbs|
|Filename||Windows Updates Service.vbe|
If you liked what you just read, subscribe to hear about our threat research and security analysis.
Threat Hunting and Incident Response Specialist
Dig Deeper with These Resources
Awake Security 2 Minute Explainer Video
What if security could think? What if it could sense danger, calculate risk, and react quickly based…
The Internet’s New Arms Dealers: Malicious Domain Registrars
This report dives into the results of a multi-month investigation that uncovered a massive global surveillance campaign…