Attackers abuse Cloudflare Tunnel to publish a private service without opening inbound firewall ports. They can host phishing pages, proxy traffic to malware, or maintain access to internal systems while blending in with normal outbound web traffic. Defenders should review outbound tunnel creation, identity controls for tunnel administration, and any external hostname that unexpectedly maps to internal assets.
How Cloudflare Tunnel abuse works in practice
Attackers use Cloudflare Tunnel to turn an outbound-only connection into a public-facing entry point. That lets them expose a private service without opening inbound firewall ports, proxy traffic through infrastructure that looks ordinary, and keep a stable path to a target while external observers see only legitimate outbound web traffic.
The abuse pattern is simple but effective: the tunnel creates a trusted-looking transport layer, then the attacker layers a phishing page, malware relay, or remote access bridge on top. Because the connection originates from inside the environment, perimeter controls that focus only on inbound exposure often miss the activity.
cloudflare tunnel abuse also fits into a broader command-and-control pattern. The tunnel can function as a low-friction egress channel, a redirector, or a persistence mechanism, so the security question is not just “is Cloudflare in use?” but “what is this tunnel publishing, who created it, and what asset does it now expose?”
Why defenders treat it as an exposure and not just a networking choice
The main risk is that the tunnel collapses the distinction between an internal service and an externally reachable one. If an attacker can create or modify the tunnel, they can place a fake login page in front of users, route traffic to a malware endpoint, or reach internal tooling through an approved outbound path. Command and Control (C2) Guide is useful here because the same outbound, beacon-like patterns that support C2 can also hide tunnel-based access.
Failure mechanism: The tunnel relies on a legitimate outbound session and trusted administration workflow, so the attacker does not need to defeat perimeter ingress controls. If tunnel creation, hostname assignment, or admin access is weakly governed, the tunnel becomes a durable exposure path rather than a temporary connectivity feature.
Impact: Defenders can lose visibility into what external hostname now maps to which internal asset, while users and security tools may treat the traffic as normal cloud-hosted access. That creates room for phishing, relay, credential capture, and repeated re-entry without obvious network alarms.
What to verify before you assume a tunnel is benign
Start by identifying who can create, edit, and delete tunnels, then compare that to your expected administrator set. Review tunnel inventory for unexpected hostnames, recently created connectors, unusual destination services, and tunnels that publish internal applications without an obvious business owner. When the abuse is part of a wider intrusion, the tunnel may be one persistence layer among several, so pair the check with endpoint and identity review. Cloudflare Thanksgiving breach 2023 is a useful reminder that service tokens and service accounts can become durable access paths when they are not rotated or governed tightly.
Then validate whether the tunnel is tied to a sanctioned service lifecycle. A legitimate tunnel usually has an owner, change record, and clear purpose. An attacker-created tunnel often has one of three signs: it appeared without a normal approval path, it points to an internal asset that should never be public, or it remains active long after the activity that created it should have ended.
Do not stop at the tunnel record itself. Check whether the tunnel has been used to expose authentication pages, admin consoles, or remote access tools, and whether those systems have evidence of session theft, credential submission, or unusual source geographies. Okta support system breach 2023 shows why session material and admin credentials matter when an attacker can place themselves between users and the service they trust.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1090 — Proxy | Cloudflare Tunnel abuse is a proxying and traffic-relay pattern. |
| Recommendation — Map tunnel traffic to T1090 and hunt for proxy-based persistence or relay activity. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Tunnel administration depends on strong user authentication and admin access control. |
| AU-2 — Event Logging | Tunnel creation and hostname mapping need auditability for detection and review. | |
| AC-6 — Least Privilege | Overbroad tunnel admin rights let attackers expose internal services through approved channels. | |
| Recommendation — Enforce IA-2 for tunnel administrators and restrict who can publish external hostnames. Log tunnel creation, modification, and deletion events for review in your SIEM. Limit tunnel administration to the minimum set of identities required. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust principles | Outbound tunnels should not be treated as trusted simply because they originate internally. |
| Recommendation — Apply zero-trust verification to tunnel-originated access paths before trusting them. | ||
Practitioner Guidance
What to prioritise: Treat tunnel administration as a privileged control point, not a convenience feature. The first question is whether the organisation can prove who created the tunnel, why it exists, and which internal asset it exposes. If those answers are unclear, the tunnel deserves immediate review even if no inbound firewall change occurred.
What to verify: Confirm that tunnel creation is tied to strong identity controls, that hostnames are mapped only to approved services, and that tunnel changes are visible in your logging and alerting stack. If the tunnel can be created from a user context that is also used for normal cloud administration, separate that privilege path or constrain it tightly.
Common mistake: Teams often focus on the tunnel software and miss the administrative identity behind it. The more important control question is whether an attacker could obtain or abuse the rights needed to create a tunnel, publish a hostname, and keep the path alive long enough to persist.
Practitioner takeaway: The defensive value comes from governing the tunnel lifecycle and the admin identity behind it, because an externally reachable hostname is only the symptom, not the control failure.