GreyNoise finds 143 proxyjacked edge devices; a separate intrusion shows why residential IPs complicate detection

Two connected findings, not one victim set

A 15 October GreyNoise investigation reports that an actor it labels skynox7 compromised at least 143 internet-connected devices in 34 countries and installed Pawns.app software to turn their connections into residential proxy nodes. The victims did not volunteer their bandwidth. GreyNoise calls this proxyjacking. The number is a minimum observed in its research, not a measured global total.

The same report opens with a separate enterprise incident. During a product demonstration, GreyNoise noticed suspicious Entra ID sign-ins from residential proxy IP addresses in locations that appeared reasonable for the organisation. A residential-proxy label alone did not establish an intrusion: a legitimate user and an unrelated proxy customer can share the same IP. Further investigation found several users authenticating from one of those IPs, and the organisation confirmed a serious intrusion. GreyNoise has not published the full case details. Its article does not say that the enterprise incident was caused by the skynox7 campaign or that the 143 devices were used against that organisation.

How proxyjacking changes the meaning of an IP address

Residential proxy software normally lets a consenting participant share their internet connection with a proxy service, often in exchange for payment. In this campaign, the operator first gained unauthorised control of exposed equipment and then installed a legitimate proxy client under the operator’s account. Traffic purchased through the proxy network can subsequently appear to originate from the victim’s home or business connection. The commercial software itself is not inherently malware; consent and who controls the payout account change the security meaning.

That makes two distinct victims possible: the owner whose device and bandwidth were taken, and a separate organisation attacked through a residential exit node. It also weakens rules that assume a local-looking IP equals a familiar user. GreyNoise’s example shows why investigators need device identity, session details and user behaviour alongside geolocation.

Observed proxyjacking sequence and defensive visibility, based on GreyNoise’s report. The proxy customer’s downstream use is a general consequence, not an observed step for every device.

Stage	Reported behaviour	Defender view
Exposure	Internet-facing NAS, NVR or application server with exploitable flaw	Inventory, versions and reachable management services
Compromise	Actor uses listed vulnerabilities to gain control	Edge logs, unexpected processes and configuration change
Monetisation	Pawns.app client enrolled for the actor, using the victim’s connectivity	Unapproved proxyware, outbound sessions and account configuration
Fallback access	SSH key authentication configured on some devices	Unknown authorised keys and remote-access changes
Downstream risk	Proxy customers can emerge from the victim’s residential IP	Authentication context beyond IP and geography

GreyNoise gives one combined count, at least 143 devices across 34 countries, but no per-country or per-vendor distribution. A bar chart would invent proportions. The HTML sequence above carries the mechanism without implying unsupported quantities.

Which technologies were named

Products and vulnerabilities GreyNoise explicitly associates with successful compromise; these are not device counts by product.

Technology	Vulnerability cited	Practical scoping question
D-Link ShareCenter NAS	CVE-2024-3272 and CVE-2024-3273	Is an affected NAS reachable, and what vendor support or isolation path exists?
Ubiquiti UniFi Video NVR	CVE-2021-44228	Is the legacy video system still deployed and exposed?
SAP NetWeaver Visual Composer	CVE-2025-31324	Are exposed instances patched and reviewed for post-exploitation?

GreyNoise also says the actor appeared to target other DVR/NVR brands, including Hikvision and Dahua. That is not the same as confirming successful compromise of those brands in the reported set. The public report does not break down the 143 devices by product, geography or time of compromise.

The company publishes hashes and an IP indicator in its source report. Indicators can help triage, but their absence is not proof a device is clean; the software is also used legitimately and an attacker can change infrastructure. The source’s phrase ‘not necessarily malware unless installed without consent’ is the key qualification.

What to check in a small lab or enterprise

Begin with the internet edge. Find NAS, NVR and SAP instances in the named product families, verify their actual versions and patch or replacement options, and restrict management exposure. On potentially affected devices, review new SSH authorised keys, unfamiliar proxyware clients, unusual outbound connections and unexplained changes to service configuration. Preserve logs before resetting a box if investigation is needed.

