Hackers Conceal Malware in Modified 7-Zip Installers Using Evasion Technique
Malware operators are embedding malicious loaders within the unpacking routines of modified 7-Zip self-extracting installers, bypassing traditional security analysis.
Malware operators have developed a sophisticated technique to hide malicious code within the unpacking routines of modified 7-Zip self-extracting archive (SFX) installers. This method involves rebuilding the open-source extraction component to insert a call to a malicious loader before the visible installation process begins. This allows attackers to execute their loader stealthily, often while a legitimate-looking installation proceeds, making detection significantly more challenging for security analysts and end-users.
The technique was observed in conjunction with the OpenSUpdater malware family, which has previously been associated with deceptive certificate practices. In these attacks, a genuine installer for a popular application, such as foobar2000, is embedded within a malicious SFX archive. This credible exterior serves as a distraction, leading observers to focus on the contained software rather than the installer's underlying code. The true danger lies within the modified extraction component itself, rather than in the final payload or configuration files.
Researchers at G Data Software identified the altered component, noting that recent samples are detected by ESET as OpenSUpdater and by Microsoft as Snackarcin. The attackers meticulously rebuilt the open-source installer code, integrating their loader into the unpacking sequence. This loader is designed to execute just before the installation progress bar appears, making its initial activity difficult to distinguish from normal installer operations. The modified code's starting point, text, and imported functions closely resemble those of an ordinary component, further aiding in its concealment.
A key aspect of this evasion strategy involves the use of a legitimate digital signature on the installer. While a valid signature typically inspires confidence, in this case, it is applied to a package where the publisher has little apparent connection to the bundled legitimate software. The researchers observed oddities in the certificate, including repeated padding bytes and version details that seemed unrelated. While they suggested this padding might alter the build's hash without invalidating the signature, the exact purpose remains unconfirmed. These anomalies, however, serve as crucial clues for suspicious packages.
The hidden loader is designed to retrieve an obscured command-and-control (C2) server address and register itself using a distinctive byte sequence. It then employs a built-in network library to download two DLL components and an encrypted data blob. The loader executes a function within the first downloaded DLL, followed by a function in the second DLL to decrypt the data blob. The decrypted content is believed to be another DLL, which is loaded into memory, and a subsequent function call is made, presumably to initiate the final payload. The exact nature of this final payload could not be verified by the researchers.
In some variants, attackers modified an open-source NSIS (Nullsoft Scriptable Install System) plugin. In these cases, the loader executes only when a specific function receives an empty string. The server location is stored in a compressed format within the script, and a payload is requested. This differs from other malicious 7-Zip archive campaigns that exploited separate Windows vulnerabilities. The common threads across these campaigns are a legitimate installer nested within another installer, a valid but potentially manipulated certificate, and a loader hidden within modified open-source code.
Security analysts are advised to exercise caution with suspicious files, even when the primary program appears legitimate. Unusual version details, oddly padded certificates, or installers nested within other installers should prompt a deeper inspection of less obvious code paths. The provided indicators of compromise (IoCs), including SHA-256 hashes for the malicious SFX samples and related NSIS samples, along with associated C2 URLs, offer critical data points for detection and response efforts.