{
	"id": "89348ee9-5984-4dad-98c4-b01343fc0543",
	"created_at": "2026-04-06T00:09:10.922654Z",
	"updated_at": "2026-04-10T03:35:46.052316Z",
	"deleted_at": null,
	"sha1_hash": "9db285382e591a59b15c507062e3c59ff08c3e2e",
	"title": "Flying in the clouds: APT31 renews its attacks on Russian companies through cloud storage",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1384896,
	"plain_text": "Flying in the clouds: APT31 renews its attacks on Russian companies\r\nthrough cloud storage\r\nBy Positive Technologies\r\nPublished: 2024-08-19 · Archived: 2026-04-05 20:15:12 UTC\r\nIntroduction\r\nIn April 2022, PT Expert Security Center detected an attack on a number of Russian media and energy companies that used\r\na malicious document called «list.docx» to extract a malicious payload packed with VMProtect. Having analyzed the\r\nnetwork packet, we found it to be identical to the one we studied in our report on APT31 tools, suggesting that these may\r\nbelong to one and the same group. The malware samples date from November 2021 to June 2022.\r\nDetailed analysis (see the \"Attribution\" section) of the unpacked malware confirmed our assumptions, as the malicious\r\npayload under VMProtect was indeed identical to the one we examined earlier.\r\nFurther monitoring revealed a number of documents used in attacks on the same companies with content similar in terms of\r\nthe techniques used (see the \"Malware analysis\" section), yet differing from what we saw earlier both in the network part\r\nand the code implementation.\r\nDetailed analysis of the tools showed the use of the Yandex.Disk service as the C2 server. This seemed a rather curious case\r\nto us, since it involved a potentially foreign group using a Russian service specifically to make the network load look\r\noutwardly legitimate.\r\nThe technique is not new, having been deployed by the TaskMasters group in its Webdav-O malware. The point of this\r\ntechnique is to bypass network defenses by connecting to a legitimate service.\r\nThis group's previous use of the Dropbox cloud service, as well as overlaps with the above-mentioned tools, suggests that\r\nhere too we are dealing with the toolkit of the APT31 group.\r\nThis report describes the tools and techniques and their features, discusses the similarities and differences, and lays out the\r\ncharacteristics on which basis we assigned them to the APT31 group.\r\nAnalyzing malicious documents\r\nThe source document we started our research with (Figure 1) uses the Template Injection technique to download a template\r\nwith a macro that loads malicious components (a legitimate file, a Java component, a malicious msvcr100.dll packed with\r\nVMProtect) from a remote server.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt31-cloud-attacks/\r\nPage 1 of 19\n\nFigure 1. External appearance of the malicious document\r\nThe template macro, a snippet of which is shown in Figure 2, creates files at the following path:\r\nC:\\ProgramData\\KasperskyOneDrive. The main task of the legitimate file is to transfer control to the malicious library using\r\nthe DLL Side-Loading technique and generate an initializing packet that is sent to C2 (see the \"Attribution\" section).\r\nFigure 2. External appearance of the loaded macro\r\nDuring a further search for similar threats, a number of documents were found with the Author field equal to pc1q213\r\n(Figure 3), containing an identical Base64 decoding code.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt31-cloud-attacks/\r\nPage 2 of 19\n\nFigure 3. Properties of the detected document\r\nAnalysis of the detected documents clearly showed their external similarity (Figure 4). Moreover, the code of the macros\r\ncontained in them is identical all the way up to the names of the functions and variables (Figures 5 and 6).\r\nFigure 4. External appearance of the detected document\r\nA characteristic feature of all the documents is that they contain components for exploiting DLL Side-Loading to run the\r\nmalicious payload inside them, as well as the external similarity of macros embedded in the documents and the Base64\r\nencoding of the payload inside the documents.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt31-cloud-attacks/\r\nPage 3 of 19\n\nFigure 5. External appearance of the macro in the detected document\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt31-cloud-attacks/\r\nPage 4 of 19\n\nFigure 6. Code of a macro from a similar document\r\nThe extracted payload also shows a number of similarities:\r\nMost of the binary files are packed with VMProtect;\r\nAll the identified legitimate executable files are components of Yandex.Browser and signed with a valid digital\r\nsignature;\r\nwinhttp.dll and wtsapi.dll were used as malicious libraries under the guise of legitimate ones (in particular, by the\r\npresence, number, and names of exports).\r\nMalware analysis\r\nOur analysis identified two new types of malware, which we named YaRAT (because it has RAT functionality and uses\r\nYandex.Disk as C2) and Stealer0x3401 (because of the constant used in obfuscating the encryption key). What's more, we\r\nsaw YaRAT in two modifications: with token encryption inside the program code, and without it.\r\nYaRAT\r\nThe Yandex.Browser installer signed with a valid Yandex digital signature, or its portable version, was used as a legitimate\r\nfile vulnerable to the Side-Loading DLL. The file loads and calls a function in the malicious winhttp.dll.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt31-cloud-attacks/\r\nPage 5 of 19\n\nFigure 7. Information about the digital signature of a legitimate executable file\r\nAnd here's an example of function calls inside a legitimate binary file.\r\nFigure 8. Calling a malicious library function\r\nThe malicious library itself is packed and encrypted, and is unpacked by calling DllEntryPoint, which happens whenever the\r\nlibrary is loaded. In this case, DllEntryPoint contains code similar to UPX, which is probably borrowed but slightly\r\nmodified.\r\nThe first stage also involves unpacking LZMA, after which the unpacked data is decrypted twice (code sections and other\r\nsections (imports, data, etc.) are decrypted separately).\r\nThe data is decrypted using the RC4 algorithm; both encryption keys are embedded in the code. A distinctive feature of both\r\ndata decryption blocks is the type of code obfuscation (Control Flow Flattening), which hinders static analysis. Alongside\r\nthis technique, an extra byte (0xB9) is inserted inside the function body, which confuses the disassembler and prevents it\r\nfrom generating the function's decompiled form.\r\nAn example of the code responsible for data decryption after the PRNG stage is given in Figure 9.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt31-cloud-attacks/\r\nPage 6 of 19\n\nFigure 9. Snippet of an obfuscated block that handles code and data decryption\r\nThe subsequent code for restoring imports and their addresses (resolving function and library addresses), as well as changing\r\nattributes for virtual memory blocks (VirtualProtect calls), is identical to regular UPX (Figure 10 shows a snippet of packer\r\ncode, Figure 11 shows regular UPX). Note also the distinctive, UPX-specific push and pop calls at the start and end,\r\nrespectively, of the unpack function. After unpacking, control passes to the payload.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt31-cloud-attacks/\r\nPage 7 of 19\n\nFigure 10. Snippet of packer code\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt31-cloud-attacks/\r\nPage 8 of 19\n\nFigure 11. Snippet of regular UPX code\r\nPayload\r\nAt the first stage, a mutex named YandexDisk is created, and the malware adds itself to startup via a registry key.\r\nFigure 12. Creating a mutex and securing it in the system\r\nNext, the malware generates string requests to Yandex.Disk with the Authorization: OAuth parameter, to which the token for\r\nthis account is concatenated (Figure 13). The token itself is stitched into the code. We found several keys belonging to three\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt31-cloud-attacks/\r\nPage 9 of 19\n\naccounts: jethroweston, Poslova.Marian, upy4ndexdate.\r\nFigure 13. Generating a request to Yandex.Disk\r\nAfter that, two lines are generated according to the pattern: pcname + /a.psd and pcname + /b.psd, for example: DESKTOP-IM5NM8R/a.psd, DESKTOP-IM5NM8R/b.psd.\r\nThe first request sent by the malware to C2 is a PUT to\r\n \r\nhttps://cloud-api.yandex.net:443/v1/disk/resources?path=\r\n \r\n(Figure 14 shows an example of generating it). It can be seen as an initializing request to be used to create a directory on\r\nYandex.Disk (a working remote directory).\r\nFigure 14. Generating a PUT request and sending it to the server\r\nIf the connection is successful, the malware downloads a file (Figure 15) whose name consists of the following strings: the\r\nname generated in the previous step and the string modifier a.psd, which ends (is concatenated to the end of) the string\r\nname. For example,\r\n \r\nhttps://cloud-api.yandex.net/v1/disk/resources/download?path=DESKTOP-IM5NM8R%2Fa.psd\r\n \r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt31-cloud-attacks/\r\nPage 10 of 19\n\nFigure 15. Contents of the file downloaded from C2\r\nThe downloaded file contains a list of commands to be executed by the malware in order to retrieve basic information about\r\nthe infected machine.\r\nThe commands are executed in a standard Windows shell (cmd.exe); the malware concatenates their results, forms them into\r\na response, and sends them to Yandex.Disk as a b.psd file. Note that the result of the execution of each command is\r\nseparated from the others by the line ==============\\r\\n (Figure 16 clearly shows the results of execution separated by\r\nthis line).\r\nFigure 16. Contents of the file with the collected data\r\nNext, the malware switches to command execution mode. Malware-executed commands:\r\nDIR — retrieves the list of files in the directory;\r\nEXEC — executes the command (in fact, calls the WinExec function of the kernel32.dll library);\r\nSLEEP — calls the Sleep function with a parameter (0x3E8 multiplied by the passed constant);\r\nUPLOAD — uploads a file to Yandex.Disk;\r\nDOWNLOAD — downloads a file from Yandex.Disk.\r\nAll network communication is via cURL. In turn, data is transferred in JSON format, so the nlohmann/json, library is used\r\nto handle it; both libraries are statically compiled with the project.\r\nSecond YaRAT modification\r\nAlso found were a number of samples covered by VMProtect and not packed with the packer described above. A distinctive\r\nfeature of all the samples is that only DllEntryPoint is covered by the protector, while the exports, which contain the main\r\nfunctionality, were not virtualized (except for some WinAPI calls).\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt31-cloud-attacks/\r\nPage 11 of 19\n\nAnother distinguishing feature of such malware samples is the Blowfish-encrypted token with a key embedded in the code.\r\nFigure 17. Decryption key inside the malware\r\nDespite the virtualized API calls, the application lends itself to static analysis and has a functionality quite similar to the one\r\ndiscussed above. The names of the built-in commands have not changed, and some commands may be missing.\r\nAs in the previous case, communication is via cURL; the same library is used to process JSON.\r\nStealer0x3401\r\nThe infection mechanism in this case is identical to the one examined in in our report: the legitimate binary file\r\ndot1xtray.exe downloads the malicious msvcr110.dll. In this instance, the __crtGetShowWindowMode export was\r\nmalicious.\r\nIn the first step, the malware checks the name of the running process, which should not be qip.exe, aim.exe, or icq.exe.\r\nOtherwise, control will not pass to the main functionality.\r\nNext, the address of the C2 server is decrypted (Figure 18). This algorithm is clearly identical to the one discussed in the\r\nprevious report. Both the encryption key and the format of its location remained unchanged.\r\nFigure 18. Decryption algorithm for the C2 server address\r\nNext, the malware harvests the necessary information about the system by group. A list of these groups is shown in Figure\r\n20 Note that this list is highly detailed and we have not seen such a list before. What's more, earlier tools used by the group\r\ncollected other data. The fact that the malware contains lines in Russian is also curious (Figure 19).\r\nFigure 19. Example of a command contained in malware\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt31-cloud-attacks/\r\nPage 12 of 19\n\nFigure 20. Information harvested about the system\r\nAll collected data is RC4-encrypted and Base64-encoded before being sent. In contrast to what we saw earlier, an encryption\r\nkey is generated for each new run; the key generation algorithm is as follows (Figure 21): based on the current time, 16\r\npseudo-random numbers of qword type are generated (the loop adds 64-bit numbers up to the specified address; the\r\ndifference between them is 128 bytes; accordingly, 16 qword values are obtained as per the data type), to which the standard\r\nkey expansion procedure for RC4 is then applied. After that, the collected data is encrypted using the expanded key.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt31-cloud-attacks/\r\nPage 13 of 19\n\nFigure 21. Generating the encryption key\r\nWhen transmitting encrypted data, the encryption key is not sent in cleartext; to obfuscate it, the previously unseen, so-called checksum procedure (Figure 22) is used for each qword value used in the key expansion procedure.\r\nThe procedure itself consists of two stages: generating a hash calculation table and directly calculating the result. The first\r\nstage involves cyclically computing the remainders from dividing the initializing constant (in this case 0x3401) using\r\nmodulo 2 (until it becomes zero), that is, the number of rounds at each step of the checksum calculation will be identical.\r\nAt the second stage, the initial value is modified (_inputVal in Figure 22) in accordance with two variables initially equal to\r\n0 and 1 (temValDword_1 and tempvalDword2 in Figure 22), from which at each step a value of type __int64 modulo\r\n0x90c9bff is generated (result_x64Val in Figure 22). The constants themselves are also modified in each round.\r\nAs we see, the initial value is modified in each specific round as per the table of remainders created in the first stage. If the\r\nremainder is equal to 1, the hash, the variables themselves used in calculating the intermediate values, and the final value are\r\nall modified. Hence, a final value is generated for the specified 14 rounds (known in advance as regards modifying the initial\r\nvalue, since the table for all rounds is identical).\r\nThe generated hash for each of the qword components of the encryption key, the malware transmits to the server side.\r\nFigure 22. Encryption key obfuscation procedure\r\nThus, the structure describing the encoded data is fairly simple:\r\n \r\nstruct Message{\r\n QWORD key[16]; // hash array of qword components of the RC4 key\r\n char encrData[sizeOfData];\r\n};\r\n \r\nThe generated data is Base64-encoded, after which it is prepended with the data= string and transmitted in this form to the\r\nserver (Figure 23).\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt31-cloud-attacks/\r\nPage 14 of 19\n\nFigure 23. Data sent to the server\r\nThe malware sends the generated data to the C2 server ramblercloud[.]com, which is disguised as a legitimate Rambler\r\ncloud drive, but is not.\r\nAttribution\r\nWhile examining a document that used Template Injection (see the \"Analyzing malicious documents\" section) and infected\r\nthe system when run, we detected traffic described by us in our previous report (see Figure 24).\r\nFigure 24. Fragment of detected traffic (the transmission format resembles that of previously investigated\r\nmalware)\r\nAfter infecting the system, the malware exchanges data with C2, then executes commands from it.\r\nAnalysis of the unpacked sample revealed similarities with the samples we found earlier. In particular, the names of RTTI\r\nobjects (including the names of the vtbl tables used for communication with C2) turned out to be identical, as did the\r\nfunctionality of both applications. No changes to the architecture, executable commands, or packet generation methods were\r\nidentified, nor had the traffic encryption key embedded in the program code been modified. The sole difference between the\r\nmalware samples is the partial virtualization of API calls inside the protected application (which is typical for any program\r\ncovered by VMProtect). A snippet of the function for processing commands from the server is given in Figure 25.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt31-cloud-attacks/\r\nPage 15 of 19\n\nFigure 25. External appearance of the function for executing commands\r\nAlso unchanged are the service strings and format strings used to generate packages and data structures within the\r\napplication, the names of the APIs used, and the order in which they are called.\r\nAnalysis of various malicious components revealed a characteristic sign that points to a single code base. In all cases, the\r\nmalware harvested information about network adapters, and the function code and call sequence were identical: a call to\r\nGetAdaptersInfo, then retrieval of the value of the NetCfgInstanceId and Characteristics keys in the\r\nSYSTEM\\\\CurrentControlSet\\\\Control\\\\Class\\\\{4D36E972-E325- 11CE-BFC1-08002BE10318} registry hive.\r\nThese calls by themselves are quite standard; that said, we found no other examples of using this technique.\r\nThe code generated by the compiler was also identical, snippets of which (see Figure 26) we found in all unpacked malware\r\ncomponents used in the campaign.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt31-cloud-attacks/\r\nPage 16 of 19\n\nFigure 26. Code snippet present in all malware found\r\nConfirms our assumption that this malware belongs to the APT31 group.\r\nAll the malicious components we detected can be divided into several groups:\r\nDocuments with the same stub;\r\nSource documents have the same Author field;\r\nMalicious components have unique (within the scope of our coverage) code snippets that we have not seen\r\nelsewhere;\r\nMalware uses a cloud service in the role of C2.\r\nThe first point of interest is the external similarity between the stub in the documents that we attributed to the APT31 group\r\nabove and the stub in one of the documents that extracted malicious components interacting with Yandex.Disk. The second\r\nis the identical code for retrieving information about network adapters that we encountered in both the attributed tools and in\r\nthe tools described in this report.\r\nOf particular note is the malware that harvested information about the infected system. This malicious component contains\r\ncode we saw in the previous report on APT31 activity, with the code itself identical to that which was presented there. This\r\nmalware additionally installed in the system a document with the Author field that we saw in other detected malware.\r\nThis malware thus acts as a linchpin for all the malicious components discussed above.\r\nHaving analyzed the above-mentioned tools, we can assign the malware samples studied to one group with a high degree of\r\ncertainty. And given the use of cloud services as C2 servers (in this case, Yandex.Disk), which this group had already\r\nweaponized (previously it used Dropbox), we can assume that a single code base was used to write the malicious\r\ncomponents.\r\nThe similar infection and persistence techniques, the numerous intersections within the code implementation framework,\r\nand the artifacts of the compilation tools used all strongly suggest that the group may continue its attacks on organizations in\r\nRussia.\r\nAuthors: Denis Kuvshinov, Daniil Koloskov, PT ESC\r\nIndicators of compromise (IoC)\r\nFile indicators\r\nName MD5 SHA-1 SHA-256\r\nmsvcr100.dll 5897e67e491a9d8143f6d45803bc8ac8 d91ffc6d48f79e0b55918fb73365b9fca37c9efa 8148aeef6995c99c6f93ebce\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt31-cloud-attacks/\r\nPage 17 of 19\n\n- 91965ee08504eeb01e76e17007497852 fd05e69d1f094b3a28bb5ae2a936607aa0db3866 d7c1668c903a92f20bdeaee0\r\nWTSAPI32.dll 0c1e1fd94383efc5a3de8f0117c154b2 3785d9c4bdf6812f753d93b70781d3db68141ce7 aee1bf1f7e70f5cbd34a59b3\r\nАнкета по результатам\r\nтестирования.doc\r\n85f8bfb3b859a35e342e35d7c35e8746 ff5e78218198dd5ca5dc2eb46ec8afdd1b6260e9 a56003dc199224113e9c85b\r\nО заседании.doc 0c993a406be04b806222a130fb5a18e8 49307f1091251dd7a498cf69d0465ddd59859cf8 256d3065de2345a6beff945\r\nWINHTTP.dll dfaa28a53310a43031e406ff927a6866 c694e99f8690114c77a6099856d61a3cd4cd814d 4a5e9ab0e65e08ceb2adb2d\r\nСправка.doc 0c4540f659d3942a28f158bce7be1143 d1cc0f861f162dfbf9df1493fe861d02b80483f6 37e259d6564071807b7b426\r\nmsvcr110.dll 1d65ef16d1f161ae3faa5ed7896734cd 144493b13df06bab3f290b260b997b71164a25f7 0a5fb4a480b1748dc7f963a4\r\npayload_1.bin 176d11c9bafac6153f728d8afb692f6f ef0f61c32a3ae2494000f36a700a151c8b10c134 ea9429fa66ba14b99ff756b8\r\n5ehn6vctt.dll 5897e67e491a9d8143f6d45803bc8ac8 d91ffc6d48f79e0b55918fb73365b9fca37c9efa 8148aeef6995c99c6f93ebce\r\n– 50eb199e188594a42262a5bbea260470 af33573bc8e507875acdb3db52bcfea13bb1286e 0afeef5a4ac1b0bc778e66a1\r\n– c89eaa7f40fc75f9a34e0f0a3b59b88b f3c600ba1d1d0cb1f3383805dbcac19e9423bdcb 98b5cfa14dd805e1172b364\r\nWTSAPI32.dll 0c1e1fd94383efc5a3de8f0117c154b2 3785d9c4bdf6812f753d93b70781d3db68141ce7 aee1bf1f7e70f5cbd34a59b3\r\nWTSAPI32.dll 640e6ecad629bd33c09ccec52f4aa6da 584fd63ab925c532cf40818886487714b3de317e add70042c65cd683925936a\r\nlibcef.dll 11010e139010697a94a8feb3704519f9 52999153cc7d3a3771a8ee9b8e55f913829109a7 c2b769f40b1ec2ee57e4d36\r\nПриложение 1 к исх\r\nписьмо по списку\r\nрассылки.pdf\r\n099c7d85d0d26a31469465d333329778 d25a68289fc1268d7c548787373a6235895716fb c3382ebff9dcd0e8776820f7\r\nматериал-20220210.exe 8b4c1f0ff1cee413f5f2999fa21f94f9 97e19f67a8d6af78c181f05198aa7d200b243ea5 f49999f1d7327921e63097b\r\nNetwork indicators\r\nportal.super-encrypt.com\r\nsuper-encrypt.com\r\nportal.intranet-rsnet.com\r\nintranet-rsnet.com\r\np1.offline-microsoft.com\r\noffline-microsoft.com\r\ncdn.microsoft-official.com\r\nmicrosoft-official.com\r\nramblercloud.com\r\nyandexpro.net\r\nMITRE TTPs\r\nID Name Description\r\nInitial Access\r\nT1566 Phishing\r\nAPT31 sends phishing messages to gain access to\r\nvictim systems\r\nExecution\r\nT1204 User Execution\r\nAPT31 sends MS Word documents containing\r\nmalicious components\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt31-cloud-attacks/\r\nPage 18 of 19\n\nResource Development\r\nT1587.001 Malware\r\nAPT31 develops malware and malware components\r\nthat can be used during targeting\r\nT1587.002\r\nDevelop Capabilities: Code Signing\r\nCertificates\r\nAPT31 uses code signing to sign their malware and\r\ntools\r\nPersistence\r\nT1547.001\r\nBoot or Logon Autostart Execution: Registry\r\nRun Keys / Startup Folder\r\nAPT31 achieves persistence by adding a program to a\r\nRegistry run key\r\nT1574 Hijack Execution Flow\r\nAPT31 executes their own malicious payloads by\r\nhijacking the way operating systems run programs\r\nDefense Evasion\r\nT1140 Deobfuscate/Decode Files or Information\r\nAPT31 uses mechanisms to decode or deobfuscate\r\ninformation\r\nT1036 Masquerading\r\nAPT31 manipulates features of their artifacts to make\r\nthem appear legitimate to users\r\nT1112 Modify Registry APT31 team uses the Windows registry for persistence\r\nT1027 Obfuscated Files or Information\r\nAPT31 uses encryption to make it difficult to detect or\r\nanalyze an executable file\r\nCollection\r\nT1560 Archive Collected Data\r\nAPT31 tools encrypted the collected data before\r\nsending it to the servers\r\nCommand and Control\r\nT1001 Data Obfuscation\r\nAPT31 obfuscates command and control traffic to make\r\nit more difficult to detect\r\nT1095 Non-Application Layer Protocol APT31 group used SSL for data transmission\r\nT1573.001 Encrypted Channel: Symmetric Cryptography\r\nAPT31 used symmetric encryption algorithms to hide\r\ntransmitted data\r\nT1132.001 Data Encoding: Standard Encoding\r\nAPT31 group used RC4 and Base64 to hide transmitted\r\ndata\r\nT1132.002 Data Encoding: Non-Standard Encoding\r\nThe APT31 group used custom encryption key\r\nobfuscation algorithms as well as payload encryption\r\nT1102 Web Service APT31 group used Yandex.Disk as C\u0026C\r\nExfiltration\r\nT1020 Automated Exfiltration APT31 uses automatic exfiltration of stolen files\r\nT1041 Exfiltration Over C2 Channel APT31 uses C\u0026C channel to exfiltrate data\r\nSource: https://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt31-cloud-attacks/\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt31-cloud-attacks/\r\nPage 19 of 19\n\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt31-cloud-attacks/   \nFigure 5. External appearance of the macro in the detected document\n  Page 4 of 19",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/apt31-cloud-attacks/"
	],
	"report_names": [
		"apt31-cloud-attacks"
	],
	"threat_actors": [
		{
			"id": "ed4c7e37-461f-40f1-ad43-6ad7e21b32bc",
			"created_at": "2022-10-25T16:07:24.303712Z",
			"updated_at": "2026-04-10T02:00:04.929134Z",
			"deleted_at": null,
			"main_name": "TaskMasters",
			"aliases": [],
			"source_name": "ETDA:TaskMasters",
			"tools": [
				"404-Input-shell web shell",
				"ASPXSpy",
				"ASPXTool",
				"AtNow",
				"DbxDump Utility",
				"HTran",
				"HUC Packet Transmit Tool",
				"Mimikatz",
				"NBTscan",
				"PortScan",
				"ProcDump",
				"PsExec",
				"PsList",
				"RemShell",
				"RemShell Downloader",
				"gsecdump",
				"jsp File browser",
				"nbtscan",
				"pwdump",
				"reGeorg"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "aacd5cbc-604b-4b6e-9e58-ef96c5d1a784",
			"created_at": "2023-01-06T13:46:38.953463Z",
			"updated_at": "2026-04-10T02:00:03.159523Z",
			"deleted_at": null,
			"main_name": "APT31",
			"aliases": [
				"JUDGMENT PANDA",
				"BRONZE VINEWOOD",
				"Red keres",
				"Violet Typhoon",
				"TA412"
			],
			"source_name": "MISPGALAXY:APT31",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "4ae78ca3-8bc8-4d67-9df1-a85df250a8a0",
			"created_at": "2024-10-08T02:00:04.469211Z",
			"updated_at": "2026-04-10T02:00:03.726781Z",
			"deleted_at": null,
			"main_name": "TaskMasters",
			"aliases": [
				"BlueTraveller"
			],
			"source_name": "MISPGALAXY:TaskMasters",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "9e6186dd-9334-4aac-9957-98f022cd3871",
			"created_at": "2022-10-25T15:50:23.357398Z",
			"updated_at": "2026-04-10T02:00:05.368552Z",
			"deleted_at": null,
			"main_name": "ZIRCONIUM",
			"aliases": [
				"APT31",
				"Violet Typhoon"
			],
			"source_name": "MITRE:ZIRCONIUM",
			"tools": null,
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "74d9dada-0106-414a-8bb9-b0d527db7756",
			"created_at": "2025-08-07T02:03:24.69718Z",
			"updated_at": "2026-04-10T02:00:03.733346Z",
			"deleted_at": null,
			"main_name": "BRONZE VINEWOOD",
			"aliases": [
				"APT31 ",
				"BRONZE EXPRESS ",
				"Judgment Panda ",
				"Red Keres",
				"TA412",
				"VINEWOOD ",
				"Violet Typhoon ",
				"ZIRCONIUM "
			],
			"source_name": "Secureworks:BRONZE VINEWOOD",
			"tools": [
				"DropboxAES RAT",
				"HanaLoader",
				"Metasploit",
				"Mimikatz",
				"Reverse ICMP shell",
				"Trochilus"
			],
			"source_id": "Secureworks",
			"reports": null
		}
	],
	"ts_created_at": 1775434150,
	"ts_updated_at": 1775792146,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/9db285382e591a59b15c507062e3c59ff08c3e2e.pdf",
		"text": "https://archive.orkl.eu/9db285382e591a59b15c507062e3c59ff08c3e2e.txt",
		"img": "https://archive.orkl.eu/9db285382e591a59b15c507062e3c59ff08c3e2e.jpg"
	}
}