On the identity side, investigate residential proxy flags as signals, not verdicts. Compare the sign-in to the expected user device, session, browser or User-Agent, MFA pattern and normal access history. A cluster of users suddenly appearing behind one residential proxy deserves higher priority, as in GreyNoise’s example, but requires corroboration before calling it malicious. Geographic familiarity alone cannot settle the question.

Why the Entra intrusion and the 143 devices must be kept separate

The opening incident in GreyNoise's report arose during a product demonstration. Analysts saw residential IPs in an organisation's Entra ID sign-in logs. At first, that observation supported several hypotheses: a legitimate user could be behind a residential proxy, an employee device could be sharing its connection knowingly or without its owner knowing, or an intruder could be routing authentication through that network. The proxy finding alone did not prove an intrusion. GreyNoise says the organisation then found multiple users authenticating from one of the same residential proxy IPs, investigated further and confirmed a serious intrusion. It has not published that case's victim identity, account count or intrusion detail.

The 143 compromised edge devices in 34 countries are from GreyNoise's separate research into a proxyjacking actor it calls skynox7. They are not a count of affected Entra users, not the victim population of the product-demonstration intrusion and not a measured total for all residential-proxy abuse. The two stories are connected by the analytical problem: an IP address with a residential geolocation can conceal a third party's activity. The public record does not tie the Entra intruder to skynox7.

A claim and denominator check for the two strands of GreyNoise's 15 October report.

Claim	Evidence in the report	Limit
Residential IPs appeared in Entra sign-in logs	Seen in an organisation's authentication data during a product demonstration	A proxy-labelled IP alone could accompany a legitimate sign-in
Serious intrusion was confirmed	GreyNoise says the organisation investigated after seeing multiple users from one proxy IP	No published account count, victim identity or full incident timeline
At least 143 edge devices compromised	GreyNoise's separate skynox7 proxyjacking investigation	No per-country or per-product distribution; no proven link to the Entra case
34 countries	Geographic breadth of the observed compromised-device set	Not 34 victim organisations or 34 operator locations

A residential IP is a clue, not an identity

A common sign-in rule treats a plausible home-country IP as reassuring and a distant cloud or VPN address as suspicious. Residential proxy markets weaken both assumptions. A remote operator can buy access to traffic exits that look like ordinary broadband, while a legitimate user can appear at a proxy-labelled IP if a household device shares bandwidth. Attribution cannot come from IP reputation or geolocation alone.

For a UK organisation reviewing Entra events, the useful unit is the session plus device plus account, not the IP alone. Ask whether the device identifier, browser or User-Agent, conditional-access result, MFA method, token history and normal work pattern agree. Multiple unrelated users suddenly appearing through one residential proxy IP warrants priority review, particularly where device characteristics or session histories diverge. It still requires corroboration: shared offices, managed gateways or approved security services can also aggregate legitimate users behind one exit.

A practical triage sequence; each row tests a hypothesis rather than assigning guilt from an IP address.

Question	Evidence to compare	What would change the assessment
Is the proxy exit expected?	Approved network services, user travel and sign-in history	Unexplained first use by several accounts
Do the sessions belong to known devices?	Device IDs, compliance, browser fingerprints and MFA registration	New or inconsistent device identity with privileged activity
Did the accounts act differently after sign-in?	Application access, token use, mailbox or cloud audit, lateral access	Anomalous actions that align in time with the proxy-routed sign-ins
Is the proxy node itself compromised?	Edge-device inventory, process and egress records, owner consent	Unauthorised proxyware or attacker SSH key on a managed device

GreyNoise lists Pawns.app binary hashes, an exploitation IP and a payout account in its report. The report itself cautions that the Pawns.app binaries are not inherently malware: consent and installation context determine whether this is authorised proxyware or proxyjacking. A hash match on a managed device is a reason to check who installed it, whose account receives payment and whether policy permits it. An IP indicator can age or be shared, so use it to seed a time-bounded hunt, not as a permanent assertion that every connection is malicious. GreyNoise also reports attacker SSH-key access on some victim devices, so removing the proxy client without checking for that second access path can leave compromise behind.

Source and method

This analysis is grounded in GreyNoise’s original 15 October report, read 16 October 2026. We preserve the distinction between its observed proxyjacking campaign, the separate login investigation, and general implications for residential-proxy detection.