SILKLOADER

Even though libvlc is an open-source project, the threat actor did not modify and compile the open-source code to create the malicious libvlc.dll files.
Instead, the malicious DLLs were created from scratch.
These DLLs are designed to mimic the legitimate libvlc.dll file by including export function names found in the legitimate version and thus imported by the VLC executable.
Only one of the export functions contains malicious code.

All other export functions are trivially implemented with “retn 0” instructions .
The “libvlc_new” export function, which implements the malicious code, is called by the VLC executable to create a libvlc instance6.
As such, the malicious code is executed immediately when the renamed VLC executable is launched.

The malicious code acts as a shellcode loader.
The shellcode loader dynamically resolves the API functions it needs.
These functions and module names are encrypted using a simple XOR based algorithm.
The loader first decodes the base64 encoded shellcode using the CryptStringToBinaryA function.
It then performs a set of anti-analysis checks, which are explained in the following subsection.
Lastly, it proxies the execution flow to the beginning of the shellcode by calling CertEnumSystemStoreLocation and setting the allocated shellcode’s address as the callback function parameter.

Anti-sandbox checks
The loader contains three anti-sandbox checks that will cause execution to terminate:
1.
It checks if the username (retrieved via GetUserNameW) is “vbccsb”.
This is the default username used by ThreatBook Cloud Sandbox, a platform primarily used within the Chinese cybersecurity sphere.
2.
It checks if the process command line contains the word “TRANSFER”.
This is likely an anti-sandbox check for VirusTotal sandboxes.
3.
It checks if the process name (VLC executable) matches a hard-coded value.
This is likely an anti-sandbox check as well, as certain sandboxes do not use the original filename for execution.
Based on analyzed samples, original filenames appear to be either one of following:
• msdtc.exe
• wpspdf.exe
• charmap.exe

The loaded shellcode contains a stub which calls a decoder located at the end of the loaded shellcode to decode another stub.
This newly decoded stub then decodes an appended payload which has been XORed.
In the case of all SILKLOADER samples that were analyzed, the appended payload was a Cobalt Strike reflective loader.
This indicates that SILKLOADER was created for the sole purpose of being used as a Cobalt Strike beacon loader.