NetSupport malware variants have been a persistent threat, demonstrating adaptability and evolving infection techniques. In this technical analysis, we delve into the infection chain, technical intricacies, and IOCs (Indicators of Compromise) of distinct NetSupport variants.
The following is a heatmap depicting the current prevalence of NetSupport in the field. This malware is spreading across the United States and Canada, signifying its geographical reach.
Figure 1 : NetSupport Heat Map
McAfee Labs recently identified a new variation of the NetSupport malware, which was distributed through JavaScript, highlighting the evolving tactics employed by cybercriminals.
Infection Chain
The infection begins with obfuscated JavaScript files, serving as the initial point of entry for the malware.
Upon execution of the JavaScript file, it invokes the Windows Script Host (wscript.exe).
Subsequently, the wscript.exe process initiates PowerShell, employing specific commands to advance the infection.
Under the attacker’s control, PowerShell proceeds to download the NetSupport payload, a remote administration tool with malicious intent.
Once downloaded, the malware executes the ‘client32.exe’ binary, which is the NetSupport client responsible for establishing control over the compromised system.
Figure 2 : Infection Chain
Technical Analysis
Variant 1:
This Variant starts with a very long JS file. It follows an intricate infection chain, utilizing PowerShell commands. Key steps include changing the directory to the user’s AppData, setting variables, downloading files, and eventually executing ‘client32.exe’. This executable establishes control over the compromised system and registers for auto-startup through Windows Registry, following which the ‘client32.exe’ binary is placed in the ‘MsEdgeSandbox’ folder under AppData, providing persistence.
The JS code looks like as shown in the picture below. Attackers leverage obfuscated JavaScript files as the starting point of an infection chain. These files are designed to bypass security mechanisms and initiate the delivery of malicious payloads.
Figure 3: Encoded Java Script File
It contains a long list of string literals, each consisting of random characters and sequences of letters. These strings are typically used for various purposes in the code, such as constructing URLs, setting values for variables, or possibly for other purposes. The code defines several variables (hy, hY, hE, hi) and a function named ‘y’.
Figure 4 : Encoded Java Script File
Then it setup different variables and objects and does some calculations or operations.
Figure 5 : Encoded Java Script File
The S function appears to decode a base64-encoded string and returns a decoded string.
The R function takes two arguments, a decoded string, and another string (g). It uses a custom algorithm to perform some XOR operations and returns the result.
The function appears to cache decoded values in the h array to avoid redundant decoding. If a decoded value is found in the cache, it is returned directly; otherwise, it is decoded using the Y[‘YUlcMP’] function and stored in the cache.
Figure 6 : Encoded Java Script File
It creates a windows notification using “wscript” and temp file in the temp directory.
Then it runs that file using shell and cleanup the file after execution.
The AMSI dumps as shown in the Figure 7, begin by changing the directory to the user’s AppData folder. It then sets up variables and proceeds to download and execute files. If certain commands are unavailable, it uses ‘bitsadmin’ for file downloads. he script ensures persistence by altering directory attributes, launching ‘client32.exe,’ and adding a Windows Registry entry for automatic execution.
Figure 7 : AMSI Dump
First, the script changes the current directory to the user’s AppData directory.
As shown in the figure 8, it several variables, including URLs for downloading files, file paths, and commands to be executed.
Figure 8 : Code block
Then it checks whether the expand-archive command is available ($g3tSp4), and whether the Start-Bits Transfer command is available ($PsaB17). If both are available, it uses Start-BitsTransfer to download and transfer files, and then extracts them using expand-archive. If these commands are not available, the script goes on to download individual files using the bitsadmin command ($sPaad) and processes them (as shown in Figure 9).
Figure 9 : Code block
If the expand-archive and Start-BitsTransfer commands are not available, the script downloads individual files from the specified URL using either Start-BitsTransfer or bitsadmin, based on availability (as shown in Figure 10).
Figure 10 : Code block
Then it sets the attributes of a directory to ‘Hidden’, changes the current directory, starts the exeexecutable, and adds an entry to the Windows Registry to execute the client32.exe file at startup (as shown in Figure 11).
Figure 11 : Code block
Variant 2:
Variant 2 of this malware shares a similar infection chain as Variant 1. Like Variant 1, it starts with obfuscated but different JavaScript files and subsequently invokes PowerShell. However, what sets Variant 2 apart is its distinct approach to manipulating files and content. It downloads a text file from a website, decodes base64-encoded data, and creates a ZIP file with potentially malicious content. Variant 2 differs significantly when it comes to file manipulation. Instead of placing the ‘client32.exe’ in the ‘MsEdgeSandbox’ folder like Variant 1, it follows an alternative path. In this case, it establishes the ‘client32.exe’ in a folder labeled ‘D’ under AppData. This distinct approach to file placement sets it apart from Variant 1, despite the shared initial infection chain.
The JS file as shown in Figure 12, includes two variables, ‘F4f’ and ‘EQGMUD.’ ‘F4f’ is set to a specific value, 140743580. ‘EQGMUD’ is a bit more complex; it’s a string formed by converting numerical values into characters. These values are derived by subtracting ‘F4f’ (140743580) from them. Finally, the ‘eval’ function is used to run the code stored in ‘EQGMUD’ as JavaScript, essentially executing this string as a script.
Figure 12 : Encoded Java Script File
The AMSI dumps as shown in the Figure 13, contains PowerShell commands that performs several actions, including downloading a file from the internet, extracting it, and making changes to the windows registry.
Figure 13 : AMSI Dump
hxxps://svirtual[.]sanviatorperu[.]edu[.]pe/readme[.]txt, this is a text file hosted on a website. It first downloads the content from this website and store it in $6.
Then the script decodes the base64-encoded data stored in $6 and stores the result in $a, which is binary data.
Then it sets the variable $d to a path in the user’ “Application Data” directory with a subdirectory named ‘D’.
Then it checks whether the $d path exists, if it doesn’t, then it creates the path.
It constructs a path to a file named ‘p.zip’ inside the directory specified in $d and stores it in the variable $p.
Then it writes the binary data stored in $a to the file specified in $p. This essentially creates a ZIP file with potentially malicious contents.
Figure 14 : Directory Created
It has this try and catch block, which indicates the code inside the clock is prepared to handle exceptions. It attempts to extract the contents of zip file ‘$p’ into the directory specified in $d.
It constructs a path to an executable file named ‘client32.exe’ inside the directory specified in $d and stores it in the variable $e.
if (Test-Path $e -PathType Leaf) { Start-Process -FilePath $e } else { Write-Host ‘No exe.’ };: This section checks if the file specified in $e exists and is a valid executable file. If it is, it attempts to start the executable using Start-Process. Otherwise, it writes ‘No exe.’ to the console.
Then it constructs a path to ‘client32.exe’ inside the directory specified in $d and stores it in the variable $s.
It sets the variable $k to a Windows Registry key path used to add programs to run at user logon.
Process Tree
Figure 15 : Process Tree
Once the JavaScript file is executed, it launches wscript.exe and then launches PowerShell with the following command.
powershell.exe -ExecutionPolicy Bypass -V
Figure 16 : PowerShell Command
This way, PowerShell with the execution policy set to “Bypass”, which means that PowerShell will not enforce any execution restrictions. This allows scripts to run without any policy-related restrictions.
Persistence
This malware is known for its persistence and attempts to hide within the user’s profile directories, which makes it challenging to remove.
It creates a “MsEdgeSandbox” folder in AppData in the first variant and downloads the following files in that folder.
Figure 17 : Created Directory
Various installation paths were seen in different variants.
C:UsersuserAppDataRoamingApple2q6lxy6vclient32.exe
C:UsersuserAppDataRoamingApple2q6lxy6vclient32.exe
C:UsersuserAppDataRoamingApple2abm1octclient32.exe
C:UsersuserAppDataRoamingApple2w35hfwm7client32.exe
C:Usersuser>AppDataRoamingApple2abm1octclient32.exe
c:usersuserappdataroamingapple2u8g65jbclient32.exe
C:UsersuserAppDataRoamingApple22w3r7sxclient32.exe
C:UsersuserAppDataRoamingApple2hnrvooclient32.exe
C:UsersuserAppDataRoamingApple2kvu25client32.exe
C:UsersuserAppDataRoamingApple25aoyhclient32.exe
C:UsersuserAppDataRoamingApple2i262cpclient32.exe
C:UsersuserAppDataRoamingApple2hnrvooclient32.exe
C:UsersuserAppDataRoamingApple2g057yiclient32.exe
C:UsersuserAppDataRoamingApple22fu82client32.exe
C:UsersuserAppDataRoamingApple25aoyhclient32.exe
C:UsersuserAppDataRoamingApple2kvu25client32.exe
C:UsersuserAppDataRoamingApple22fu82client32.exe
C:UsersuserAppDataRoaming Apple2_5frlv9client32.exe
C:UsersuserAppDataRoaming Apple2_y8yyxpclient32.exe
C:UsersuserAppDataRoaming Apple2_v8qm4fclient32.exe
C:UsersuserAppDataRoaming Apple2_y44ztrclient32.exe
C:UsersuserAppDataRoaming Apple2_joafqoclient32.exe
C:UsersuserAppDataRoaming Apple2_ncfy5nclient32.exe
C:UsersuserAppDataRoaming Apple2_v8qm4fclient32.exe
C:UsersuserAppDataRoaming Apple2_y44ztrclient32.exe
C:UsersuserAppDataRoaming Apple2_y8yyxpclient32.exe
C:UsersuserAppDataRoaming Apple2_ncfy5nclient32.exe
C:UsersuserAppDataRoaming Apple2_joafqoclient32.exe
C:UsersuserAppDataRoaming Apple2_5frlv9client32.exe
C:UsersuserAppDataRoaming Apple2_z8yde3xclient32.exe
C:UsersuserAppDataRoaming Apple2_z8yde3xclient32.exe
C:UsersuserAppDataLocalTempo2pi4q4o.i1yclient32.exe
c:usersuser appdataroamingdclient32.exe
C:UsersuserAppDataRoamingDclient32.exe
client32
c:usersuserappdataroamingdclient32.exe
C:Program Files (x86)NetSupportNetSupport DNAClientdnarc.exe
c:program files (x86)netsupportnetsupport dnaclientdnarc.exe
Payload Overview
exe: This executable file is a component of NetSupport Manager Client, a widely used software solution for remote desktop management and support.
The folder contains various files, which is typical of software installations. These files include DLLs, EXEs, INIs, INFs, and LICs, each serving a specific purpose within the software.
NetSupport Manager Client is a commercially available software product that can be purchased or obtained through a free trial.
To confirm the authenticity of the software, a hash query was performed using the executable file’s hash value. The query was submitted to VT, The results of the VT query indicated that Client32.exe is legitimately signed, reaffirming its status as a genuine software component.
Figure 18 : File Signature
Client32.ini: This file contains the configuration settings for NetSupport Manager. It governs how NetSupport Manager interacts with managed hosts and allows operators to configure various options.
NSM.LIC: The LIC file contains license details related to the NetSupport Manager installation, which are essential for proper licensing and software activation.
The Client32.ini file provides operators with a range of configuration options. These options enable NetSupport Manager operators to manage remote hosts effectively or remain concealed when necessary.
Figure 19 : INI File
For this specific installation, the INI file indicates the presence of two NetSupport Manager console addresses:
jokosampbulid1.com:1412
Domain: jokosampbulid1.com
Port: 1412
Upon querying the domain “jokosampbulid1.com” on VirusTotal, it was identified as a C2 server associated with the NetSupport Manager RAT.
C2
exe establishes a communication channel with a remote server located at IP address 45.15.158.212 on port 1412.
The choice of port 1412 suggests that it may be a specific port designated for NetSupport Manager’s communication protocol.
15.158.212
port : 1412
Figure 20 : C2 Communication
“NetSupport Manager/1.3” indicates that the communication is originating from a NetSupport Manager Client with version 1.3.
Figure 21 : HXXP Stream
Conclusion:
The analysis of NetSupport malware variants has revealed a persistent and continually evolving threat landscape. These variants employ intricate infection chains and technical intricacies to accomplish their malicious goals. Our investigation has provided insights into their modus operandi, including downloading, and executing files through obfuscated JavaScript code and altering the Windows Registry for persistence.
At McAfee Labs, our commitment is unwavering. We strive to provide robust and effective threat defense mechanisms to safeguard our users from a wide array of threats, including NetSupport and its various iterations. Our security software harnesses the power of signature-based, machine learning, threat intelligence, and behavior-based detection techniques, all working together to identify and thwart threats effectively. In an ever-changing digital landscape, our focus remains on keeping you safe and secure from emerging threats.
IOCs
Variant 1:
Type
SHA256
JS
5ffb5e9942492f15460e58660dd121b31d4065a133a6f8461554ea8af5c407aa
EXE
89F0C8F170FE9EA28B1056517160E92E2D7D4E8AA81F4ED696932230413A6CE1
C2
hxxp://45[.]15[.]158[.]212/fakeurl.htm
Variant 2:
Type
SHA256
JS
48bc766326068e078cf258dea70d49dcce265e4e6dbf18f1a0ce28d310f6a89a
73e0975c94ebcdec46fd23664ccecf8953dd70eea1f4e5813e7f8cd8d2dbc4f9
URL
hxxps://svirtual[.]sanviatorperu[.]edu[.]pe/readme.txt
The post Beneath the Surface: How Hackers Turn NetSupport Against Users appeared first on McAfee Blog.