Why Cloudflare Tunnel Is Attractive to Attackers

Cloudflare Tunnel (cloudflared) is a legitimate remote access tool that allows operators to expose internal services to the internet through Cloudflare’s infrastructure without opening inbound firewall ports. The tunnel is initiated outbound from inside the network, connects to Cloudflare edge nodes over HTTPS, and traffic flows through Cloudflare’s CDN.

From a defender’s perspective, this creates a detection problem. The tunnel client makes outbound HTTPS connections to Cloudflare IP addresses — the same infrastructure used by millions of legitimate websites. Traditional network controls that block by IP reputation or allow-list by domain see only *.cloudflare.com traffic. The malicious tunnel is indistinguishable at the network layer from any other Cloudflare-hosted site.

Threat actors have increasingly incorporated cloudflared into post-exploitation tooling as a way to establish persistent, bidirectional C2 channels that survive firewall rule changes and egress filtering. The technique requires no inbound firewall modifications, no dynamic DNS, and no attacker-controlled infrastructure that can be blocked by IP reputation feeds.

How the Attack Works

After initial access, an attacker drops or downloads the cloudflared binary (or uses a pre-installed version on developer machines) and runs:

cloudflared tunnel --url http://localhost:8080

This opens a bidirectional tunnel to a Cloudflare Quick Tunnel endpoint (*.trycloudflare.com), giving the attacker remote access to whatever is running on localhost:8080 — which may be a C2 listener, a web shell, or an interactive shell session. The attacker accesses it from outside via the assigned subdomain.

For persistence, attackers install cloudflared as a service:

cloudflared service install

This registers cloudflared as a Windows service or systemd unit, survivng reboots without further action.

Named tunnels using a config.yml with a Cloudflare account credential are used in more sophisticated campaigns, providing stable hostnames rather than ephemeral Quick Tunnel URLs.

Detection Layer 1: Process and Binary

The most reliable detection anchor is the process itself. cloudflared is not a standard component of most enterprise environments. Its presence on endpoints outside a documented list of DevOps or networking hosts is anomalous.

Sigma Rule — cloudflared process execution:

title: Cloudflare Tunnel Client Execution
id: a7d3f8c1-2e45-4b90-9c3d-1f2a3b4c5d6e
status: experimental
description: Detects execution of cloudflared binary, which may indicate C2 tunnel setup
logsource:
  category: process_creation
  product: windows
detection:
  selection_name:
    Image|endswith:
      - '\cloudflared.exe'
  selection_cmd:
    CommandLine|contains:
      - 'tunnel'
      - '--url'
      - 'trycloudflare.com'
  condition: selection_name or selection_cmd
falsepositives:
  - Legitimate DevOps use of Cloudflare Tunnel on approved developer machines
level: medium
tags:
  - attack.command_and_control
  - attack.t1572

Also hunt for cloudflared installed as a service:

title: Cloudflare Tunnel Service Installation
id: b8e4f9d2-3f56-5c01-0d4e-2g3b4c5d6e7f
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    CommandLine|contains: 'cloudflared service install'
  condition: selection
level: high
tags:
  - attack.persistence
  - attack.t1543.003

Detection Layer 2: Network

Network detection requires looking at TLS SNI or DNS queries rather than IP addresses, since Cloudflare’s IPs are shared across millions of domains.

DNS queries to watch:

  • *.trycloudflare.com — Quick Tunnel ephemeral subdomains; no legitimate enterprise use
  • api.cloudflare.com — Tunnel registration and management API calls

KQL for Microsoft Sentinel (DNS logs):

DnsEvents
| where QueryType == "A"
| where Name endswith ".trycloudflare.com"
| summarize count() by Name, Computer, ClientIP
| where count_ > 0

Quick Tunnel hostnames are machine-generated and completely random — any .trycloudflare.com query from an endpoint that is not a documented tunnel host should be investigated.

Network flow correlation: Look for sustained HTTPS connections from internal hosts to 198.41.192.0/24 or 198.41.200.0/24 (Cloudflare Argo Tunnel endpoint ranges) where the volume and duration are inconsistent with normal web browsing. Tunnel traffic is persistent and low-volume rather than bursty.

Detection Layer 3: File System and Registry

File drops: cloudflared is frequently downloaded rather than pre-installed. Look for new executables in temp directories, user profile folders, or dropped alongside other attacker tooling.

DeviceFileEvents
| where FileName =~ "cloudflared.exe" or FileName =~ "cloudflared"
| where FolderPath !startswith "C:\\Program Files"
| project Timestamp, DeviceName, FolderPath, FileName, InitiatingProcessCommandLine

Service creation: cloudflared service install creates a Windows registry key:

HKLM\SYSTEM\CurrentControlSet\Services\Cloudflared

Any unexpected service entry with cloudflared as the image path, or a service whose binary is in a non-standard path, is a high-confidence indicator.

Hunting Guidance

For proactive threat hunting, pull 30 days of process execution logs and identify any cloudflared invocations outside your documented allow-list. Cross-reference against service creation events to catch persistence mechanisms. Review DNS logs for .trycloudflare.com queries and correlate against the originating host’s recent process tree for lateral movement indicators.

Also search for renamed binaries. Attackers sometimes copy and rename cloudflared to masquerade as legitimate processes. Hunt by PE import hash or file hash against known cloudflared versions rather than by filename alone.

Response Considerations

When cloudflared C2 is confirmed:

  1. Preserve the tunnel config. The config.yml or command-line arguments identify the Cloudflare account used and the target endpoint — both are useful for understanding attacker reach and scope.
  2. Kill the service and block the binary hash across the estate.
  3. Audit for persistence. Service installation means the tunnel survives reboot — check all persistence mechanisms, not just the tunnel binary.
  4. Review what the tunnel exposed. If the tunnel pointed to localhost:8080 and the host runs a web application, determine whether the attacker accessed that application and what data was reachable.
  5. Check for credential access. cloudflared named tunnels authenticate with a Cloudflare account credential stored in a JSON token file — look for exfiltration of .cloudflared/ config directories.