OpenSUpdater Malware Hides Inside 7-Zip Installers to Evade Detection

Threat actors behind the OpenSUpdater malware family are concealing a reflective loader inside recompiled 7-Zip self-extracting archive components, allowing malicious code to blend into otherwise legitimate-looking installers and evade conventional triage.

Rather than relying solely on a malicious embedded executable, the operators modify the decompression stub itself the code responsible for unpacking an embedded archive, writing files to disk, and launching the configured program.

This shifts the malicious execution path to an area analysts may routinely treat as a trusted, standard 7-Zip component.

The analyzed OpenSUpdater samples package a genuine foobar2000 installer named setup.exe within a 7-Zip SFX archive.

The files are reportedly signed by Animated Productions, LLC, a purported game-application developer.

While the signature remains valid, the use of a legitimate audio-player installer by an unrelated publisher creates a notable provenance mismatch.

The samples also carry unusually bloated certificate data containing repeated byte patterns.

Certificate padding can alter a file hash between builds without necessarily invalidating the signature, complicating hash-based detection and enabling adversaries to generate superficially distinct malware artifacts.

The certificate data reportedly accounts for only about 2.6% of the files, suggesting the padding is less likely to be purely intended to defeat file-size limits at automated sandboxes.

In a normal 7-Zip SFX package, analysts typically inspect two locations first: the plain-text SFX configuration and the archived payloads.

The configuration identifies properties such as the installer window title, display text, and the RunProgram directive used to execute an embedded file.

Since setup.exe is normally the primary execution target, it is a logical first focus during static analysis.

OpenSUpdater exploits that expectation. The genuine-looking payload and normal-looking SFX configuration divert attention away from the decompression stub, where the actual loader resides.

Researchers found the malicious insertion inside the 7-Zip SFX ExtractArchive routine, immediately before progress-bar initialization.

In one analyzed sample, the loader call appeared at address 0x421400. The corresponding legitimate 7-Zip source logic is located in CPP/7zip/Bundles/SFXSetup/ExtractEngine.cpp.

GDatasoftware said in a report shared with GBhackers, this malware technique abuses the 7-Zip SFX, or self-extracting archive, mechanism commonly used by developers to distribute simple installers.

OpenSUpdater Malware

The placement is deliberate. A basic review of imports, strings, entry points, and major control flow can make the stub appear consistent with a genuine SFX module.

By inserting the loader in the middle of an expected extraction function instead of creating an obvious new executable section or malicious entry point, the operators reduce the chance that analysts will identify the altered code during rapid inspection.

The embedded loader performs three core functions: C2 beaconing, component download, and in-memory payload execution.

It retrieves a command-and-control URL through an obfuscated routine, then registers with the server using a distinct magic byte sequence that may serve as a client-identification marker.

It next uses statically compiled cURL functionality to download two DLLs and an encrypted blob. The first DLL export, cx1, is invoked before the loader calls the second DLL’s cx2 export to decrypt the blob.

The decrypted content is another DLL, which is reflectively mapped into memory. The loader then executes its cx3 export, likely initiating the final payload without requiring a conventional on-disk executable.

The activity is not limited to 7-Zip. Other observed variants reportedly modify open-source libraries used by NSIS installers, including the EmbedHtml plugin.

In that case, the loader is inserted into EmbedHtml::GetUrl() and activates only when the function receives an empty-string argument, while the C2 address is recovered from a compressed blob within the NSIS script.

This technique continues a pattern associated with OpenSUpdater.

Google’s Threat Analysis Group reported in 2021 that the malware used malformed code-signature structures accepted by Windows but rejected by OpenSSL-based parsing, allowing the samples to retain an apparently valid signature while frustrating some security tooling.

Defenders should treat installers-within-installers, publisher-to-payload mismatches, anomalous version metadata, and padded certificate structures as high-value triage signals.

Security teams should also compare SFX stubs with trusted upstream builds, inspect modified control flow in decompression modules, and monitor for unexpected outbound connections made by installer processes.

The OpenSUpdater campaign demonstrates that trusted open-source code can become an effective concealment layer when attackers recompile and subtly patch it.

In this case, the most dangerous code is not the visible installer payload it is the overlooked extraction component that launches before installation appears to begin.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC