The SOCKS protocol has been around for a very long time, and it has been used as a proxy in many different ways. One of its more infamous capabilities is the ability to proxy arbitrary client traffic to arbitrary servers, effectively masking the true origin of a connection. This is why SOCKS is useful in anonymity systems such as Tor exit infrastructure, as well as why exposed SOCKS services can be targeted for abuse as open proxies.
There are a lot of SOCKS servers on the internet — a lot, a lot. In Censys, SOCKS ranks as the 15th-most-observed protocol, with 3,486,509 unique hosts advertising one or more SOCKS services at the time of writing.
But let’s not panic just yet. A host running a SOCKS service does not automatically mean it can be abused by anyone on the internet. In most cases, these services are protected by authentication or otherwise constrained in ways that make them inaccessible to arbitrary clients.
At a protocol level, SOCKS makes this distinction early on. During the initial handshake, a client advertises the authentication methods it supports, and the server selects one. If the server replies indicating that no authentication is required, the connection can proceed immediately. If it selects a different method, such as username and password, the client must authenticate before proxying can occur. This handshake allows us to quickly determine whether a SOCKS service requires authentication without proxying any traffic.
In fact, only 73,556 of those three million hosts expose SOCKS services that require no authentication. Even that number, however, overstates the exposure. An unauthenticated SOCKS service is not necessarily a functional open proxy; many are restricted by outbound controls that limit where traffic can actually go.
To separate theoretical exposure from actual abuse potential, we conducted a secondary validation scan. For each of the 73,556 unauthenticated SOCKS servers, we attempted to proxy a simple HTTP request to ipify.org, a service that returns the requester’s public IP address. This lets us test whether a random client could use the SOCKS server to reach the public internet and receive a response, and also confirm which IP address the proxy used when making that request.
Before getting into the results, it’s worth defining some terminology. When we refer to a SOCKS host, we mean the host and port on which the SOCKS service is running. When we refer to a transit IP, we mean the IP address observed by the ipify API when traffic was proxied through that SOCKS host.
Out of the 73,556 unauthenticated SOCKS services tested, only 968 successfully proxied traffic at all. These usable proxies mapped to 802 unique SOCKS hosts and 523 distinct transit IP addresses.
Among the services that functioned, proxy behavior varied. By proxying an HTTP request to ipify.org and comparing the returned address to the SOCKS listener, we found that 416 of the 968 usable proxies (43%) exited traffic directly from the SOCKS host itself, with the egress IP matching the host that accepted the connection. The remaining 552 proxies (56%) routed traffic through a different transit IP; while these services accepted unauthenticated connections, outbound traffic was forwarded through a separate upstream server rather than originating from the SOCKS server directly.
A Proxy Manager
One of the more interesting transit hosts we encountered was 156[.]254[.]39[.]226, located in Hong Kong and operating in AS139880 (OWGELS-AS-AP, OWGELS INTERNATIONAL). This single IP address appeared as the transit address for 232 distinct unauthenticated SOCKS hosts, meaning that traffic originating from hundreds of distinct SOCKS services ultimately exited to the public internet via this host.
The fact that so many otherwise unrelated SOCKS servers shared this host as a common transit point suggests some sort of aggregation layer rather than independent, stand-alone proxy deployments. Instead of each SOCKS host routing traffic directly to its destination, outbound connections were funneled through this shared infrastructure, spread across the following address ranges:
156[.]254.39.0/24
156[.]254.42.0/24
156[.]254.44.0/24
156[.]254.47.0/24
156[.]254.50.0/24
156[.]254.54.0/24
156[.]254.58.0/24
156[.]254.60.0/24The host appears to expose an administrative HTTP dashboard interface on port 9999. And while this interface looks heavily vibe-coded and written in Chinese, it appears to be fully functional and populated with live data. Enabling language translation provides a better view of the meaning behind the various UI elements:
Below these summary statistics is a table of real-time, per-connection data currently using this proxy network. This includes the source IP address, the number of outbound connections, total traffic transferred, and historical connection counts, along with cumulative byte totals and first/last-seen timestamps:
Within the “IP allocation” configuration tab, there is a section that appears to list additional proxy servers configured within the system. Note that these IP ranges line up closely with the networks we observed proxying traffic through this host:
On the same configuration page, there also appears to be a mapping between account identifiers and transit IP addresses. In the example below, the account name aa0a, listening on port 1111, is mapped to three separate transit IPs (with other similar account names along with an “admin” account)
What this service is ultimately used for, or who operates it, isn’t something we can say with certainty. What is clear, however, is that this is not a small-scale operation. The number of hosts involved, combined with the use of multiple contiguous address blocks, suggests a level of coordination and ongoing investment that goes well beyond a hobbyist setup.
International Proxy Traversal
Given how often we observed SOCKS proxies egressing traffic from IP addresses different from where the service itself was hosted, we next looked at cases where this behavior crossed national boundaries. Or to put it another way: were proxies located in one country routinely relaying traffic through infrastructure in another, and if so, which countries and networks were involved?
We identified 89 open SOCKS hosts that egressed traffic through infrastructure in a different country than the one where the proxy was hosted. Notably, China accounted for four of the top ten origin countries in these cross-country proxy paths:
There are several potential reasons why these cross-country proxies exist, and not all of them imply malicious intent. In some cases, operators rely on upstream providers where outbound traffic exits from a different geographic location than where the SOCKS service itself is hosted. Others may intentionally centralize egress through a smaller number of transit hosts to simplify traffic management.
In other scenarios, routing traffic through infrastructure in a different country can be a deliberate way to work around regional network restrictions. For example, some networks in the United States block traffic originating from China, while Chinese networks may restrict access to services outside the country (i.e. The Great Firewall). In this context, a SOCKS host in China that transits traffic through infrastructure in the United States can serve as a practical mechanism for getting around these restrictions.
We can zoom in further and examine proxies that originate outside of the United States but egress traffic through infrastructure in a different country, along with the networks those proxies transit.
For proxies originating in China, the SOCKS hosts themselves were observed in networks operated by Alibaba, ChinaNet, China Unicom, and CNIX. Their outbound traffic, however, exited through a diverse set of US-based providers, including BAGE, DigitalOcean, DMIT, MONETWORKS, Oracle, OVH, YISUCLOUD, and IT7NET.
IT7NET also appeared as a transit provider for a SOCKS server in Singapore, while M247 was the primary transit network for proxies hosted in WORLDSTREAM in the Netherlands. The majority of these observed transit nodes belonged to cloud hosting/co-location and commercial internet providers.
One notable exception stands out, though. A single proxy server hosted in Hong Kong (47[.]242[.]229[.]131) was observed routing traffic through ATT-INTERNET4 (45[.]27[.]211[.]21) in the United States, a network primarily associated with residential and small business connectivity rather than data center infrastructure. In other words, this represents a chained proxy setup in which a SOCKS server hosted in Alibaba’s Hong Kong region egressed traffic through what appears to be a U.S.-based residential network.
Malicious Intent(?)
While we know that these SOCKS proxies are unauthenticated and capable of forwarding traffic to arbitrary hosts on the internet, we do not know whether they have actually been used for malicious activity. To get a better sense of that, we ran a bulk analysis against GreyNoise covering both the SOCKS proxy hosts themselves and the transit IPs they routed traffic through.
Of the 802 open SOCKS proxy hosts we identified, GreyNoise had observed activity on 110, or about 13.7 percent. Among those, 63 percent were classified as malicious, 30 percent as unknown (meaning traffic was observed but not clearly benign or malicious), and the remaining 7 percent as suspicious.
We saw a similar pattern when looking at the transit infrastructure. Out of 502 distinct transit IPs, GreyNoise had data on 130, roughly 24 percent. Of those, 62 percent were classified as malicious, 30 percent as unknown, and 8 percent as suspicious.
When we combine both the SOCKS hosts and the transit IPs, we end up with 900 unique hosts. Across that combined set, GreyNoise saw traffic from 133 (14%) of them, flagged 81 as malicious, 42 as unknown, and 10 as suspicious (767 of the hosts (85%) were never seen by GreyNoise). The most common labels associated with these hosts are shown below:
What stands out here, and isn’t particularly surprising, is that most of the observed activity falls into the category of scanning and enumeration (with the exception of CVE-2025-30208). Once a proxy is exposed, it tends to attract automated tooling that looks for exactly this kind of access, and those hosts often end up distributed across various lists used by people engaged in less-than-above-board activity. This does not necessarily mean the proxy operators themselves are responsible, but it does show that exposed proxy infrastructure does not remain unnoticed for very long.
Outro
One of the goals of this post was to show that things are not always as they first appear. Just because a service advertises itself as unauthenticated does not necessarily mean it can actually be used as a proxy. If we looked only at the scan data, it would be easy to assume that there is a massive number of open proxies sitting on the internet. It’s only after following up with actual proxy requests that a more accurate picture emerges, and in practice, the situation is far more limited than it initially appears.
That said, some of the proxies that do work have not gone unnoticed. GreyNoise data suggests that portions of this infrastructure have already been discovered and used by others on the internet, while many of the hosts have never been observed engaging in malicious activity.
