STORESOCKS – Microsoft Store Apps Deliver a Go Backconnect Proxy

Executive Summary

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.

Key Findings

• STORESOCKS is an ongoing Microsoft Store abuse campaign that distributes trojanized utility applications as signed MSIX packages.
• The campaign has been active since at least October 2025 and remained active on 27 June 2026.
• The actor impersonated or reused common utility themes, including WinDirStat, Lightshot, screen recorders, memory cleaners, and auto-clickers.
• Each observed Store package contains a functional Electron decoy application that loads a native Go backconnect proxy in the background.
• The campaign uses MSIX-native windows.startupTask persistence with the -start argument, causing the application to run headless at logon.
• Earlier Store waves used koffi with client.dll. The live June 2026 wave uses @yuuang/ffi-rs with telemetry.dll or lib3Z7.dll.
• The proxy registers the victim host with helper infrastructure and can use the host as a TCP and UDP proxy node through encrypted relay sessions.
• The proxy protocol supports SOCKS5-style target addressing, including IPv4, domain name, and IPv6 destination formats.
• The live payloads are approximately 68 MB and are assessed to be re-hosted inside a larger Gogs-based Go build. This obscures provenance and weakens simple size and source-path assumptions.
• At least two seller accounts, PersonalUtilities and SOFTWARE MARKETPLACE, operated four live armed Store applications on 27 June 2026.
• Detection should focus on the full chain: Store-delivered MSIX, Electron runtime, Node FFI bridge, native DLL in the application directory, startup task with -start, helper registration, and relay proxying.

Targeting and Victimology

STORESOCKS targets users searching for free desktop utilities. The observed application themes are broad and high-volume rather than organization-specific. Disk usage tools, screenshot utilities, screen recorders, memory cleaners, and auto-clickers are common search targets for users who need a quick tool and may not have a preferred trusted vendor.

This targeting pattern is consistent with proxy monetization rather than targeted espionage. A successful infection does not require privileged credentials, domain administrator access, or access to a sensitive business application. Any host with stable outbound connectivity can become useful as a proxy node. This makes consumer endpoints, unmanaged corporate endpoints, developer workstations, and utility-heavy desktops relevant from a defensive perspective.

The publisher accounts follow a disposable pattern. The campaign uses plausible but generic seller names, rotates application themes across accounts, and reuses similar utility categories across waves. Several listings also used special characters and trademark-style symbols in display names, which helped create distinct Store identities while keeping the names familiar to users.

Some listings showed ratings and an established Store presence. Hexastrike has not independently validated whether those ratings were organic, manipulated, or partially generated through campaign activity. From a user perspective, the result is still relevant. A working utility with visible ratings and a valid Store install path reduces suspicion.

The applications are designed to avoid immediate user complaints. When launched normally, they open a real interface and provide visible utility behavior. The proxy component is loaded before the interface is created. During logon execution, the same loader path runs headless and exits before opening a window.

For incident response, user reports are unlikely to be the first signal. Useful evidence is more likely to come from package contents, startup behavior, DLL loads from WindowsApps paths, and network communication to helper or relay infrastructure.

Campaign Scope and Evolution

Hexastrike identified multiple seller accounts and application families associated with STORESOCKS. Earlier listings had already been removed by the time of analysis, while four applications remained live and armed on 27 June 2026.

Publisher	Store hash	Applications	Product IDs	Status on 27 June 2026
PeakTools	jbr3b8129hcpp	WinDirStat, ScreenRecorder	9MW9HR27K9B9, 9NJXJTN15CV2	Removed
HobbyApps	6b1d5ygjy0x60	Lightshot or Screenshot Tool, Cleaner	9NTC2KMZMGND	Removed
NikiaFraizer	48fm0y264fyxm	ScreenRecorder, Memreduct	Related packages observed	Removed
PersonalUtilities	37q3eh6e1w8j0	MemoryCleaner, Memory Cleaner Plus, Auto Clicker – Fast	9PKWPPBH5M6D, 9PGM15TVJKNT	Partially removed, two apps live
SOFTWARE MARKETPLACE	3z7eh2g3cf7qg	Memory Cleaner℠, Auto Clicker⁺	9P7502ZPX6V4, 9PG13ZP1R035	Live

The use of multiple accounts and related utility names indicates a maintained distribution operation rather than isolated Store abuse. The actor continued after earlier removals with new seller accounts, new application names, new payload names, and new infrastructure.

The campaign evolved in visible waves. The earliest known samples date to October 2025. Store waves in March and May 2026 used client.dll and koffi. The live June 2026 wave used telemetry.dll or lib3Z7.dll, @yuuang/ffi-rs, and new telemetry-themed helper domains.

