Services like Netflix use content delivery networks (CDNs) to maximize bandwidth usage. However, the CDNs might be becoming a new way of spreading malware.
Services like Netflix use content delivery networks (CDNs) to maximize bandwidth usage as it gives users greater speed when viewing the content, as the server is close to them and is part of the Netflix CDN. This results in faster loading times for series and movies, wherever you are in the world. But, apparently, the CDNs are starting to become a new way of spreading malware.
The attack chain is very extensive, and incorporates the execution of remote scripts (similar in some respects to the recent “fileless” banking malware trend), plus the use of CDNs for command and control (C&C), and other standard techniques for the execution and protection of malware.
The purpose of this article is to offer an analysis of the downAndExec standard that is making extensive use of JS scripts to download and execute — in this particular instance, banking malware on victims’ computers.
Phase 1: Initial infection
The attack chain begins with the sending of files detected by ESET as NSIS/TrojanDropper.Agent.CL. Through queries available on VirusTotal for filenames associated with analyzed samples, we can see the aim is to then convince victims to execute the malware by deploying Social Engineering techniques.
|Hash (SHA1)||File Names (VirusTotal)||Timestamp (VirusTotal)|
|não confirmado 923337.crdownload||2017-06-09|
One of the characteristics of NSIS is the fact that, since the release of version 9.43 (June/2014), it is possible to extract the script embedded in the executable file, which has all the functionalities of this initial trojan.
When loaded, the script makes extensive use of recursive calls to make it difficult to monitor the execution path.
With very few modifications made to the original script, and making use of resources such as ActiveX(only available for Internet Explorer), it is possible to debug the script using Google Chrome’s DevTools.
The script is characteristic of the malware classified as downloader malware, with the objective of downloading and then executing other types of malware on the victim’s computer. In this instance, the script performs the download of a single snippet of externally-hosted JS, which is necessary to supplement the execution process.
The infrastructure of a CDN provider is used intensively to host the aforementioned JS snippet. Due to the impracticability of blocking the entire CDN domain, the response to such a threat poses the following challenges:
- Blocking new C&C malware: this is perhaps the reason why we saw (and can still see) new URLS frequently emerging on the same domain that hosts the C&Cs.
- Search for IoCs: in affected environments there are (potentially) a large number of access records made by non-malicious software.
To simulate the CDN hosting the malicious JS snippet and facilitate the debugging process, you can serve this content locally using a local HTTP service (only observing in order to enable resource sharing and thus execute the script at other origins).
Note in Figure 4 how the script makes a request to the external domain (CDN) in order to obtain the contents of the snippet and, if the response status is “OK” (i.e. HTTP 200), the content is returned.
Phase 2: Second download phase
After the call f(), which returns the contents of the JS snippet (i.e. the script string), the eval function is then called, adding the “downAndExec(\”<parameter_1>\”, \”<parameter_2>\”)” string to the end of the JS snippet.
The first parameter (<parameter_1>) corresponds to the URL where the C&C is hosted, and the second parameter (<parameter_2>) contains the “x-id” data that, as mentioned above, is necessary to download other payloads.
The JS snippet has several strings that are assigned to the code at the time of execution. This makes it difficult to understand the script when a static analysis is performed (even though the names of the functions have not been modified or obfuscated).
The main section of this script refers specifically to the downAndExec() function, which is added by the first NSIS downloader. This means that if the JS snippet is analyzed separately, possibly using a sandbox solution, the malicious functions of the code will not be executed, and the final analysis will conclude that the snippet is not malicious.
In addition to protection against sandboxing, the script also performs a number of checks before executing the malicious section of code in order to identify computers that are of potential interest to cybercriminals.
The first check is isOS(), which simply returns a true statement, but which could also be a stub for a future version of this malware. The second check is haveAnyPrograms(), which checks to see if there are any files of interest installed on the victim’s computer.
The getPathfromGuid() and getPathFromGuidWow() functions perform searches for files by the existence of CLSID keys in the HKCR. The files searched for by CLSID are:
In the event that none of these files are found, the script then searches for folders associated with banking programs such as those used by Bradesco, Itaú, Sicoob and Santander.
The search for these files is intended to prevent activation of malicious functions on computers that are probably not used for online banking purposes. This means that the number of detections is reduced (and beyond the range of many analysts), while effectiveness remains very high.
If any of these files are found via haveAnyPrograms(), a third check is undertaken in order to verify that the connection is from Brazil. Since the accounts of victims of potential interest are in Brazil, and in order to avoid analyses (mainly automatic) carried out by non-Brazilian countries, the following snippet verifies that the customer IP is from a Brazilian AS (autonomous system).
This check is carried out through the API on ip-api.com, which returns data on the public IP supplied by the Internet Service Provider when the customer connects to the Internet. If the countryCode is verified as “BR”, the snippet successfully passes the third condition (i.e. isBR()) and then executes the malicious section of code.
Phase 3: Communication with C&C and execution of the payload.
If the victim’s computer meets all of the conditions, the execution proceeds to the section that initiates communication with the C&C, with the (final) compromise of the machine being the result.
The dlToText_s() function being called on line 497 receives two parameters: the C&C URL (parsed in downAndExec as <parameter_1>), concatenated with “/?t”, and a string (parsed in downAndExec as <parameter_2>).
The first parameter of dlToText_s() (i.e. “<parameter_1>/?t”) indicates which C&C payload should be downloaded, whereas the second parameter only serves to protect the payload download via an “x-id” field (of value <parameter_2>) adding to the header of the GET requisition.
At the time of analysis, the t file contained only the value “3”. As we can see in downAndExec(), different types of behavior are possible based on the t value.
This value is attributed to K, with the script proceeding with the following possibilities:
- K= “1”: snippet exits the execution phase without performing a malicious action.
- K= “3”: snippet downloads three files, one of which is simply a string (with the name of a DLL), and two other PE files. The runAsUser() function is called during the sequence.
- K= “4”: A similar instance to K = “3”, but with only two PE files being downloaded, and with the runAsRundll() function being called instead of runAsUser().
The PE file (for K = “4”) was not available for download, and it is not yet known what will happen in this instance. For K = “3”, the downloaded files are:
|dllf||String conteniendo nombres de DLLs (ej.: “cryptui.dll”, “mssign32.dll”)|
|bin||PE correspondiente al CERTMGR.EXE (legítimo)|
|dllb||PE malicioso detectado por ESET como Win32/Spy.Banker.ADYV trojan|
Analysis of the payloads is still in progress; running CERTMGR.EXE, however, indicates that the malicious PE is injected into the memory through DLL pre-loading (DLL preloading attack).
As we have seen, the downAndExec technique involves two download stages and several protections, either to identify machines matching the desired profile, or to distribute malicious code in “sterile” sections, which on their own do not execute (in order to bypass online protections), but which, when joined with other pieces of malicious code, are capable of compromising a victim’s computers.
There are still a number of questions requiring further research in relation to downAndExec:
- Why use a Content Delivery Network to host the JS snippet?
- There are functions such as runAsAdmin() that are not being used. Is the JS snippet being used as a shared module for other types of Brazilian cybercrime or malware?
- How will the virus work when K= “4”?
Once we have answers to these and the other questions, we will return to this topic, but in the meantime, please don’t forget to read our blog and to keep informed about other methods used by Brazilian cybercriminals.
Indicators of Compromise (IoC)
|ESET detection names||Hashes (SHA1)|