Trickbot, a banking Trojan family that has been around for some time now, aims at stealing banking credentials from infected victims. This blog post talks about a new variant of this Trojan that (ab)uses PowerShell, MS-Word macros and Office Equation Editor vulnerabilities as its infection vectors.

The document comes via email disguised as a BACS (Bacs Payment Schemes Limited, formerly known as Bankers’ Automated Clearing Services) request form as depicted in Figure 1.

Figure 1: Fake BACS request form that looks identical to the original form

The sender’s email id, “noreply@lloydsbcnk.com”, is crafted, a common enough social engineering technique to deceive an unsuspecting user into opening the attachment, which then requires the user to enable macros, claiming that this is necessary to auto-fill the form. Figure 2 depicts the flow of execution on opening the malicious DOC attachment and enabling the macros.

Figure 2: Execution flow

Macros contained in the Word document are depicted in Figure 3.

Figure 3: Macros

Once enabled, the macros triggered creates the cmd and PowerShell processes as depicted in Figure 2 to execute the script for downloading the Trickbot binary. Here’s the actual PowerShell script that gets executed:

Figure 4: Actual script (courtesy of app.any.run)

Figure 5: Reformatted form of script for better readability

PowerShell is now one of the most widely abused Windows components by malware authors since it is available by default on modern Windows and interacts easily with the .NET framework. The Trickbot script uses the .NET API “DownloadFile” from a common .NET class (System.Net.Webclient) for downloading the malware’s preliminary binary component. Some thoughts on why this specific API was chosen:

• The download happens in the background. There is no download progress indicator, i.e. the user is completely unaware of what’s happening
• The thread cannot be interrupted until the current download is complete or fails.

The script also has a failsafe mechanism by way of a try/catch block which provides alternative download links to the binary component which were specifically created for the purpose of serving this malware:

• hxxp[:]//interbanx[.]co[.]id/lopagores[.]png
• hxxp[:]//chimachinenow[.]com/lopagores[.]png

These two domains were also found to host other malicious files as depicted in Figure 6.

Figure 6: Other malicious files hosted (courtesy of VirusTotal)

Once lopagores.png (which is actually a Portable Executable, i.e. PE) is downloaded successfully, the script executes it using the Start-Process command from a hard-coded path that keeps changing from sample to sample (temporary location as shown in Figure 5).

Behavioral analysis of the downloaded binary file

The binary component then copies itself to a sub-folder under the user’s %APPDATA% area along with another file named “client_id”, which contains the system details like the machine name and OS version, as well as an arbitrarily generated string to identify the bot and the campaign to which it belongs as depicted in Figure 7.

Figure 7: Sub-folder under %APPDATA% (NB: sample has been renamed to its SHA256 hash value)

An aptly-named folder “Modules” is also created along with the above files that acts as a placeholder for:

• Any modules that get downloaded or pushed from the C&C (Command and Control) server
• Files that are injected into various browsers to scrape user credentials

Persistence is taken care of by a scheduled task with multiple triggers created with the name “MsNetValidator” to masquerade as a legitimate task, a simple but effective way to hide from the average user.

Figure 8: Scheduled task for persistence

Registry modifications are also made (as shown in Figure 9) to exclude its folder from Windows Defender scans.

Figure 9: Registry entry for exclusion from Windows Defender scan

Before contacting any C&C server for downloading additional modules, the malware first retrieves the host IP by simply querying one or more of the following domains until a response is received.

www[.]ipify[.]org      icanhazip[.]com        myextrnalip[.]com
wtfismyip[.]com        ip[.]anysrc[.]net      api[.]ipify[.]org
ipecho[.]net           ipinfo[.]io            checkip[.]amazonaws[.]com

It injects into the legitimate svchost process to modify the scheduled task for the next trigger as depicted in Figure 2.

Inside the code of the downloaded binary file

The main binary component, a Visual C executable, is designed to decrypt the malicious code only at runtime.

Decryption

This piece of malware performs multiple layers of decryption before the final bad act. For those who are interested here’s a slightly more detailed explanation. The 1st level (bog standard) decryption of some bytes followed by a call to the decrypted bytes is seen in Figure 10.

Figure 10: 1st level of decryption

The 2nd level (evasive action) involves the decrypted code allocating more memory into which further encrypted content is copied and decrypted, and another call is made to that decrypted content as seen in Figure 11.

Figure 11: The 2nd level of decryption

In the 3rd level (definitely bad) this decrypted code allocates even more memory, and more encrypted code is loaded into it and decrypted, which happens to be the “meaningful” malware code.

Figure 12: 3rd level of decryption to “meaningful” malware code

