{
	"id": "94b1bb72-6729-4164-8e5b-19226e9bb13a",
	"created_at": "2026-04-06T00:15:47.365092Z",
	"updated_at": "2026-04-10T13:11:37.649321Z",
	"deleted_at": null,
	"sha1_hash": "b3edaaa08e0864c4c7a25cf2abaf52f3254edf2a",
	"title": "APT-C-35 Gets a New Upgrade",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1823113,
	"plain_text": "APT-C-35 Gets a New Upgrade\r\nBy Arnold Osipov \u0026 Hido Cohen\r\nArchived: 2026-04-02 11:45:30 UTC\r\nThe DoNot Team (a.k.a APT-C-35) are advanced persistent threat actors who’ve been active since at least 2016.\r\nThey’ve targeted many attacks against individuals and organizations in South Asia. DoNot are reported to be the\r\nmain developers and users of Windows and Android spyware frameworks [1][2][3].\r\nMorphisec Labs has tracked the group’s activity and now exclusively details the latest updates to the group’s\r\nWindows framework, a.k.a. YTY, Jaca. In this blog post, we briefly discuss the history of the DoNot team and\r\nshed light on updates revealed by the latest samples found in the wild. \r\nAPT-C-35/DoNot Background\r\nThe DoNot Team is consistent with their TTPs, infrastructure, and targets. They’re also well known for their\r\ncontinuous updates and improvements to their toolkit. \r\nThe group mainly targets entities in India, Pakistan, Sri Lanka, Bangladesh, and other South Asian countries. They\r\nfocus on government and military organizations, ministries of foreign affairs, and embassies.\r\nFor initial infection, the DoNot Team uses spear phishing emails containing malicious attachments. To load the\r\nnext stage they leverage Microsoft Office macros and RTF files exploiting Equation Editor vulnerability and\r\nremote template injection.\r\nKnown TTPs, or malware commonalities, include:\r\nModular architecture where each module is delivered in a separate file\r\nFunctionalities: file collection, screenshots, keylogging, reverse shell, browser stealing, and gathering\r\nsystem information\r\nVarious programming languages such as C++, .NET, Python, etc.\r\nUtilizing Google Drive to store command and control (C2) server addresses\r\nMultiple domains are used for different purposes throughout the infection chain\r\nAll previously known framework variants attributed to the DoNot Team share similar attributes.\r\nhttps://blog.morphisec.com/apt-c-35-new-windows-framework-revealed\r\nPage 1 of 18\n\nMorphisec Labs has identified a new DoNot infection chain that introduces new modules to the Windows\r\nframework. In this post we detail the shellcode loader mechanism and its following modules, identify new\r\nfunctionality in the browser stealer component, and analyze a new DLL variant of the reverse shell.\r\nMapping a Malware Route\r\nDelivery pathway to infect a machine\r\nDoNot’s latest spear phishing email campaign used RTF documents and targeted government departments,\r\nincluding Pakistan’s defense sector. When the RTF document is opened, it tries to fetch a malicious remote\r\ntemplate from its C2 by sending an HTTP GET request in the form: \u003cdomain\u003e/\u003cX\u003e/\u003cY\u003e.php. If the User-Agent\r\nfor that request doesn’t contain MSOffice, which is case sensitive and added by default in Office applications, the\r\nC2 returns a decoy document with empty content. Otherwise, it downloads and injects a macro weaponized\r\ndocument. This technique may trick a security solution that tries to scan the URL without the MSOffice User-https://blog.morphisec.com/apt-c-35-new-windows-framework-revealed\r\nPage 2 of 18\n\nAgent header and mark it as clear. The remote template URLs are active for a limited period of time which makes\r\nanalysis difficult.\r\nPre-Shellcode Execution \r\nWhen a remote template is injected, it lures the victim to enable editing and content to allow the malicious macros\r\nto execute. Once macros are enabled, the Document_open routine executes and starts with a for loop to delay the\r\nmalicious code execution, and then calls to the appropriate function based on the Winword.exe bitness.\r\nDocument_open routine code\r\nThe function injects a shellcode (32-bit/64-bit) into the process memory and invokes it. The shellcode is injected\r\nusing the following three WinAPI functions:\r\n1. ZwAllocateVirtualMemory—Allocates virtual memory with Execute/Read/Write permission\r\n2. MultiByteToWideChar—Maps the shellcode character string to UTF-16\r\n3. EnumUILanguagesA—Passes the shellcode as a callback parameter. Other variants also use the\r\nInternal_EnumSystemCodePages WinAPI\r\nWinAPI calls used for the shellcode execution\r\nDelivering the Payload\r\nBefore the execution of the payload, the shellcode decrypts itself using a simple decryption routine—not followed\r\nby xor with a two-byte key, which changes between stages. After the shellcode is invoked, it starts execution by\r\ndecrypting the rest of the shellcode bytes and passing the execution to the next stage. \r\nhttps://blog.morphisec.com/apt-c-35-new-windows-framework-revealed\r\nPage 3 of 18\n\nShellcode decryption routine before decrypting the next chunk\r\nNext, the shellcode downloads an encrypted blob from its C2: \u003cdomain\u003e/\u003cX\u003e/\u003cY\u003e\u003cZ\u003e.ico (for the 32-bit\r\nshellcode) or \u003cdomain\u003e/\u003cX\u003e/\u003cY\u003e\u003cZ\u003e.png (for the 64-bit shellcode) and decrypts it. The decrypted blob is the\r\nsecond-stage shellcode, and like the first-stage shellcode, it starts by decrypting the rest of the bytes in the\r\nshellcode before passing execution to the next stage.\r\nIn the 64-bit version of the first stage shellcode, the actor left what seem to be strings belonging to the\r\nconfiguration of the shellcode builder:\r\n'sm\\\\INCLUDE\\\\PCOUNT\\\\SHELL32.INC'\r\ninclude 'c:\\\\Fasm\\\\INCLUDE\\\\WIN32AXP.INC'\r\ninclude 'Shellcodes\\\\MyAssemblyMacros\\\\MyAssemblyMacrosMain.INC'\r\n;if debugging turn this bit on\r\ndebug = 0\r\nhttps://blog.morphisec.com/apt-c-35-new-windows-framework-revealed\r\nPage 4 of 18\n\nxor_key_main = 0xAD\r\nxor_key_payload = 0xFE\r\nxor_key_url = 0xCE\r\nexpiry_year_date = 0x7e6070f\r\nmcafee_expiry_year_date = 0\r\navg_expiry_year_date = 0\r\nnorton_expiry_year_date = 0\r\nbitdefender_expiry_year_date = 0x7e6070f\r\neset_expiry_year_date = 0x7e60717\r\ndefine_real_variable local_path_exe_env, '%tmp%\\\\..\\\\winsvsc.exe',0\r\ndefine_real_variable tmp_env_path, '%tmp%\\\\document.doc',0\r\ndefine_real_variable clear_registry, 'reg delete \\\"HKCU\\\\Software\\\\Microsoft\\\\Office\\\\12.0\\\\Word\\\\Resili\r\nThese configurations include XOR keys used in the second-stage shellcode, and expiry dates for security products\r\nsuch as McAfee, Norton, and Bitdefender. Some strings appear to be the attacker’s local paths and debugging\r\nflags.\r\nNext, the shellcode checks for security solutions by validating the existence of their drivers’ .sys, located under\r\nC:\\Windows\\System32\\drivers. If security solutions are present, the shellcode compares the current date to an\r\nexpiry date configured in the shellcode builder and operates accordingly. \r\nFor instance, in the researched sample, [1] – [7] denote the following values:\r\n[1] hxxp://mak.logupdates.xyz/DWqYVVzQLc0xrqvt/HG5HlDPqsnr3HBwOKY0vKGRBE7V0sDPdZb09n7xhp0klyT5X.mp3\r\n[2] hxxp://mak.logupdates.xyz/DWqYVVzQLc0xrqvt/HG5HlDPqsnr3HBwOKY0vKGRBE7V0sDPdZb09n7xhp0klyT5X.doc\r\n[3] %tmp%\\syswow64.dll\r\n[4] %tmp%\\document.doc\r\n[5] Qoltyfotskelo\r\n[6] schtasks.exe /create /tn wakeup /tr \\\"rundll32 %tmp%\\syswow64.dll, HPMG\\\" /f /sc DAILY /st 11:00 /ri 10 /du\r\n[7] cmd.exe %tmp%\\\\syswow64.dll\r\nThe malware will execute values depending on whether it finds a security solution. For example, the following\r\ntable demonstrates the operation performed based on the driver found and the comparison between the current\r\ndate and expiry date:\r\nDriver\r\nName\r\nAffiliate\r\nExpiry\r\nDate\r\nSets Action 1 Action 2\r\ngzfit.sys BitDefender\r\nAntivirus\r\n0x7E6070F\r\n-\u003e\r\n2022/07/15\r\nif\r\ncurrent_date\r\n\u003c= expiry:\r\nAction1 else:\r\nAction2\r\nDownloads\r\nfrom [1] to\r\n[3],\r\nDownloads\r\nfrom [1] to\r\n[3]\r\nDownloads\r\nfrom [2] to\r\nhttps://blog.morphisec.com/apt-c-35-new-windows-framework-revealed\r\nPage 5 of 18\n\nDriver\r\nName\r\nAffiliate\r\nExpiry\r\nDate\r\nSets Action 1 Action 2\r\nmodifies 3\r\nfirst bytes,\r\nand calls\r\nexported\r\nfunction [5]\r\n[4]\r\nExecutes\r\ncmd.exe,\r\nand [7] via\r\nWinExec\r\nklif.sys\r\nKaspersky\r\nAntivirus\r\n0x7E6070B\r\n-\u003e\r\n2022/07/11\r\nif\r\ncurrent_date\r\n\u003c= expiry:\r\nAction1 else:\r\nAction2\r\nInjects\r\nshellcode to\r\nbcrypt.dll\r\nshellcode\r\nperforms the\r\nsame as\r\nabove\r\nDownloads\r\nfrom [1] to\r\n[3]\r\nDownloads\r\nfrom [2] to\r\n[4]\r\nExecutes\r\ncmd.exe,\r\nand [7] via\r\nWinExec\r\naswsp.sys Avast\r\n0x7E6070F\r\n-\u003e\r\n2022/07/15\r\nif\r\ncurrent_date\r\n\u003c= expiry:\r\nAction1 else:\r\nAction2\r\nDownloads\r\nfrom [1] to\r\n[3],\r\nmodifies 3\r\nfirst bytes,\r\nand calls\r\nexported\r\nfunction [5]\r\nDownloads\r\nfrom [1] to\r\n[3]\r\nDownloads\r\nfrom [2] to\r\n[4]\r\nand\r\nexecuting\r\n[6] and [7]\r\nvia\r\nWinExec\r\nhttps://blog.morphisec.com/apt-c-35-new-windows-framework-revealed\r\nPage 6 of 18\n\nDriver\r\nName\r\nAffiliate\r\nExpiry\r\nDate\r\nSets Action 1 Action 2\r\nehdrv.sys\r\nESET\r\nNOD32\r\nAntivirus\r\n0x7E60717\r\n-\u003e\r\n2022/07/23\r\nif\r\ncurrent_date\r\n\u003c= expiry:\r\nAction1 else:\r\nAction2\r\nDownloads\r\nfrom [1] to\r\n[3],\r\nmodifies 3\r\nfirst bytes,\r\nand calls\r\nexported\r\nfunction [5]\r\nDownloads\r\nfrom [1] to\r\n[3]\r\ndownloads\r\nfrom [2] to\r\n[4]\r\nand\r\nexecuting\r\n[6] and [7]\r\nvia\r\nWinExec\r\nbsfs.sys\r\nQuickHeal\r\nAntivirus\r\n0x7E60711\r\n-\u003e\r\n2022/07/17\r\nif\r\ncurrent_date\r\n\u003c= expiry:\r\nAction1 else:\r\nAction2\r\nDownloads\r\nfrom [1] to\r\n[3]\r\nDownloads\r\nfrom [2] to\r\n[4]\r\nand\r\nexecuting [6]\r\nand [7] via\r\nWinExec\r\nint 3 and\r\nexit\r\n360AvFlt.sys Qihoo360\r\n0x7E60713\r\n-\u003e\r\n2022/07/19\r\nif\r\ncurrent_date\r\n\u003c= expiry:\r\nAction1 else:\r\nAction2\r\nNothing\r\ndownloads\r\nfrom [1] to\r\n[3]\r\ndownloads\r\nfrom [2] to\r\n[4]\r\nand\r\nexecuting\r\n[6] and [7]\r\nvia\r\nWinExec\r\nSecurity solutions and corresponding actions according to the expiry date\r\nIf none of the drivers are found on the victim’s machine, the shellcode executes the default routine which\r\ndownloads from [1], and modifies the three first bytes back to their original form. This technique is used to evade\r\nsecurity solutions and keep them from scanning the executable. It then executes the exported function [5].\r\nhttps://blog.morphisec.com/apt-c-35-new-windows-framework-revealed\r\nPage 7 of 18\n\nMorphisec Labs hasn’t found a clear motive for the included expiry date and driver check. When malware checks\r\nfor security solutions in conjunction with a certain date, it’s often because the authors tested their bypass against\r\nthe latest version. Future updates would react differently as they’re not tested. Another common malware behavior\r\nafter finding security solutions is to evade or abort execution. In this case, the malware slightly modifies its\r\nbehavior but mostly continues its malicious activity. \r\nModule Delivery and Execution\r\nThe initial infection executes the main DLL. This DLL is responsible for beaconing back to the C2 server that the\r\ninfection was successful and downloading the next component in the framework. The following figure outlines the\r\nhigh-level relationships between the components in the rest of the execution:\r\nComponent relationships with new/updated components highlighted\r\nMain DLL (pgixedfxglmjirdc.dll) Beaconing\r\nDelivered by the shellcode, the main DLL usually contains two exported functions. In our case,  Qoltyfotskelo\r\n(referred to as the first exported function) and Yolueorgw (referred to as the second exported function).\r\nThe first exported function is responsible for installing persistence and checking for security solutions. Persistence\r\nis achieved by setting a new Scheduled Task (via COM objects) that runs every three minutes. The action assigned\r\nto the task is to run the second exported function—Yolueorgw.\r\nhttps://blog.morphisec.com/apt-c-35-new-windows-framework-revealed\r\nPage 8 of 18\n\nThe second exported function is responsible for beaconing back to the C2 server. Before it does so, it creates a\r\nmutex to avoid multiple instances running at the same time, and performs VM detection using WMI queries:\r\nLooking for VMware, VMware Virtual Platform, and VirtualBox in csproduct name\r\nThe malware then uses Windows Management Instrumentation (WMI) to collect basic system information such as\r\nthe name, operating system caption, build number, and processor ID:\r\nBeaconing information sent to the server before encryption\r\nTo that information, it concatenates the victim’s ID and the folder names under C:\\Program Files and C:\\Program\r\nFiles (x86) to learn which software is installed on the system.  What we refer to as victim ID is a concatenation of\r\nhttps://blog.morphisec.com/apt-c-35-new-windows-framework-revealed\r\nPage 9 of 18\n\nUsername-ComputerName-ProcessorId. This string identifies the victim in later communication with the C2\r\nserver. \r\nOnce this is done the malware can encrypt the victim’s data and beacon back to its C2 server. The malware and\r\nserver encryption is AES-256 with two sets of embedded keys and IVs. The encrypted data is then encoded using\r\nBase64. \r\nThe beaconing process is divided into two steps shown below:\r\nBeaconing messages for downloading the next component\r\nThe first message to the server is sent as a POST request to the first URL path (\u003cfirst_path\u003e) embedded in the\r\nbinary. The body contains the following encrypted information:\r\nName: CPU Name\u003eCaption: OS Version\u003eBuild: Build Number V:|||Username-ComputerName-ProcessorId||||||O|||3|||Folder #1 Name?Folder #2 Name…\r\nDepending on the server’s response, the malware will either stay idle and keep the beaconing loop, or download\r\nthe next stage. If the latter, the malware sends another POST request to a second URL path (\u003csecond_path\u003e) on\r\nthe same server. This message contains the following encrypted information: Username-ComputerName-ProcessorId|||Next stage DLL name\r\nThe response to that request is the next stage DLL. To execute the next stage, the malware creates another\r\nscheduled task and removes the previous one using a clean-up .bat file (see ms.bat in the Appendix section).\r\nModule Downloader (WavemsMp.dll)\r\nhttps://blog.morphisec.com/apt-c-35-new-windows-framework-revealed\r\nPage 10 of 18\n\nThe main purpose of this stage is to download and execute the modules used to steal the user’s information. To\r\nunderstand which modules are used in the current infection, the malware communicates with another C2 server.\r\nThe malware fetches the new address from an embedded link that refers to a Google Drive document containing\r\nthe encrypted address:\r\nDownload the encrypted C2 server address from Google Drive\r\nThe decryption of the C2 address downloaded from Google Drive\r\nThis architecture allows the authors to frequently update their C2 servers without needing to redeliver the binary.\r\nAfter the C2 server address is decrypted, the malware sends a POST request to it with the encrypted victim’s ID in\r\nthe request body. The response is the modules’ configuration:\r\nThis framework’s modularity stands out. The configuration controls which modules to download and execute\r\nwithout needing to update the binary. Morphisec Labs witnessed how this functionality came into play when a\r\nsingle binary communicated with different C2 servers and downloaded different modules across multiple runs\r\nover time.\r\nThe response specifies information about the modules, delimited by | (pipeline) where each part has the following\r\nformat:\r\nModule name\u003eModule size\u003eShould download?\u003eExport name to execute\u003eAdditional parameters\r\nAdditionally, there are special characters the malware looks for such as:\r\nT?\u003cfile_name\u003e?\u003cfile_data\u003e—creates a file at %Temp%\\usdata and writes the content\r\nM?\u003cmodule_name\u003e?\u003cmodule_size\u003e—downloads another file from the server to\r\n%ProgramData%\\MJDpnd\r\nD?—unknown\r\nhttps://blog.morphisec.com/apt-c-35-new-windows-framework-revealed\r\nPage 11 of 18\n\nThe following figure illustrates the various modules and the interactions between them:\r\nieflagKlo.dll—Keylogger module\r\nieflagUl.dll—File uploader module which uploads the modules’ output\r\nieflagSp.dll—Screenshot module\r\nieflagTr.dll—File collection module\r\nieflagUsd.dll—Removable disk file collection module\r\nieflagBr.dll—Browser information stealer module\r\nieflagRvso.dll—Reverse shell module\r\nFor more information about each module, refer to this analysis.\r\nUpgraded Browser Stealer Module \r\nWhile Morphisec Labs was researching the previously known modules, one module caught our attention—the\r\nbrowser stealer. The browser stealer was first introduced to the framework in late 2020 and since then, we haven’t\r\nseen any significant changes. Until now.\r\nInstead of implementing the stealing functionality inside the DLL, the module uses four additional executables\r\ndownloaded by the previous stage (WavemsMp.dll). Each additional executable steals information from Google\r\nChrome and/or Mozilla Firefox. The following table summarizes what data is stolen from each browser:\r\nhttps://blog.morphisec.com/apt-c-35-new-windows-framework-revealed\r\nPage 12 of 18\n\nName\r\nStolen\r\nData\r\nPlain text file Encrypted file\r\nWinBroGogle.exe\r\nGoogle\r\nChrome\r\ncredentials\r\nC:\\ProgramData\\ucredgogle_qrty %base%\\usagoglyse.rnm\r\nWinBroGoMoH.exe\r\nGoogle\r\nChrome\r\nand\r\nMozilla\r\nFirefox\r\nHistory\r\n1. %base%\\goo_bhf.txt\r\n2. %base%\\maza_bhf.txt\r\n1. %base%\\goo_bhf.rnm\r\n2.\r\n%base%\\maza_bhf.rnm\r\nWinBroMozla32.exe\r\nFirefox\r\nlogin\r\n(profile\r\ndata)\r\nC:\\ProgramData\\usam0zlp_xcertyuqas %base%\\usam0zlp.rnm\r\nWinBroMozla64.exe\r\nFirefox\r\nlogin\r\n(profile\r\ndata)\r\nC:\\ProgramData\\usam0zlp_xcertyuqas %base%\\usam0zlp.rnm\r\nStolen data by each executable (%base% = C:\\ProgramData\\DeviceStage\\usabrowatad)\r\nThe browser module executes each executable; they steal the data and store it in a temporary plain text file. The\r\nfile is then encrypted and saved as a .rnm file which is later sent back to the C2 server by the file upload module\r\nieflagUl.dll.\r\nReverse Shell DLL Implementation\r\nSo far the reverse shell module has been implemented as an executable file. But now the actor aligns with the rest\r\nof the modules and recompiles the reverse shell as a DLL. The functionality remains the same, opening a socket to\r\nthe attacker’s machine (located at 162.33.177[.]41), creating a new hidden cmd.exe process, and setting the\r\nSTDIN, STDOUT, and STDERR as the socket.\r\nhttps://blog.morphisec.com/apt-c-35-new-windows-framework-revealed\r\nPage 13 of 18\n\nThe shell runs until the actor sends the string “exit\\n”.\r\nDefending Against Threats Like APT-C-35\r\nDefending against APTs like the DoNot team requires a Defense-in-Depth strategy that uses multiple layers of\r\nsecurity to ensure redundancy if any given layers are breached. Any sufficiently large organization is at risk of\r\nbeing attacked by an APT group such as the DoNot team. And these groups target a crucial security gap that few\r\norganizations have plugged. This gap exists between attack surface reduction strategies—such as patching security\r\nupdates, hardening networks, firewalls, and web applications firewalls; and technologies such as data security\r\ntools, NGAV, EDR, EPP, and XDR, etc., which focus on detecting anomalies on the disc or in the operating\r\nsystem. That gap is the runtime environment in memory.\r\nThe hardest attacks to defend against are those that—like the Windows framework detailed here—target\r\napplications at runtime. This is because popular security solutions such as NGAV, EDR, EPP, XDR, etc. focus on\r\ndetecting anomalies on the disc or operating system. Their ability to detect or block attacks in memory at runtime\r\nis limited. To the extent they can do so, they cause major system performance issues and false alerts because they\r\nmust be dialed to their most aggressive alert settings. \r\nHowever, a unique technology named Automated Moving Target Defense (AMTD) is purpose-built to defend\r\nagainst advanced, runtime attacks against Windows and Linux without affecting system performance or generating\r\nfalse alerts. It proactively stops supply chain attacks, code injection, defense evasion, remote code execution,\r\nprivilege escalation, credential theft, and ransomware. And it does so without needing signatures or behavior\r\nmodels. How? By randomizing trusted runtime application code so no two machines look the same, and even a\r\nsingle system changes over time. While trusted applications can navigate the modified runtime environment, MTD\r\nblocks any software component oblivious to the traps left behind. And it does this without any noticeable impact\r\non system performance. To learn more about this revolutionary technology, read the free white paper—The\r\nUltimate Ransomware Strategy: Zero Trust + Moving Target Defense.\r\nhttps://blog.morphisec.com/apt-c-35-new-windows-framework-revealed\r\nPage 14 of 18\n\nAppendix\r\nms.bat\r\necho off\r\nSETLOCAL\r\nset id=%1\r\nset pat=%2\r\nset t_sk=%3\r\nset t_sk_self=%4\r\nset extra_lld=%5\r\n::echo %id%\r\n::echo %pat%\r\nschtasks /delete /tn %t_sk_self% /f\r\ntaskkill /F /PID %id% /T\r\ntimeout /t 2\r\ntaskkill /PID %id% /T /F\r\ntimeout /t 2\r\nschtasks /delete /tn %t_sk% /f\r\ntimeout /t 2\r\nschtasks /delete /tn %t_sk_self% /f\r\ntimeout /t 2\r\nschtasks /delete /tn %t_sk_self% /f\r\ntimeout /t 2\r\ndel %pat%\r\n:: del batch file self\r\ntimeout /t 2\r\ndel \"%~f0\" \u0026 EXIT\r\nIndicators of Compromise (IOCs)\r\nBlog Sample\r\n486f772d81a3b90ba76617fd5f49d9ca99dac1051a9918222cfa25117888a1d5\r\nDocs\r\nhttps://blog.morphisec.com/apt-c-35-new-windows-framework-revealed\r\nPage 15 of 18\n\nd566680ca3724ce242d009e5a46747c4336c0d3515ad11bede5fd9c95cf6b4ce\r\n28c71461ac5cf56d4dd63ed4a6bc185a54f28b2ea677eee5251a5cdad07077b8\r\n9761bae130d40280a495793fd639b2cb9d8c28ad7ac3a8f10546eb3d2fc3eefc\r\n41c221c4f14a5f93039de577d0a76e918c915862986a8b9870df1c679469895c\r\nComponents (DLLs and EXEs)\r\n2c84b325b8dc5554f216cb6a0663c8ff5d725b2f26a5e692f7b3997754c98d4d\r\na70038cdf5aea822d3560471151ce8f8bacd259655320dea77d48ccfa5b5af4f\r\nd3a05cb5b4ae4454079e1b0a8615c449b01ad65c5c3ecf56b563b10a38ecfdef\r\nd71fa80d71b2c68c521ed22ffb21a2cff12839348af6b217d9d2156adb00e550\r\n7fc0e9c47c02835ecbbb63e209287be215656d82b868685a61201f8212d083d9\r\n6e7b6cc2dd3ae311061fefa151dbb07d8e8a305aed00fa591d5b1cce43b9b0de\r\n90cb497cad8537da3c02be7e8d277d29b78b53f78d13c797a9cd1e733724cf78\r\n93ca5ec47baeb7884c05956ff52d28afe6ac49e7aba2964e0e6f2514d7942ef8\r\n9b2ef052657350f5c67f999947cf8cd6d06a685875c31e70d7178ffb396b5b96\r\n80f2f4b6b1f06cf8de794a8d6be7b421ec1d4aeb71d03cccfc4b3dfd1b037993\r\nf0c1794711f3090deb2e87d8542f7c683d45dc41e4087c99ce3dca4b28a9e6f6\r\n5ebee134afe192cdc7fc5cc9f83b8273b6f282a6a382c709f2a21d26f532b2d3\r\nDomains\r\nworldpro[.]buzz ser.dermlogged[.]xyz doctorstrange[.]buzz clipboardgames[.]xyz beetelson[.]xyz\r\ntobaccosafe[.]xyz kotlinn[.]xyz fitnesscheck[.]xyz dayspringdesk[.]xyz srvrfontsdrive[.]xyz\r\nglobalseasurfer[.]xyz esr.suppservices[.]xyz\r\nAbout the author\r\nhttps://blog.morphisec.com/apt-c-35-new-windows-framework-revealed\r\nPage 16 of 18\n\nArnold Osipov\r\nMalware Researcher\r\nArnold Osipov is a Malware Researcher at Morphisec, who has spoken at BlackHat and and been recognized by\r\nMicrosoft Security for his contributions to malware research related to Microsoft Office. Prior to his arrival at\r\nMorphisec 6 years ago, Arnold was a Malware Analyst at Check Point.\r\nHido Cohen\r\nhttps://blog.morphisec.com/apt-c-35-new-windows-framework-revealed\r\nPage 17 of 18\n\nSource: https://blog.morphisec.com/apt-c-35-new-windows-framework-revealed\r\nhttps://blog.morphisec.com/apt-c-35-new-windows-framework-revealed\r\nPage 18 of 18",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blog.morphisec.com/apt-c-35-new-windows-framework-revealed"
	],
	"report_names": [
		"apt-c-35-new-windows-framework-revealed"
	],
	"threat_actors": [
		{
			"id": "b740943a-da51-4133-855b-df29822531ea",
			"created_at": "2022-10-25T15:50:23.604126Z",
			"updated_at": "2026-04-10T02:00:05.259593Z",
			"deleted_at": null,
			"main_name": "Equation",
			"aliases": [
				"Equation"
			],
			"source_name": "MITRE:Equation",
			"tools": null,
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "2ac63ef4-a7b8-4a30-96ad-b30ccb2073fc",
			"created_at": "2022-10-25T16:07:23.546262Z",
			"updated_at": "2026-04-10T02:00:04.651083Z",
			"deleted_at": null,
			"main_name": "Donot Team",
			"aliases": [
				"APT-C-35",
				"Mint Tempest",
				"Origami Elephant",
				"SectorE02"
			],
			"source_name": "ETDA:Donot Team",
			"tools": [
				"BackConfig",
				"EHDevel",
				"Jaca",
				"yty"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "cfdd350b-de30-4d29-bbee-28159f26c8c2",
			"created_at": "2023-01-06T13:46:38.433736Z",
			"updated_at": "2026-04-10T02:00:02.972971Z",
			"deleted_at": null,
			"main_name": "VICEROY TIGER",
			"aliases": [
				"OPERATION HANGOVER",
				"Donot Team",
				"APT-C-35",
				"SectorE02",
				"Orange Kala"
			],
			"source_name": "MISPGALAXY:VICEROY TIGER",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434547,
	"ts_updated_at": 1775826697,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b3edaaa08e0864c4c7a25cf2abaf52f3254edf2a.pdf",
		"text": "https://archive.orkl.eu/b3edaaa08e0864c4c7a25cf2abaf52f3254edf2a.txt",
		"img": "https://archive.orkl.eu/b3edaaa08e0864c4c7a25cf2abaf52f3254edf2a.jpg"
	}
}