Infection Chain

Store Delivery and Trust

Initial access occurs when the user installs a trojanized utility application from the Microsoft Store. The package is delivered as MSIX and carries a valid Store signature. The user sees a normal Store application, not an unsigned executable downloaded from an unknown website.

This trust path changes defender assumptions. A valid Store signature should be treated as a distribution and integrity signal. It should not be treated as proof that runtime behavior is benign. In STORESOCKS, the package structure is valid, the application is functional, and the malicious behavior is embedded inside the packaged application.

An MSIX package is a structured application archive. It contains the application files, identity metadata, declared capabilities, integrity metadata, and signature data. In STORESOCKS, the relevant files are the manifest, the Store signature, the Electron application directory, the Electron archive, the unpacked Node modules, and the native payload DLL.

MSIX Persistence

STORESOCKS uses MSIX-native persistence. The AppxManifest.xml declares a windows.startupTask extension that points to the packaged application executable and passes the -start argument.

<uap5:Extension Category="windows.startupTask" Executable="app/<Application>.exe" EntryPoint="Windows.FullTrustApplication" uap10:Parameters="-start">
  <uap5:StartupTask TaskId="<Application>AutoRun" DisplayName="<Application>" Enabled="true"/>
</uap5:Extension>

When launched normally, the application loads the DLL and opens the visible utility interface. When launched through the startup task at logon, it loads the same DLL but returns before creating the user interface. The result is headless execution without a visible window.

The observed packages also request internetClient and runFullTrust. The first is expected for many network-aware applications. The second allows the packaged desktop application to run with broader Win32 functionality. For defenders, the important point is that persistence is declared inside the packaged application model.

Electron Loader

The Store apps use Electron for the visible utility interface. The loader code sits inside app\resources\app.asar and uses Node FFI to call the bundled Go DLL.

ASAR is Electron’s application archive format. It is not encryption and it is not a security boundary. In STORESOCKS, unpacking app.asar exposes the JavaScript loader, helper configuration, payload filename references, and the call path into the native DLL.

Earlier STORESOCKS Store waves used koffi. The live June 2026 wave uses the package @yuuang/ffi-rs, which the loader imports as ffi-rs. Both are Node Foreign Function Interface libraries, which let JavaScript call exported functions from native libraries such as DLLs. In STORESOCKS, the FFI library is the bridge between the Electron application and the Go backconnect proxy DLL.

The Store application loads the FFI module from the unpacked Node module directory, opens the bundled native DLL from the application directory, and calls the DLL export used to start the proxy.

The loader calls a single exported function named Start. The important argument is a string that behaves like command-line configuration. It contains the Store-specific user_id and, in the live wave, the helper registration URLs.

-user_id=microsoft_store_AutoClicker_9PGM15TVJKNT_jun5_2026
-helper-urls=https://storetelemetryapi.xyz/register,https://gate1.storetelemetryapiapps.XYZ/register

The user_id embeds the Store product ID and campaign tag. This gives the backend an install attribution mechanism by application, seller account, and wave. The helper URLs identify the first registration endpoints used by the proxy after startup.

The loader checks for the DLL before calling it. In observed builds, this allows the application path to continue without an obvious user-facing failure if the native payload is absent.

The Go Backconnect Proxy

The native payload is a Go DLL loaded by the Electron application through Node FFI. The loader calls the exported Start function and passes a configuration string containing the Store user_id, optional helper-urls, and host identifier settings. Earlier Store packages used client.dll. The live June 2026 packages use telemetry.dll or lib3Z7.dll.

The DLL parses the loader arguments, builds a host identifier, registers with helper infrastructure, then loops over a list of session handlers until it can establish relay connectivity.

Earlier client.dll builds expose the original Go module layout, including the server module and server/src/cmd/backconnect_dll command path. This identifies the build family, while the code path confirms the role: helper registration, polling, relay connection, stream setup, TCP proxying, UDP proxying, and teardown.

The helper infrastructure is configured by the loader and embedded campaign settings. In the earlier Store wave, the payload references mylabubus.shop helper infrastructure. The user_id string includes the Store application identity, allowing the backend to separate installs by app, product ID, and campaign wave.

The victim does not expose an inbound listener. After helper registration, the DLL waits for relay instructions and then opens outbound relay sessions. Earlier client.dll samples use TLS with yamux multiplexing, allowing multiple proxy streams over one outbound connection.

