cloudflared : le tunnel Cloudflare et la détection de son abus

cloudflared est le client open source de Cloudflare Tunnel : il expose un service local sur Internet via un tunnel sortant chiffré, sans ouvrir le moindre port entrant ni toucher au pare-feu. Pratique pour un développeur, redoutable entre de mauvaises mains : c'est un outil à double tranchant que des groupes d'attaquants détournent pour du command and control, de la persistance et de l'exfiltration. Ce guide montre l'usage légitime, les exploits réels menés avec cet outil, et surtout comment détecter son abus. Public : sysadmins et équipes sécurité (niveau intermédiaire à avancé).

Ce que vous allez apprendre

• Comprendre ce qu'est un tunnel Cloudflare et pourquoi il contourne le pare-feu par conception.
• Exposer un service local en 30 secondes (démonstration réelle).
• Reconnaître les attaques réelles menées avec cloudflared et pourquoi les attaquants l'adorent.
• Détecter l'abus : indicateurs réseau, processus et fichiers.
• Situer la technique dans le modèle de menaces (ATT&CK T1090 proxy, T1572 tunneling).

Qu'est-ce qu'un tunnel Cloudflare

Un tunnel Cloudflare inverse le sens habituel de la connexion. Au lieu d'ouvrir un port entrant sur votre pare-feu pour qu'Internet vienne à vous, le démon cloudflared ouvre une connexion sortante vers le réseau Cloudflare (l'edge), et le trafic public transite par ce tunnel jusqu'à votre service local.

L'intérêt défensif est réel : aucun port entrant à exposer, donc rien à scanner ni à brute-forcer sur votre IP publique. C'est la même philosophie que les mesh VPN comme Tailscale ou NetBird, ou qu'un proxy d'identité comme Pomerium : on supprime la surface exposée au lieu de la durcir.

Le revers : votre chemin d'accès dépend de Cloudflare (un tiers), et l'egress sortant, presque toujours autorisé, devient une voie royale. C'est précisément ce que les attaquants exploitent.

Démonstration : exposer un service en 30 secondes

Le mode le plus simple, le quick tunnel, ne demande ni compte, ni domaine. Installez d'abord le binaire de façon vérifiable (jamais un curl | sh) : téléchargez la release et contrôlez son empreinte SHA256 publiée par Cloudflare.

# Télécharger le binaire (Linux amd64) et vérifier son empreinte
curl -sL -o cloudflared \
  https://github.com/cloudflare/cloudflared/releases/download/2026.6.1/cloudflared-linux-amd64
sha256sum cloudflared
# La sortie doit correspondre au checksum de la release GitHub avant de l'exécuter
chmod +x cloudflared

Sur RHEL/Debian, préférez le dépôt signé de Cloudflare (pkg.cloudflare.com) pour bénéficier des mises à jour et de la vérification GPG.

Exposez ensuite un service local, ici un simple serveur web sur le port 8765 :

./cloudflared tunnel --url http://localhost:8765

En quelques secondes, cloudflared renvoie une URL publique aléatoire :

INF Requesting new quick Tunnel on trycloudflare.com...
INF |  https://administrators-garlic-misc-dip.trycloudflare.com  |
INF Registered tunnel connection connIndex=0 location=cdg08 protocol=quic

Votre localhost:8765 est désormais joignable depuis Internet, sans avoir ouvert un seul port ni modifié le pare-feu. C'est bluffant côté productivité, et c'est exactement ce qui en fait une arme.

Quick tunnel contre tunnel nommé

Le quick tunnel (--url) est éphémère, avec un sous-domaine jetable trycloudflare.com, sans compte : parfait pour tester, et pour un attaquant qui veut un canal jetable. Le tunnel nommé, lui, vise la production : il exige un compte Cloudflare et un domaine, se pilote depuis le tableau de bord Zero Trust, et se protège par une couche d'identité (Cloudflare Access, SSO). Un tunnel sans identité devant, c'est une porte ouverte à qui trouve l'URL.

L'outil à double tranchant : les attaques réelles

La même propriété qui vous protège, un tunnel sortant chiffré et de confiance, est un cadeau pour un attaquant déjà présent sur une machine. Plusieurs campagnes documentées l'ont industrialisé.

• Serpentine#Cloud (analysé par Securonix) : des chaînes de raccourcis .lnk et de scripts Python obfusqués livrent des charges injectées en mémoire en s'appuyant sur l'infrastructure Cloudflare Tunnel.
• Gamaredon (rapporté par Surefire Cyber) : ce groupe étatique a adopté les tunnels Cloudflare pour exécuter ses attaques.
• Livraison de RAT via TryCloudflare : des campagnes de phishing utilisent des sous-domaines trycloudflare.com jetables pour distribuer des chevaux de Troie d'accès distant (rapporté par The Hacker News).
• Accès persistant et exfiltration (analysé par GuidePoint Security) : les attaquants exposent SSH, RDP, SMB vers l'extérieur sans modifier les règles de pare-feu, et maintiennent un accès discret.

Pourquoi les attaquants l'adorent, en une liste :

• Le tunnel est sortant : il traverse le pare-feu, car l'egress est presque toujours autorisé. Aucune règle entrante à créer.
• Le trafic est chiffré et porte des certificats Cloudflare de confiance : il se fond dans le trafic légitime, invisible à la détection par signature.
• trycloudflare.com est gratuit, jetable et rarement bloqué ni surveillé par les organisations.
• Empreinte minimale : lancer un tunnel nommé ne demande qu'un token, si bien qu'aucune configuration n'est écrite sur le disque avant que le tunnel ne soit établi. Peu de traces pré-connexion.

Dans le langage MITRE ATT&CK, c'est du T1090 (proxy) et du T1572 (protocol tunneling), au service du command and control et de la persistance.

Installé ou non, l'attaquant peut l'apporter

Ne pas installer cloudflared ne vous protège pas : c'est un seul binaire Go qu'un attaquant dépose lui-même en post-exploitation. La vraie question n'est donc pas « faut-il l'installer ? » mais « saurais-je le voir tourner ? ». La défense se joue sur la détection, pas sur l'absence de l'outil.

Détecter l'abus

Puisque le contenu est chiffré et l'infrastructure de confiance, la détection est comportementale. Voici les indicateurs concrets, dont ceux capturés en lab sur un vrai tunnel.

Indicateurs réseau

Un tunnel cloudflared établit des connexions sortantes très reconnaissables :

• Résolutions et connexions vers *.argotunnel.com (par exemple region1.v2.argotunnel.com), *.trycloudflare.com, *.cftunnel.com.
• Protocole QUIC (UDP) en priorité, avec repli TCP/HTTP2, sur le port 7844 vers les plages IP de Cloudflare.
• Un poste ou un serveur interne qui parle directement à l'edge Cloudflare alors qu'il ne devrait pas est un signal fort.

# Repérer un processus qui tient des connexions vers l'edge tunnel
sudo ss -tunp | grep -Ei 'argotunnel|7844'

Indicateurs processus et fichiers

• Exécution d'un binaire cloudflared que vous n'avez pas déployé, surtout avec tunnel run, --url, ou un token en ligne de commande.
• Présence de ~/.cloudflared/ ou /etc/cloudflared/ : cert.pem, un fichier de credentials de tunnel, un config.yml. Un lancement par token seul en laisse peu, d'où l'importance des indicateurs réseau.

# Un cloudflared en cours d'exécution + ses artefacts éventuels
pgrep -a cloudflared
ls -la ~/.cloudflared /etc/cloudflared 2>/dev/null

Les parades qui tiennent

• Filtrage egress (liste d'autorisation de sortie) : casse le canal « sortant qui passe toujours ». Bloquez argotunnel.com et trycloudflare.com si vous ne les utilisez pas.
• Whitelisting applicatif : sur RHEL, fapolicyd empêche l'exécution d'un cloudflared non fiable déposé par un attaquant.
• Inventaire des tunnels autorisés : tout tunnel non déclaré est suspect.
• EDR comportemental + alerte sur l'exécution de cloudflared hors de vos déploiements.

Utiliser cloudflared sans se tirer une balle dans le pied

Si vous adoptez Cloudflare Tunnel de façon légitime, quelques réflexes évitent d'en faire une porte dérobée involontaire.

1. Tunnel nommé + identité : jamais un tunnel nu. Placez Cloudflare Access (ou un SSO) devant, pour qu'une URL trouvée ne suffise pas à entrer.

2. Moindre privilège : faites tourner le service cloudflared avec un compte non-root dédié, et gardez les secrets du tunnel (cert.pem, credentials) en permissions 0600.

3. Surveiller son propre outil : même légitime, journalisez son exécution et ses connexions ; un tunnel compromis ressemble à un tunnel sain.

4. Souveraineté : si dépendre de Cloudflare vous gêne, un mesh auto-hébergé comme NetBird ou Tailscale offre le même « zéro port entrant » sans tiers.

À retenir

1. cloudflared expose un service sans ouvrir de port : il supprime la surface d'attaque au lieu de la cacher, ce qui est une vraie bonne pratique.

2. C'est un outil à double tranchant : le même tunnel sortant chiffré est l'outil rêvé d'un attaquant pour le C2, la persistance et l'exfiltration.

3. Des campagnes réelles l'ont industrialisé (Serpentine#Cloud, Gamaredon, RAT via TryCloudflare) : c'est du T1090/T1572 côté ATT&CK.

4. L'installer ou non ne change pas le pire cas : un attaquant apporte son propre binaire. La défense, c'est la détection.

5. Détecter, c'est du comportemental : connexions vers *.argotunnel.com / *.trycloudflare.com (QUIC/UDP 7844), exécution inattendue de cloudflared, filtrage egress et whitelisting applicatif.

6. En usage légitime, mettez une identité devant, le moindre privilège, et surveillez votre propre tunnel.

Prochaines étapes

MITRE ATT&CK Le proxy (T1090) et le tunneling (T1572), le langage de la détection.

Command & Control Comment les attaquants pilotent une intrusion, dont par tunnel.

fapolicyd (whitelisting RHEL) Empêcher l'exécution d'un cloudflared non autorisé.

NetBird : mesh souverain Le zéro port entrant, sans dépendre d'un tiers.

×

📖 Voir la documentation →