{
	"id": "5e41d2c2-c0a6-4785-b13d-10cfad6d1b2d",
	"created_at": "2026-04-06T00:10:44.641205Z",
	"updated_at": "2026-04-10T03:20:19.959478Z",
	"deleted_at": null,
	"sha1_hash": "e4fa009a4b8bfff2a7355a398d76494b8254daa1",
	"title": "MontysThree: Industrial espionage with steganography and a Russian accent on both sides",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1107624,
	"plain_text": "MontysThree: Industrial espionage with steganography and a\r\nRussian accent on both sides\r\nBy Denis Legezo\r\nPublished: 2020-10-08 · Archived: 2026-04-05 21:21:31 UTC\r\nIn summer 2020 we uncovered a previously unknown multi-module C++ toolset used in highly targeted industrial\r\nespionage attacks dating back to 2018. Initially the reason for our interest in this malware was its rarity, the\r\nobviously targeted nature of the campaign and the fact that there are no obvious similarities with already known\r\ncampaigns at the level of code, infrastructure or TTPs. To date, we consider this toolset and the actor behind it to\r\nbe new. The malware authors named the toolset “MT3”; following this abbreviation we have named the toolset\r\n“MontysThree”.\r\nFollowing the MT3 abbreviation we named the toolset MontysThree\r\nThe malware includes a set of C++ modules used for persistence, obtaining data from a bitmap with\r\nsteganography, decryption of configuration tasks (making screenshots, fingerprinting the target, getting the file,\r\netc.) and their execution, and network communications with major legitimate public cloud services such as\r\nGoogle, Microsoft and Dropbox. MontysThree is configured to search for specific Microsoft Office and Adobe\r\nAcrobat documents stored in current documents directories and on removable media. The malware uses custom\r\nsteganography and several encryption schemes: besides custom XOR-based encryption, the modules rely on\r\n3DES and RSA algorithms for configuration decryption and communications.\r\nMontysThree contains natural language artifacts of proper Russian language and configuration that seek\r\ndirectories that exist only on Cyrilic localised Windows versions. While most external public cloud\r\nhttps://securelist.com/montysthree-industrial-espionage/98972/\r\nPage 1 of 9\n\ncommunications use token-based authorisation, some samples contain email-based accounts for them, which\r\npretend to be a Chinese lookalike. We consider these names to be false flags. Many more artifacts suggest that the\r\nmalware was developed by a Russian-speaking actor and is targeting Cyrillic Windows versions.\r\nHow the malware spreads\r\nThe initial loader module is spread inside RAR self-extracting archives (SFX) with names related to employees’\r\nphones list, technical documentation and medical test results. There are no lures, only PE files (masquerading a\r\n.pdf or .doc file), but such titles are now a typical trick used in spear-phishing – “corporate info update” or\r\n“medical analysis results”. One of the loaders (MD5 da49fea229dd2dedab2b909f24fb24ab) has the name\r\n“Список телефонов сотрудников 2019.doc” (“Employee phone list”, in Russian). Other loaders have the names\r\n“Tech task.pdf” and “invitro-106650152-1.pdf”. The latter is the name of a medical laboratory in Russia. All of\r\nthem seem like typical spear-phishing tricks. The SFX script is as follows:\r\nPath=%TEMP%\\\r\nSavePath\r\nSetup=rundll32.exe \"invitro-106650152-1.pdf\",Open\r\nSilent=1\r\nOverwrite=1\r\nUpdate=U\r\nDelete=invitro-106650152-1.pdf\r\nOn execution, the SFX script calls the Open() function (we’ll return to this exported name) of the decompressed\r\nloader executable in the %TEMP% directory and deletes it. Judging by the filename, it most likely imitates\r\nmedical analysis results, given that “Invitro” is a prominent medical laboratory in Russia. This initial PE32 is the\r\nfirst loader module.\r\nHow modules work and communicate\r\nhttps://securelist.com/montysthree-industrial-espionage/98972/\r\nPage 2 of 9\n\nExecution flow of MontysThree’s modules\r\nThe diagram above shows the overall execution flow of the MontysThree modules. Four modules and their\r\nfeatures are listed in the table below. The modules share common communication conventions. When dealing with\r\nshared data, such as the configuration and detailed execution log, the malware initializes the structure in thread\r\nlocal storage (TLS), which in its turn refers to heap structures. Interestingly, besides RAM, the execution log is\r\nstored on disk in a file, encrypted with a one-byte XOR.\r\nThe entry point DllEntryPoint() works just like a construtor, which allocates the structure with TlsAlloc() and\r\nsaves it in a global variable. Modules must export a function named Open(), which takes no parameters (but could\r\nparse the command line) and returns a four-byte error code.\r\nModule name Features\r\nLoader\r\nThis anti-detection module is in charge of custom steganography, kernel module\r\ndecryption.\r\nKernel\r\nThis kernel (main) module is in charge of decrypting the config XML, then parsing and\r\nexecuting the corresponding tasks in it.\r\nHttpTransport\r\nNetwork module to communicate with Google, Microsoft, Dropbox legitimate public\r\ncloud services, as well as with WebDAV sources. The module is able to make requests\r\nthrough RDP and Citrix in a naive way using legitimate clients.\r\nLinkUpdate Persistence module is a Windows Quick Launch .lnk modifier. With this naive persistence\r\nmethod users would run the Loader module by themselves every time along with the\r\nhttps://securelist.com/montysthree-industrial-espionage/98972/\r\nPage 3 of 9\n\nbrowsers from the Windows Quick Launch toolbar.\r\nNow let’s take a look how the developers mixed strong modern cryptography standards with custom XOR-based\r\nones.\r\nTask Encryption in use\r\nSteganography To decrypt the kernel module the initial loader uses a custom algorithm.\r\nLogs encryption\r\nThe malware logs exist in memory as well as in encrypted files on disk at the same\r\ntime. In RAM the developers store the logs in plaintext, on disk they use one-byte\r\nXOR.\r\nConfig encryption\r\nKernel module uses strong encryption algorithms. Configuration data is encrypted\r\nwith 3DES and the key is encrypted using RSA. All the keys – RSA public/private as\r\nwell as encrypted 3DES – are stored inside the module’s .data section.\r\nNetwork module\r\nencryption\r\nInitially encrypted HttpTransport is made of four binary blobs stored in the kernel\r\nmodule. The kernel concatenates them and decrypts them with a custom XOR-based\r\nalgorithm. A round key of four bytes length is used\r\nCommunications\r\nencryption\r\nThe encryption algorithm is RSA using the same public and private keys stored inside\r\nthe kernel module .data section.\r\nLoader module: Bitmap decryptor and next stage launcher\r\nIf the filename of the bitmap containing the steganography-encrypted data is provided to the loader as an\r\nargument, the loader decrypts the next stager from the pixel array. In the first iteration, it extracts the\r\nsteganography parameter data. To do so, the algorithm takes the last bits of the bytes.\r\nhttps://securelist.com/montysthree-industrial-espionage/98972/\r\nPage 4 of 9\n\nThe IID, IParam and ISize parameters are kept in the first 384 bytes of the pixel array, meaning that only the last\r\nbit of every pixel array’s byte is needed. As a result, the module gathers 48 bytes of steganography configuration\r\nstructure with the fields, determining the next decryption stages.\r\nField Offset Features\r\nIID 0x00 Determines one or two decryption layers would apply to the following pixel array.\r\nIParam 0x04 Determines which bits from pixel arrays bytes would form the next kernel module.\r\nISize 0x28 The decrypted kernel module’s resulting size.\r\nAfter extracting the steganography parameters, the next stager is decrypted using a two-step algorithm. Firstly, the\r\nIParam algorithm chooses the bits from the pixel array’s bytes. Then, if IID equals 2, a custom dexoring operation\r\nusing a four-byte round key is applied on the gathered bytes. The initial key for the first four-byte decryption has\r\nthe hardcoded value 0x23041920. Then the formula for the round XOR key for the next bytes is:\r\nkey ^= 8 * (key ^ (key \u003c\u003c 20))\r\nWe consider this steganography algorithm to be custom made and not taken from some open source third-party\r\nrepository. Surprisingly, the decryption result is not injected into some process’s memory, but dropped to disk as a\r\nfile named msgslang32.dll. The loader then simply uses the Windows API functions LoadLibraryW() and\r\nGetProcAddress() to run the next stager’s Open() function, as we previously saw with the loader module.\r\nKernel module: Config decryptor and tasks dispatcher\r\nThe kernel module contains three encryption keys used for configuration decryption and C2 communications.\r\nPublic and private RSA keys are stored in the .data section as PUBLICKEYBLOB and PRIVATEKEYBLOB\r\nrespectively. These are used to encrypt C2 communications and to decrypt the 3DES key as well. The third 3DES\r\nkey is also stored in the .data section in its encrypted form; this key is used to decrypt an embedded .cab archive\r\ncontaining the XML config. To decompress the .cab archive the module uses Window’s standard system utility,\r\n“expand.exe”. We’ll see another common software usage in the HttpTransport module.\r\nThe XML configuration contains valuable data that helps us understand the campaign operator’s interest. It is\r\nstructured using various “tasks” for the malware, such as fingerprinting the target using its OS version, process list\r\nand capturing screenshots; but also grabs the list of users’ recent documents with any of the extensions .doc, .docx,\r\n.xls, .xlsx, .rtf, .pdf, .odt, .psw, .pwd from the several recent documents directories in %USERPROFILE% and\r\n%APPDATA%, including %APPDATA%\\Microsoft\\Office\\Последние файлы. This folder name translates to\r\n“Recent files” in Russian, suggesting that the malware is aimed at Cyrillic localised Windows versions.\r\nhttps://securelist.com/montysthree-industrial-espionage/98972/\r\nPage 5 of 9\n\nConfig holds the tasks scheduling (screenshot top), access tokens (here Dropbox, redacted), directories and\r\nextensions of interest. One directory exists only on Cyrillic Windows localized versions\r\nWe observed several Cyrillic text strings such as “Снимок рабочего стола” (desktop snapshot), “Системная\r\nинформация” (system information), “Время выхода” (exit time).\r\nConfig tasks description starts with MT3D and contains proper short phrases in Russian\r\nThe decrypted config structure is as follows:\r\nField Size Content\r\nMagic 4 bytes MT3D. All parsed files must have this as a prefix to be valid\r\nCreation\r\ntime\r\n4 bytes Timestamp, task config creation time stored as Epoch time\r\nHeader size 4 bytes Header size has to be greater than 18. Observed value is e.g. 0x7E\r\nXML size 4 bytes\r\nXML task description has to be greater than zero. Observed value is e.g.\r\n0x662D\r\nXML body\r\nXML\r\nsize\r\nThe task’s description and schedule in XML format\r\nWhile the samples we looked at didn’t contain RTTI information, the execution logs allowed us to recover the\r\nC++ class names. After the kernel module parses the tasks from the configuration into memory, the main class that\r\nhttps://securelist.com/montysthree-industrial-espionage/98972/\r\nPage 6 of 9\n\nprocesses the instruction is CTask. CTask’s IoControl() method is in charge of handling the corresponding tasks\r\nand in turn runs the following methods:\r\nCTask method Features\r\nMainIoControl()\r\nHandler of “Main” task in XML. In case of a RESET command the file, serving as a\r\n“pipe”, will be deleted. Any other command here will be logged, but not executed\r\nFileIoControl()\r\nHandler of “File” task with PUT, DEL, FIND, WATCH, WATCH_REMOVABLE,\r\nRUN and LOGS subcommands\r\nSysInfoIoControl() Handler of “SysInfo” task with SCREENSHOT, INFO and TASKLIST subcommands\r\nHttpIoControl() Handler of “Http” task with SENDRECV subcommand\r\nGDriveIoControl() Handler of “GDrive” task with SENDRECV subcommand\r\nDropboxIoControl() Handler of “Dropbox” task with SENDRECV subcommand\r\nAll methods used for external communications first decrypt the HttpTransport module and use it to transmit the\r\ncorresponding data RSA-encrypted. The RSA keys in use are the same aforementioned keys used to decrypt the\r\n3DES config key. In a separate Window procedure, the malware monitors if a USB device is plugged in, searching\r\nfor files of interest.\r\nHttpTransport module: network tasks\r\nThe HttpTransport module exists as four encrypted chunks of data inside the .text section of the kernel module.\r\nWhen the kernel needs to communicate, it decrypts this module and, as usual for MontysThree, runs the Open()\r\nfunction, passing command line arguments.\r\nDepending on the arguments transmitted from the kernel module, the module may upload or download content\r\nusing RDP, WebDAV, Citrix and HTTP protocols. Downloading data from Google and Dropbox public services\r\nusing user tokens is implemented in HttpTransport as well. In case of HTTP GET/POST requests, the malware\r\nwould receive a steganography bitmap picture using Windows API HTTP-related functions from a corresponding\r\nURL.\r\nThe aforementioned communication protocols themselves aren’t implemented inside the module. The malware\r\nauthors make use of legitimate Windows programs like RDP, Citrix clients and Internet Explorer already installed\r\non the target’s machine. For example, the module executes a task to send some data to a URL and receive the\r\nreply through an RDP connection as follows: edit the .rdp file to silently run Internet Explorer on the remote\r\nmachine; paste the URL to the browser via the clipboard; wait and paste the contents to the opened web page via\r\nthe clipboard as well; wait and receive the result through the clipboard again.\r\nTo copy data, the malware literally sends Ctrl+C, Ctrl+V and Ctrl+A. Perhaps it’s the first time we have seen such\r\na method of “RDP communication”. The Citrix communication is done using a similar procedure: the malware\r\ndoesn’t implement the protocol but rather searches for Windows Quick Launch .lnk for XenApp pnagent.exe, runs\r\nInternet Explorer remotely and communicates with it through the clipboard using special keyboard shortcuts.\r\nhttps://securelist.com/montysthree-industrial-espionage/98972/\r\nPage 7 of 9\n\nDropbox and Google data upload and download relies on another principle: its implementation uses the custom\r\nclass CSimpleHttp to authenticate and send HTTP requests. For WebDAV communication, the developers simply\r\nuse the “net use” Windows command.\r\nLinkUpdate\r\nThis auxiliary module is in charge of achieving persistence on the host. It changes the .lnk files in the Windows\r\nQuick Launch panel to run the loader along with legitimate applications such as browsers when the user executes\r\nthem using the modified link.\r\nWho is behind this malware\r\nAs we mentioned at the beginning, to date we have observed no similarities or overlaps with known campaigns in\r\nterms of TTPs, infrastructure or malware code. So far, we attribute this activity and the use of MontysThree to a\r\nnew actor. Some samples contain account details used for communicating with public cloud services, which\r\npretend to be of Chinese origin. Taking into consideration all the aforementioned Cyrilic artefacts, we consider\r\nthese account names to be false flags.\r\nWe assume that the actor behind MontysThree is both Russian-speaking and is going after Russian-speaking\r\ntargets. Some of the filenames of the RAR SFX archives used for spreading the malware were written in Russian\r\nand referenced a Russian medical laboratory, used to entice the user to open the file. The XML configuration\r\nshowcased data fields and Windows titles written in Russian, as well as specific folder paths that exist on Cyrilic\r\nlocalised versions of Windows. We also saw some grammatical errors in the malware’s English log message\r\nstrings.\r\nLet’s sum up\r\nTypically we see targeted malware that is mostly going after governmental entities, diplomats and telecom\r\noperators, which are fruitful for state-sponsored actors. Industrial espionage cases like MontysThree are far more\r\nrare.\r\nThe overall campaign sophistication doesn’t compare to top notch APT actors in terms of spreading, persistence\r\nmethod. And some aspects of the malware – logging in RAM and files at the same time, keeping the encryption\r\nkeys in the same file, running an invisible browser on the remote RDP host – seem immature and amateurish in\r\nterms of malware development.\r\nOn the other hand, the amount of code and therefore effort invested, in MontysThree is significant. The toolset\r\ndemonstrates some tech-savvy decisions: Storing 3DES key under RSA encryption, custom steganography to\r\navoid IDS and the use of legitimate cloud storage providers to hide the C2 traffic.\r\nFile Hashes\r\nLoader\r\n1B0EE014DD2D29476DF31BA078A3FF48\r\nhttps://securelist.com/montysthree-industrial-espionage/98972/\r\nPage 8 of 9\n\n0976C442A06D2D8A34E9B6D38D45AE42\r\nA2AA414B30934893864A961B71F91D98\r\nKernel\r\nA221671ED8C3956E0B9AF2A5E04BDEE3\r\n3A885062DAA36AE3227F16718A5B2BDB\r\n3AFA43E1BC578460BE002EB58FA7C2DE\r\nHttpTransport\r\n017539B3D744F7B6C62C94CE4BCA444F\r\n501E91BA1CE1532D9790FCD1229CBBDA\r\nD6FB78D16DFE73E6DD416483A32E1D72\r\nDomains and IPs\r\nautosport-club.tekcities[.]com\r\ndl10-web-stock[.]ru\r\ndl16-web-eticket[.]ru\r\ndl166-web-eticket[.]ru\r\ndl55-web-yachtbooking[.]xyz\r\nSource: https://securelist.com/montysthree-industrial-espionage/98972/\r\nhttps://securelist.com/montysthree-industrial-espionage/98972/\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://securelist.com/montysthree-industrial-espionage/98972/"
	],
	"report_names": [
		"98972"
	],
	"threat_actors": [],
	"ts_created_at": 1775434244,
	"ts_updated_at": 1775791219,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e4fa009a4b8bfff2a7355a398d76494b8254daa1.pdf",
		"text": "https://archive.orkl.eu/e4fa009a4b8bfff2a7355a398d76494b8254daa1.txt",
		"img": "https://archive.orkl.eu/e4fa009a4b8bfff2a7355a398d76494b8254daa1.jpg"
	}
}