How Pay-Per-Install Malware Hides Behind Trusted Downloads
Palo Alto Unit 42 traced a pay-per-install campaign that used gaming videos, SEO poisoning and a shared loader to deliver multiple malware families.
A malware infection that initially looks like routine adware may be the visible edge of a much larger criminal delivery system. That is the central lesson from Palo Alto Unit 42’s investigation of CL-CRI-1171, a cybercrime cluster that used gaming-themed YouTube content, search-engine manipulation and trojanized software downloads to distribute multiple malware families.
Unit 42 describes the operation as a pay-per-install (PPI) marketplace. Rather than serving one fixed malware family, the infrastructure delivers payloads for different customers. A shared loader handles the initial compromise, after which separate payloads operate with their own persistence methods, command-and-control (C2) infrastructure and objectives.
The research identified more than 10,000 distinct samples of the loader, which Unit 42 tracks as OfferLoader. The organization observed three payload families in the investigated activity: the cross-platform Insomnia RAT, the WebSocket tunneling malware ARKTunnel and the Chrome-focused Docro Hijacker. Unit 42 emphasizes that these samples represent only a small portion of the broader distribution pipeline.
A two-lane route to the same infection service
CL-CRI-1171 used two principal paths to reach victims. One targeted gamers through YouTube channels that published apparently legitimate advice about improving frame rates, resolving game crashes and adjusting settings. Unit 42 identified at least 11 connected channels, collectively attracting hundreds of thousands of followers and millions of views. The channels directed viewers toward downloads described as optimization tools or packs. After Unit 42 notified YouTube, the identified channels were terminated.
The second path relied on SEO poisoning. Users searching for utilities, cracked software or game-related tools were directed to malicious domains and file-hosting pages. A reconstructed lure page imitated a legitimate software download and displayed a fake scanning animation before redirecting the visitor toward the campaign’s delivery infrastructure. Unit 42 reports that this route also reached a more professional audience and resulted in infections on corporate endpoints, including critical-infrastructure and government entities. The supplied research does not identify those organizations by name.
The two routes converged on the same type of PPI gate. Links from YouTube descriptions could pass through intermediary Blogspot pages containing instructions intended to persuade users to download and execute a file. SEO traffic reached similar landing pages through search results and redirectors.
One notable feature was the gate’s use of a click_id parameter. According to Unit 42, the value encoded information such as the operating system, browser, referring domain, search term and public IP address. The gate used that information to decide whether to provide the malicious download. Scanners, crawlers and analysts could instead receive a decoy page, a broken link or a legitimate-looking software page. This selective behavior helps explain why the campaign generated little public attention despite its scale.
OfferLoader turns one download into multiple campaigns
The investigation began with two apparently ordinary software infections at separate organizations. One involved a Bluetooth driver installer; the other involved a trojanized WinDirStat package. Both followed the same post-exploitation pattern and delivered the same three payload branches.
OfferLoader was packaged using Inno Setup, a legitimate installation framework. In the observed cases, the loader arrived inside a ZIP archive alongside a legitimate copy of WinRAR renamed with a .store extension. The malicious behavior was embedded in the installer’s compiled Pascal code rather than in conventional application files.
After execution, the loader unpacked a temporary stage and sent an initial beacon to voyagemist[.]space. The response determined whether subsequent offers would be installed: a response containing no stopped further deployment, while ok allowed the payload branches to proceed. The loader then launched three child processes—eld0.exe, eld1.exe and eld2.exe—with affiliate-tracking parameters passed on the command line.
This design separates the loader from the payload operators. OfferLoader’s task ends after launching the offers, while each branch uses its own infrastructure. From a defender’s perspective, that division is important: removing the initial dropper does not by itself establish that the endpoint is clean, and a generic loader alert may conceal several independent post-compromise activities.
Three payloads with different objectives
Insomnia RAT: redundant access through two runtimes
The first branch, associated with eld0.exe, deployed two related backdoors. One was a Node.js agent and the other a Python agent. Unit 42 named the combined deployment Insomnia RAT based on the user-agent string used in its C2 traffic.
The branch used a hidden PowerShell process to download and execute a script. Unit 42 reports that the script attempted to weaken Windows Defender protections, add the entire C:\ drive as an exclusion and suppress security notifications. It also installed Python and Node.js to provide the runtimes required by the two agents. The Node.js installation was hidden from the normal installed-programs list through a registry setting.
Persistence was established through two scheduled tasks. The Node.js agent used a task named Maps Performance Task under a Microsoft Windows Maps path and was configured to run hourly and at system startup under the SYSTEM account. The Python component used OOBETaskScheduler under a Windows Servicing path. The redundant design gave the operators a second agent if one runtime or component was detected or removed.
The agents collected host information including the MachineGuid, UUID or hostname, operating-system details and, for the Python component, processor architecture. They contacted C2 using HTTPS POST requests to /d for commands and /e for results or error reporting. Unit 42 observed command types corresponding to Node.js, command-shell, PowerShell, shell and self-update operations.
ARKTunnel: a tunnel concealed in an image
The second branch, eld1.exe, used a different concealment method. It extracted a ZIP archive from a bitmap image resource through least-significant-bit steganography. The archive, identified by Unit 42 as ProcorTrex.zip, contained wscl.exe, the WebSocket-based RAT named ARKTunnel.
ARKTunnel installed itself as a Windows service using names including wscl-13 and msvcsrvc, with delayed automatic startup. Its documented functions included TCP and UDP tunneling and file execution. The C2 address was stored in an encrypted configuration blob and resolved to reg[.]pcsdkflyer[.]ca.
Unit 42 found at least 50 ARKTunnel samples spanning approximately a year of development. The samples used rotating corporate-style identities and shared structural characteristics, including the wscl.exe filename pattern and GUID-based temporary extraction directories. The research assesses these as variants of the same malware family, but does not attribute ARKTunnel to a named nation-state or established criminal group.
Docro Hijacker: browser manipulation for monetization
The third branch, eld2.exe, installed Docro Hijacker. Rather than acting primarily as a conventional backdoor, this malware modified Chrome behavior to manipulate search traffic and generate revenue.
Unit 42 found that the branch used Adblock.dll to bypass Chrome’s Secure Preferences HMAC-SHA256 integrity check. It then changed the default search provider and installed a Manifest V3 extension under C:\ProgramData\DocsHelper\docro\. The extension used Chrome’s declarative request-rewriting functionality to alter traffic.
The extension contacted vendralo[.]info for a per-victim identifier and hourly rule updates. A script from drelto[.]info could be loaded into search-result pages, allowing the operator to inject advertising, rewrite affiliate links or redirect clicks. Unit 42 reports that the extension supported searches across more than 190 Google country-code domains. Install and status telemetry was sent to finersto[.]com and extentrack[.]com, while the altered search provider used mqsearch[.]com.
What organizations should do now
- Investigate commodity-loader alerts as potential multi-payload incidents. A suspicious installer, temporary Inno Setup stage or generic Trojan detection may be an entry point rather than the complete incident.
- Review scheduled tasks and services. Pay particular attention to newly created tasks with plausible Microsoft-style names, SYSTEM execution and unusual hourly triggers, as well as delayed-start services with unfamiliar binaries.
- Hunt for unexpected runtimes and scripts. The reported Insomnia chain installed Python and Node.js, used hidden PowerShell and created a second scheduled task. These combinations deserve review when they appear outside approved development or administration workflows.
- Monitor browser integrity and extension changes. Look for unexpected Chrome extensions, modifications to Secure Preferences, unfamiliar search providers and extensions installed outside the organization’s approved software process.
- Use the supplied indicators carefully. Relevant file hashes include OfferLoader samples such as
7f792c45de1e28fd42ac44c9444f157a2161742d130bac336c0e991aabbb112c, the ARKTunnel executableb367762140ae7f5098230b8a5da738c9241f286281ec9439dd6ca581fc87989cand the Docro installer2c6e11027b011042c9a118fc20728f8f4ebb6be8795cc84cc9a45622c297d354. Hashes should supplement behavioral and network-based analysis, not replace it. - Block or scrutinize the reported infrastructure. Defanged examples include
stryper[.]info,aa[.]amazingshield[.]xyz,crowdstri[.]com,reg[.]pcsdkflyer[.]caandmqsearch[.]com. Organizations should validate indicators against current telemetry before applying broad domain blocks. - Reduce exposure to untrusted downloads. Application allowlisting, managed software catalogs, browser protections, DNS filtering and user education can reduce the chance that a gaming guide or search result becomes an execution event.
What remains unknown
Unit 42 did not identify every payload delivered by CL-CRI-1171, the full population of affected organizations or the operators behind each payload buyer. The research also does not establish that every domain or sample in the broader infrastructure delivered all three analyzed malware families. The campaign’s PPI model means that payloads, buyers and objectives may change while the shared delivery layer remains in place.
Conclusion
CL-CRI-1171 demonstrates how a low-profile loader can provide the foundation for a large and flexible malware marketplace. Gaming content and search results supplied credibility, gated redirects filtered out analysis, and OfferLoader separated delivery from the later payloads. The resulting malware ranged from redundant remote access to network tunneling and browser monetization.
For defenders, the practical implication is straightforward: treat apparently minor loader infections as possible compound compromises. Persistence, browser changes, unexpected runtimes, service creation and outbound connections should be examined together rather than as isolated anomalies.