How do attackers use FRP?

How FRP supports attacker access paths

FRP gives attackers a practical way to bridge an exposed relay on the internet to a service that is sitting behind NAT, firewalls or restrictive inbound rules. That matters because the relay is not the goal on its own, it is the transport layer that lets an external operator reach internal ports as if they were locally available.

It is most effective when defenders focus only on inbound filtering and do not inspect unusual outbound sessions. The technique turns egress into the real control point, so service exposure can persist even when the target network looks closed from the outside.

Attackers usually pair this with Command and Control (C2) Guide style infrastructure, because the same relay can support operator access, service tunnelling and staged tooling without needing a public-facing implant on every target host.

What attackers gain from a reverse proxy relay

The immediate benefit is reachability. Once FRP is in place, attackers can expose SSH, RDP, databases, admin panels or custom services through a controlled tunnel and keep using them from outside the network boundary. That makes post-compromise access more reliable than ad hoc port forwarding or one-off reverse shells.

It also supports layering. A single relay can carry multiple channels, which lets the operator move between interactive command access, application access and file transfer without constantly re-establishing entry. In practice, this reduces friction for staging remote tooling and for reusing the same path across several internal assets.

That is why FRP fits neatly into the sort of infrastructure described in The State of NHI & AI Agent Breach Report 2026: once attackers control a foothold, they often look for a stable channel that can be reused for access, movement and follow-on abuse.

What defenders should look for when FRP is in use

Detection usually starts with the network path, not the binary name. Long-lived outbound connections to unfamiliar hosts, especially from servers that should not initiate remote access, are a strong signal. So are proxy processes running on systems that rarely need them, or tunnels that map internal services to unusual external endpoints.

Defenders should also look for the behaviour around the tunnel. If a host suddenly becomes reachable through an unexpected port, or if remote administration patterns appear on systems that are not meant to be externally managed, the tunnel may be enabling access rather than simply relaying traffic.

Because the technique is fundamentally about operator reachability, it overlaps with CISA cyber threat advisories guidance on egress control and with broader threat hunting for active adversary infrastructure.

Risk and Threat Considerations

FRP is attractive because it converts an internal service into something remotely usable without changing perimeter controls. That creates a control gap when security monitoring assumes inbound exposure is the main risk and overlooks outbound tunnels, relay services and shadow remote administration paths.

Failure mechanism: The attacker establishes an outbound relay from a compromised host, then uses the tunnel to access internal services, preserve interactive control and move between systems without exposing a public listener on the victim network.

Impact: This can hide command access, extend dwell time, bypass simple perimeter filtering and make exposed services look legitimate to defenders unless tunnel telemetry and host behaviour are actively reviewed.

Practitioner Guidance

What to prioritise: Treat any FRP-like relay on production servers as a potential access path, not a benign utility. Start with hosts that have no business need for inbound remote exposure, then verify whether the outbound destination, listening ports and service mappings are approved.

What to verify: Check whether the process is expected, whether the tunnel is persistent across reboots and whether the exposed service is already covered by a sanctioned remote-access method. If the answer to any of those is no, assume the tunnel deserves incident review until proven otherwise.

Practitioner takeaway: With FRP, the critical question is not whether traffic is encrypted or outbound, it is whether an unapproved relay has turned internal reachability into an attacker-controlled access channel.

Related resources from NHI Mgmt Group

• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?
• How do attackers turn stolen npm secrets into broader compromise?