Quote:

Introduction

In the nebula of Chinese-speaking threat actors, it is quite common to see tools and methodologies being shared. One such example of this is the infamous “DLL side-loading triad”: a legitimate executable, a malicious DLL to be sideloaded by it, and an encoded payload, generally dropped from a self-extracting archive. Initially considered to be the signature of LuckyMouse, we observed other groups starting to use similar “triads” such as HoneyMyte. While it implies that it is not possible to attribute attacks based on this technique alone, it also follows that efficient detection of such triads reveals more and more malicious activity.

The investigation described in this article started with one such file which caught our attention due to the various improvements it brought to this well-known infection vector.

FoundCore Loader

This malware sample was discovered in the context of an attack against a high-profile organization located in Vietnam. From a high-level perspective, the infection chain follows the expected execution flow:
 

After being loaded by a legitimate component from Microsoft Outlook (FINDER.exe, MD5 9F1D6B2D45F1173215439BCC4B00B6E3), outlib.dll (MD5 F267B1D3B3E16BE366025B11176D2ECB) hijacks the intended execution flow of the program to decode and run a shellcode placed in a binary file, rdmin.src (MD5 DF46DA80909A6A641116CB90FA7B8258). Such shellcodes that we had seen so far, however, did not involve any form of obfuscation. So, it was a rather unpleasant surprise for us when we discovered the first instructions.Experienced reverse-engineers will immediately recognize disassembler-desynchronizing constructs in the screenshot above. The conditional jumps placed at offsets 7 and 9 appear to land in the middle of an address (as evidenced by the label loc_B+1), which is highly atypical for well-behaved assembly code. Immediately after, we note the presence of a call instruction whose destination (highlighted in red) is identified as bogus by IDA Pro, and the code that follows doesn’t make any sense.

Explaining what is going on requires taking a step back and providing a bit of background about how disassemblers work. At the risk of oversimplifying, flow-oriented disassemblers make a number of assumptions when processing files. One of them is that, when they encounter a conditional jump, they start disassembling the “false” branch first, and come back to the “true” branch later on. This process is better evidenced by looking at the opcodes corresponding to the code displayed above, again starting from offset 7.

It is now more obvious that there are two ways to interpret the code above: the disassembler can either start from “E8”, or from “81” – by default, IDA will choose the latter: E8 is in fact the opcode for the call instruction. But astute readers will notice that “JLE” (jump if lower or equal) and “JG” (jump if greater) are opposite conditions: no matter what, one of those will always be true and as such the actual code, as seen by the CPU during the execution, will start with the byte “81”. Such constructs are called opaque predicates, and this E8 byte in the middle was only added there in order to trick the disassembler.

Defeating this trick is but a trivial matter for IDA Pro, as it is possible to manually correct the disassembling mistake. However, it was immediately obvious that the shellcode had been processed by an automated obfuscation tool. Opaque predicates, sometimes in multiples, and dead code were inserted between every single instruction of the program. In the end, cleaning up the program automatically was the only practical approach, and we did so by modifying an existing script for the FinSpy malware family created by the respected reverse-engineer Rolf Rolles.

This step allowed us to discover the shellcode’s purpose: to decrypt and decompress the final payload, using a combination of RC4 and LZNT1. Even then, it turned out that the attackers had more tricks up their sleeve. Normally, at this stage, one would have expected to find a PE file that the shellcode would load into memory. But instead, this is what we got.
...