Each stream is dispatched as TCP or UDP. Target addressing follows SOCKS5-style address types: 0x01 for IPv4, 0x03 for domain names, and 0x04 for IPv6. The DLL resolves the requested destination and bridges traffic between the relay stream and the target. UDP handling includes flow accounting for target, local socket, packet count, byte count, keepalive state, duration, and errors.

The live June 2026 payloads changed packaging, not purpose. telemetry.dll and lib3Z7.dll are about 68 MB and are wrapped in a larger Go build associated with gogs.io/gogs. The live builds retain the same loader entry point, host identification dependency, helper registration model, and TCP and UDP proxy behavior. This makes source-path-only rules and small-file assumptions unreliable.

Operational Impact of a Proxy Infection

STORESOCKS does not need to steal local data to create impact. Once activated, the host can become egress infrastructure for third-party traffic. Teams should review outbound activity from installation through removal, identify helper or relay contact, and check whether unusual third-party egress followed activation. Abuse reports or suspicious activity may point back to the victim organization because traffic can exit through the infected host.

Attribution

Hexastrike tracks STORESOCKS as an unattributed proxy-botnet operation. We do not link this activity to a named actor or APT group.

The evidence points to infrastructure monetization rather than targeted intrusion. The campaign uses broad utility themes, disposable Store seller accounts, Store product IDs inside user_id values, and a payload built to enroll hosts as TCP and UDP proxy nodes. Those traits are consistent with residential proxy or relay-access monetization.

The campaign relies on integration of trusted distribution, functional decoys, startup persistence, native loading, and proxy enrollment.

Detection Opportunities

STORESOCKS should be detected through correlation across installation, persistence, runtime, and network activity. A single Store install, Electron app, desktop shortcut, or DLL name is not enough.

Store Installation and Persistence

Prioritize review of newly installed Store utility applications when the installation is followed by package-created startup behavior or automatic execution after logon.

Relevant detection logic:

• New Store utility application installed from an unfamiliar publisher.
• Utility categories matching the campaign pattern, including cleaners, recorders, screenshot tools, disk analyzers, memory tools, and auto-clickers.
• Package-declared startup task or other Store package startup registration.
• Startup execution that occurs shortly after installation.
• Store application requesting full-trust desktop execution and also declaring startup behavior.

Desktop shortcut creation is install-time context only. It should not be treated as a STORESOCKS indicator without startup, runtime, or network correlation.

Runtime Behavior

Prioritize Store utility processes that combine automatic startup with native code loading.

Relevant detection logic:

• Store application process launched from C:\Program Files\WindowsApps\ at logon.
• Store application startup execution with the -start argument.
• Store utility process loading a bundled native DLL from its own package directory.
• Store utility process loading known STORESOCKS payload names such as client.dll, telemetry.dll, or lib3Z7.dll.
• Electron-based Store utility using JavaScript-to-native loading through a Node FFI bridge.
• Store utility running headless at startup but presenting a normal interface when opened manually.

The analytic should tie these events to the same package or process tree. The strongest endpoint pattern is Store startup execution followed by native DLL loading from the packaged application directory.

Network and Proxy Activity

Known STORESOCKS domains and IP addresses should be blocked and used for scoping. They are useful for containment and retrospective search, but the actor has rotated infrastructure across waves.

Relevant detection logic:

• DNS requests or outbound connections to known STORESOCKS helper or relay infrastructure.
• Store utility process contacting helper or registration infrastructure shortly after installation or logon.
• Outbound /register-style traffic from a Store application process.
• Periodic helper communication from the same Store application process after initial registration.
• Long-lived outbound sessions from a Store utility process to relay infrastructure.
• Unusual third-party outbound traffic from the host after helper or relay contact.

The process context matters. Traffic to known infrastructure is higher priority when it originates from a Store utility process that also has startup behavior and native DLL loading.

Hardening and Mitigation Guidance

Store Application Control

Apply the following controls where business requirements allow:

• Restrict Microsoft Store installations to approved applications.
• Require review for utility apps from unfamiliar publishers.
• Block or review Store apps that combine full-trust desktop execution with startup behavior.
• Treat Store apps as managed software inventory, not as user preference.
• Review Store utility apps before deployment to developer workstations, shared systems, executive endpoints, and hosts with valuable egress.

Startup and Package Governance

Apply the following controls:

• Inventory package-declared startup tasks, not only Run keys, services, and scheduled tasks.
• Review Store apps that start automatically after logon.
• Review Store apps that launch headless or without clear user interaction.
• Include C:\Program Files\WindowsApps\ in endpoint visibility and hunting coverage.
• Preserve package contents, manifest, Electron archive, native DLLs, and endpoint telemetry before removal when investigation is required.

