IPWeb: Peering from Within

Synthient continues to track proxy services that source bandwidth from compromised devices. This report focuses on IPWeb and the APSolo malware underpinning its illicit proxy operations. IPWeb operates a globally distributed network of compromised devices built on APSolo. Various operational security (OPSEC) mistakes allowed Synthient’s Research Team to obtain and preserve the original malware client and backend source used by the operators. The recovered source code and deployment artifacts expose the inner workings of the platform and help link it to IPWeb, a China-based proxy service. IPWeb has gained popularity among threat actors because it permits access to localhost and private-network destinations from proxy exits, allowing actors to probe device-local and LAN services.

A Silent Backdoor

From January through June 2026, Synthient’s Research Team acquired numerous TV boxes and IoT devices for ongoing research into the pay-per-install networks leveraged by residential proxy providers. One binary repeatedly surfaced across many of these devices, having been installed through pay-per-install campaigns as “appprocess_boot[.]jar” in a folder named “ipwb”. This Java binary, hereafter referred to as “APSolo,” is a ProxySDK that never asks for consent and is distributed at scale.

Fig. 1. APSolo client with its hard-coded Tier 1 server.

On startup, appprocess_boot[.]jar (APSolo) is observed connecting to its Tier 1 UDP server 34[.]237[.]159[.]252:11116 with the following protocol:

APSolo first queries the server for its exit IP address, then requests the configuration using that IP address and an optional country code. If successful, the server returns an IPv4 address, a randomized high port, and a 16-byte admission key. APSolo then assigns the device a randomized persistent UUID, connects to the Tier 2 relay and submits opcode 0x08 with the admission key, geography fields, persistent UUID, and version or channel value before proxied traffic begins. The APSolo backend notably assigns different servers based on the Channel ID, with these acting as isolated pools. APSolo operators are commonly observed hosting both the Tier 1 and Tier 2 servers on the same gateway.

Fig. 2. APSolo connection flows from victim device to relay.

Since our initial observation, the Tier 1 relay at 34[.]237[.]159[.]252:11116 has moved, with APSolo using the *[.]bestipip[.]com subdomains for the initial Tier 1 relay. Synthient's Research Team discovered a total of 8 unique Channel IDs in the wild; the full list is detailed in the table below.

Even Threat Actors Love Open Source

The Synthient Research Team examined all variants of APSolo, noting that all builds share one artifact: a custom logging library named “solo_ProxyLogger.” A GitHub search for this keyword identified an APSolo repository published by the account “imzhuli” in 2022 that contains the identical logging library.

Fig. 3. APSolo source containing the custom solo_ProxyLogger library. (Source: GitHub)

Further analysis of the repository revealed the same custom logger, protocol implementation, and hard-coded controller infrastructure observed in active APSolo samples. Synthient assesses that this repository contains the original APSolo client source code. The client repository stopped receiving updates after March 2022, while separate backend and deployment repositories continued to receive updates through September 2026.

Fig. 4. APSolo client configuration containing controller settings. (Source: GitHub)

From these repositories, Synthient recovered APSolo backend and DevOps code published under “imzhuli”. Synthient assesses with high confidence that “imzhuli” is an operator and maintainer: the try_auto_deploy repository contains detailed production deployment configuration, PPP_UI_Utils contains infrastructure-management workflows and operational access paths, and APSolo contains the main client source code. Synthient preserved these repositories for verification and future researcher access; the archive has not yet been published.

Fig. 5. Identical Relay implementation recovered from the APSolo backend. (Source: GitHub)

These repositories show APSolo’s continued development across CoreX, MiniPP, MiniPP_R, PPPro, PP2, PP3, try_auto_deploy, and PPP_UI_Utils, with commits extending into September 2026. The APSolo backend evolved from CoreX → MiniPP → MiniPP_R → PPPro → PP2 → PP3. Future iterations added TCP and UDP relays, device challenges, and relay selection.

Fig. 6. Public APSolo repository commit history. (Source: GitHub)

Who is IPWeb

The recovered backend exposed infrastructure that overlaps with a commercial proxy service: IPWeb. Synthient’s Research Team linked APSolo to the Chinese-language service through shared controller infrastructure, deployment artifacts, and outbound traffic from the APSolo SDK. Among these was a config file pushed to GitHub by imzhuli which includes the IP address 45[.]197[.]7[.]51 which is actively used by IPWeb for their Kafka and ClickHouse instance.

Fig. 7. Infrastructure Configuration Files (GitHub)

