Attackers Hide a Malware Loader Inside 7-Zip's Extraction Engine, Not the Installer Itself

Most installer security checks look in the wrong place. Analysts scrutinize the program a self-extracting archive is about to run and the plain-text configuration that tells it what to do — a newly documented attack technique is built to exploit exactly that blind spot.

What happened

Security researchers have identified 7-Zip self-extracting (SFX) installers that carry a hidden loader inside the extraction engine itself, rather than in the bundled program or its configuration. Different vendors track the resulting malware family under separate names, including OpenSUpdater and Snackarcin.

A standard 7-Zip SFX installer unpacks an embedded archive and launches a chosen file. Reviewers typically inspect that launched file and the installer's configuration block — both of which look ordinary in these samples, because the tampering sits somewhere else entirely: in the extraction program itself.

The attackers rebuilt the open-source 7-Zip SFX stub and inserted a call to their loader immediately before the installer's progress bar appears — a point in the code most reviews never reach, because the extraction routine looks standard enough to be set aside.

In the analyzed samples, the archive contains a real, working program (an audio-player installer) and carries a valid digital signature. But the signing identity doesn't match the software it's certifying — a mismatch researchers flagged as suspicious in itself. The certificate also contains unusual padding, and its version metadata reads like unrelated filler words rather than genuine product information; researchers note the padding may be designed to alter the build's hash without breaking the signature, though this hasn't been confirmed.

Once triggered, the hidden loader contacts a remote server, downloads two DLL components plus an encrypted data blob, decrypts it in memory, and loads the result — giving the operators a live channel to push further code. Researchers could not retrieve those follow-on components, so the final payload's behavior remains unverified. A related campaign applies the same idea to NSIS-based installers, modifying an open-source plugin so the hidden loader only activates under a specific trigger condition, making casual inspection even less likely to catch it.

Why it matters

This isn't a flaw in 7-Zip itself — it's a deliberately modified installer component paired with a legitimate, working program, built to survive the review steps most teams already rely on. A valid signature and a clean-looking bundled app are often treated as sufficient reassurance; here, both are present, and both are misleading. Any process that only vets what an installer contains — file signature, embedded binary, install script — without also examining the SFX/extraction wrapper itself has a structural gap this technique is designed to walk through.

Indicators to watch

Domains are defanged; re-fang only inside a controlled analysis environment such as a sandbox, SIEM, or threat-intel platform.

What to do

• Don't treat a valid code signature as proof an installer package is safe — check whether the signing identity plausibly matches the software being distributed.
• Flag installers that embed another full installer inside them, unusually padded certificates, or version metadata that doesn't read as genuine product information.
• Extend static and dynamic analysis to the SFX/extraction stub itself, not just the file it ultimately runs — the tampering here sits in the unpacking code, not the payload.
• Monitor outbound connections from freshly run installers; a legitimate-looking setup process reaching out to fetch additional DLLs mid-install is a strong signal worth alerting on.
• Block or watch the indicators above, and review EDR/AV detections tagged OpenSUpdater or Snackarcin.