Network Containment and Exposure Review

For confirmed or suspected STORESOCKS hosts:

• Block known STORESOCKS domains and IP addresses at DNS, proxy, firewall, and EDR layers.
• Remove the affected Store package.
• Verify that package-created startup behavior is removed.
• Review outbound traffic from installation time through removal time.
• Identify whether the host contacted helper or relay infrastructure.
• Review unusual third-party egress after helper contact because the host may have been used as a proxy node.
• Check whether abuse reports, account blocks, fraud alerts, or suspicious service access align with the host’s public IP during the exposure window.
• Hunt for related non-Store EXE and DLL builds outside C:\Program Files\WindowsApps\ when the host shows STORESOCKS network activity.

Conclusion

STORESOCKS shows how a commodity proxy operation can abuse a trusted software distribution channel without relying on a visibly suspicious installer. The campaign uses working utility applications, Microsoft Store packaging, MSIX-native startup behavior, Node FFI loading, and a Go backconnect proxy hidden behind familiar desktop tools.

The live June 2026 wave demonstrates active development. The actor changed seller accounts, renamed payloads, switched loader libraries, moved infrastructure, inflated payload size, and re-hosted the proxy module inside a larger Gogs-based Go build while preserving the same core operational model. Earlier takedowns did not end the campaign.

Effective defense requires more than blocking domains or searching for one DLL name. The durable detection is the chain: Store-delivered MSIX utility, Electron runtime, Node FFI bridge, native Go DLL, startup task with headless behavior, helper registration, and relay proxying. Organizations that allow Microsoft Store applications should include Store package inspection, startup task review, and WindowsApps telemetry in their endpoint security program.

MITRE ATT&CK Mapping

Tactic	ID	Technique	STORESOCKS
Resource Development	T1583.001	Acquire Infrastructure: Domains	Actor-controlled domains were used for helper and relay infrastructure.
Initial Access	T1195.002	Supply Chain Compromise: Compromise Software Supply Chain	The actor delivered trojanized utility software through a trusted Store distribution channel rather than an unsigned external installer.
Execution	T1204.002	User Execution: Malicious File	Users installed and launched trojanized Store applications.
Execution	T1106	Native API	Node FFI called native DLL exports from the Electron application.
Persistence	T1547	Boot or Logon Autostart Execution	MSIX windows.startupTask launched the application with -start at logon.
Defense Evasion	T1036.005	Masquerading: Match Legitimate Name or Location	Applications impersonated common utility tools and used plausible Store branding.
Defense Evasion	T1027	Obfuscated Files or Information	Live payloads were renamed, size-inflated, and re-hosted inside a larger Gogs build to obscure provenance.
Discovery	T1082	System Information Discovery	The implant registered machine ID and build metadata with helper infrastructure.
Command and Control	T1071.001	Application Layer Protocol: Web Protocols	HTTPS was used for helper registration and ping communication.
Command and Control	T1573.002	Encrypted Channel: Asymmetric Cryptography	TLS was used for relay sessions in analyzed earlier samples.
Command and Control	T1090	Proxy	The victim host was used as a TCP and UDP proxy node through relay infrastructure.

Indicators of Compromise

Note: First Seen and Last Seen values reflect Hexastrike’s observation window for each indicator and do not necessarily represent creation date, registration date, first malicious use, or the full period of operator control. For removed Store applications, Last Seen indicates the date the removed or unavailable status was observed, not the last date the application was live.

