Cloudflare Tunnel and trycloudflare abuse: Spot, block and allowlist tunnels with confidence

Cloudflare Tunnel lets any host publish a service to the internet with nothing but an outbound connection, and that same property makes the cloudflared connector and its account-less trycloudflare.com Quick Tunnels attractive to intruders who need command and control, remote access or a staging site that blends into ordinary Cloudflare traffic. Ransomware operators, espionage groups and commodity malware have all been documented using it. This guide explains how named tunnels and Quick Tunnels work at the network and host level, what legitimate use looks like, how to detect unsanctioned tunnels, how to allowlist the tunnels you do run, and how to respond when one is found. It is written for SOC analysts, detection engineers and network teams, and goes deeper on one service than the T1572 Protocol Tunnelling Defensive Guide and the Cloud Services Abuse for C2 Guide.

Key takeaways

• Quick Tunnels have no business on most corporate networks. Cloudflare describes them as for testing and development, needing no account, with a random trycloudflare.com hostname, so there is rarely a reason to allow them from production hosts.
• The connector is the signal, not the destination. cloudflared talks to Cloudflare's edge on port 7844 over QUIC or HTTP/2, which is distinctive; blocking Cloudflare IP ranges wholesale is neither practical nor necessary.
• Sanctioned tunnels need an allowlist with owners. If your organisation uses Cloudflare Tunnel, record which hosts run it, under which account and tunnel ID, and alert on everything else.
• Tunnel tokens are non-human credentials. Cloudflare's documentation says anyone with access to a remotely managed tunnel's token can run the tunnel, so the token must be vaulted, rotated and revoked like any secret.
• Response is host first. A tunnel is usually a symptom of hands-on access; contain the host, find how cloudflared arrived, and treat credentials on that host as exposed.

How Cloudflare Tunnel works

A tunnel is created by running the open source cloudflared connector on a host that can reach the service to be exposed. The connector makes outbound connections to Cloudflare's network, and Cloudflare routes inbound requests for a public hostname back down those connections. No inbound firewall port is opened, which is the design goal Cloudflare describes as a positive security model: block all ingress and allow only cloudflared egress.

Cloudflare's Quick Tunnel documentation lists the limits that make them a testing tool: no uptime guarantee, up to 200 in-flight requests per tunnel, no Server-Sent Events, and a URL that stops working when the process stops. The connector itself prints a disclaimer that account-less tunnels are subject to Cloudflare's terms of use and that Cloudflare may investigate their use, and points production users to named tunnels.

How attackers use tunnels

MITRE ATT&CK v20 records several documented cases, all mapping to Protocol Tunneling (T1572) and often Proxy (T1090):

• Ransomware operations: the CISA advisory on Medusa ransomware (AA25-071A) lists Cloudflared among the group's command and control tools, alongside Ligolo, describing it as used to expose applications, services or servers to the internet via Cloudflare Tunnel.
• Espionage: ATT&CK records that Gamaredon Group used the Cloudflare Tunnel client to proxy C2 traffic and used TryCloudflare to obtain C2 nodes.
• Hypervisor access: Scattered Spider installed tunnelling tools on VMware vCenter and attacker controlled VMs, including Chisel configured to communicate with trycloudflare subdomains, according to the ATT&CK entry citing CrowdStrike and CISA reporting.
• Malware infrastructure: ShrinkLocker uses a trycloudflare.com subdomain to hide the operator's real address and tunnel data sent from victim systems.

The common patterns are: a tunnel from inside the network to give persistent remote access without a VPN account (overlapping with Remote Access Tools, T1219, and External Remote Services, T1133); a Quick Tunnel on attacker infrastructure to host payloads or phishing pages on a trusted looking domain; and exfiltration over the tunnel (Exfiltration Over Web Service, T1567). This page deliberately does not describe how to set those up; the defensive point is that every one of them requires cloudflared or a compatible client to run somewhere, and requires DNS and network traffic you can see.

Network indicators

Two cautions. Cloudflare publishes these addresses so customers can allow them, so they can change: re-check the official list when you build rules. And a determined operator can fall back from QUIC to HTTP/2 or use other tunnel tools, so pair network rules with host detection.

Host indicators and detection logic

• Process creation: Sysmon Event ID 1 or EDR process events for cloudflared or cloudflared.exe, and for any binary whose metadata or hash matches cloudflared release builds even when renamed. Command lines with tunnel, --url (Quick Tunnel) or a long token string are worth triage.
• Service installation: on Windows the connector installs a service named Cloudflared with the description "Cloudflared agent" (from the cloudflared source), surfacing as System event 7045 and Security event 4697 where service auditing is on; on Linux, a cloudflared systemd unit.
• Network connection by process: Sysmon Event ID 3 (disabled by default, so enable it for this) or EDR network telemetry showing a process connecting to port 7844.
• DNS by process: Sysmon Event ID 22 ties a lookup of argotunnel.com or trycloudflare.com to the process that made it, which separates a browser visiting a page from a connector.
• Unexpected host types: cloudflared on a domain controller, hypervisor management appliance, database server or point of sale system is almost never sanctioned.
• Parent process and timing: cloudflared launched by a script host, a remote management tool or shortly after a new admin logon is a hands-on keyboard pattern.

Hunting by data source

Record each confirmed false positive as an inventory entry rather than a suppression, so the next unknown connector stands out. A first seen view (hosts contacting port 7844 or argotunnel.com for the first time in 30 days) is usually the most productive single hunt.

