The Varonis Security Research team recently investigated an ongoing crypto mining infection that had spread to nearly every device at a mid-size company. Analysis of the collected malware samples revealed a new variant, which the team dubbed “Norman” that uses various techniques to hide and avoid discovery. We also discovered an interactive web shell that may be related to the mining operators.
Research overview
Want to learn ransomware basics and earn a CPE credit? Try our free course.
- We found a large-scale infection of crypto miners; almost every server and workstation in the company was infected.
- Since the initial infection, which took place over a year ago, the number of variants and infected devices grew.
- Norman employs evasion techniques to hide from analysis and avoid discovery.
- Most of the malware variants relied on DuckDNS (a free, Dynamic DNS service). Some needed it for command and control (C&C) communications, while others used it to pull configuration settings or to send updates.
- Norman is an XMRig-based crypto miner, a high-performance miner for Monero cryptocurrency.
- We have no conclusive evidence that connects the crypto miners to the interactive PHP Shell. However, we have strong reason to believe they originate from the same threat actor. We make a case whether they may or may not be connected.
- We provide tips for defending against remote web shells and crypto miners.
The investigation
The investigation began during an evaluation of our Data Security Platform, which quickly raised several suspicious network-related alerts for abnormal web activity alongside correlated abnormal file activities. The customer quickly realized the devices flagged by the Varonis platform belonged to the same users who had reported recent unstable applications and network slowdowns.
Varonis’ Forensics team manually investigated the customer’s environment, hopping from infected station to station based on the alerts generated by Varonis. Varonis’ Incident Response team implemented a custom rule in DatAlert to detect machines that were actively mining and quickly contained the incident. The team forwarded malware samples to our Forensics and Research teams, which determined that additional investigation was needed.
Infected hosts were easily detected by their use of DuckDNS, a dynamic DNS service that allows its users to create custom domain names. As stated above, most of the malware from this case relied on DuckDNS for command and control (C&C) communications, to pull configuration settings or send updates.
Almost every server and workstation was infected with malware. Most were generic variants of crypto miners. Some were password dumping tools, some were hidden PHP shells, and some had been present for several years.
We delivered our findings to the customer, removed the malware from their environment, and the infection stopped.
Out of all the crypto miner samples that we found, one stood out. We named it “Norman.”
Meet “Norman” the crypto miner
Norman is an XMRig-based crypto miner, a high-performance miner for Monero cryptocurrency. Unlike other miner samples we have collected, Norman employs evasion techniques to hide from analysis and avoid discovery.
At first glance, the malware seemed to be a generic miner hiding itself as “svchost.exe.” However, the techniques it used proved to be more interesting.
The malware’s deployment can be divided into three stages:
- Execution
- Injection
- Mining
A step-by-step analysis
Stage one: execution
The first stage starts with the svchost.exe executable.
The malware is compiled with NSIS – “Nullsoft Scriptable Install System,” which is unusual. NSIS is an open-source system used to create Windows installers. Like SFX, it creates a file archive and a script file that runs when the installer executes. The script file instructs the program which files to run and can interact with the other files inside the archive.
Note: to get the NSIS script file from the executable, you’ll need to use 7zip version 9.38, as the function is deprecated in later versions.
The NSIS archived malware contains the following files:
- CallAnsiPlugin(dot)dll, CLR.dll – NSIS modules for calling .NET DLL functions.
- 5zmjbxUIOVQ58qPR(dot)dll – Payload main DLL
- 4jy4sobf(dot)acz, es1qdxg2(dot)5pk, OIM1iVhZ.txt – Payload data files
- Retreat(dot)mp3, Cropped_controller_config_controller_i_lb(dot)png – Miscellaneous files that are not related to the malware
The command from the NSIS script file that runs the payload:
The malware is executed by calling a function in 5zmjbxUIOVQ58qPR(dot)dll which accepts the other files as parameters.
Stage two: injection
The 5zmjbxUIOVQ58qPR(dot)dll file is the main payload, according to the above NSIS script. A quick look at the metadata showed that the DLL was originally named “Norman.dll’’, and thus, we named it so.
The DLL is built with .NET and triple obfuscated with Agile obfuscator, a known commercial .NET obfuscator.
Execution involves many payload injections into itself and other processes. Depending on the OS’s bit type, the malware will choose a different execution path and launch different processes.
Based on the execution path, the malware will choose different processes to launch:
The injected payload has two main functions: execute the crypto miner and evade detection.
If the OS is x64
As the original svchosts.exe (the NSIS file) executes, it creates another process of itself and injects a payload into it (1). Soon after, it executes either Notepad or Explorer and injects the crypto miner into it (2).
The original svchost.exe is then terminated, and the newer svchost.exe is used as a watchdog for the miner process.
If the OS is x32
The original svchosts.exe (the NSIS file) executes, creates another instance of itself and injects with the payload like the 64x variant.
This time the malware will inject the payload into the user’s explorer.exe process. From there, it will launch either wuapp.exe or svchost.exe and inject the miner into it.
The malware hides the injection to explorer.exe by overwriting the injected payload with wuapp.exe’s path and nulls.
Like with the x64 execution path, the original svchost.exe is terminated and the second svchost.exe is used as a watchdog that will reinject the explorer.exe if needed, for example, if the process is terminated by the user.
At the end of either the x64 or the x32 execution tree, the malware will always inject the crypto miner into a legitimate process that it launches.
Once running, the malware is designed to avoid detection by terminating the miner when a user opens Task Manager.
Notice how when the Task Manager process starts, the wuapp.exe is terminated.
After Task Manager closes, the malware will execute the wuapp.exe process and reinject the miner.
Stage three: miner
Let’s take a look at the XMRig miner mentioned earlier.
The malware injects a UPX obfuscated version of the miner to either Notepad, Explorer, svchost or wuapp depending on the execution path.
The miner’s PE header was removed, and we can see that it is obfuscated with UPX:
After dumping and rebuilding the executable, we were able to run it:
Note that the XMR address is banned, which effectively disables this miner.
The miner’s configurations:
"url": "pool.minexmr.com:5555","user": "49WvfokdnuK6ojQePe6x2M3UCD59v3BQiBszkuTGE7wmNJuyAvHM9ojedgxMwNx9tZA33P84EeMLte7t6qZhxNHqHyfq9xA","pass": "x"
A mysterious PHP shell transmitting to C&C
During our ongoing investigation, our Forensics specialists revealed an XSL file that caught our eye. After our in-depth analysis of the sample, we revealed a new PHP-shell that continually connects to a command-and-control (C&C) server.
On multiple servers in the customer’s environment, we found an XSL file being run by known Windows executable mscorsv.exe from a folder under sysWOW64.
The malware’s folder was named “AutoRecover” and contained multiple files:
- The XSL file, xml.XSL
- Nine dynamic link library files (DLLs)
Executables
-
-
- Mscorsv(dot)exe
- Wmiprvse(dot)exe
-
The XSL file
XSL files are style sheets, like those that are used with CSS, that describes how to display an XML document.
Using Notepad, we identified that the file was not an XSL file, but Zend Guard obfuscated PHP code. This interesting fact led us to the assumption that this is the malware’s payload based on the execution pattern.
The nine DLLs
After a quick look at the XSL file, the nine DLLs made sense.
In the main folder, there is a DLL called php.dll and three other libraries related to SSL and MySQL.
In the subfolders, we found four PHP libraries and one Zend Guard library. All of these are legitimate and come with the installation of PHP or as external libraries.
At this point, we felt we could safely assume that the malware was based on PHP and obfuscated by Zend Guard.
The executables
There were two executables: Mscorsv.exe and WmiPrvSE.exe
By looking into mscorsv.exe, we found that it was not signed by Microsoft, though its “ProductName” was “Microsoft© .Net Framework.”
This seemed odd at first, but moving forward to the Wmiprvse.exe executables explained it.
The Wmiprvse.exe was not signed, but was copyrighted to the PHP group and had a PHP icon. A quick look at its strings shows the PHP help manual’s commands.
Running the -version parameter revealed it to be an executable made to run Zend Guard.
The mscorsv.exe and running strings produced almost the same output as the Wmiprvse.exe. Running it with -version prints the same data to the screen.
We compared the binary data of the two files and saw that they were the same except for the “Copyright” and “Company Name”/”Product Name.”
Therefore, we concluded that the XSL file contains PHP code that runs using the Zend Guard executable, which is disguised as mscorsv.exe.
Deciphering the XSL file
A quick Google search provided us with a Zend Guard deobfuscator and a deobfuscated xml.XSL file.
The malware itself turned out to be a PHP shell that continually connects to a command-and-control (C&C) server.
The commands and output that it sends and receives are encrypted. Because we had the source code, however, we had both the encryption key and the commands.
The malware itself has a few built-in capabilities:
- Eval – mostly used to modify existing variables in the code
- Writing a file locally
- DB capabilities
- PSEXEC capabilities
- Hidden execution
- Process and service mapping
According to the following variable, it seems like the malware has multiple versions:
The versions that we spotted were:
-
-
- 0.5f
- 0.4p
- 0.4o
-
The malware’s only persistency is that, upon execution, it creates a service that executes itself and its name changes from version to version.
By digging on the internet for similar samples, we found malware that seemed to be a previous version of our sample. The folder’s content was similar, but the XSL file was different, and its contents showed a different version number.
Parlez-vous malware?
The malware may have originated from France or another French-speaking country: the SFX file had comments in French, which indicate that the author used a French version of WinRAR to create the file.
Moreover, some variables and functions in the code were in French:
Watching and waiting for new commands
We modified the code and ran the malware so that it would inform us about commands it received:
After the initial session, we can see that the malware receives a base 64 encoded command for the EVAL64 switch.
The encoded command is decoded and executed. It changes a few of the internal variables (read and write buffer size), and then the malware enters a loop as it waits for commands.
As of today, we have not received new commands.
Interactive PHP shells and crypto miners: are they connected?
We are uncertain whether Norman is connected to the PHP shell, as there are valid arguments for both cases:
Why they may be connected
- None of the malware samples had any lateral movement capabilities, though they had spread across different devices and network segments. Though the threat actor could have infected each host individually (perhaps via the same vector used in the initial infection), it would have been more efficient to use the PHP-Shell to move laterally and infect other devices in the victim’s network.
- Large-scale and targeted campaigns against an organization often leave technical artifacts or generate threat intelligence leads; we found none in this case.
- Both Norman and the PHP shell used DuckDNS.
Why they may not be connected
- There are no technical similarities between the crypto mining malware variants and the PHP-shell. The crypto-malware was developed in C\++ while the shell was in PHP, the code structures show no similarities, and the network functionalities are implemented differently.
- There are no communication capabilities between the malware variants and the PHP-shell.
- They lack common dev comments, files, metadata, or “fingerprinting.”
Three tips to defend against remote shells
Malware that relies on commands from C&C servers to operate are a different type of threat than the average virus. Their actions will not be as predictable and will likely resemble the actions of a manual attack or pentester. As such, detecting these attacks will be a bit more difficult than running an AV scan.
Here are three tips to defend your company against remote shells:
- Keep all software up to date. Attackers often exploit vulnerabilities in software and operating systems to move laterally in the organization and steal data. Staying up to date with patches greatly reduce the risk of threats.
- Monitor abnormal data access. An attacker will most likely try to exfiltrate sensitive data from the organization. Monitoring abnormal users access to sensitive data could help detect compromised users and data that might have been exposed.
- Monitor network traffic. By using a firewall or proxy, it is possible to detect and block malicious communication to C&C servers, thus preventing the attacker from executing commands or extracting data.
Concerned about crypto miners? Six tips to help protect your business
- Keep all operating systems up to date. Patch management is crucial to prevent exploitations and unwanted infections.
- Monitor network traffic and web proxies. It is possible to detect and prevent a portion of attacks by blocking traffic based on malicious domains or restricting unnecessary communications.
- Use and maintain antivirus and endpoint-based solutions (but don’t let that be your only layer of defense). Endpoint products should be able to detect well-known crypto miners and prevent infections before any damages occur. Keep in mind that new variants or new evasion techniques can bypass endpoint security products.
- Monitor CPU activity on computers. Crypto miners generally use the computer’s CPU to mine. Any noticeable degradation in processing speed requires investigation.
- Monitor DNS for unusual use of dynamic DNS services (like DuckDNS). While DuckDNS and other dynamic DNS services play a legitimate role, malware’s use of DuckDNS made it easier for our teams to detect infected hosts in this investigation.
- Have an IR plan ready. Make sure you have the right procedures for similar incidents, and be capable of automatically detecting, containing, and remediating crypto miners.
Note to Varonis customers: Varonis DatAlert includes threat models that detect crypto mining malware. Customers can also create custom rules to provide dedicated detections against potentially blacklisted domains. To verify you’re running the most recent version of DatAlert and have the correct threat models enabled, please reach out to your sales teams or Varonis support.