IPWeb has operated since 2022 and has largely gone unnoticed. Following Google’s January 2026 disruption of IPIDEA, IPWeb has become a core supplier for residential IPs to IPIDEA.

Fig. 8. IPWeb’s public website. (ipweb[.]cc)

IPWeb also maintains a presence on GitHub under the shared company account “resource-ipweb”. This account contains documentation for IPWeb, 006IP, and YangtuIP, all of which are white-label brands owned and operated by IPWeb. Leveraging these repositories, we are able to build a map of some of the developers within the organization and the role they play in maintaining the proxy service.

Fig. 9. Potential positions based on GitHub commits. (GitHub)

Commercial Redistribution

IPIDEA has a significant cultural impact on the residential proxy space.

Similar to IPIDEA, IPWeb has established a distribution network that uses affiliated brands, white-label deployments, and resellers.

Fig. 10. IPWeb’s reseller and white-label distribution network.

This model is lucrative for both operators and resellers; bandwidth purchased for approximately $0.40 per GB can be resold for as much as $15 per GB, a 3,650% markup.

Fig. 11. BartProxies reselling IPWeb bandwidth at a 3,650% markup. (Archive.org)

Intertwined with DDoS

Cheap, widely resold bandwidth has made IPWeb an attractive platform for abuse. Following Synthient’s disclosure of the ADB LAN pivot in January 2026, numerous threat actors have been observed targeting Chinese proxy providers because of weak security controls and their reliance on TV boxes for supply.

Fig. 12. Threat actor commands targeting exposed Android devices. (Note: iproyal[.]cc is a Chinese actor impersonating the official IPRoyal) (Telegram)

Synthient’s Research Team assesses that IPWeb has directly enabled the spread of DDoS botnets, including Jackskid, Katana, and SDKC. Synthient’s Helios telemetry shows that more than 33% of observed traffic was associated with device-exploitation activity, including requests involving c[.]cx, localtest[.]me, and thingortwo[.]g2afse[.]com. Domains such as localtest[.]me resolve to localhost, allowing proxy clients to reach services exposed on the exit device or its local network. In observed attacks, actors used this behavior to identify and infect Android devices running ADB as root. Synthient’s Research Team also observed IPWeb-linked traffic associated with ad fraud, spam, and credential stuffing.

Fig. 13. APSolo traffic distribution by destination and port.

Size and Scale

Synthient has maintained access to IPWeb's pool since 2025, with internal data showing significant growth. As of 24 September 2026, Synthient estimates that there are around 800K daily active IPs, concentrated primarily in Brazil, Colombia, and India.

Fig. 14. IPWeb’s proxy pool size.

Organizations

• Block or monitor the Tier 1 and Tier 2 indicators listed in the IOC appendix.
• Segment TV, Android, and other IoT devices on dedicated VLANs or guest networks.
• Disable ADB over the network, including TCP port 5555, and alert on scanning or connection attempts.
• Enrich fraud, login, and abuse telemetry with residential-proxy, ASN, and provider signals; apply step-up verification and rate limits rather than relying only on blanket IP blocks.
• ISPs should notify or quarantine subscribers with verified compromise, coordinate remediation with OEM and CPE vendors, and sinkhole confirmed controllers where legally permitted.

Personal

• Avoid purchasing unofficial TV boxes or Android-based devices from unsupported retailers. Prefer certified devices from vendors that publish security updates, place TV and IoT equipment on a router guest network, and disable UPnP, ADB, and remote-debugging features.
• Use router-level DNS or firewall controls to block known controller and relay indicators.

Synthient’s public research repository contains the complete IOC and observable set, supporting source snapshots and preserved artifacts here.

The Chinese proxy landscape is incredibly complex, with misattribution being common among security organizations, which often label all providers as IPIDEA or Kookeey. In reality, the space is diverse, with a number of novel botnets helping to support the broader underground proxy economy. These botnets are propped up by a larger set of actors operating in the Pay-Per-Install (PPI) space, granting cheap access to a vast array of devices. IPWeb is not unique in this regard; however, due to its size and scale, it has grown to be a large player in the proxy space.

IPWeb poses a significant risk to organizations due to the lack of KYC and the whitelisting of all ports, which have helped fuel spam and credential stuffing. By allowing threat actors to pivot on localhost and private-network IPs, APSolo has gone from a generic proxy service to an initial access service which is leveraged by actors wanting to grow their DDoS botnets.

Ultimately, platforms like IPWeb will continue to go unchecked unless they regulate themselves or become regulated by larger coordinated efforts.