Malware News STORESOCKS – Microsoft Store Apps continue to deliver a Go Backconnect Proxy

[Khushal]

Content source

https://hexastrike.com/resources/blog/threat-intelligence/storesocks-microsoft-store-apps-deliver-a-go-backconnect-proxy/

Executive Summary​

STORESOCKS – Microsoft Store Apps Deliver a Go Backconnect Proxy - Hexastrike Cybersecurity

STORESOCKS is an ongoing proxy campaign hiding a Go backconnect implant inside signed, trojanized Microsoft Store utility apps. Detection and IOCs inside.

hexastrike.com

Microsoft Store Apps + Go Backconnect Proxyware Part 2

Microsoft App Store publisher continues hosting undisclosed proxyware: StoreSocks proxyware campaign analysis and updates.

blog.lukeacha.com

Hexastrike uncovered an ongoing backconnect proxy campaign distributed through trojanized Microsoft Store applications. We track this activity as STORESOCKS.

Since at least October 2025, an unknown actor has published trojanized free utility applications to the Microsoft Store. The applications impersonate common desktop tools, including WinDirStat, Lightshot, screen recorders, memory cleaners, and auto-clickers. They are not broken decoys or simple launchers. Each analyzed Store package contains a working Electron-based utility interface that matches the advertised purpose of the application. In the background, the same application loads a native Go DLL through a Node FFI bridge and enrolls the victim host as a TCP and UDP proxy node.

The delivery path is central to the campaign. The applications are packaged as MSIX and are validly signed through Microsoft’s Store signing pipeline. This gives the packages a trust signal that many users and organizations associate with safer software distribution. The malicious behavior is not introduced by an unsigned installer or a visible second-stage dropper. It is bundled inside the Store-delivered package and executed by the packaged application itself.

The payload is a Go backconnect proxy. It registers the victim host with helper servers, receives relay instructions, establishes encrypted relay sessions, and tunnels proxy streams through the victim system. The recovered protocol supports SOCKS5-style target addressing for IPv4, domain names, and IPv6. The implant supports both TCP and UDP proxying.

The campaign has evolved across multiple waves. Earlier Store packages used client.dll and the Node FFI library koffi. The live June 2026 wave uses telemetry.dll or lib3Z7.dll, switches to @yuuang/ffi-rs, and inflates the payload size to approximately 68 MB. Hexastrike assesses that the live payloads contain the same backconnect module re-hosted inside a larger Go application tree associated with Gogs, an open-source Git service. This changes how the binary presents itself to tooling and makes simple provenance checks less reliable.

At the time of analysis on 27 June 2026, earlier Store listings had already been removed. The campaign was still active. Hexastrike confirmed at least four armed Microsoft Store applications across two seller accounts live on 27 June 2026.

 

[Bot]

Notable technique, worth flagging for the community

I cannot verify the specific claims in this report (timeline, seller accounts, file names, or the exact payload size) since I have no way to independently confirm vendor telemetry or file hashes. That said, the technique described lines up with a known pattern seen in several past campaigns, so it is worth discussing on its technical merits.

Why the MSIX/Store signing angle matters

• Microsoft Store signing (MSIX) verifies that a package was submitted through the Store pipeline and passed automated checks, not that the app is free of malicious functionality.
• Automated Store review historically has had blind spots for apps that only trigger malicious behavior post-install, load native modules dynamically, or use legitimate-looking UI frontends (in this case, a working Electron interface) to mask background activity.
• A valid Store signature is a distribution trust signal, not a behavioral safety guarantee. Organizations that whitelist "anything from the Microsoft Store" as inherently safe are relying on an assumption that has been abused before.

The architecture described is technically plausible

Using Node FFI (koffi, ffi-rs, etc.) to bridge an Electron shell to a native Go DLL is a known pattern for hiding payload logic outside the JS bundle, since static analysis tools and reviewers tend to focus on script content rather than bundled native binaries. Reusing a legitimate open-source Go tree (Gogs, in this case) to bulk up and reshape a malicious binary is also a known evasion tactic, since it changes import tables, strings, and size profile enough to throw off simple YARA/heuristic matching.

Backconnect/SOCKS proxy implants bundled into "free utility" apps is a well-established monetization pattern for threat actors: infected hosts are resold as residential-style proxy exit nodes.

Practical takeaways

• If anyone here installed WinDirStat, Lightshot-style screen recorders, memory cleaners, or auto-clicker apps from the Microsoft Store recently, check running processes and any DLLs matching the names mentioned in the report (client.dll, telemetry.dll, lib3Z7.dll) and consider submitting the binaries to VirusTotal for a second opinion.
• Outbound TCP/UDP connections from a utility app that has no legitimate reason to relay traffic (no VPN/proxy feature advertised) is a red flag worth checking with a firewall/network monitor.
• A reputable, actively maintained antivirus/EDR product with behavioral detection is more useful here than static signature scanning alone, since the payload described is explicitly designed to evade simple provenance checks.

If members have samples or hashes tied to this campaign, posting them in the Malware Analysis section would let others cross-check against their own AV/EDR telemetry rather than relying solely on the linked report.