Unveiling the depths of Residential Proxies providers

Residential proxies (RESIP) are services that route traffic through real users’ IPs (desktops, mobile, routers) and are sourced via voluntary proxyware, SDK integration, or clandestine installation on compromised hosts; attackers use them to blend malicious traffic with legitimate user traffic and evade detection. The report details installation and persistence techniques (DNS change, downloading packed binaries like “iparmv6”, cron jobs, init script modifications) and provides IOCs for hunting. #APT29 #PawnsApp

Keypoints

RESIP provide access to millions of residential IPs sourced by proxyware (voluntary apps), SDKs embedded in apps, or clandestine installation on compromised devices.
Attackers use RESIP to obfuscate origin and evade automated defenses — documented use by APT29 and other groups for password spraying, brute force, phishing, and DDoS.
Compromise-to-proxy workflow observed: SSH access → DNS change to 1.1.1.1 → download UPX-packed binary (e.g., iparmv6) → run with credentials → persist via cron jobs and init scripts.
Proxyware binaries are multi-architecture (ARM, x32, x64) and often packed with UPX; providers and resellers frequently use anonymous cryptocurrencies and short-lived wallets to obfuscate revenue flows.
RESIP ecosystem is fragmented but interconnected (shared wallets, legal shell companies, resellers, and rebrands), complicating takedown and attribution efforts.
Hunting/prevention recommendations: block/uninstall proxyware on managed hosts, hunt for network/host IOCs (domains, binaries, IPs), and enforce application whitelisting and least-privilege policies.

MITRE Techniques

[T1090] Proxy – Using residential proxies to hide attacker origin and blend with legitimate traffic (‘RESIP networks to route their traffic interacting with the compromised tenant through a vast number of IP addresses blending with legitimate users’ traffic.’).
[T1110] Brute Force – Performing password spraying/credential access campaigns routed through RESIP to evade location-based controls (‘espionage-related password spraying attacks’).
[T1498] Network Denial of Service – Launching or amplifying DDoS operations using RESIP infrastructure (‘Many campaigns relying on RESIP were recorded … leveraged the infrastructure of FineProxy and RayoByte’).
[T1195] Supply Chain Compromise – Embedding proxyware into third‑party SDKs and applications so end‑users unknowingly provide exit points (’embedding proxyware into SDKs … present in many types of applications’).
[T1053] Scheduled Task/Job – Establishing persistence via cron entries to relaunch downloaded proxyware binaries (‘cronjob1=”*/10 * * * * $croncmd1”’ and adding cron entries to persist execution).
[T1543] Create or Modify System Process – Modifying init/service scripts (e.g., lighttpd) and creating daemon-like processes (watchdog) to ensure proxyware runs on service start (‘grep -qxF ‘/home/user/chron’ /etc/init.d/lighttpd || echo ‘/home/user/chron’ >> /etc/init.d/lighttpd’).
[T1572] Protocol Tunneling – Establishing SSL/TLS tunnels (revsocks) to relay traffic from compromised hosts (‘download a binary, enabling him to establish his own SSL/TLS tunnel via revsocks’).

Indicators of Compromise

[IP address] examples seen in hunting leads and runtime — 3.228.177[.]90 (Bright SDK related), 34.237.199[.]147 (EarnApp related).
[Domain] proxyware and SDK endpoints — clientsdk.brdtnet[.]com (Bright SDK), api.pawns[.]app (Pawns.app/IPRoyal), and other API endpoints (and several more listed in Appendix C).
[File name / binary] installed or executed proxyware files — iparmv6 (Pawns.app binary observed on compromised hosts), Pawns.app.exe, lum_sdk.dll (Bright SDK components).
[Command / script artifacts] persistence and DNS changes — crontab entries like ‘*/10 * * * * $croncmd1’, and ‘nameserver 1.1.1.1’ modifications used in observed attacks.
[Cryptocurrency wallet] financial pivot / cluster — example wallet 0x8379c994c5c39fc9c66bf5b55aa796920e532511 used to aggregate ETH payments (and other wallets observed aggregating funds).

Attackers build RESIP exit pools via three main technical routes: (1) voluntary proxyware that users install (Pawns.app, EarnApp, Honeygain) which run a local binary and register the device as an exit point; (2) SDK integration where proxy functionality is embedded in third‑party apps so users unknowingly expose their IPs; and (3) direct compromise where operators access a host (SSH), change DNS to avoid blocking, download a packed proxy binary (example: an UPX-packed “iparmv6” linked to Pawns.app), set executable permissions and run it with configured credentials. These binaries are often multi-architecture and designed to act as exit proxies for the RESIP pool.

For persistence and resilience, observed operators add cron jobs to re-download or relaunch components (example cron entries to run a ‘chron’ binary every 10 minutes and to reapply DNS nameserver settings), and modify service init scripts (e.g., appending ‘/home/user/chron’ to /etc/init.d/lighttpd) so proxyware starts with services. Operators also host binaries on already‑compromised relays, use SSL/TLS tunnels (revsocks) to conceal proxy traffic, and centralise payments via short‑lived cryptocurrency wallets to obfuscate financial trails.

Detection and hunting should focus on signed/unpacked proxyware filenames (listed in Appendix C), domains used by SDKs and APIs (clientsdk/earnapp/pawns endpoints), anomalous egress patterns from endpoints (unexpected geographic IPs, high-port tunnels, frequent short-lived outbound connections), DNS changes to 1.1.1.1 or other unusual resolvers, and the cron/init script artifacts shown above. Blocking unapproved proxyware, enforcing application whitelists, limiting privilege for installing services, and hunting the IOCs above are practical steps to remediate and reduce RESIP exposure.