Threat intel

G DATA researcher Karsten Hahn published an analysis on September 24 of new OpenSUpdater samples that hide a malware loader in an unusual place: the code of a 7-Zip self-extracting archive (SFX), the small program at the front of a .exe that unpacks the archive behind it and runs the installer inside. The archive holds a genuine foobar2000 audio player installer named setup.exe, and the outer file carries a valid code signature from Animated Productions, LLC, a company whose website says it develops game apps.

Anyone who downloads software from places other than the vendor's own site can run into this. OpenSUpdater is an old family: Google's Threat Analysis Group (TAG) described it in September 2021 as a tool for installing adware and other unwanted software, aimed mostly at users in the U.S. who download cracked games and grey-area software. What changed is where the malicious code sits. Analysts who open the file see a real installer and a valid signature, and the unpacking stub is code they usually skip as known 7-Zip.

How it works

A 7-Zip SFX installer is three pieces glued together: the SFX stub (an executable built from 7-Zip's open source code), a short text configuration saying which file to run after unpacking, and the 7z archive itself. Analysts usually check the configuration and the files in the archive, because the stub is known code that ships with 7-Zip. OpenSUpdater's authors took the 7-Zip source, added their loader, and recompiled the stub.

The added code sits in the ExtractArchive function from CPP/7zip/Bundles/SFXSetup/ExtractEngine.cpp, right before the progress bar is initialised. In the first sample G DATA analysed, that function starts at address 0x421400. Because it runs in the middle of normal unpacking, the malicious work happens during what looks like an ordinary install screen.

The loader has three parts:

• A beacon handler gets the command and control (C2) server address from an obfuscated function and registers with the server by sending a magic byte sequence.
• A downloader, built on statically compiled curl library functions, fetches two DLLs and one encrypted blob from that server.
• A reflective loader, which maps DLLs into memory itself instead of asking Windows to load them from disk, calls export cx1 of the first DLL, then export cx2 of the second DLL to decrypt the blob. The decrypted blob is a third DLL, which the loader maps into memory and runs through its export cx3.

G DATA did not receive any DLLs from the server during its analysis, so the final payload of this wave is unknown. Given the family's history, adware or further unwanted software is the likely outcome, but that is an inference, not a finding.

A third sample uses a different wrapper: an NSIS installer (Nullsoft Scriptable Install System, another open source installer builder). There the loader is planted in the EmbedHtml plugin. Its GetUrl() function runs the malicious code only when called with an empty string, and the C2 address is read from compressed data in the NSIS script.

The signature tricks

The certificate data in the new samples is padded with the bytes 0xB8 and 0x84 repeated at random, which makes up 2.6% of each file. G DATA suggests the padding may be there to change the file hash between builds without breaking the signature, but did not confirm that. Either way, a hash blocklist entry for one build will not match the next.

This is the same group's second trick with signatures. In 2021 TAG found OpenSUpdater signed with deliberately malformed certificates: the parameters element of the SignatureAlgorithm field carried an End-of-Content marker instead of a NULL tag. Tools that parse signatures with OpenSSL rejected them and could not read the signer, while Windows accepted the files as validly signed. Both tricks target the same thing: the trust that a valid signature earns in automated triage.

What to check

No vulnerability is involved, so this is detection and download policy.

Published indicators. G DATA listed these SHA-256 hashes:

• a7666e5aa3c6ecae0295caa7c3f49714eb561d6e1be6807cf1020b79f1902cd0 (7-Zip SFX, C2 codeonicinc[.]com)
• e99a053b9d6a414256177e1529417f85867d6ed355f6009300d626f63429753c (7-Zip SFX, C2 codeonicinc[.]com)
• ba38916e82c47cff6de71791f179ce762e640e2975e40d6a1803d16ff591b752 (NSIS, C2 setupsoftwarecenter[.]com)

Add both domains to your DNS filter or web proxy blocklist, then search DNS and proxy logs back as far as they go for any lookup of them. In Microsoft Defender for Endpoint, DeviceNetworkEvents filtered on RemoteUrl containing either domain covers the endpoint side. Because the certificate padding may change the hash per build, treat a clean hash search as weak evidence.

The signer. Animated Productions, LLC signing a foobar2000 installer is a mismatch between the publisher and the product. In Defender for Endpoint, query DeviceFileCertificateInfo for Signer values containing "Animated Productions" and join on SHA1 to DeviceProcessEvents to see where those files ran. On a single file, Get-AuthenticodeSignature in PowerShell or Sysinternals sigcheck -i shows the signer. If you run application control such as Windows Defender Application Control (WDAC) or AppLocker, a publisher rule blocking this signer is quick to add, and an allowlist of expected publishers stops the next certificate too.

Nested installers. G DATA's advice to analysts is to keep digging when there is an installer inside an installer. For a 7-Zip SFX, open it in 7-Zip to list the archive and read the text configuration between the stub and the archive, which names the program to run. A self-extractor whose payload is someone else's signed installer, published under a different company's certificate, deserves a sandbox run before anyone trusts it.

Behaviour. Detection names to search your antivirus console for are OpenSUpdater (ESET) and Snackarcin (Microsoft). In EDR, look for an installer process that opens outbound HTTPS connections before any child setup.exe starts, and for executable memory regions that are not backed by a file on disk inside an installer process, the usual trace of reflective loading.

If you find it. Isolate the machine. Since the final payload is unknown and the loader can run whatever DLL the server sends, treat the host as compromised: collect its process and network history since the install, remove the dropped installer, rotate credentials used on it, and reimage if you cannot account for what ran.

Where users should get software

foobar2000 is distributed from foobar2000.org. A copy wrapped in a self-extractor and signed by a different company did not come from there. The durable fix is a short list of approved sources: vendor sites, an internal software portal or a package manager such as winget, and application control that enforces it. Users who can install whatever they find will keep running into repackaged installers, whichever stub the next one hides in.

Our security operations team hunts for signed-but-wrong binaries and odd installer behaviour in EDR data, and safeguarding and hardening reviews set up application control and download policy. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: G DATA Security Blog, GBHackers, Cyber Security News, Cyberpress, OffSeq Threat Radar, Google Threat Analysis Group (2021), The Record (2021).