The ongoing threat posed by the OpenSUpdater malware family has recently been highlighted, particularly in its innovative approach to disguising malicious code. Researchers have uncovered that threat actors are embedding a reflective loader within recompiled components of 7-Zip self-extracting archives. This tactic employs a seemingly legitimate installer, allowing the malicious code to blend into otherwise benign software and effectively evade traditional cybersecurity analysis.
Instead of simply utilizing a rogue executable, the operators of OpenSUpdater ingeniously modify the actual decompression stub. This is the code responsible for unpacking embedded archives and launching the designated program. By altering this critical component, the execution path for the malicious code shifts to an area that analysts often assume is safe—a standard 7-Zip feature.
The samples of OpenSUpdater analyzed by experts encompass a legitimate installer of the audio player foobar2000, structured as “setup.exe” within a 7-Zip SFX archive. Surprisingly, these files display a digital signature from Animated Productions, LLC, a company that ostensibly develops gaming applications. While the signature itself appears valid, the incongruity of using a legitimate audio player installer from a different publisher raises significant suspicions regarding the provenance of the software.
Moreover, the peculiar embellishment of certificate data, which shows repeated byte patterns, adds another layer of complexity. This certificate padding serves to modify the file hash between iterations without rendering the signature invalid. As a result, it complicates hash-based detection methods, allowing adversaries to craft superficially distinct malware variants that slip beneath the radar of cybersecurity measures.
The analysis reveals that the padded certificate data constitutes only about 2.6% of the total file size. This observation indicates that the padding is unlikely to have been purely aimed at evading size limits imposed by automated sandbox environments. In typical 7-Zip SFX packages, analysts often scrutinize the plaintext SFX configuration and archived payloads first. The configuration serves as a guide for properties like the installer window title and execution commands.
Given that “setup.exe” is typically the primary target for execution, it is a logical initial focus for static code analysis. OpenSUpdater cleverly exploits this expectation by creating a payload that appears legitimate, diverting attention away from the compromised decompression stub, which is the true host for the malicious loader.
Researchers discovered that the malevolent insertion is situated within the 7-Zip SFX “ExtractArchive” routine, specifically positioned just before the progress bar initialization. In one such analyzed sample, the loader call is located at the address “0x421400,” correlating to the legitimate source logic found in “CPP/7zip/Bundles/SFXSetup/ExtractEngine.cpp.” According to GDatasoftware, which shared its findings with cybersecurity community GBhackers, this malware strategy exploits the common practice among developers of using 7-Zip SFX for distributing straightforward installers.
The placement of the malicious loader is intentional. A cursory analysis of imports, strings, entry points, and control flow gives the stub the appearance of conforming to a typical SFX module. By inserting the loader within an expected extraction function, rather than creating an obvious new executable or malicious entry point, the operatives significantly decrease the likelihood that analysts will identify the tampered code during rapid inspections.
The embedded loader is designed to perform three central functions: communicating with a command-and-control server (C2), downloading additional components, and executing a payload directly in memory. It initiates contact with a C2 URL through an obfuscated routine and registers with the server using a unique magic byte sequence, possibly acting as an identifier for the client.
Following this, the loader employs statically compiled cURL functionality to download two DLLs along with an encrypted data blob. The loader first invokes a function from the first DLL, termed “cx1,” before calling the “cx2” export of the second DLL to decrypt the previously mentioned blob. The decrypted data turns out to be another DLL, which the loader subsequently maps into memory, executing its “cx3” export, likely launching the final payload without necessitating a conventional executable on disk.
The threat is not confined solely to 7-Zip applications. Variants of the OpenSUpdater malware have been reported to modify open-source libraries employed by NSIS installers, specifically altering the EmbedHtml plugin. In such instances, the loader is interjected within “EmbedHtml::GetUrl()” and activates when the function receives an empty-string argument, retrieving the C2 address from a compressed data blob nestled within the NSIS script.
This ongoing pattern linked to OpenSUpdater has prompted cybersecurity experts to take note. In 2021, Google’s Threat Analysis Group indicated that the malware utilized malformed code-signature structures recognized by Windows but not by OpenSSL-based parsing tools. This tactic allowed samples to maintain an ostensibly valid signature, thereby thwarting some security technologies.
As organizations strive to bolster their cybersecurity frameworks, it is essential to treat discrepancies like installers packaged within installers, mismatches between publishers and payloads, unusual version metadata, and padded certificate frameworks as high-priority indicators. Security teams are encouraged to compare SFX stubs against trusted upstream builds, meticulously inspect the control flow in decompression modules, and monitor unexpected outbound connections triggered by installer processes.
Ultimately, the OpenSUpdater campaign underscores a disturbing reality: trusted open-source code can be manipulated to serve nefarious ends when attackers recompile and subtly patch it. In this alarming case, the most perilous code does not reside within the visible installer but rather within the overlooked extraction component, which activates before any installation appears to commence.