EquationGroup's MiniLoader

Abstract

Key takeaways

• 2023 malware loader analysis of EquationGroup
• Small failures in the malware packaging made it impossible to self-destruct
• Detection guidances provided

In this article, we examine a relatively small, concise, and extremely clean malicious code that we consider very likely linked to an entity belonging to the NSA or FiveEyes group.

At the end of 2025, the CNCERT issued a bulletin regarding an attack attributed to the NSA (https://mp.weixin.qq.com/s/XPjT0BVOJPJxSmASW0tXTA), and mentioned a specific name: "NewDSZ". This name is used by several antivirus engines as a signature title, and a file dating from 2023, never publicly described and triggering these signatures, was recovered: (e50923a0449596a2fce81a3538de2e58c7e623bd0a7e36f54a13e88ebcd79e46 ).

Since the latter has never been publicly documented, we will study it in this article. We will see that, in theory, it should not have been found on a platform like VirusTotal given its operation, and its presence is likely explained by several minor configuration errors.

We will then see how this type of code can be detected or searched for in EDR or SIEM platforms.

MiniLoader analysis

This malware consists of a DLL file that aims to masquerade as the legitimate Microsoft Windows file ncobjapi.dll. It is actually a proxy DLL that forwards calls to the legitimate DLL. The 10 exported functions are PE exports pointing to strings such as \\WINDOWS\\System32\\ncobjapi.WmiXxx, and calls to these will be effectively transferred to the functions of the legitimate DLL.

Persistence for this code is ensured by the fact that the WMI Provider Host service is (well, was at this time, but it does not really matter) implemented in the file %SystemRoot%\System32\Wbem\wmiprvse.exe, which imports ncobjapi.dll, located in %SystemRoot%\System32. Therefore, placing a ncobjapi.dll file in the same folder, which basically exploits the the DLL search order mechanism. Consequently, even though we could not precisely identify the exact installation path of this DLL, it is extremely likely that it is installed under the name %SystemRoot%\System32\wbem\ncobjapi.dll.

When loaded into memory, it first creates an event via a call to NtCreateEvent. This event can have two names, depending on whether VerifyVersionInfoW indicates that the system is running on Windows Vista or later:

• Previous versions (Windows Server2003/XP x64 versions) : \BaseNamedObjects\{%08x-%04x-%04x-%04x-%08x%04x}
• Windows Vista or later : \BaseNamedObjects\BFE_Notify_Event_{%08x-%04x-%04x-%04x-%08x%04x}

The values for the formats strings are extracted from the creation timestamp of the legitimate file %SystemRoot%\System32\wbem\xml\wmi2xml.dll.

The direct call to NtCreateEvent may be performed to bypass potential userland hooks.

Some strings (suspicious functions to avoid antivirus scoring detections, payload files, etc.) are encrypted via a simple XOR performed with pseudo-random bytes.

View on ExaLyze

Strings decrypted in this way are systematically overwritten with null bytes after use, probably in order to avoid memory scanning detections.

Next, the malware checks if the string wmiprvse.exe can actually be found in the command line and if the current thread has a ThreadId value of 0. If this is the case, a specific routine lists the process's active threads and suspends the last identifiable thread (if it is not the current thread). The reason for this manipulation has not been identified. Note that on Windows 11, this service does not longer exists. However, this malware will still be loaded into memory, because the WMISvc.dll which implements the winmgmt service uses COM objects implemented in other InProcServer DLLs located in the same WBEM folder, some of which directly import ncapiobj.dll, ultimately implying the loading of this DLL.

Then, whether the string wmiprvse.exe is present or not, a thread is created to attempt to execute the malicious payload. It attempts to execute the payload in a second thread, then performs cleanup according to the payload's return code.

The execution of the payload is done as follows: First, it opens the file %SystemRoot%\System32\wbem\Repository\FS\MAPPING0.MAP (or %SystemRoot%\System32\wbem\Repository\MAPPING0.MAP if the FS folder does not exist). WMI indeed uses MAPPING1.MAP files, but MAPPING0.MAP is not an existing legitimate file.

Once the file is read, an AES-256 decryption is performed via the cryptographic APIs of advapi32.dll such as CryptImportKey or CryptDecrypt. The key and IV are stored directly in the binary itself, the IV being simply stored and the key being built instruction by instruction then decrypted in the same way the strings are. Once decrypted, the first 8 bytes are ignored, as well as the last 8 bytes.

Once the file is decrypted, it is copied into an RWX memory area, then the payload is executed directly at its offset 0 before being immediately set back to RW. It returns a pointer to a payload management structure, unless it is NULL (in which case execution fails). If not, this structure contains two pointers:

• The 1st (offset 0x38 of the structure) will be used as the payload start pointer: the preceding bytes will be set to 0.
• The 2nd (offset 0x48 of the structure) will be used as the payload end pointer: the following bytes will be set to 0.

Subsequently, the area defined by these pointers will be set to RX, then executed, and set back to RW. The value returned by this second call will be used as a payload pointer to execute. This will be executed, and can specify two elements:

• A delay before retrying a new full execution of the payload (time in seconds)
• A return code indicating whether it is necessary to erase the payload from the system

After executing the payload, all artifacts are systematically wiped in memory by overwriting null bytes on each structure and each portion of memory.

The cleanup consists of performing the following operations:

• Overwriting the file %SystemRoot%\System32\wbem\Repository\FS\MAPPING0.MAP with null bytes and deleting the file via DeleteFileW.
• Renaming the file %SystemRoot%\System32\wbem\wmi2xml.dll via MoveFileExW to a NULL path with the MOVEFILE_DELAY_UNTIL_REBOOT flag, which allows deletion at the next reboot (the file is in use because it is loaded in memory).

Two inconsistencies appear in this code:

• Given the identified exports, the analyzed file is not made to replace wmi2xml.dll but ncobjapi.dll. Consequently, some operations cannot succeed: either the file will not fulfill the necessary prerequisites for loading as wmi2xml.dll (wrong export names), or its auto-deletion will not be effective. This may explain how this file ended up on a platform like VirusTotal.
• This DLL exports its functions under the name wmpshell.dll (linked to Windows Media Player); this element was apparently not modified after compilation, which is very likely an oversight—quite frequent in this type of case, but surprising given the supposed author of this code.

Attribution

Antivirus software can produce false positives when applying signatures, and we have seen some codes labeled "NewDSZ" incorrectly. However, we believe this is not an error here for the following reasons:

• The simplicity and elegance of this code remind us of other codes attached to the NSA or Five Eyes that we have analyzed in the past.
• The code was submitted under the name "wmi2xml.dll" from Russia in October 2023, from two distinct sources. The targeting is consistent with a Western country.
• The developers took particular meticulous care to erase any trace in memory or possibility of signing the code, which denotes an advanced maturity rarely seen outside of this actor.
• The use of a loader performing call forwarding on a Microsoft component and the use of MoveFileExW with a MOVEFILE_DELAY_UNTIL_REBOOT flag for self-removal recall the article (https://www.gendigital.com/blog/insights/research/chasing-an-angry-spark#stealth,-anti-analysis,-and-self-removal).

Detection guidance

The detection of this type of code is quite difficult, given the efforts made by the actor. However, some elements can be significant:

• Unsigned DLL having wmpshell.dll as an export name: it is possible that this oversight is not just linked to this specific code, as this type of error is quite frequent.
• The paths in which this DLL is placed can be searched, as well as the MAPPING0.DAT file. Even if these files are very likely to self-delete quickly, an EDR-type software will potentially have logged the file creations.
• When active in memory, this loader will load the legitimate DLL in addition to itself, which will result in two modules of the same name being loaded in memory, one of which is unsigned.
• This loader seems to target standard Microsoft Windows components, and it remains relatively unlikely that the file is signed by Microsoft; therefore, loading a module not signed by Microsoft in a standard Windows process can be a source of detection, after excluding certain special cases on an information system.
• This loader is visibly used to perform export forwarding on legitimate Microsoft Windows components, and will very likely be placed in folders related to the operating system, without being signed, but possessing Microsoft VersionInformation. This type of behavior is a priori very rare: the WBEM folder, for example, is only populated with PE files signed by Microsoft. Files that are unsigned or signed by Microsoft may be present in standard Windows folders, but rarely possess this VersionInformation, and exclusion lists are possible.

Conclusion

We have seen here a truly interesting code, rarely visible on analysis platforms given the efforts made by such a mature actor to hide. This possibility is likely explained by small operational errors during the generation of this code—errors that surprised us a lot given what we were used to from them. We have not been able to find other versions of this code, despite signs suggesting that at least two others exist.

Appendix A: File paths

The access paths described here are for some deduced from the errors identified in the code:

• %SystemRoot%\System32\wbem\ncobjapi.dll
• %SystemRoot%\System32\wbem\wmi2xml.dll
• %SystemRoot%\System32\wbem\Repository\FS\MAPPING0.MAP
• %SystemRoot%\System32\wbem\Repository\MAPPING0.MAP

Appendix B: Hashes

e50923a0449596a2fce81a3538de2e58c7e623bd0a7e36f54a13e88ebcd79e46

Appendix C: YARA Rules

rule Equation_MiniLoader
{
  meta:
    description = "EquationGroup's MiniLoader"
    author = "ExaTrack"
  strings:
    $cryptstr = { 8a 04 0? 30 01 48 ff c1 4? 83 e? 01 75 f2 }
    $move = "MoveFileExW"
    $verif = "VerifyVersionInfoW"
    $crypt = "CryptSetKeyParam"
  condition:
    $cryptstr and $move and $verif and $crypt and uint16be(0) == 0x4d5a and filesize < 1MB
}