Category	Type	Value	Comment	First Seen	Last Seen
Store application	product ID	9PKWPPBH5M6D	Memory Cleaner Plus, PersonalUtilities	2026-06-27	2026-06-27
Store application	product ID	9PGM15TVJKNT	Auto Clicker – Fast, PersonalUtilities	2026-06-27	2026-06-27
Store application	product ID	9P7502ZPX6V4	Memory Cleaner℠, SOFTWARE MARKETPLACE	2026-06-27	2026-06-27
Store application	product ID	9PG13ZP1R035	Auto Clicker⁺, SOFTWARE MARKETPLACE	2026-06-27	2026-06-27
Store application	product ID	9MW9HR27K9B9	WinDirStat, PeakTools	2026-04-07	2026-06-27
Store application	product ID	9NJXJTN15CV2	ScreenRecorder, PeakTools	2026-05-04	2026-06-27
Store application	product ID	9NTC2KMZMGND	Lightshot or Screenshot Tool, HobbyApps	2026-04-07	2026-06-27
Store application	product ID	9NRXPZDL2K0J	Cluster-linked product ID		2026-06-27
Store publisher	store hash	37q3eh6e1w8j0	PersonalUtilities	2026-06-27	2026-06-27
Store publisher	store hash	3z7eh2g3cf7qg	SOFTWARE MARKETPLACE	2026-06-27	2026-06-27
Store publisher	store hash	jbr3b8129hcpp	PeakTools	2026-04-07	2026-06-27
Store publisher	store hash	6b1d5ygjy0x60	HobbyApps	2026-04-07	2026-06-27
Store publisher	store hash	48fm0y264fyxm	NikiaFraizer	2026-05-06	2026-06-27
Network activity	domain	storetelemetryapi.xyz	Live June 2026 helper infrastructure	2026-06-27	2026-06-27
Network activity	domain	storetelemetryapiapps.xyz	Live June 2026 helper-related infrastructure	2026-06-27	2026-06-27
Network activity	domain	gate1.storetelemetryapiapps.xyz	Live June 2026 helper registration endpoint	2026-06-27	2026-06-27
Network activity	domain	telemetrystoreapi1.xyz	Live June 2026 helper infrastructure	2026-06-27	2026-06-27
Network activity	domain	api1.mylabubus.shop	Store wave 1 helper infrastructure	2026-03-05	2026-06-27
Network activity	domain	api2.mylabubus.shop	Store wave 1 helper infrastructure	2026-03-05	2026-06-27
Network activity	domain	mylabubus.shop	Store wave 1 infrastructure	2026-03-05	2026-06-27
Network activity	domain	api1.checkupdatesnow.xyz	Store wave 2 helper infrastructure	2026-05-03	2026-06-27
Network activity	domain	api2.checkupdatesnow.xyz	Store wave 2 helper infrastructure	2026-05-03	2026-06-27
Network activity	domain	helper.labubusmarket.com	2025 helper infrastructure	2025-10-18	2026-06-27
Network activity	domain	relay.labubusmarket.com	2025 relay infrastructure	2025-10-18	2026-06-27
Network activity	IP address	2.26.26.139	Live June 2026 helper infrastructure	2026-06-27	2026-06-27
Network activity	IP address	147.45.221.28	checkupdatesnow.xyz infrastructure	2026-05-03	2026-06-27
Network activity	IP address	147.45.221.29	mylabubus.shop infrastructure	2026-03-05	2026-06-27
Network activity	IP address	185.218.137.62	relay.labubusmarket.com infrastructure	2025-10-18	2026-06-27
Network activity	IP address	178.250.187.243	helper.labubusmarket.com infrastructure	2025-10-18	2026-06-27
Network activity	IP address	144.124.254.145	Earlier campaign infrastructure	2026-03-05	2026-06-27
Network activity	IP address	89.124.124.112	Earlier campaign infrastructure	2026-03-05	2026-06-27
Network activity	IP address	146.103.110.251	Earlier campaign infrastructure	2025-10-18	2026-06-27
Network activity	IP address	91.84.106.129	Related mylabubus.shop infrastructure	2026-03-05	2026-06-27
Malware	SHA-256	09049e365c86e0bc6192fb1601d0fbe6bf2235f9f3e26ea1c83e26f41d041530	client.dll, older Store wave payload	2026-03-05	2026-06-27
Malware	SHA-256	27870854b9e85265e21d06a4b9e696093c1558c1480e36a42540943d66f7a3ec	client.dll, May 2026 x86 payload	2026-05-03	2026-06-27
Malware	SHA-256	54a79692f3406c9fdf5ad4d090e6593a8906fcd6620c1ecf2f22c7390b577b78	client.dll, May 2026 x64 payload	2026-05-03	2026-06-27
Malware	SHA-256	94182f6ad0ed5e1f02ffe646d5cef1ad161de43924656000478e1359de230438	telemetry.dll, Memory Cleaner build	2026-06-27	2026-06-27
Malware	SHA-256	a094293b06e43060eb93d31237a931d26756df18f7e0ec5f2b762d7672bb08c6	telemetry.dll, Auto Clicker build	2026-06-27	2026-06-27
Malware	SHA-256	9ce75ad965ab67de4db57f41340bd4acef232d0401da18e0652f34612ce2c8b3	lib3Z7.dll, SOFTWARE MARKETPLACE packages	2026-06-27	2026-06-27
Malware	filename	client.dll	Earlier STORESOCKS payload name	2025-10-18	2026-06-27
Malware	filename	telemetry.dll	Live PersonalUtilities payload name	2026-06-27	2026-06-27
Malware	filename	lib3Z7.dll	Live SOFTWARE MARKETPLACE payload name	2026-06-27	2026-06-27