Our Information Security Investigation Unit recently investigated a network that was almost completely infected with a crypto-mining virus in a mid-sized company. Analysis
collected malware samples showed that a new modification was found
such viruses, called , using various methods to hide its presence. In addition, it was discovered , which may be related to mining operators.
Study Overview
- Varonis has identified a large-scale infection with cryptominers: almost all servers and workstations in the company were infected with such software
- Since the initial infection more than a year ago, the number of modifications and infected devices has steadily increased
- The new kind of cryptominer Monero (Norman) we discovered uses various methods to hide it from analysis by security software in order to avoid detection.
- Most of the malware variants used DuckDNS (a free Dynamic DNS service) to connect to the control center (C&C servers), as well as to obtain configuration parameters or send new data
- Norman is a high-performance Monero cryptocurrency miner based on an open source miner - XMRig
- We do not yet have conclusive evidence linking cryptominers with an interactive PHP shell. However, there are good reasons to believe that the same attacker is their source. Researchers are collecting additional evidence of the presence or absence of such a link.
- In this article, you can read Varonis recommendations regarding protection against remote web shells and cryptominers.
Investigation
The investigation began during another pilot project (Varonis Data Security Platform), which made it possible to quickly identify several suspicious anomalous events at the network level when making requests to the Internet (through a web proxy) associated with anomalous actions on the file system.
The customer immediately pointed out that the devices identified by our Platform
belonged to the same users who recently reported app crashes and network slowdowns.
Our team manually explored the customer's environment, moving from one infected station to another according to the alerts generated by the Varonis Platform. The incident response team, on the other hand, has developed a special rule in to detect computers on which mining was actively carried out, which helped to quickly eliminate the threat. Samples of the collected malware were sent to the forensics and development teams, who said that additional analysis of the samples was needed.
Infected hosts were discovered due to the calls they used to DuckDNS, a Dynamic DNS service that allows its users to create their own domain names and quickly map them to changing IP addresses. As noted above, the bulk of the malware in the incident accessed DuckDNS for connections to the control center (C&C), while the other part was used to obtain configuration parameters or send new data.
Almost all servers and computers were infected with malware. Mainly used
common variants of cryptominers. Other malware was also password dumping tools, PHP shells, and a number of tools have been working for several years.
We provided the results to the customer, removed the malware from their environment, and stopped further infection.
Among all the discovered samples of cryptominers, one stood out. We named him Norman.
Meet! norman. Cryptominer
Norman is a high performance Monero cryptocurrency miner based on the XMRig code. Unlike other miner samples found, Norman uses ways to hide it from analysis by security software to avoid detection and prevent further distribution.
At first glance, this malware appears to be a common miner hiding under the name svchost.exe. However, research has shown that it employs more interesting methods of hiding from detection and maintaining work.
The deployment process of this malware can be divided into three stages:
- performance;
- implementation;
- mining.
Step by step analysis
Stage 1. Execution
The first stage starts with the svchost.exe executable.
The malware is compiled using NSIS (Nullsoft Scriptable Install System), which is unusual. NSIS is an open source system used to create Windows Installers. Like SFX, this system creates a file archive and a script file that is executed while the installer is running. The script file tells the program which files to run and can interact with other files in the archive.
Note: To get the NSIS script file from the executable, you must use 7zip version 9.38, since this feature is not implemented in later versions.
The NSIS archived malware contains the following files:
- CallAnsiPlugin.dll, CLR.dll - NSIS modules for calling .NET DLL functions;
- 5zmjbxUIOVQ58qPR.dll - main payload DLL;
- 4jy4sobf.acz, es1qdxg2.5pk, OIM1iVhZ.txt - payload files;
- Retreat.mp3, Cropped_controller_config_controller_i_lb.png are just files that have nothing to do with further malicious activity.
The command from the NSIS script file that runs the payload is shown below.
The malware is executed by calling the 5zmjbxUIOVQ58qPR.dll function, which takes other files as parameters.
Stage 2. Implementation
The 5zmjbxUIOVQ58qPR.dll file is the main payload as seen in the above NSIS script. A quick look at the metadata showed that the DLL was originally named Norman.dll, which is why we named it that.
The DLL file is developed in .NET and protected from reverse engineering by triple obfuscation
using the well-known commercial product Agile .NET Obfuscator.
During execution, many self-injection operations are involved in their own process, as well as in other processes. Depending on the bitness of the OS, malware will
choose different paths to system folders and run different processes.
Based on the path to the system folder, the malware will choose different processes to run.
The injected payload has two main functions: executing a cryptominer and preventing detection.
If the OS is 64-bit
When executing the original svchosts.exe (NSIS file), it creates a new native process and injects the payload (1) into it. Shortly thereafter, he launches notepad.exe or explorer.exe and injects a cryptominer into it (2).
After that, the original svchost.exe file is terminated, and the new svchost.exe file is used as a program that monitors the work of the miner process.
If the OS is 32-bit
During the execution of the original svchosts.exe file (NSIS file), it duplicates its own process and injects the payload into it, just like in the 64-bit version.
In this case, the malware injects the payload into the user process explorer.exe. Already from it, the malicious code launches a new process (wuapp.exe or vchost.exe), and injects a miner into it.
The malware hides the fact of injection into explorer.exe by overwriting previously injected code with the path to wuapp.exe and empty values.
As in the case of running in a 64-bit environment, the original svchost.exe process exits and the second one is used to re-inject malicious code into explorer.exe if the process is terminated by the user.
At the end of the execution algorithm, malware always injects a cryptominer into a legitimate process it launches.
It is designed to prevent detection by shutting down the miner when the user launches the Task Manager.
Please note that after starting the Task Manager, the wuapp.exe process ends.
After closing the task manager, the malware restarts the wuapp.exe process and again
introduces a miner into it.
Stage 3. Miner
Consider the XMRig miner mentioned above.
The malware injects a disguised UPX version of the miner into notepad, exe, explorer.exe,
svchost.exe or wuapp.exe, depending on the bitness of the OS and the stage of the execution algorithm.
The PE header in the miner has been removed and in the screenshot below we can see that it is masked with UPX.
After creating the dump and rebuilding the executable, we were able to run it:
It should be noted that access to the target XMR site is denied, effectively neutralizing this miner.
Miner configuration:
"url": "pool.minexmr.com:5555","user":
"49WvfokdnuK6ojQePe6x2M3UCD59v3BQiBszkuTGE7wmNJuyAvHM9ojedgxMwNx9tZA33P84EeMLte7t6qZhxNHqHyfq9xA","pass":"x"Mysterious PHP shell passing data to C&C
During this investigation, our forensic experts found an XSL file that caught their attention. After a deep analysis of the sample, a new PHP shell was discovered that constantly connects to the control center (C&C server).
On several servers in a customer's environment, an XSL file was found that runs a known Windows executable (mscorsv.exe) from a folder in the sysWOW64 directory.
The malware folder was named AutoRecover and contained multiple files:
- XSL file: xml.XSL
- nine DLL files
Executable files:
- mscorsv.exe
- wmiprvse.exe
XSL file
XSL files are style sheets, similar to those used in CSS, that describe how to display an XML document.
Using Notepad, we determined that it was not actually an XSL file, but Zend Guard obfuscated PHP code. This curious fact suggests that this
malware payload based on its execution algorithm.
Nine DLLs
Initial analysis of the XSL file led to the conclusion that the presence of so many
DLLs make some sense. The main folder contains a DLL called php.dll and three other libraries related to SSL and MySQL. In the subfolders, experts found four PHP libraries and one Zend Guard library. All of them are legitimate, and are obtained from the PHP installation package or as external dlls.
At this stage, the assumption was made that the malware was created based on PHP and obfuscated by Zend Guard.
Executable files
Also in this folder were two executable files: Mscorsv.exe and Wmiprvse.exe.
After analyzing the mscorsv.exe file, we determined that it was not signed by Microsoft, although its ProductName was "Microsoft. Net Framework.
At first it just seemed strange, but the analysis of Wmiprvse.exe made it possible to better understand the situation.
The Wmiprvse.exe file was also unsigned, but contained a PHP group copyright and a PHP icon. On a cursory scan, commands from the PHP help were found in its lines. When run with the -version switch, it was found to be an executable file designed to run Zend Guard.
When running mscorsv.exe the same way, the same data was displayed on the screen. We compared the binary data of these two files and saw that they are identical except for the metadata.
Copyright and Company Name/Product Name.
Based on this, it was concluded that the XSL file contains PHP code that is run using the Zend Guard executable hidden under the name mscorsv.exe.
Parsing an XSL file
Using an Internet search, the experts quickly obtained a Zend Guard deobfuscation tool and restored the original appearance of the xml.XSL file:
It turned out that the malware itself is a PHP shell that constantly connects to the control center (C&C server).
The commands and output it sends and receives are encrypted. Since we received the source code, we had both the encryption key and the commands.
This malware contains the following built-in functionality:
- Eval - usually used to modify existing variables in code
- Local File Write
- Possibilities of working with the database
- Possibilities of working with PSEXEC
- Hidden execution
- Mapping processes and services
The following variable suggests that the malware has multiple versions.
During sampling, the following versions were found:
- 0.5f
- 0.4p
- 0.4o
The only function of ensuring the permanent presence of malware in the system is that when executed, it creates a service that executes itself, and its name
changes from version to version.
Experts tried to find similar samples on the Internet and found malware,
which, in their opinion, was the previous version of the existing sample. The contents of the folder were similar, but the XSL file was different and had a different version number.
Parle-Vu Malware?
This malware may have originated in France or another French-speaking country: the SFX file had comments in French that indicate that the author used the French version of WinRAR to create it.
Moreover, some variables and functions in the code were also named in French.
Monitoring execution and waiting for new commands
The specialists modified the malware code and safely launched the already modified
version to gather information about the commands it received.
At the end of the first communication session, the experts saw that the malware received a Base64 encoded command as an argument for the EVAL64 startup key.
This command is decoded and executed. It changes several internal variables (read and write buffer sizes), after which the malware enters the command waiting work loop.
At the moment, no new orders have been received.
Interactive PHP shell and cryptominer: are they related?
Varonis is not sure if Norman is related to the PHP shell, as there are strong arguments both for and against this assumption:
Why might they be related?
- None of the cryptomining malware samples had the ability to self-propagate to other systems, although they were found on various devices in various network segments. It is possible that the attacker was infecting each node separately (possibly using the same attack vector as when infecting Patient Zero), although it would have been more efficient to use a PHP shell to propagate through the network that became the target of the attack.
- Large-scale targeted automated campaigns against a specific organization often leave technical artifacts or recognizable traces of cybersecurity threats in their implementation. In this case, nothing of the kind was found.
- Both Norman and the PHP shell used the DuckDNS service.
Why might they not be related?
- There are no technical similarities between the cryptomining malware variants and the PHP shell. The malicious cryptominer was created in C++, and the shell was created in PHP. Also, there are no similarities in the code structure, and the network functions are implemented differently.
- There is no direct interaction between the malware variants and the PHP shell to exchange data.
- They do not share developer comments, files, metadata, or digital fingerprints.
Three recommendations for protecting against remote shells
Malicious software that requires commands from the control center (C&C servers) is not like regular viruses. Its actions are not so predictable and will be more similar to the actions of a hacker or pentester performed without automated tools or scripts. Therefore, detecting these attacks without malware signatures is a more difficult task than conventional antivirus scanning.
Below are three recommendations for protecting companies from remote shells:
- Keep all software up to date
Attackers often use vulnerabilities in software and operating systems to spread across an organization's network and search for data of interest in order to
theft. Timely installation of patches significantly reduces the risk of such threats. - Monitor abnormal data access events
Most likely, attackers will try to take the organization's confidential data beyond the perimeter. Monitoring anomalous access events to this data will allow
detect compromised users and the entire set of folders and files that could actually fall into the hands of attackers, and not just treat all the data available to these users as such. - Monitor network traffic
Through the use of a firewall and/or proxy server, malicious connections to malware control centers (C&C servers) can be detected and blocked, preventing attackers from executing commands and making it difficult to infer
perimeter data.
Worried about gray mining? Six recommendations for protection:
- Keep all operating systems up to date
Patch management is very important to prevent misuse of resources and malware infection. - Control network traffic and web proxies
Do this to detect some attacks, and to prevent some of them, you can block traffic based on information about malicious domains or restrict unnecessary data channels. - Use and maintain antivirus solutions and endpoint security systems (but by no means limit yourself to using only this layer of protection).
Products on end devices can detect well-known cryptominers and prevent infections before systems performance and power usage are compromised. Keep in mind that new modifications or new ways to prevent detection may cause endpoint security tools to fail to detect new versions of the same malware. - Monitor CPU activity of computers
As a rule, cryptominers use the central processing unit of a computer for mining. It is necessary to analyze any messages about a decrease in performance (βMy computer began to slow down.β). - Monitor DNS for unusual use of Dynamic DNS services (like DuckDNS)
Although DuckDNS and other Dynamic DNS services are not harmful to the system in and of themselves, the use of DuckDNS by malware has made it easier for our teams of experts to detect infected hosts.
- Develop an Incident Response Plan
Make sure that you have the necessary described procedures for such incidents to automatically detect, limit and eliminate the threat of gray crypto mining.
Note for Varonis customers.
includes threat models that enable the detection of cryptomining malware. Customers can also create their own rules to target software based on domains that are blacklisted candidates. To ensure you are running the latest version of DatAlert and applying the correct threat models, please contact your sales representative or Varonis support.
Source: habr.com