NIS2 50+ salariés ou €10M+ CA : reporting d’incident en 72h obligatoire. Reporting d’incident en 72h obligatoire. Êtes-vous prêt ? →
Skip to main contentSkip to footer

C2 SaaS : quand Slack, Dropbox et GitHub deviennent des canaux d’attaque

Le C2 SaaS n’est plus une curiosité de threat researcher : c’est le mode opératoire qui ressort du dernier rapport DFIR sur la chaîne d’attaque EtherRat/TukTuk, terminée par le ransomware The Gentleman. Pour les PME-ETI, l’enjeu est simple : si votre détection s’arrête à « trafic sortant vers IP suspectes », vous laissez passer des attaquants qui parlent désormais Slack, Dropbox et GitHub Issues comme langue maternelle de commande et contrôle.

Pourquoi le C2 SaaS change la donne en PME-ETI

Historiquement, un canal de command-and-control (C2) reposait sur un domaine attaquant, une IP fixe ou un serveur compromis. Le défenseur PME-ETI s’appuyait sur des indicateurs de compromission classiques : réputation IP, GeoIP exotique, certificat auto-signé, ASN suspect. Tout cela est en train de tomber. Le rapport DFIR publié cette semaine décrit le framework TukTuk, qui multiplexe son trafic C2 sur des plateformes parfaitement légitimes : ClickHouse Cloud, Supabase, Ably, Dropbox, GitHub Issues, Slack, Arweave. À côté, EtherRat utilise EtherHiding — du C2 niché dans des smart contracts Ethereum lus depuis l’endpoint. Et l’exfiltration finale passe par Rclone vers Wasabi, un object storage indistinguable d’un usage métier.

Pour une PME-ETI, c’est une rupture. Bloquer Slack, GitHub ou Dropbox au périmètre n’est pas une option : ce sont des outils de production. Et la signature réseau classique ne fonctionne plus, parce que le canal de C2 est aussi celui qu’utilise votre équipe DevOps tous les jours.

Anatomie d’une intrusion C2 SaaS : du MSI à la rançon

La chaîne d’attaque décrite par le rapport DFIR est représentative de ce qui attend la majorité des entreprises non préparées :

  • Vecteur initial : MSI malveillant déguisé en RAMMap (Sysinternals), distribué via malvertising et faux portails de téléchargement.
  • Persistance et latéralisation : déploiement de GoTo Resolve (RMM légitime), création de tunnels TryCloudflare, abus de tâches planifiées.
  • Commande et contrôle : EtherRat lit ses instructions dans une chaîne Ethereum (EtherHiding), TukTuk module et multiplexe ses retours via SaaS publics.
  • Exfiltration : Rclone vers un bucket Wasabi attaquant, débit lent et fragmenté pour rester sous le seuil d’alerte DLP.
  • Détonation finale : ransomware The Gentleman, déploiement domain-wide via GPO ou outil d’administration compromis.

Le temps moyen entre intrusion initiale et chiffrement reste sous la barre des 72 heures sur ce type de campagne — et un défenseur PME-ETI qui n’inspecte que les IP n’a aucune chance de détecter quoi que ce soit.

Repenser la détection face au C2 SaaS : quatre leviers PME-ETI

1. Passer de la réputation IP au comportement applicatif

La question n’est plus « cette IP est-elle malveillante ? » mais « ce poste a-t-il un usage légitime de Slack/Dropbox/GitHub ? ». Un poste comptabilité qui se met à appeler l’API GitHub Issues à 3h du matin n’a rien à y faire — c’est anomalie comportementale, pas réputation. Cela suppose une baseline par poste et par rôle, alimentée par EDR et proxy d’inspection TLS.

2. Inspecter le TLS sur les flux SaaS sensibles

Sans inspection TLS, le C2 SaaS est invisible. Un pare-feu next-gen ou un proxy CASB capable de déchiffrer (avec exception légale documentée) les flux vers les SaaS à fort potentiel d’abus — Slack, Dropbox, GitHub, Telegram, Discord, Pastebin — est désormais une exigence de base. C’est aussi un sujet RGPD à arbitrer avec votre DPO : l’inspection doit être encadrée, traçable, et limitée aux flux pertinents.

3. Surveiller les RMM et les binaires de tunneling

GoTo Resolve, AnyDesk, ScreenConnect, TeamViewer, cloudflared, ngrok : ces outils sont massivement détournés. Une PME-ETI doit maintenir une liste blanche d’outils RMM autorisés et générer une alerte sur l’exécution de tout binaire de RMM hors liste. Même chose pour les tunnels — TryCloudflare a été utilisé dans cette campagne précisément parce qu’il ne nécessite pas de compte attaquant.

4. Détecter Rclone et l’exfiltration vers object storage

Rclone est devenu l’outil d’exfiltration favori parce qu’il parle nativement S3, Azure Blob, Backblaze, Wasabi, Dropbox, Google Drive. Une règle EDR sur l’exécution de rclone.exe avec configuration cloud — surtout vers Wasabi ou Backblaze, peu utilisés en métier — détecte 80 % des scénarios d’exfiltration moderne. Ce n’est pas un anti-virus, c’est une règle d’usage.

Le bon réflexe : aligner détection et architecture SaaS

Le C2 SaaS impose un changement de paradigme : la sécurité n’est plus une affaire de périmètre, c’est une affaire d’usage et de baseline. Pour une PME-ETI, cela passe par :

  • Un EDR/XDR moderne capable de remonter les appels API SaaS au niveau processus (CrowdStrike Falcon en sensor, SentinelOne, Microsoft Defender).
  • Une Agentic SOC — comme celle proposée par ucyber.ai — pour corréler en temps réel l’usage SaaS, les exécutions de RMM, les flux vers object storage et les comportements utilisateurs.
  • Un plan de réponse qui anticipe ces canaux : si un poste exfiltre vers Dropbox, vous devez pouvoir le couper en quelques minutes — pas en quelques heures.

Pour aller plus loin sur la maîtrise de la supply chain et des dépendances SaaS, consultez notre analyse sur les 4 chantiers prioritaires face à la vague zero-day et notre guide sur la gouvernance des agents IA en PME-ETI.

Sources

Renforcez dès maintenant la cybersécurité de votre PME ou ETI avec ucyber.ai.
Évaluez votre niveau de sécurité ou
contactez-nous pour en savoir plus.
Suivez-nous sur LinkedIn.

Réserver 15 min — diagnostic