Proxy

Proxy sits in the middle-to-late stage of an intrusion, after the attacker already has a working foothold and wants durable, harder-to-trace command and control. UNC5537's 2024 campaign against Snowflake customers shows the pattern cleanly: the group obtained valid credentials from infostealer logs, then authenticated to victim Snowflake instances almost exclusively through Mullvad and Private Internet Access, commercial VPN services that gave them a different, disposable exit IP for nearly every login. When they moved to exfiltration, they shifted to VPS infrastructure from providers like ALEXHOST, staging stolen data there before it went to MEGA or a buyer.

Nation-state actors use the internal and external proxy sub-techniques the same way at larger scale: Volt Typhoon and other China-nexus operators route through hijacked SOHO routers and VPS-based multi-hop chains specifically so the traffic a US network defender investigates traces back to a residential IP block, not to state infrastructure. On the internal side, ngrok and FRP tend to show up earlier, in ransomware and access-broker intrusions, as a fast way to expose RDP or SMB through a firewall the operator does not control credentials for. In both cases, proxy activity is the connective tissue between an initial foothold and whatever the attacker does next: further lateral movement, data staging, or, once destructive techniques run, ransomware detonation.

Corporate VPN clients, legitimate remote-support tunnels, and developers using ngrok to demo a local web app all generate traffic that looks identical at the network layer to a malicious tunnel. FRP and similar tunneling tools are also legitimately used by IT teams to expose internal services during vendor testing, and plenty of remote employees use commercial VPN services, including Mullvad and PIA, for entirely personal privacy reasons that have nothing to do with the corporate network.

The fix is context, not the tool name. An allow-list of the ngrok or FRP use your engineering team actually runs, tied to specific accounts and expected hours, turns the rest into signal; the same applies to VPN egress, where a small number of user workstations routing through a VPN client is normal and a server or service account doing the same is not. Weight the alert by what changed: a first-seen tunnel destination, a service account making a consumer VPN connection it has never made before, or a tunnel that immediately forwards RDP or SMB rather than a web port, separates real incidents from a developer's afternoon demo.

When a proxy alert fires, start with ownership: is there an engineering ticket, change record, or known IT project that explains this specific tunnel or VPN session on this specific host? If the process is ngrok or frp and nobody claims it, pull the full command line, since the authtoken and tcp/http flags on ngrok, or the frpc.ini path on FRP, tell you exactly what port is being exposed and to where. If the alert is a VPN or Tor egress, check whether the account or host has ever made that connection before and whether it correlates with anything else unusual: a new service, a spike in outbound data, or a login from a location the user has never worked from.

Escalate immediately when an unclaimed tunnel is forwarding RDP, SMB, or another lateral-movement port, or when a server or service account, not a person, is the one routing through Tor or a commercial VPN; neither has a routine business reason to do that. Contain by killing the tunnel process and blocking the relay domain or exit IP at the perimeter, then hunt for the same infrastructure across the fleet, since one exposed host rarely means only one. Preserve the host for IR rather than reimaging immediately: the local tunnel configuration, the ngrok config file or frpc.ini, usually names the exact external server the attacker is relaying through, which is often the fastest lead back to the rest of the intrusion.