Triage questions

1. Is the host on the sanctioned tunnel list, and does the tunnel ID or token belong to your Cloudflare account?
2. Is it a Quick Tunnel (no token, api.trycloudflare.com) or a named tunnel tied to an unknown account?
3. Which local service is exposed: RDP, SSH, SMB, a web admin page, or a SOCKS proxy?
4. How did the binary arrive (download, RMM push, script), and which account ran it?

Allowlisting sanctioned tunnels

Blocking cloudflared everywhere is right for organisations that do not use Cloudflare Tunnel. Organisations that do use it need a narrower rule set:

Developers who need Quick Tunnels can be given an isolated network segment or a named tunnel in a development account. Small organisations without TLS inspection get most of the value from three things: block egress on 7844, block trycloudflare.com at DNS, and alert on cloudflared process creation. Large organisations should add per process DNS and network telemetry and a tunnel inventory reconciled against the Cloudflare account. See the Secure Web Gateway and Web Filtering Guide and the DNS Security Guide.

Where identity fits: tunnel tokens and accounts

• Tunnel tokens: a remotely managed tunnel only needs its token to run, and anyone holding the token can run it. Store tokens in a secrets manager, never in scripts or images, and scan repositories for them. See the Secrets Management Guide.
• Rotation: Cloudflare recommends rotating tunnel tokens at a regular cadence. With at least two replicas, refresh the token, reinstall half the replicas with the new token, wait for traffic to move, then do the other half.
• Compromised token: refresh the token, delete all existing connections for the tunnel through the API, then update every legitimate replica with the new token.
• Cloudflare account access: the people and API tokens that can create tunnels can publish internal services to the internet. Put them behind SSO and MFA and scope permissions to individual tunnels where possible.
• Credentials on the host: an unsanctioned tunnel usually means the host is controlled by someone else; rotate service account passwords, keys and tokens stored there.

Responding to an unsanctioned tunnel

1. Preserve evidence: capture the process tree, command line, binary hash, service or unit definition, and DNS and firewall logs for the host before stopping anything.
2. Contain: isolate the host with EDR or block its egress on 7844 and to trycloudflare.com; stopping only the process lets an operator restart it.
3. Scope: search all hosts for the same hash, service name and DNS pattern; tunnels are often deployed to more than one foothold.
4. Identify the exposed service: if RDP, SSH or a SOCKS proxy was published, review authentication logs on that host and anything it could reach.
5. Remove persistence: delete the service or unit, binary and configuration, and check for scheduled tasks or RMM jobs that would reinstall it.
6. Rotate credentials: accounts used on the host, plus any tunnel token if a sanctioned tunnel was hijacked.
7. Report abuse: report malicious tunnels to Cloudflare through its abuse process so the hostname can be taken down.
8. Close the gap: add the block and alert rules above and record the case as a detection test.

The Unauthorised Remote Monitoring and Management Tool Playbook covers the wider pattern of attacker installed remote access software.

Detection and measurement

• Hosts running cloudflared that are not in the tunnel inventory (target zero).
• Outbound 7844 flows from non-connector hosts per week, and time to triage each.
• Coverage: percentage of servers and workstations sending process, network and DNS telemetry that can attribute a connection to a process.
• Tunnel tokens with an owner and a rotation date inside policy.
• Results of a quarterly authorised test that runs a benign Quick Tunnel from a lab host and measures whether alerts fire.

Framework mapping

Common failure patterns

• Allowing all of Cloudflare: treating Cloudflare as one trusted destination means tunnel traffic is never inspected or questioned.
• Port 7844 open by default: permissive egress lets any process reach the tunnel edge; most organisations can deny it everywhere except connector hosts.
• Name based detection only: rules that match cloudflared.exe miss renamed binaries; use publisher, hash and behaviour.
• Shadow tunnels from engineering: developers publish internal services with Quick Tunnels for convenience, creating unmanaged internet exposure that looks identical to attacker use.
• Tokens in scripts: sanctioned tunnel tokens embedded in install scripts or images let anyone with the script run a connector into your account's tunnel.
• Killing the process and moving on: without scoping and credential rotation, the operator returns through the same foothold.

Practitioner checklist

• Decide whether Cloudflare Tunnel is sanctioned; if not, block it outright.
• Block api.trycloudflare.com at DNS and deny port 7844 except from inventoried connector hosts.
• Alert on cloudflared process creation, service installation and port 7844 connections by process.
• Enable Sysmon Event IDs 3 and 22 or equivalent EDR telemetry on servers.
• Keep a tunnel inventory with host, owner, account and tunnel ID, reconciled monthly.
• Vault tunnel tokens, rotate them on schedule, and know the compromised token procedure.
• Block cloudflared by publisher and hash on hosts that are not connectors.
• Run a benign Quick Tunnel test quarterly to prove detections fire.

Standards and references

• Cloudflare: Quick Tunnels (TryCloudflare)
• Cloudflare: Tunnel with firewall
• Cloudflare: Tunnel permissions
• Cloudflare: cloudflared source repository
• CISA: #StopRansomware: Medusa Ransomware (AA25-071A)
• MITRE ATT&CK: Protocol Tunneling
• Microsoft: Sysmon
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: T1572 Protocol Tunnelling Defensive Guide · Cloud Services Abuse for C2 Guide · RMM Tool Security Guide · Unauthorised Remote Monitoring and Management Tool Playbook · Secure Web Gateway and Web Filtering Guide