OpenSUpdater Hides in Recompiled 7zip SFX

SFX stands for “self-extracting archive”. 7zip SFX allows developers to create simple installers.

7zip has so called “SFX modules”, although the term can be a bit confusing in the context of reversing. A clearer description would be “decompression stub”.

In a 7zip SFX the embedded files reside in the overlay in an archive format. The module’s responsibility is to decompress this archive, extract the files from it, write them to disk and run one of them.

7zip has several decompression stubs aka modules to provide different features, e.g., if the developer wants it to display a graphical user interface during extraction, 7zip needs a different SFX module than for a command line interface. Third party modules such as Oleg Scherbakov’s SFX module also exist and enrich the SFX with more options for customization.

But how does the SFX stub know what text should be displayed during installation, and which file(s) should be executed? This information is saved in a plain text configuration appended to the SFX stub. The stub will search for a start marker and an end marker to extract the configuration. For a simple graphical interface it allows to set the window title, a message and a command in the “RunProgram” key that usually runs the entry point file but may also execute any other program on the system (see figure 1 for a configuration example with “setup.exe” as entry point file).

For a malware analyst, this entry point file is of particular interest, because it is one of the first places to search for potential malicious code.

The OpenSUpdater samples [1] and [2] are 7zip self-extracting archives with a foobar2000 installer named setup.exe inside them. They are validly signed by Animated Productions, LLC, and according to their website, which looks LLM generated, they develop game apps.

The foobar2000 installer is genuine, but it does not make sense for a game developer to publish it, which should be a sign that something is off. Furthermore, the version information seems to consist of random words chosen from a dictionary (see figure 2).

The certificate itself is bloated with two bytes, 0xB8 and 0x84, which are randomly repeated. However, the certificate still makes up only 2.6% of the file. While many threat actors use bloated files to prevent uploads to sites such as Virustotal.com or analysis sandboxes like Any.Run, it does not explain why the bloat exists here. Maybe it is a way of binary padding, which changes the hash of each build without affecting the validity of the signature.

To sum it up: Triage clearly shows signs that something is not right; but finding the actual loader code to confirm that can be tricky.

If a malware analyst checks a suspicious 7zip SFX installer, the main points of interest are the configuration and the embedded files. If there are a lot of embedded files, the analyst usually checks the entry point file first which is run via the config. The decompression stub commonly just contains one of the standard SFX modules and analysts often omit it while looking for potential malicious code. That means a modified SFX module is likely to be missed.

Even if an analyst looks at the SFX module, they will probably check the entry point and main code and anything that stands out during triage, e.g., strings or imports that shouldn’t be there. However, these all look like the genuine SFX stub at first glance.

The insertion point in the 7zip SFX code which runs the loader is stashed in the middle of the software, right before the progress bar is initialized in ExtractArchive (0x421400 in sample [1]). This function resides in the source file CPP/7zip/Bundles/SFXSetup/ExtractEngine.cpp. Adding a call to the loader there is out of place and clearly an evasion attempt.

The loader roughly consists of a beacon handler, a downloader, and a payload loader.

The beacon handler obtains the C2 URL via an obfuscated function. Then it registers at the C2 server with a magic byte sequence, which is potentially an identification mechanism.

The downloader uses statically compiled curl library functions to obtain two DLLs and one encrypted blob from the C2 server.

The reflective loader calls the export cx1 of DLL1, then cx2 of DLL2 to decrypt the encrypted blob. The now decrypted blob is another DLL, which the reflective loader maps to memory. Finally, it calls its export cx3. This is likely the payload. I did not obtain any DLLs from the server at the time of analysis.

Recompiling the 7zip SFX stub is just one variant we have encountered. Other installers, such as sample [3], abuse open source software libraries, such as the NSIS plugin EmbedHtml. Here the function EmbedHtml::GetUrl() works as the insertion point for the loader, and it only triggers the malicious code if it is called with an empty string.

That loader code in turn reads the C2 server URL from a compressed blob in the NSIS script, then contacts the C2 server to ask for the payload.

These variants all have something in common: that a reflective loader hides in recompiled open source software, that they have a bloated, but validly signed certificate, and embed a genuine installer for a free application into another installer such as NSIS or 7zip SFX.

Malware analysis has always been a discipline about finding the needle in the haystack for software that seems clean at first glance. The only tip I have for analysts is to stay persistent in finding out what’s wrong if there are suspicious signs such as an installer in an installer or a bloated certificate; and to consider checking uncommon locations for malware code.

[1] a7666e5aa3c6ecae0295caa7c3f49714eb561d6e1be6807cf1020b79f1902cd0

[2] e99a053b9d6a414256177e1529417f85867d6ed355f6009300d626f63429753c

[3] ba38916e82c47cff6de71791f179ce762e640e2975e40d6a1803d16ff591b752

[4] hxxps://codeonicinc(dot)com (sample [1] and [2])

[5] hxxps://setupsoftwarecenter(dot)com (sample [3])