A short journey into DarkVNC attack chain
During an analysis of different remote desktop trojans we came across an interesting attack-chain which leverages an RTF that exploits CVE-2017-8759 to deliver DarkVNC, a malicious version of the well-known VNC, designed to silently remote-control a victim.
DarkVNC Attack Chain
The DarkVNC chain as reconstructed by ReaQta-Hive can be seen below:
After opening the RTF document, one of the first processes to start is csc.exe which is a Command-Line build tool used to invoke the C# compiler, even though csc.exe is a perfectly legit, tool it can be abused for malicious purposes. The first step is to inspect the command-line of csc.exe to discover what is going to be compiled on-the-fly:
cam0snfh.cmdline should raise some suspicion: beside the “weird” name it also run from the user’s directory:
/t:library /utf8output /R:"System.dll" /R:"System.Runtime.Remoting.dll" /R:"System.Data.dll" /R:"System.Xml.dll" /R:"System.Web.Services.dll" /out:"[EDITED].dll" /D:DEBUG /debug+ /optimize- "C:\Users\User\AppData\Local\Temp\xyzlw5gj.0.cs"
The compilation will produce [EDITED].dll (we redacted the name of the DLL for safety reasons since it’s in the form: www.maliciousdomain.com). To understand what this DLL does, we have to inspect the source-code located in the file xyzlw5gj.0.cs:
This block of code takes advantage of the CVE-2017-8759 (WSDL Parser Code Injection) that allows an attacker to inject and execute arbitrary code. Specifically the csc.exe generated DLL will be executed by Office. The same technique has been used in the wild to distribute FinSpy.
In our case winword.exe will finally execute mshta.exe that launches an hta script which invokes a powershell. The main purpose of powershell is to drop and execute result.exe whose scope is to deliver DarkVNC which we can consider the final payload. The convoluted process described above can be summarized with a simple image that gives us an immediate insight on what is happening on the victim’s endpoint:
As previously stated, result.exe acts as a loader, its goal is to decrypt and inject the malicious DLL that contains DarkVNC. From a static analysis point of view we have the following characteristics:
|File size:||551.50 KB (564736 bytes)|
|File type:||Win32 EXE|
The executable does not have a Version Information and from an initial inspection it’s encrypted with some private PE cryptor. We will skip the detailed analysis of the packer and subsequent unpacking steps because we are more interested in the overall behavior. result.exe uses several layers of encryption but does not implement complex anti-reverse engineering countermeasures, so the fastest way track the core behavior by setting a breakpoint on VirtualAlloc() and following the various layers.
Execution will jump from layer to layer until we reach the last one where it’s possible to get the most important aspects of the injector.
The svchost.exe process is created as a suspended process so the malicious code will be executed when the process is finally resumed. At this point we can extract DarkVNC from memory.
The DarkVNC Module
The static inspection of the module’s PE shows the following:
There are two exports whose meaning is self-explanatory, they are used to manage the VNC Server.
The first step is to convert from string to address the attacker’s address, which in this case is in the form IP:443.
Obtains the ComputerName and an additional identifier in order to assemble the string that will identify the victim’s endpoint, the final string will be: (COMPUTER_NAME)_ADDITIONAL_ID-DARKVNC. Immediately after, the VNC Server is started. We will not go through the analysis of the whole module for the sake of brevity, but from the inspection of strings we can speed-up the initial assessment.
The string #hvnc is pretty indicative, this core shares many similarities with HVNC (HiddenVNC) a well-known Remote-Control Module whose source-code can be found in the carberp leak. This module shares with it a large amount of similarities like:
- Hidden VNC capabilities: The module will create a new Window Desktop to keep hidden the malicious VNC instance. This technique is usually adopted to bypass anti-fraud engines on personal banking websites by impersonating the victim’s computer and logging in with stolen credentials without raising alerts on the bank’s side. Here’s a quick representation of the above behavior taken from ReaQta-Hive’s process-tree point of view:
We have a new explorer.exe instance and one of the child processes is Chrome!
While there are also some basic differences between DarkVNC and HVNC, one of the most interesting is represented by the following:
According to the documentation MOZ_DISABLE_CONTENT_SANDBOX disables content process sandboxing.
The threat from a higher perspective
So far we have identified the following DarkVNC samples:
- Delivered via Terror EK: http://www.malware-traffic-analysis.net/2017/10/17/index.html
Hashes of the sample analyzed in this post:
- RTF: 7a641c8fa1b7a428bfb66d235064407ab56d119411fbaca6268c8e69696e6729
- result.exe: 1d6f4cac33fff1b744dce13bdf003b15d8eabce53b0578e3b4bdbc5cbf001d78
Detection & Protection
Visibility over the endpoints is essential to quickly detect new threats as they’re deployed by the attackers. Real-time behavioral analysis creates a window of opportunity to detect behaviors that are unusual, running VNC or Teamviewer is not a malicious activity by itself but those same tools can be abused to get control over an endpoint. Being capable of detecting such anomalies allows for a timely analysis and response before the severity of the incident escalates.
Check out ReaQta-Hive to understand how an Endpoint Threat Response platform can help your organization to secure the infrastructure from threats like the one just analyzed, track incidents and respond in real-time. Anomalous behaviors can be hard to understand manually and the help offered by the algorithms greatly increase the chances of detection and consequently the reaction time.