Unmasking Proxy Infrastructure: How to Detect IOX, FRP, Rakshasa Proxies with Hunt.io
Published on
Published on
Published on
May 8, 2025
May 8, 2025
May 8, 2025



Red team and malicious cyber actors often rely on proxy tools to relay traffic through intermediary servers that help them bypass perimeter controls, obscure origin infrastructure, and blend in with legitimate network activity. Open-source proxies like IOX, FRP, and Rakshasa are frequently used for these purposes, offering lightweight tunneling and remote access capabilities that can be deployed across a range of environments.
These tools are valued for their operational flexibility, not because they are novel, but because they work. When deployed with few modifications, they tend to exhibit repeatable behaviors: standard ports, generic TLS certificates, and recognizable file structures.
In some cases, these proxies appear in open directories alongside malware, staging scripts, or credential harvesting tools, offering insight into infrastructure setup and intent.
This post demonstrates how to identify these deployments using Hunt.io by leveraging observable traits across TLS, HTTP, and file-based artifacts, enabling defenders to surface proxy infrastructure before it's operationalized.
How Proxies Fit into the Attacker Playbook
Adversaries regularly rely on intermediate infrastructure to obscure their presence. From compromised edge devices repurposed as relay nodes to leased VPS systems configured for traffic forwarding, these setups serve a similar role to proxy tools, enabling operators to evade detection, maintain persistence, and complicate attribution.
Many of the open-source proxies examined in this post reflect that same utility, offering lightweight, modular options for redirecting traffic across attacker-controlled paths.
Proxy Tools in the Wild: Uncovering Suspicious Infrastructure with Hunt.io
IOX
IOX is an open-source proxy tool written in Go. It supports TCP and UDP forwarding, SOCKS5 tunneling, and optional encryption using pre-shared keys. When deployed, it enables traffic to move between two systems without revealing the true origin or destination, making it effective for relaying data across segmented networks or routing connections through attacker-controlled infrastructure.
The tool has been linked to multiple real-world intrusions. In 2022, Sygnia reported that Emperor Dragonfly (Bronze Starlight) deployed a modified version of IOX alongside Cobalt Strike and a keylogger. Separately, Securonix documented IOX being used by Slow Tempest on compromised Windows hosts to maintain outbound connectivity and exfiltrate sensitive data.
Hunting IOX Deployments in AttackCapture
AttackCapture™, Hunt.io's attacker-focused dataset, provides a living repository of open directories exposed on the internet, indexed and categorized to expose attacker tooling, staging logic, and TTPs. AttackCapture surfaces reconnaissance tools, compiled payloads, and operational artifacts that illustrate how operators prepare, sequence, and deploy their tooling across infrastructure.
IOX binaries can be identified through simple filename-based queries using /iox, without requiring a specific file extension. This method returns both Linux and Windows variants, many of which are staged alongside related artifacts. Defenders can pivot on directory contents, retrieve SHA-256 hashes, and inspect adjacent tooling to confirm malicious use or infrastructure staging.
Across multiple open directories, IOX appeared alongside tooling frequently associated with post-compromise activity. These included shell scripts, Linux ELF binaries, and known malware families such as Gh0stRAT, PowerCat, Havoc, and Viper. The presence of IOX in these environments suggests it was being staged for lateral movement, outbound access, or to support operator-controlled traffic redirection.
Rakshasa: Certificate-Based Infrastructure Fingerprinting
Rakshasa is a multi-level proxy and tunneling tool written in Go, designed to forward TCP traffic between internal and external systems through chained nodes. It supports SOCKS5 and HTTP proxying, TLS-encrypted communication using embedded certificates, and optional AES encryption with user-defined keys.
The program distinguishes between two roles:
node
(limited functionality) and
fullnode
(which supports remote shell access, multi-hop proxying, and interactive control).
Trend Micro has reported on the use of Rakshasa by Earth Baku, an APT group that leveraged the tool to maintain access and move laterally within compromised internal networks.
Pivoting on Default Certificates in HuntSQL
A review of the source code for Rakshasa reveals that the tool uses a hardcoded TLS certificate when built using the default configuration. The embedded certificate fields are as follows:
Common Name: chinamobile[.]com
Organization: Company, INC.
Country: US
Locality: San Francisco
Expiration: April 3, 2388
Using these static fields alongside the JA4X fingerprint, we came up with a query in HuntSQL to identify servers returning this certificate within the past 30 days:
SELECT ip, port
FROM certificates
WHERE ja4x.full == '4f24da86fad6_4f24da86fad6_bb943afcc34f'
AND subject.common_name == 'chinamobile.com'
AND subject.organization == 'Company, INC.'
AND subject.country == 'US'
AND timestamp > NOW - 30 DAY
GROUP BY ip, port
The HuntSQL results returned IP:port combinations most frequently exposing services on 8883, 443, 8443, and 8081. While 8883 appears to be Rakshasa's default port when launched without parameters, the tool supports user-defined ports and is often deployed across standard TLS or proxy service ports to reduce scrutiny.
Infrastructure presenting this certificate also exhibited consistent behavioral traits:
TLS handshake attempts are accepted just long enough to present the certificate, then reset, allowing metadata extraction but limiting further analysis.
Use of the explicit cipher suite
ECDHE-RSA-AES128-GCM-SHA256
, overriding Go's defaults
When probing the HTTP proxy component, some servers responded with:
HTTP/1.0 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Access to internal site"
Content-Length: 0
When combined with Rakshasa's static certificate fields, the observed TLS and HTTP behaviors provide defenders with a strong basis for identifying likely deployments. The limited number of matching servers adds weight to the findings, though these indicators should be corroborated with additional evidence before being used in detection or response workflows.
FRP: Surfacing Proxy Infrastructure Through HTTP Fingerprints and Open Directories
Fast Reverse Proxy (FRP) is a cross-platform tunneling tool commonly used to expose internal services behind NAT or firewall boundaries. It supports TCP, UDP, HTTP, and HTTPS protocols, enabling flexible access to services over the internet through a client-server model. The tool uses two binaries-frpc (client) and frps (server)-configured through simple .ini files and frequently deployed with minimal customization.
FRP has been observed in multiple targeted operations. Cybereason reported that the Iranian APT group Phosphorus deployed the proxy tool after exploiting vulnerable Microsoft Exchange servers. More recently, Cisco Talos documented the use of FRP by UAT-5918 to establish persistent tunnels from compromised endpoints to attacker-controlled infrastructure.
Hunting FRP with Hunt.io
When an FRP server is accessed directly without a valid path, it responds with a default 404 Not Found page. We can use this to our advantage to identify deployments across the internet through HTTP body hash matching in HuntSQL™.
We'll use the following simple query to uncover likely Fast Reverse Proxy infrastructure:
SELECT ip, port
FROM http
WHERE http.body_hash == '967E369D3BE4FAB5EB1229EC015B2923ABF6BC81EBE3AAA662CB095CBEC81023'
GROUP BY ip, port
While the response body hash provides a reliable signal, the volume of results, over 23,000, makes it difficult to validate at scale. To narrow down the signal, we pivoted to AttackCapture's Code Search.
FRP configuration files typically include predictable syntax, such as logging parameters and authentication tokens. By reviewing the open-source repository and inspecting live file structures, we searched for config files containing both
/frpc.log
and the string
token = 12345678
, which appears in many default test setups.
Filtering with Code Search: Config Files and Tool Clusters
In AttackCapture, we used the following query:
"/frpc.log" AND "token = 12345678"
This returned a more manageable set of directories containing frpc_full.ini files and associated configuration data.
Proxy tools like IOX, FRP, and Rakshasa often go unreported in threat feeds, but their consistent use across intrusion sets makes them a valuable signal for defenders. Monitoring for these tools helps surface attacker-controlled infrastructure used in staging, tunneling, or lateral movement, often before more obvious indicators appear.
When observed alongside credential harvesters, remote shells, or frameworks like Cobalt Strike, they can reveal broader operational patterns and support infrastructure-level attribution.
Final thoughts
The use of proxies to obscure malicious activity is well-established, but the accessibility of open-source tooling like IOX, FRP, and Rakshasa has lowered the barrier to entry for staging infrastructure that blends easily with legitimate traffic. These tools are often deployed ahead of more recognizable activity, serving as enablers for lateral movement, remote access, and persistent communication.
For defenders, tracking the deployment patterns and behaviors of proxy tools offers a practical path to identifying attacker-controlled infrastructure in its staging phase, before malware is deployed or beaconing begins.
Red team and malicious cyber actors often rely on proxy tools to relay traffic through intermediary servers that help them bypass perimeter controls, obscure origin infrastructure, and blend in with legitimate network activity. Open-source proxies like IOX, FRP, and Rakshasa are frequently used for these purposes, offering lightweight tunneling and remote access capabilities that can be deployed across a range of environments.
These tools are valued for their operational flexibility, not because they are novel, but because they work. When deployed with few modifications, they tend to exhibit repeatable behaviors: standard ports, generic TLS certificates, and recognizable file structures.
In some cases, these proxies appear in open directories alongside malware, staging scripts, or credential harvesting tools, offering insight into infrastructure setup and intent.
This post demonstrates how to identify these deployments using Hunt.io by leveraging observable traits across TLS, HTTP, and file-based artifacts, enabling defenders to surface proxy infrastructure before it's operationalized.
How Proxies Fit into the Attacker Playbook
Adversaries regularly rely on intermediate infrastructure to obscure their presence. From compromised edge devices repurposed as relay nodes to leased VPS systems configured for traffic forwarding, these setups serve a similar role to proxy tools, enabling operators to evade detection, maintain persistence, and complicate attribution.
Many of the open-source proxies examined in this post reflect that same utility, offering lightweight, modular options for redirecting traffic across attacker-controlled paths.
Proxy Tools in the Wild: Uncovering Suspicious Infrastructure with Hunt.io
IOX
IOX is an open-source proxy tool written in Go. It supports TCP and UDP forwarding, SOCKS5 tunneling, and optional encryption using pre-shared keys. When deployed, it enables traffic to move between two systems without revealing the true origin or destination, making it effective for relaying data across segmented networks or routing connections through attacker-controlled infrastructure.
The tool has been linked to multiple real-world intrusions. In 2022, Sygnia reported that Emperor Dragonfly (Bronze Starlight) deployed a modified version of IOX alongside Cobalt Strike and a keylogger. Separately, Securonix documented IOX being used by Slow Tempest on compromised Windows hosts to maintain outbound connectivity and exfiltrate sensitive data.
Hunting IOX Deployments in AttackCapture
AttackCapture™, Hunt.io's attacker-focused dataset, provides a living repository of open directories exposed on the internet, indexed and categorized to expose attacker tooling, staging logic, and TTPs. AttackCapture surfaces reconnaissance tools, compiled payloads, and operational artifacts that illustrate how operators prepare, sequence, and deploy their tooling across infrastructure.
IOX binaries can be identified through simple filename-based queries using /iox, without requiring a specific file extension. This method returns both Linux and Windows variants, many of which are staged alongside related artifacts. Defenders can pivot on directory contents, retrieve SHA-256 hashes, and inspect adjacent tooling to confirm malicious use or infrastructure staging.
Across multiple open directories, IOX appeared alongside tooling frequently associated with post-compromise activity. These included shell scripts, Linux ELF binaries, and known malware families such as Gh0stRAT, PowerCat, Havoc, and Viper. The presence of IOX in these environments suggests it was being staged for lateral movement, outbound access, or to support operator-controlled traffic redirection.
Rakshasa: Certificate-Based Infrastructure Fingerprinting
Rakshasa is a multi-level proxy and tunneling tool written in Go, designed to forward TCP traffic between internal and external systems through chained nodes. It supports SOCKS5 and HTTP proxying, TLS-encrypted communication using embedded certificates, and optional AES encryption with user-defined keys.
The program distinguishes between two roles:
node
(limited functionality) and
fullnode
(which supports remote shell access, multi-hop proxying, and interactive control).
Trend Micro has reported on the use of Rakshasa by Earth Baku, an APT group that leveraged the tool to maintain access and move laterally within compromised internal networks.
Pivoting on Default Certificates in HuntSQL
A review of the source code for Rakshasa reveals that the tool uses a hardcoded TLS certificate when built using the default configuration. The embedded certificate fields are as follows:
Common Name: chinamobile[.]com
Organization: Company, INC.
Country: US
Locality: San Francisco
Expiration: April 3, 2388
Using these static fields alongside the JA4X fingerprint, we came up with a query in HuntSQL to identify servers returning this certificate within the past 30 days:
SELECT ip, port
FROM certificates
WHERE ja4x.full == '4f24da86fad6_4f24da86fad6_bb943afcc34f'
AND subject.common_name == 'chinamobile.com'
AND subject.organization == 'Company, INC.'
AND subject.country == 'US'
AND timestamp > NOW - 30 DAY
GROUP BY ip, port
The HuntSQL results returned IP:port combinations most frequently exposing services on 8883, 443, 8443, and 8081. While 8883 appears to be Rakshasa's default port when launched without parameters, the tool supports user-defined ports and is often deployed across standard TLS or proxy service ports to reduce scrutiny.
Infrastructure presenting this certificate also exhibited consistent behavioral traits:
TLS handshake attempts are accepted just long enough to present the certificate, then reset, allowing metadata extraction but limiting further analysis.
Use of the explicit cipher suite
ECDHE-RSA-AES128-GCM-SHA256
, overriding Go's defaults
When probing the HTTP proxy component, some servers responded with:
HTTP/1.0 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Access to internal site"
Content-Length: 0
When combined with Rakshasa's static certificate fields, the observed TLS and HTTP behaviors provide defenders with a strong basis for identifying likely deployments. The limited number of matching servers adds weight to the findings, though these indicators should be corroborated with additional evidence before being used in detection or response workflows.
FRP: Surfacing Proxy Infrastructure Through HTTP Fingerprints and Open Directories
Fast Reverse Proxy (FRP) is a cross-platform tunneling tool commonly used to expose internal services behind NAT or firewall boundaries. It supports TCP, UDP, HTTP, and HTTPS protocols, enabling flexible access to services over the internet through a client-server model. The tool uses two binaries-frpc (client) and frps (server)-configured through simple .ini files and frequently deployed with minimal customization.
FRP has been observed in multiple targeted operations. Cybereason reported that the Iranian APT group Phosphorus deployed the proxy tool after exploiting vulnerable Microsoft Exchange servers. More recently, Cisco Talos documented the use of FRP by UAT-5918 to establish persistent tunnels from compromised endpoints to attacker-controlled infrastructure.
Hunting FRP with Hunt.io
When an FRP server is accessed directly without a valid path, it responds with a default 404 Not Found page. We can use this to our advantage to identify deployments across the internet through HTTP body hash matching in HuntSQL™.
We'll use the following simple query to uncover likely Fast Reverse Proxy infrastructure:
SELECT ip, port
FROM http
WHERE http.body_hash == '967E369D3BE4FAB5EB1229EC015B2923ABF6BC81EBE3AAA662CB095CBEC81023'
GROUP BY ip, port
While the response body hash provides a reliable signal, the volume of results, over 23,000, makes it difficult to validate at scale. To narrow down the signal, we pivoted to AttackCapture's Code Search.
FRP configuration files typically include predictable syntax, such as logging parameters and authentication tokens. By reviewing the open-source repository and inspecting live file structures, we searched for config files containing both
/frpc.log
and the string
token = 12345678
, which appears in many default test setups.
Filtering with Code Search: Config Files and Tool Clusters
In AttackCapture, we used the following query:
"/frpc.log" AND "token = 12345678"
This returned a more manageable set of directories containing frpc_full.ini files and associated configuration data.
Proxy tools like IOX, FRP, and Rakshasa often go unreported in threat feeds, but their consistent use across intrusion sets makes them a valuable signal for defenders. Monitoring for these tools helps surface attacker-controlled infrastructure used in staging, tunneling, or lateral movement, often before more obvious indicators appear.
When observed alongside credential harvesters, remote shells, or frameworks like Cobalt Strike, they can reveal broader operational patterns and support infrastructure-level attribution.
Final thoughts
The use of proxies to obscure malicious activity is well-established, but the accessibility of open-source tooling like IOX, FRP, and Rakshasa has lowered the barrier to entry for staging infrastructure that blends easily with legitimate traffic. These tools are often deployed ahead of more recognizable activity, serving as enablers for lateral movement, remote access, and persistent communication.
For defenders, tracking the deployment patterns and behaviors of proxy tools offers a practical path to identifying attacker-controlled infrastructure in its staging phase, before malware is deployed or beaconing begins.
Related Posts:

We originally launched our "Open Directory" feature in Hunt a year ago. The premise behind it was to get into the mind of the attacker by get a backstage view into their attacks. What we learned was that there was a ton of information that could be correlated and indexed. Today, we're reaffirming our commitment to getting into the tooling of attackers by launching AttackCapture™ by Hunt.io.

We originally launched our "Open Directory" feature in Hunt a year ago. The premise behind it was to get into the mind of the attacker by get a backstage view into their attacks. What we learned was that there was a ton of information that could be correlated and indexed. Today, we're reaffirming our commitment to getting into the tooling of attackers by launching AttackCapture™ by Hunt.io.

Uncovering Threat Actor Tactics: How Open Directories Provide Insight into XWorm Delivery Strategies
Learn how threat actors leverage open directories to deliver XWorm malware disguised as popular software, providing insight into their tactics.

Uncovering Threat Actor Tactics: How Open Directories Provide Insight into XWorm Delivery Strategies
Learn how threat actors leverage open directories to deliver XWorm malware disguised as popular software, providing insight into their tactics.

We originally launched our "Open Directory" feature in Hunt a year ago. The premise behind it was to get into the mind of the attacker by get a backstage view into their attacks. What we learned was that there was a ton of information that could be correlated and indexed. Today, we're reaffirming our commitment to getting into the tooling of attackers by launching AttackCapture™ by Hunt.io.

Uncovering Threat Actor Tactics: How Open Directories Provide Insight into XWorm Delivery Strategies
Learn how threat actors leverage open directories to deliver XWorm malware disguised as popular software, providing insight into their tactics.
Products
Hunt Intelligence, Inc.
Products
Hunt Intelligence, Inc.
Products
Hunt Intelligence, Inc.