The concept of "packing" or "crypting" a malicious program is widely popular among threat actors looking to bypass or defeat analysis by static and dynamic analysis tools. Evasion of classification and detection is an arms race in which new techniques are traded and used in the wild. For example, we observe many crypting services being offered in underground forums by actors who claim to make any malware "FUD" or "Fully Undetectable" by anti-virus technologies, sandboxes and other endpoint solutions. We also see an increased effort to model normal user activity and baseline it as an effective countermeasure to fingerprint malware analysis environments.
The samples we inspected were carrying the Delphi signature (Figure 1) and were consistent with Delphi code constructs on analyzing with IDR (Interactive Delphi Reconstructor).
Figure 1: Delphi signature in sample
The Delphi programming language can be an easy way to write applications and programs that leverage Windows API functions. In fact, some actors deliberately include the default libraries as a diversion to hamper static analysis and make the application "look legit" during dynamic analysis. Figure 2 shows the forum post of an actor discussing this technique.
Figure 2: Underground forum post of an actor discussing technique
We have observed many spam campaigns with different themes that drop payloads packed using this packer.
An example is an average swift transfer spam that carries a document file as an attachment (hash: 71cd5df89e3936bb39790010d6d52a2d), which leverages malicious macros to drop the payload. The spam email is shown in Figure 3.
Figure 3: Spam example 1
Another example is an average quotation themed spam that carries an exploit document file as an attachment (hash: 0543e266012d9a3e33a9688a95fce358), which leverages an equation editor vulnerability to drop the payload (Figure 4).
Figure 4: Spam example 2
The documents in the examples fetched a payload from http://220.127.116.11/win32.exe. This turned out to be Lokibot malware.
The packer goes to great lengths to ensure that it is not running in an analysis environment. Normal user activity involves many application windows being rotated or changed over a period of time. The first variant of the packer uses GetForegroundWindow API to check for the user activity of changing windows at least three times before it executes further. If it does not see the change of windows, it puts itself into an infinite sleep. The code is shown in Figure 5. Interestingly, some of the publicly available sandboxes can be detected by this simple technique.
Figure 5: Window change check
To confirm user activity, a second variant of the packer checks for mouse cursor movement using GetCursorPos and Sleep APIs, while a third variant checks for system idle state using GetLastInputInfo and GetTickCount APIs.
The original payload is split into multiple binary blobs and stored in various locations inside the resource directory, as shown in Figure 6.
Figure 6: Bitmap resource with encrypted contents
To locate and assemble the real payload bytes, the packer code first directly reads content from a hardcoded resource ID inside the resource section. The first 16 bytes of this form a XOR key used to decrypt rest of the bytes using rolling XOR. The decrypted bytes actually represent an internal data structure, as shown in Figure 7, used by the packer to reference encrypted and obfuscated buffers at various resource IDs.
Figure 7: Structure showing encrypted file information
The packer then reads values from the encrypted buffers, starting from dwStartResourceId to dwStartResourceId+dwNumberOfResources, and brings them to a single location by reading chunks of dwChunkSize. Once the final data buffer is prepared, it starts decrypting it using the same rolling XOR algorithm mentioned previously and the new key from the aforementioned structure, producing the core payload executable. This script can be used to extract the real payload statically.
Many of the unpacked binaries that we were able to extract from the sample set were identified as belonging to the Lokibot malware family. We were also able to identify Pony, IRStealer, Nanocore, Netwire, Remcos, and nJRAT malware families, as well as a coin mining malware family, among others. A distribution of the malware families using the packer is shown in Figure 8. This diversity of malware families implies that many threat actors are using this "crypting" service/tool for their operations, possibly buying it from the developer itself.
Figure 8: Distribution of malware families using packer
Packers and crypter services provide threat actors an easy and convenient option to outsource the workload of keeping their real payloads undetected and unclassified as long as possible. They are regularly finding nifty ways to bypass sandbox environments with anti-analysis techniques; hence, detonating malware samples in a sandbox environment that try to model real user behavior is a safe bet.
FireEye MVX Engine both detects and blocks this activity.