Who's Mining in My Enterprise? New Phost-Miner Discovered
Deep Instinct recently detected a series of suspicious PowerShell events at a major Asia-based aviation enterprise.
Investigation of the events uncovered a persistent, file-less, crypto-currency (Monero) miner which uses TOR infrastructure to remain anonymous.
The malware is composed of a multi-stage PowerShell command which employs reflective-PE injection and run-time code compilation to inject malicious executable content hidden in the Windows Registry directly to the victim machine’s memory.
The events were discovered concurrently to the revelation of a similar type of malware in the same business sector, however, the malware was deemed to be unrelated.
Caption: Attack flow diagram
Scheduled Task Wrapper
As with most cases of file-less malware, the outermost layer is a base64 encoded PowerShell command:
Caption: Outer Base64 encoded PowerShell command
Decoding the encoded command blob reveals code which sets a 2nd encoded command blob as a scheduled task that runs at system startup:
Caption: Scheduled task set to run at system startup, Contains encoded PowerShell command.
Reflective Registry Loader
Decoding the encoded inner command blob, which was set as a scheduled task, reveals a reflective-PE loader based on the notorious Invoke-ReflectivePEInjection module from PowerSploit and PowerShell Empire frameworks, which facilitates multiple forms of code injection.
The loader is designed to decode base64 encoded content from the registry, and self-inject it into its own running process, using some run-time compiled C# code:
Caption: PowerShell snippets to read from registry and self-inject into own running process. “Rlo7F” variable containing decoded content is later given to function “MacbEBXil” as input.
While run-time compilation is not new, it is becoming more and more prevalent with the rising popularity of file-less attacks, and can bear certain advantages for an attacker such as the avoidance of some of PowerShell’s protection mechanisms.
Registry contained Miner payload
Examining the registry entries provided to us by the customer shows a fairly large base64 encoded blob.
Decoding the content stored in the registry reveals the blob contains 2 .DLL file – a 32bit one and a 64bit one, which are loaded by the PowerShell script based on the victim system’s respective bitness:
Caption: Base64 encoded registry entry containing set of 2 separate .DLLs (32bit and 64bit)
From initial analysis, both .DLL files import a single function – VirutalProtect, which is used to protect the malware’s memory, and a single exported function – init, used to execute the malware:
Caption: Imported and exported functions
The bulk of both .DLL’s content is contained in their .data section, the unusually high entropy is suggestive of an encrypted section:
Caption: Malicious .DLL file sections
Examining some strings from the file gives a clear indication that the encryption method used is Salsa20, the same algorithm was employed by GandCrab (v4.0 and onwards) and EternalPetya, but in this case, it is used to encrypt the .DLL’s own content:
Caption: “expand 32-byte k” string, indicative of Salsa20 encryption.
Once running in memory of the current PowerShell process, the malware will initiate communications with a series of TOR nodes, the precise nature and content of these exchanges is still being investigated. A sharp spike in CPU usage also occurs, typical of Crypto-Mining malware.
Eventually an unencrypted exchange of communications takes place which is indicative of a Monero miner:
Caption: Miner network traffic
It is possible that the TOR nodes involved function as mining proxies, used to avoid direct communications with the malware’s mining pool, or avoid disclosure of additional resources. Similarly to what has been recently reported by ESET.
During the past 2 years, Crypto-Mining malware has been in a constant rise, featuring ever-increasing levels of sophistication, utilizing advanced file-less techniques to attack targets in enterprise environments.
While analysis and research of this malware are still ongoing, in light of the above-mentioned findings – we are reasonably convinced that this a new, sophisticated Crypto-miner variant. Fairly distinguishable from other previously documented malware of this type.
A particular point of interest that arose during our analysis is the fact that one of the malware’s communication nodes is on the same IP range as an address involved in the recent Monero project breach, suggesting a possible connection. This is, however, purely circumstantial at this time.
Additional findings shall be published as they become available.
Registry exports (Base64 encoded registry content)
Network – Monero Node
184.108.40.206 (Shares IP range with Monero project breach)