Analysis of MontysThree industrial espionage software

In the summer of 2020, activities of targeted industrial espionage software were discovered, the toolset included unknown C++ modules. The malware author named the toolset 'MT3', and researchers named the toolset 'MontysThree'.

The malware includes a set of C++ modules for persistent control, which obtain data from bitmaps using steganography, decrypt configuration tasks (screenshots, obtaining target fingerprints, obtaining files, etc.), and so on. The malware uses custom steganography, custom XOR encryption, 3DES, and RSA algorithms for decryption and communication.

Method of spread

Analysis of MontysThree industrial espionage software

The initial loading program module is in the RAR self-extracting file, only PE files (disguised as .pdf or .doc files), one of which (MD5 da49fea229dd2dedab2b909f24fb24ab) is named "Списоктелефоновсотрудников2019.doc" ("Employee phone list", in Russian), and there are also "Tech task.pdf" and "invitro-106650152-1.pdf". The latter is the name of a Russian medical laboratory. The SFX script is as follows:

Path=%TEMP%\
SavePath
Setup=rundll32.exe "invitro-106650152-1.pdf",Open
Silent=1
Overwrite=1
Update=U
Delete=invitro-106650152-1.pdf

After execution, the SFX script will call the executable file already decompressed in the %TEMP% directory and then delete it.

Technical analysis

The execution process is as follows:

1603243488_5f8f8de0392da68a8854f.png!small?1603243489329

The table below lists four modules and their functions, these modules share common communication specifications. When handling shared data such as configuration files and execution logs, the malware initializes structures in the thread-local storage (TLS).

The DllEntryPoint() entry point works similarly to a constructor, the module must export a function named Open() without any parameters (but can parse the command line) and return a four-byte error code.

1603244042_5f8f900a1ce3eb7ae1f72.png!small?1603244042705

Loader module

The encrypted bitmap filename is provided as a parameter to the loader, which decrypts the next program from the pixel array. During the first iteration, it extracts the steganographic parameter data.

1603269728_5f8ff4601bf1d5af9ea88.png!small?1603269728710

The IID, IParam, and ISize parameters are stored in the first 384 bytes of the pixel array, so only the last bit of each pixel array byte is needed. This module uses these fields to collect a 48-byte configuration structure, determining the next decryption stage.

1603269815_5f8ff4b74ba867492ef9e.png!small?1603269815740

After extracting the steganographic parameters, a two-step algorithm is used to decrypt the next program. First, the IParam algorithm selects bits from the bytes of the pixel array. If IID equals 2, a four-byte轮回 key is used for the collected bytes, and the initial decryption key hardcoded as 0x23041920 for the first four bytes. The XOR formula for the next byte is:
key ^= 8 * (key ^ (key << 20))

The decryption result is not injected into the memory of any process, but instead, a file named msgslang32.dll is generated and placed on the disk. The loader uses the Windows API functions LoadLibraryW() and GetProcAddress() to run the next stage's Open() function.

Kernel module

The kernel module contains three encryption keys for configuring decryption and C2 communication. The public and private RSA keys are stored in the .data section in the form of PUBLICKEYBLOB and PRIVATEKEYBLOB, respectively, and are used for encrypting C2 communication and decrypting the 3DES key.

The third 3DES key is also stored in the .data section in encrypted form. This key is used to decrypt the .cab file containing the XML configuration, and the module uses the Windows standard program "expand.exe" to decompress the .cab.

The XML configuration includes various "tasks" of malicious software, such as fingerprinting the target, capturing screenshots, and obtaining a list of documents with extensions .doc, .docx, .xls, .xlsx, .rtf, .pdf, .odt, .psw, .pwd from the latest directory in %USERPROFILE%, %APPDATA%, and %APPDATA%\Microsoft\Office\Последние файлы, which translates to "Recent Files" in Russian.

Config includes task scheduling (screenshot), access tokens, interested directories, and extensions:

1603270344_5f8ff6c841671aeea2700.png!small?1603270344831

Russian strings such as “Снимокрабочегостола” (desktop snapshot), “Системнаяинформация” (system information), and “Времявыхода” (exit time) are detected.

1603270408_5f8ff7089d2d8fc807e6f.png!small?1603270409477

The decrypted configuration structure is as follows:

1603270440_5f8ff72809c7a2a72652a.png!small?1603270440525

The main class responsible for handling instructions is CTask. The IoControl() method of CTask is responsible for handling the corresponding tasks and can run the following methods:

1603270711_5f8ff837d4ed7f51299c0.png!small?1603270712529

Communication module

HttpTransport exists in the .text section of the kernel module and contains four encrypted data blocks. When the kernel needs to communicate, it decrypts the module and runs the Open() function, passing command-line arguments.

Based on the parameters transmitted from the kernel module, the module can upload or download content using RDP, WebDAV, Citrix, and HTTP protocols. HttpTransport also implements downloading data from Google and Dropbox public services using user tokens. Under HTTP GET / POST requests, the malware will use Windows API HTTP functions to receive steganographic bitmap images from URLs.

The aforementioned communication protocols are not implemented internally in the module. The malware operates using installed Windows programs on the computer (such as RDP, Citrix client, and Internet Explorer), and URLs can be pasted into the browser via clipboard; wait and then receive the result again through the clipboard.

The upload and download of Dropbox and Google data depend on another principle: using a custom class CSimpleHttp for authentication and sending HTTP requests.

Summary

Malware typically targets government entities, diplomats, and telecommunications operators, with industrial espionage like MontysThree being much rarer.

In terms of propagation methods and persistent control methods, its complexity cannot be compared with top APTs. The malicious software development aspect (logging into RAM and files simultaneously, retaining the encryption key in the same file, running an invisible browser on the remote RDP host) is still immature.

The amount of code and effort invested in MontysThree is immense: storing 3DES keys under RSA encryption, bypassing IDS with custom steganography, and using legitimate cloud storage to hide C2 traffic.