Our analysis also shows that it scans the memory for traces of monitoring tools and/or malware analysis-related processes. The list of processes that it scans for is as follows:

pstorec.dll
vmcheck.dll
dbghelp.dll
wpespy.dll
api_log.dll
sbiedll.dll
SxIn.dll
dir_watch.dll
Sf2.dll
cmdvrt32.dll
snxhk.dll

These names are stored in encrypted form without any special character or entropy so as to avoid easy detection based on strings or entropy. If none of the aforementioned process are found active, the malware goes on to copy itself to user’s %APPDATA% folder (as depicted earlier in Figure 7) and launches itself as a new process. This process, after verifying it is in fact running from under the user’s %APPDATA% folder, goes on to decrypt another Visual C binary (as depicted in Figure 13), which does not touch the disk at all, i.e. it is decrypted, read and memory mapped whilst in memory itself.

Figure 13: Final decryption (Trickbot payload)

Before passing on the execution flow to the decrypted file in memory, the malware checks if it is being debugged by calling the function ZwQueyInformationProcess with the parameter ProcessInformationClass set to 0, which retrieves the pointer to the PEB (Process Environment Block) structure, which is in turn read to conclude if the process is being debugged or not as depicted in Figure in 14.

Figure 14: Check if being debugged

This decrypted binary in memory is the actual payload of Trickbot which is responsible for tasks like:

• Querying the local IP
• Ensuring persistence (via registry and scheduled tasks)
• Creating the “Modules” folder
• Decrypting a configuration file from its resource (as depicted in Figures 15 & 16) using functions from NCrypt.dll or BCrypt.dll
• Contacting C&C server

Figure 15: Encrypted config file content stored in resources

Figure 16: Retrieving functions from NCrypt.dll or BCrypt.dll

The decrypted resource blob (as depicted in Figure 17) is saved as Config.conf under the user’s %APPDATA% folder.

Figure 17: Content of Config.conf file

<ver> tag indicates the Trickbot version which is 1000166, <gtag>  indicates the campaign ID and <srv> has the list of C&C IPs and ports for downloading additional modules. The C&C pushes custom or specific modules for specific targets which are responsible for code injection, mailcollector, sqlfinder, screenlock, etc. on successful validation of request received from Trickbot payload.

Same malware, different vulnerability

We also saw instances of this malware being served via a crafted MS-Word document which tries to exploit the Office Equation Editor vulnerabilities, i.e. CVE-2017-11882 and CVE-2017-8570 This crafted document, in the guise of a “Payment advice” form from HSBC bank, gets delivered from a typo-squatted domain “noreply@hsbc-paymentadvice.co.uk” or “noreply@hsbcpaymentadvice.co.uk” in an attempt to make the email look legitimate. The crafted document probably uses ThreadKit because it drops task.bat under the %Temp% folder and executes it using cmd.exe (typical ThreadKit behaviour) which will be followed by a PowerShell process (as depicted earlier in Figure 2). Figure 18 shows the actual PowerShell script and its reformatted form used to download the executable.

Figure 18: PowerShell Script (courtesy of app.any.run)

From Figure 18, it is evident that both infection vectors use the same domains to download the malware. The file downloaded by the second method is a Microsoft Visual Basic 5.0 compiled binary (the reader may recall that the first method downloaded a Visual C binary), but it drops a similar Trickbot payload during runtime though. Our analysis indicates that this banking Trojan constantly seeks new infection vectors and is still very active. The malware authors are still implementing new functionalities and modules.

Indicators of Compromise (IoCs)

File details

DOC file:

FA9762828CF25F0182CC5A6781E708DA   (fake Lloyds Bank DOC)  Trojan ( 0001140e1 )
5FE7EF0E15A4E9468018E0A76457D159   (fake HSBC bank DOC)	   Trojan ( 0001140e1 )

PowerShell script:

7B177E32052DCF80830A087C9157A598   (Script from Lloyds Bank DOC)  Trojan ( 0001140e1 )
A5E7AF38D0CC548071B1B93731CE2B62   (Script from HSBC bank DOC)	  Trojan ( 0001140e1 )

Executables:

C4634916686AD740E1D17F23721152E2  (EXE from fake Lloyds DOC)  Trojan ( 0052cf591 )
1E9BC9805114D86B411F5DDEF01C67D0  (EXE from fake HSBC DOC)    EmailWorm ( 003c363a1 )

K7 products also have dynamic detection for the Trickbot variants.

URLs List

hxxp[:]//interbanx[.]co[.]id   (malicious domain blocked by K7SafeSurf)
hxxp[:]//chimachinenow[.]com   (malicious domain blocked by K7SafeSurf)

Lokesh J
Threat Researcher, K7TCL