DownAndExec: Banking malware utilizes CDNs in Brazil

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.

Figure 1: NSIS/TrojanDropper.Agent.CL detection telemetry in June 2016.

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.

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.

Figure 2: Recursive call c() and script patch for debugging through 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.

Figure 3: CDN simulation hosting the malicious JS snippet.

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).

Figure 4: Loading the externally-hosted JS snippet.

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.

Figure 5: downAndExec call with C&C contention and x-id inserted into 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.

Figure 6: Relationship of the files involved in downAndExec.

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).

Figure 7: Obfuscation used in the JS snippet.

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.

Figure 8: Definition of downAndExec() in the JS snippet.

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.

Figure 9: Structure of the haveAnyPrograms() function that searches for banking software on the system.

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).

Figure 10: Function to verify that the customer IP address is in Brazil.

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.

Figure 11: Main execution section of the JS snippet.

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.

Figure 12: Functions used for the download of C&C payloads.

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.

Figure 13: Content of the t file.

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:

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)