How attackers attempted to introduce compromised devices into a legitimate proxy industry—and the companies, customers, and financial relationships behind residential IP addresses.
Incident Analysis · Cybercrime Economics · Residential Proxies · Supply Chains · Network Security
Analysis based on publicly available information as of October 16, 2026.
Abstract
On October 15, 2026, GreyNoise disclosed that skynox7 had compromised at least 143 network-connected devices across 34 countries and installed Pawns.app, commercial software for sharing internet connections. GreyNoise identified an associated payout account, but neither the volume of traffic sold nor any payment received is publicly established. [1]
Residential proxy businesses aggregate connections from individuals, application developers, and other suppliers, then sell access to customers needing distributed IP addresses. IPRoyal identifies Pawns.app as a direct source of residential proxies; the controlling person of PAWNS.APP LTD is also identified as an IPRoyal co-founder. [6][7][9]
The market has identifiable prices and customers. Pawns.app advertises $0.20 per GB of eligible software development kit (SDK) traffic, while IPRoyal sells managed residential access for several dollars per GB in small plans; the two rates belong to different contracts and cannot be subtracted to calculate profit. IPRoyal’s published case studies name Reworkd, Ondato, and NitroPack, but do not connect those customers to skynox7’s devices. [11][13][14][15][16]
The attacker needed no independent proxy marketplace. Control of a compromised device was enough to attempt enrollment in an existing supply network, even though control of its software is different from authority to commercialize its connection. Consent records, usage measurement, customer contracts, and payments sit with different participants, making that authority difficult to infer from a working client or verified account alone.
Earlier investigations show that unauthorized proxyware installation is recurrent, but not that every attempted node generated revenue. [2][3][5] A further uncertainty applies here: Pawns.app says that, as of 2026, it no longer offers internet bandwidth sharing, while business SDK and command-line interface (CLI) materials remained available. Public records do not establish whether skynox7’s clients were accepted, routed paying traffic, or received compensation. [9][11][19][20]
This investigation reconstructs the commercial and technical path behind the attempt, then asks what evidence would connect control of a device to a legitimate right to sell its connectivity.
1. Incident Overview
GreyNoise’s October investigation grew out of a separate incident involving the difficulty of recognizing malicious activity conducted through residential proxy networks.
During a product demonstration, GreyNoise identified suspicious IP addresses in an organization’s Microsoft Entra ID sign-in logs. The addresses were associated with residential connections and appeared in locations that were geographically plausible for the organization’s users. Further investigation confirmed that the addresses were residential proxies, although that fact alone could not determine whether the sign-ins were legitimate. The organization subsequently discovered that multiple users were authenticating through the same residential proxy address and, after further investigation, confirmed a serious intrusion. GreyNoise did not disclose the full details of that incident. [1]
The case demonstrated why ordinary assumptions about internet addresses can become unreliable when traffic is routed through commercial proxy networks. A connection originating from an expected country or residential ISP does not necessarily originate with a user located there. A third party may be directing traffic through someone else’s connection, making the apparent source of the activity different from the infrastructure and person responsible for initiating it.
GreyNoise then reported a separate campaign involving skynox7, an attacker compromising internet-facing network devices and installing Pawns.app. The confirmed targets included D-Link ShareCenter network-attached storage (NAS) devices affected by CVE-2024-3272 and CVE-2024-3273, Ubiquiti UniFi Video network video recorder (NVR) systems affected by CVE-2021-44228, and SAP NetWeaver Visual Composer installations affected by CVE-2025-31324. The attacker also appeared interested in other video-recording equipment, including products associated with Hikvision and Dahua, although those observations were not presented as additional confirmed compromises. [1]
Some compromised devices were configured to accept an attacker-controlled SSH public key, preserving an alternative means of access. The reported compromises gave the attacker control sufficient to install and run Pawns.app on equipment that could remain connected to the internet for extended periods. GreyNoise does not specify the effective execution privileges across all affected systems. [1]
The selected targets were not interchangeable in their ordinary function. NAS devices store files, NVR systems manage surveillance video, and SAP installations support enterprise applications. Yet all can provide processing capacity and network connectivity once compromised. For a bandwidth-monetization operation, the business value of an infected device may have comparatively little to do with the information stored on it.
The Pawns.app installation gave these otherwise unrelated systems a common commercial context. GreyNoise identified skynox7@proton.me as the payout account associated with the campaign, giving investigators a concrete link between the compromised infrastructure and the attacker’s intended financial beneficiary.
The public report does not establish whether all 143 devices were accepted into the Pawns network, whether they forwarded paying customers’ traffic, or whether the attacker received any money. The observed incident therefore demonstrates compromise and attempted commercialization rather than a fully reconstructed series of commercial transactions.
That limitation is important, but it does not make the economic mechanism speculative. The software, registration interfaces, compensation arrangements, and commercial proxy market involved in the attempt are independently documented.
2. How Proxyjacking Became a Repeatable Business
2.1 From voluntary bandwidth sharing to unauthorized installations
Residential proxy services developed around a relatively simple commercial proposition: an individual with an internet connection can allow third parties to route traffic through that connection and receive compensation for doing so. The network operator aggregates many such participants and sells customers access to a distributed pool of addresses.
A commercial customer may value the location and characteristics of a residential IP because websites respond differently to requests from different networks. Search results can vary by country, online services may impose geographic restrictions, and automated requests from data-center infrastructure may encounter restrictions that ordinary residential connections do not. Access to a large pool of geographically diverse connections consequently becomes a product with measurable commercial demand.
The voluntary arrangement becomes proxyjacking when an unauthorized party enrolls equipment or connectivity without the knowledge or permission of its legitimate operator. The attacker gains access to the network resource through compromise, then attempts to receive compensation intended for someone entitled to provide it.
AhnLab documented this technique on July 22, 2022. Its investigation described malware delivered through advertising-related software that installed Peer2Profit and IPRoyal Pawns without user permission. In one version, the attacker executed the IPRoyal command-line client with account credentials associated with the attacker; later variants used a DLL-based implementation. [2]
This arrangement differed from conventional cryptocurrency mining because the stolen resource was not primarily computational power. The infected computer provided connectivity through its existing internet connection, while the attacker attempted to monetize the resulting network service.
In a report published April 4, 2023, Sysdig described a similar operation. An attacker exploited a vulnerable Apache Solr environment through Log4Shell and deployed the IPRoyal Pawns client. Sysdig’s researchers examined the deployment commands and associated account information, confirming that the ordinary proxyware client was being used as part of a malicious intrusion. [3]
Sysdig also tested whether Pawns accepted connections originating from commercial cloud infrastructure. Its experiments found that the service rejected certain AWS EC2 and OVHcloud IP addresses, demonstrating that restrictions on eligible network types already existed.
That distinction would remain central to later investigations. An endpoint could be technically unsuitable because it belonged to a data center, independently of whether its operator had permission to provide the connection. Conversely, an endpoint might appear commercially attractive because its IP address belonged to an ordinary access network, even when the software running on it had been installed without authorization.
2.2 A market that attackers can use without owning
The same economic approach continued appearing in later investigations, even as the techniques used to obtain devices changed.
In July 2026, Telekom Security published a forensic investigation into compromised embedded infrastructure that included an IPRoyal/Pawns-compatible proxy runtime on a Zyxel NSG100. Researchers recovered network configuration data, connection state, and traffic-related information from the device, and observed proxy traffic being relayed. The broader environment contained scanning, staging, command-and-control, and task-management capabilities, indicating that proxy functionality formed part of a larger infrastructure operation. [4]
The researchers did not attribute the recovered runtime to the current official Pawns client or prove that a commercial provider accepted the connection. Its importance is narrower: the investigation demonstrates how an already compromised network appliance could be used for proxy-related activity alongside other attacker-controlled functions.
In September 2026, AhnLab reported that the actor it tracks as Larva-25012 had resumed distributing proxyware, including products associated with IPRoyal and other commercial providers. The campaign made use of systems already infected by other malware, illustrating how control obtained through one operation could be reused for a different revenue-generating purpose. [5]
In a separate July 2026 case, Google said it had worked with the FBI, Lumen, and others to disrupt NetNut’s residential proxy network. Google estimated at least two million devices, described SDK-based enrollment, and reported a white-label resale program through which other brands could sell access to that network. [21] This is not evidence of wrongdoing by IPRoyal or Pawns.app, or a connection to skynox7. It shows at a larger scale why a retail proxy brand may not reveal how each underlying connection entered a network.
Together, these cases show how proxyjacking can operate as a secondary business layered onto an existing intrusion. The attacker acquires machines through exposed vulnerabilities, malicious installers, or prior compromises, then attempts to monetize their connectivity through external services.
The commercial infrastructure reduces what the attacker must independently provide. There is no need to develop a customer portal, assemble a sales team, negotiate contracts with enterprise customers, or build a worldwide network from scratch. A functioning proxy service already performs those activities, creating a supply channel that an unauthorized participant can attempt to enter.
3. The Business Behind the Residential Proxy Market
3.1 Pawns.app, IPRoyal, and the corporate organization of supply
The relationship between Pawns.app and IPRoyal helps explain how voluntarily shared connectivity becomes a commercial proxy product.
IPRoyal’s current sourcing page identifies Pawns.app as a direct source of residential proxies alongside external providers. The public record also connects the two businesses through a person with a defined role in each, without establishing the full group structure or internal financial arrangements. [9]
The legal organization can be partially reconstructed through public corporate and contractual records.
PAWNS.APP LTD was incorporated in the United Kingdom on October 28, 2024, under company number 16043795. Companies House identifies Karolis Toleikis as a director and as a person with control over at least 75% of the company’s shares and voting rights. IPRoyal separately identifies Toleikis as a co-founder, establishing a documented personal connection between the supply company and the proxy provider. [6][7]
IPRoyal’s current customer-facing terms identify IPRoyal Services FZE LLC, incorporated in Ajman in the United Arab Emirates under license number 4387, as the principal contractual service provider. The company may contract with other group companies and third-party providers in delivering its services. [8]
These records establish corporate and operational connections, although they do not disclose the full ownership structure of the IPRoyal group or the financial transfers between its constituent companies. Pawns.app’s supplier compensation, IPRoyal’s retail revenues, and any payments between the two businesses should not be treated as a single audited financial statement.
Their division of commercial functions is nevertheless clear from their public offerings. Pawns.app operates technology and contractual arrangements through which connectivity can be contributed, while IPRoyal markets and sells access to a managed proxy network. The companies occupy different positions in the same supply-and-distribution system. [9][10]
This is not an unusual structure in technology markets. Many legitimate businesses separate resource procurement from customer acquisition and service delivery. What makes the distinction relevant here is that the legality of a contributed connection depends on information originating with the device owner or network operator, rather than only with the company selling access to that connection.
3.2 The different kinds of bandwidth supplier
IPRoyal’s published sourcing policy describes two broad channels: direct acquisition through Pawns.app and procurement through external IP service providers. The company’s residential proxy pool is advertised as containing more than 64 million IP addresses, although that figure represents a marketed pool size rather than a count of simultaneously active physical devices. [9]
Within those channels, several different participants can supply the network.
An individual may install a bandwidth-sharing application and voluntarily make an eligible internet connection available. The participant is responsible for obtaining whatever permissions are required under the applicable internet service contract and device-use arrangements, while the software operator measures eligible usage and calculates compensation.
A separate model involves SDK integration. An application developer incorporates Pawns.app technology into software used by other people, permitting the application to offer optional bandwidth sharing. The developer becomes the commercial partner receiving compensation for qualifying traffic, while the people operating the individual devices provide the underlying connectivity.
Pawns.app advertises $0.20 per GB of eligible shared traffic for SDK partners. Its agreement requires the developer to obtain valid consent from users and makes the developer responsible for any remuneration offered to those users. The agreement does not guarantee a minimum amount of traffic or income. [10][11]
This creates a legitimate separation between the person providing the connection and the organization receiving payment. The developer may receive compensation centrally even though the actual network resources belong to numerous individual users, provided the users have consented and the other conditions of the agreement are satisfied.
A third route involves external IP suppliers. IPRoyal states that such partners undergo identity verification, review of their sourcing model, checks concerning consent, and ongoing monitoring. The identities of every individual supplier and the amounts paid under those relationships are not publicly disclosed. [12]
Skynox7 attempted to introduce a different kind of participant into this market. The attacker controlled compromised devices sufficiently to install software and associate it with an earnings account, but the owners of those devices had not authorized the attacker to sell their connectivity.
The resulting activity can resemble ordinary enrollment at the software level while differing fundamentally in the underlying right to provide the resource.
3.3 Who purchases residential proxy access?
Residential proxy customers are not necessarily specialist networking companies. IPRoyal’s published customer case studies identify businesses in AI data extraction, identity verification, web performance, marketing, and other commercial services. [13][14][15]
Reworkd, for example, provides AI-assisted web data extraction to organizations operating in government technology, legal technology, and e-commerce. Its system generates browser automation to collect structured information from websites and exposes the resulting data through an API. According to IPRoyal’s case study, Reworkd adopted its proxies after encountering reliability problems with other services, improving its reported scraping success rate from approximately 80% to more than 95%. [13]
This relationship illustrates how proxy access can become an input to another company’s product. Reworkd purchases connectivity to operate its collection infrastructure, while its own customers purchase the resulting data services. The customer requesting information about regulations or public procurement does not necessarily know which residential IP address was used during a particular extraction.
Ondato offers another example. The company provides Know Your Customer and Anti-Money Laundering technology but uses IPRoyal’s residential proxies for geographically targeted search-engine research and marketing intelligence. Its demand arises from the need to observe information as it appears in different markets rather than from the provision of proxy services itself. [14]
NitroPack, a web performance company, has described using IPRoyal proxies in experiments and services related to geographically distributed website performance. Other published IPRoyal case studies involve marketing firms and organizations conducting service monitoring or regional SEO research. [15]
These relationships establish that commercial demand exists outside the cybercrime economy. They do not establish that any named customer received traffic through devices compromised by skynox7, or even that their particular purchases depended on the Pawns.app supply channel rather than another source in IPRoyal’s inventory.
That distinction is essential to understanding the market. The customers purchase useful technical capabilities from a legitimate service provider, while the legitimacy of the individual nodes contributing those capabilities depends on an upstream supply relationship that customers do not ordinarily inspect themselves.
3.4 How revenue moves through the network
Published prices illustrate the difference between obtaining bandwidth and selling managed proxy access.
| Commercial relationship | Publicly advertised price or arrangement |
|---|---|
| Pawns.app SDK partner compensation | $0.20 per GB of eligible shared traffic |
| IPRoyal residential proxies, 1 GB pay-as-you-go | $7.35 per GB |
| IPRoyal residential proxies, 1 GB subscription | $7.00 per GB |
| IPRoyal large-volume subscription pricing | From $1.75 per GB at 10 TB |
| Individual bandwidth-sharing accounts | Earnings and payout eligibility depend on the applicable program |
Sources: Pawns.app business offering [11] and IPRoyal pricing [16].
It would be misleading to subtract $0.20 from IPRoyal’s retail price and describe the difference as the company’s profit. These amounts concern different products and contractual relationships, and they do not establish that a particular GB purchased by an IPRoyal customer corresponds directly to a GB compensated under an SDK agreement. Infrastructure operations, customer acquisition, quality control, payment processing, and other costs are also not captured by the comparison.
The figures nevertheless reveal the commercial functions being performed. A supplier is compensated for eligible measured usage, while the proxy operator sells customers access to a managed network whose value depends on geographic coverage, reliability, availability, and other properties.
Additional businesses participate in the financial side without providing bandwidth. IPRoyal’s terms identify payment service providers including Stripe, Paddle, CoinGate, Bitlocus, SpectroCoin, and Alipay. Those providers support transactions through different payment arrangements, rather than supplying network capacity themselves. [8]
The wider business also has customer acquisition and referral mechanisms, although the economic role of a marketing affiliate should not be confused with that of an IP supplier. A referral partner may receive compensation for introducing a purchaser, while a bandwidth supplier receives compensation for making a network resource available under the applicable agreement.
These relationships create several separate financial records: a customer’s purchase, the allocation of traffic to an endpoint, compensation credited to a supply partner, payments made to that partner, and possibly subsequent payments to an individual user.
An attacker who enrolls compromised equipment attempts to divert one of those revenue relationships. The victim continues bearing the normal costs of internet connectivity and equipment operation, while the attacker tries to have the economic value of that resource credited elsewhere.
For skynox7, the publicly identified payout account shows where the attacker intended the earnings to go. It does not establish that any payment processor transferred money to that account or that the attacker’s profits can be calculated from the number of infected devices.
4. From a Compromised Device to a Commercial Proxy
4.1 The technical boundary between controlling a machine and supplying its connection
The first technical step is access to a device that can run a proxy client and reach the internet. GreyNoise observed that access on compromised NAS, NVR, and SAP systems; the next step was installing Pawns.app and associating it with the attacker’s account. [1]
In a residential proxy service generally, a buyer’s request is relayed through an admitted endpoint to its destination; the destination sees the endpoint’s public egress IP, and the response returns through the relay. That routing function does not by itself establish file access or unrestricted access to the device’s internal network. The protocols, filtering, and actual customer traffic for skynox7’s installations have not been disclosed.
Pawns.app’s published Docker instructions illustrate the registration model used by its command-line software. The installation procedure starts a container with account credentials, a device name, a device identifier, and an option accepting the service’s terms of use. The application can be configured to restart automatically and continue operating without further interaction. [17]
These are convenient features for legitimate automation. They can also be exercised through unauthorized execution sufficient to install and run the client. The vulnerable entry points reported by GreyNoise establish compromise, but its public account does not specify each resulting process identity or privilege level. [1]
Account credentials, device identifiers, and terms acceptance provide inputs for enrollment. They identify a client and its operator, but the publicly documented CLI parameters do not themselves carry proof from the device owner or ISP that this particular connection may be resold.
This does not mean Pawns.app necessarily accepts every technically functioning client. Sysdig observed restrictions on eligible network environments, while the provider-side checks applied to skynox7’s installations remain unknown. [3]
The public CLI instructions do not show the backend decision that follows registration. Whether a node is admitted, and which other checks are applied, depends on provider-side procedures not visible in the installation command. Section 5 examines the separate evidence of permission and consent.
4.2 A separate Android SDK example of delegated consent
The Android SDK is a separate supply route from the CLI reported in the skynox7 campaign. Its public source provides a bounded example of where one product path checks consent. [18]
In the source at the fixed commit cited below, the published full configuration stores a consent Boolean in Android SharedPreferences, defaulting to false. The public startSharing() method checks that state, while setConsentGiven() lets the integrating application update it. The implementation therefore checks a state supplied through the application; that local Boolean is not independent proof that the connection holder had authority to contribute the resource. [18]
Pawns.app’s SDK agreement formalizes that division. The developer must obtain explicit consent, keep the feature disabled by default, make withdrawal available, and preserve consent records for at least 24 months. The developer also remains responsible for ensuring that the person consenting is authorized to use the device and its connection. [10]
The SDK code does not show how the CLI handled consent or what a backend accepted in the skynox7 case. Its relevance is the boundary between a local consent state and the developer’s contractual obligation to obtain and retain genuine consent, examined in Section 5.3.
4.3 What exactly was operating in October 2026?
The product history introduces a further unresolved question.
Pawns.app’s official company-information page states that, as of 2026, it does not offer internet bandwidth sharing and that the feature was discontinued. It does not date the discontinuation. Yet its business website continues to advertise bandwidth-sharing SDK services, including compatibility with multiple operating systems. IPRoyal’s August 11, 2026 FAQ also describes its residential proxy network as having been built through Pawns.app and presents users joining and leaving that network as an available activity. [9][11][19]
The Docker distribution record complicates a simple interpretation of discontinuation. As observed on October 16, 2026, the IPRoyal-managed Docker Hub repository listed Pawns CLI images, including version 0.36.6. [20]
These sources are not necessarily mutually exclusive. The individual consumer application may have discontinued bandwidth sharing while a business SDK or legacy CLI service remained available under different arrangements. Published documentation may also have been updated at different times.
The available materials do not resolve which explanation is correct. In particular, the existence of an updated container image does not demonstrate that the corresponding client could still register commercially eligible nodes, route paying customer traffic, or earn rewards from the backend.
This uncertainty matters directly to skynox7. If the attacker used an operational enrollment path, the next question is whether the service accepted the unauthorized devices. If that path was no longer commercially active, the installation might have achieved little beyond placing an unwanted application on the victim systems.
The public GreyNoise report does not contain the provider-side records needed to distinguish those possibilities.
4.4 Where the commercial transaction would actually begin
The technical and financial stages of the attack need to be separated.
Compromising a device gives the attacker control over a machine. Installing Pawns.app introduces software capable of participating in a proxy network. Associating the software with an account expresses an intended commercial relationship, but the service must still accept the device, allocate traffic, measure valid usage, and authorize payment.
Under Pawns.app’s published SDK agreement, simply providing an IP address is not sufficient to earn compensation. Payments are based on traffic successfully routed and measured, and the company can exclude traffic associated with abuse, ineligible hosting environments, fraud, lack of consent, or certain continuously operating devices without active user engagement. [10]
These contractual provisions concern SDK partners and should not automatically be assumed to describe every control applied to the CLI. They nevertheless show that the company’s documented business model distinguishes connection availability from eligible compensated traffic.
The distinction also affects how the 143 compromised devices should be interpreted. An attacker could successfully install software on enterprise infrastructure only to discover that the IP address was not eligible for the commercial service. Even an accepted node might receive no paying customer traffic, or its usage might subsequently be excluded from compensation.
The available public evidence establishes the compromise, installation, and intended account association. It does not establish the later stages of acceptance, sale, traffic accounting, or payout.
5. Who Has the Authority to Sell the Connection?
5.1 The industry’s compliance problem is already recognized
IPRoyal’s explanation of its approach to proxy sourcing and network compliance was last updated on October 12, 2026. Written by Chief Risk Officer Linas Konovalovas, the document describes a supplier review process involving identity verification, examination of business models and IP acquisition methods, evidence of informed user consent, technical testing, and daily checks against public abuse databases. [12]
The company explicitly rejects suppliers unable to provide sufficient evidence of consent and states that software-based sourcing without a legitimate business justification or proof of permission does not meet its standards.
Its policy also addresses the buyer side. IPRoyal prohibits proxy reselling because it can obscure the identity and intended activities of the final customer, making abuse prevention more difficult. The proxy provider’s ability to know who is using the network is treated as a security consideration as well as a contractual requirement.
These policies provide important counterevidence to any claim that the residential proxy market operates without verification. IPRoyal publicly recognizes unauthorized supply as a risk and describes institutional procedures intended to prevent it.
The unresolved question concerns the granularity and placement of that verification.
An external supplier can be screened as a business, including a review of its application and the manner in which it obtains consent. A particular IP address may separately undergo quality and reputation checks. Neither necessarily demonstrates that a specific device, at a particular time, was enrolled by someone authorized to commercialize its network access.
A provider could maintain additional internal records linking these facts. The public documentation does not describe enough of that process to establish how it applies across every supply channel, particularly individual CLI installations.
5.2 The right being transferred is not ownership of the IP address
Commercial proxy services are frequently described as buying and selling IP addresses, but the underlying transaction is more precise.
A supplier ordinarily does not transfer ownership of an IP address to the proxy provider. Instead, the supplier permits traffic to be routed through an internet connection, allowing the provider to offer customers a service that appears to originate from that connection.
Several different forms of authority may therefore be involved.
The ISP provides connectivity under a contract. The subscriber may have permission to use the connection but not necessarily to operate a commercial proxy service through it. The owner of a device can determine which software should run on the device, while an employee or administrator may exercise delegated operational privileges. In an SDK arrangement, the application developer may receive consent from a user without itself owning either the device or the connection.
A lawful contribution must be consistent with the relevant permissions, which cannot always be inferred from technical control over the machine.
For the skynox7 devices, evidence of authorization would have to come from the people or organizations entitled to make decisions about each connection, not from the attacker’s ability to operate a vulnerable NAS or NVR. Public reports contain no such authorization.
5.3 Consent and customer knowledge occupy different parts of the transaction
Pawns.app’s SDK agreement creates a particularly interesting division of information.
The developer is responsible for obtaining explicit consent and preserving records that can be produced upon request. At the same time, Section 3.14 allows Pawns.app to provide contributed IPs and bandwidth to its clients and their downstream customers without disclosing the identity of those buyers or the terms of their arrangements to the SDK partner. [10]
The division is commercially understandable. An application developer selling eligible traffic to a supplier does not ordinarily need access to the proxy provider’s customer contracts, just as a commercial buyer does not need to know the identities of every individual device owner participating in a properly sourced network.
However, the information required to verify an end-to-end authorization claim is now distributed across several systems.
The application developer may retain the evidence that a person consented. Pawns.app measures traffic and maintains records of its supply relationships. IPRoyal handles commercial purchases and customer access, while the ISP holds the underlying connectivity contract. The commercial buyer may see the network attributes of the endpoint without having direct access to the individual consent record.
No single participant necessarily holds every record needed to reconstruct the entire transaction from a device owner’s permission to a customer’s use of its connection.
That does not make verification impossible, but it means it must be designed across organizational and contractual boundaries. Supplier vetting, device enrollment, traffic measurement, and payment approval have different purposes, and evidence generated at one stage must retain a meaningful relationship to the others.
5.4 Payment verification answers a different question
The financial relationship adds another layer.
Commercial suppliers can require verified accounts, accurate banking information, and additional identity checks before allowing payments. Pawns.app’s SDK agreement authorizes withholding compensation for invalid traffic or contractual violations, while IPRoyal’s customer-facing terms govern payments processed through established financial providers. [8][10]
These controls can identify a recipient of funds or detect suspicious transactions. An authorized application developer may receive payment for many consenting users; an attacker may use a real account to seek payment for connections the victims never agreed to provide. The account record alone cannot distinguish those situations.
The relevant distinction is between the identity of the payee and the origin of the payee’s entitlement. For an individual unit of compensated traffic, a complete record would need to connect the service account, the contributing endpoint, the applicable authorization, the period of use, the measured traffic, and the resulting payment.
This explains why the payout account identified by GreyNoise is important but insufficient. It establishes the attacker’s intended financial endpoint, while the missing provider records prevent investigators from reconstructing an actual flow of proceeds.
5.5 Why the recurring attacks do not prove that the controls failed
The public history shows repeated attempts to monetize compromised devices through legitimate proxyware, but it does not provide uniform evidence of successful payment.
AhnLab’s 2022 report established unauthorized installations and attacker-controlled configuration. Sysdig examined a deployment involving a vulnerable container and a commercial proxy client. Telekom Security later observed active relay behavior in an IPRoyal/Pawns-compatible runtime on compromised infrastructure, while explicitly withholding attribution to a particular official client or provider-side authorization system. GreyNoise’s 2026 campaign established a further set of compromises and an intended payout account. [1][2][3][4]
These investigations involve different attackers, devices, software versions, and degrees of visibility. They cannot be combined into proof that a specific supplier accepted all of the unauthorized connections, much less that it knowingly tolerated them.
They do, however, show why the same commercial model continues attracting attackers. The intrusion and the attempted monetization can be organized separately, allowing operators to reuse legitimate software and external market infrastructure rather than constructing a complete criminal service.
The market’s security therefore depends not only on detecting malicious buyers, but also on verifying the origins of the resources being supplied to it.
The most useful evidence would come from comparing device-side observations with the provider’s own registration and financial records. For skynox7, that would mean identifying which compromised endpoints were actually accepted, whether any customer traffic passed through them, whether compensation was credited, and whether it was ultimately paid or withheld.
Without those records, it is possible to explain the attacker’s business model and the market’s verification problem, but not to declare that the complete commercial transaction succeeded.
6. Conclusion — Who Can Sell Someone Else’s Internet Connection?
The skynox7 campaign illustrates an unusual form of cybercrime in which an attacker attempts to extract value from compromised infrastructure without necessarily stealing its data or encrypting its files. The resource being exploited is the victim’s continuing ability to communicate with the internet, and the attempted means of monetization is a legitimate commercial platform built to aggregate and distribute that capability.
Reconstructing the business behind the software reveals an industry extending far beyond the compromised devices. Pawns.app and IPRoyal perform different supply and sales functions with a documented personal and sourcing connection, while external suppliers, application developers, individual participants, payment providers, commercial customers, and downstream data businesses contribute to separate stages of the market.
The named customers and published prices establish the commercial demand for residential proxies, but they do not connect those customers to skynox7. Similarly, the attacker-controlled payout account identifies an intended recipient of earnings without establishing that traffic was sold or money was transferred.
The industry has not ignored the risks of unauthorized sourcing. Pawns.app’s SDK terms require explicit consent and recordkeeping, while IPRoyal describes identity checks, sourcing reviews, consent verification, and ongoing IP monitoring. These controls are meaningful, although their effectiveness against a particular unauthorized installation cannot be established solely from their public descriptions.
The underlying difficulty arises because the attributes making a connection commercially valuable are not the same attributes that determine whether it can legitimately be provided. The geographic location, reliability, and accessibility of an IP address can be evaluated through technical measurements. The authority to contribute that connection originates in relationships among device owners, users, employers, network administrators, and internet service providers.
Those relationships are only partially visible from the endpoint itself.
A compromised device can operate as an apparently ordinary network node even though the person directing its software has no right to commercialize its connection. A verified account can identify the person seeking payment without proving the origin of that entitlement, while a legitimate buyer can purchase proxy access without seeing the evidence through which each contributing device was admitted.
The attacks documented between 2022 and 2026 demonstrate that this distinction has remained economically attractive to criminals despite changes in software, deployment practices, and compliance requirements.
For skynox7, the final financial outcome remains unresolved. The more general problem is already visible: a market can accurately measure and sell the use of a resource while still needing independent evidence that the supplier has the authority to provide it.
As residential proxy networks become increasingly integrated into data collection, AI infrastructure, marketing, and distributed online services, that evidence becomes part of the supply chain’s security. The decisive question is not simply whether an IP address is real, residential, and functional, but whether the organization selling access to it can establish that the underlying connection was contributed by someone entitled to do so.
References
Incident investigations and historical cases
[1] GreyNoise, “skynox7: Proxyjacking Edge Devices Into Residential Proxies,” October 15, 2026.
https://www.greynoise.io/blog/proxyjacking-edge-devices-residential-proxies
[2] AhnLab ASEC, “Attackers Profiting from Proxyware,” July 22, 2022.
https://asec.ahnlab.com/en/37276/
[3] Sysdig Threat Research Team, “Proxyjacking has Entered the Chat,” April 4, 2023.
https://www.sysdig.com/blog/proxyjacking-attackers-log4j-exploited
[4] Telekom Security, “From Infected Zyxel to Exposed C2: A Case Study in IoT Botnet Operations,” July 29, 2026.
https://github.security.telekom.com/2026/07/from-infected-zyxel-to-exposed-c2.html
[5] AhnLab ASEC, “Larva-25012: A 2026 Proxyware Distribution Campaign by the Threat Actor,” September 17, 2026.
https://asec.ahnlab.com/en/95516/
Corporate organization and commercial supply
[6] IPRoyal, “About Us,” identifying Karolis Toleikis as co-founder.
https://iproyal.com/about-us/
[7] UK Companies House, PAWNS.APP LTD, Company No. 16043795, including officers and persons with significant control.
https://find-and-update.company-information.service.gov.uk/company/16043795
[8] IPRoyal Services FZE LLC, Terms of Service, effective October 15, 2026.
https://iproyal.com/terms-of-service/
[9] IPRoyal, “Residential Proxy Sourcing,” and “How Do You Source Your Residential Proxies?”, FAQ updated August 11, 2026.
https://iproyal.com/residential-proxy-sourcing/
https://help.iproyal.com/en/articles/7959923-how-do-you-source-your-residential-proxies
[10] PAWNS.APP LTD, SDK Terms and Conditions, updated May 11, 2026, particularly Sections 1.1, 3.3, 3.6, 3.10 and 3.14.
https://business.pawns.app/sdk-terms/
[11] Pawns.app Business, “Scalable SDK Monetization for Apps,” including advertised compensation and platform support.
https://business.pawns.app/sdk/
[12] IPRoyal, Linas Konovalovas, “Transparency First: How IPRoyal Approaches Proxy Sourcing and Use,” October 12, 2026.
https://iproyal.com/blog/proxy-industry-transparency/
Buyers, prices, and downstream services
[13] IPRoyal, “Reworkd Boosts Scrape Success From 80% to 95% With IPRoyal.”
https://iproyal.com/case-studies/reworkd/
[14] IPRoyal, “Geo-targeted SERP Insights Help Ondato Boost Marketing.”
https://iproyal.com/case-studies/ondato/
[15] IPRoyal, “NitroPack Supercharges Site Speed Using Residential Proxies.”
https://iproyal.com/case-studies/nitropack/
[16] IPRoyal, “Residential Proxies Pricing.”
https://iproyal.com/pricing/residential-proxies/
Technical implementation and product status
[17] Pawns.app, “How to Install and Run the Pawns.app Container in Docker,” updated May 27, 2025.
https://pawns.app/blog/how-to-install-and-run-the-pawns-app-container-in-docker/
[18] Pawns.app, Android SDK source at commit 704cec412ab43b097c8be823d57ce30bc84c7978: ConsentManager.kt and Pawns.kt.
[19] Pawns.app, “Official Information About Pawns.app,” including its as-of-2026 statement that internet sharing is no longer offered.
https://pawns.app/llm-info/
[20] IPRoyal, Docker Hub repository iproyal/pawns-cli, including version 0.36.6.
https://hub.docker.com/r/iproyal/pawns-cli/tags
[21] Google Threat Intelligence Group, “Google’s Continued Disruption of Malicious Residential Proxy Networks,” July 2026.
https://cloud.google.com/blog/topics/threat-intelligence/google-continued-disruption-residential-proxy-networks
Evidentiary Scope
This analysis combines incident reports, security research, public corporate filings, contractual documents, product documentation, pricing pages, official customer case studies, and independently examined public SDK source code.
The GreyNoise investigation establishes at least 143 compromised devices across 34 countries, the deployment of Pawns.app, and an attacker-associated payout account. It does not provide a complete record of provider-side node acceptance, customer traffic, account balances, earnings approval, or withdrawals. The analysis therefore does not characterize the campaign as having generated a verified amount of revenue.
The historical AhnLab, Sysdig, and Telekom investigations concern separate observations and are not attributed to the same attacker as skynox7. In particular, Telekom’s IPRoyal/Pawns-compatible runtime does not establish that an official Pawns client or IPRoyal backend authorized its traffic. Google’s NetNut investigation concerns a separate network and does not establish any supply or business connection to IPRoyal or Pawns.app.
IPRoyal’s customer case studies establish named commercial relationships but do not show that any of the identified customers received traffic from skynox7’s compromised devices. The company’s advertised IP pool is a commercial coverage figure and should not be interpreted as a verified number of concurrently active devices.
The corporate records establish identifiable relationships among PAWNS.APP LTD, Karolis Toleikis, and the IPRoyal business, but do not disclose a complete group ownership structure, intercompany revenue distribution, or the commercial terms of every external supply relationship.
The Android SDK observations derive from fixed public source files at the cited commit. They describe local consent state and the public API check, not the CLI used in the incident. They do not establish unauthorized commercial traffic through the live backend or exploitation of this SDK in the skynox7 campaign.
Finally, the apparently inconsistent public descriptions of Pawns.app’s discontinued bandwidth-sharing feature, continuing SDK offering, and listed CLI distribution remain unresolved. The public availability of software does not establish that every associated commercial backend function was operational in October 2026.
The analysis identifies a recurring attempted form of unauthorized resource monetization and the supply-chain verification problem it creates. It does not allege that Pawns.app, IPRoyal, their named customers, or their payment service providers knowingly participated in or benefited from the unauthorized installations.