Un C2 dans Google Sheets : c’est la technique retenue par le groupe APT36 dans la campagne d’espionnage PATCHCORD, révélée cette semaine. Plutôt que d’exposer un serveur de commande et contrôle classique, les attaquants pilotent leurs implants via un simple tableur hébergé chez Google. Pour une PME-ETI, la conséquence est brutale : le trafic malveillant sort par sheets.googleapis.com, un domaine que votre pare-feu, votre proxy et votre passerelle web laissent passer sans discuter.
PATCHCORD : pourquoi un C2 dans Google Sheets change la donne
Le principe est d’une simplicité redoutable. L’implant déposé sur le poste compromis s’authentifie auprès de l’API Google avec des identifiants OAuth embarqués, lit une cellule d’un document partagé pour récupérer ses instructions, puis écrit ses résultats dans une autre cellule. Aucun domaine suspect, aucune IP à réputation dégradée, aucun certificat auto-signé.
Ce choix d’architecture neutralise la majorité des contrôles réseau déployés en PME-ETI :
- Filtrage par réputation de domaine : Google est en liste blanche partout, par construction.
- Inspection TLS : beaucoup d’organisations excluent les domaines Google du déchiffrement pour des raisons de confidentialité et de compatibilité.
- Détection par beaconing : les intervalles de synchronisation d’un tableur ressemblent à ceux d’une application bureautique légitime.
- Blocage sortant : couper l’accès aux API Google est rarement envisageable quand l’entreprise utilise Workspace.
APT36 n’est pas un cas isolé. La technique du C2 sur service SaaS légitime se généralise : nous avions déjà documenté l’abus de Microsoft Graph par le malware HollowGraph, et Mustang Panda a exploité Zoho WorkDrive selon le même schéma. Le point commun : l’attaquant emprunte l’infrastructure de confiance que vous avez vous-même autorisée.
Ce que le C2 dans Google Sheets révèle de votre surface d’exposition
Si un implant peut dialoguer avec Google Sheets depuis un poste de votre parc, c’est que trois conditions sont réunies, et chacune est corrigeable.
1. Le poste peut atteindre les API Google, pas seulement l’interface web
La plupart des utilisateurs n’ont besoin que de docs.google.com et drive.google.com dans un navigateur. L’accès programmatique à sheets.googleapis.com depuis un binaire arbitraire n’a aucune justification métier sur un poste bureautique.
2. Aucun contrôle ne s’applique au tenant de destination
Le tableur utilisé par APT36 n’appartient pas à votre organisation. Google Workspace propose un contrôle de restriction de contexte (Context-Aware Access) et surtout le blocage des tenants externes, souvent activé pour Gmail mais oublié pour Drive et Sheets.
3. Le poste exécute du code non signé sans supervision
Le C2 dans Google Sheets n’est que la phase de commande. L’accès initial, lui, reste classique : pièce jointe piégée, faux installeur, exploitation d’un service exposé. Le durcissement en amont reste votre meilleur retour sur investissement.
Détecter un C2 dans Google Sheets sans casser Workspace
La bonne approche n’est pas de bloquer Google, mais de séparer l’usage humain de l’usage machine. Voici les actions concrètes à mener cette semaine.
- Inventorier les processus qui parlent aux API Google. Sur un poste sain, seuls le navigateur et le client de synchronisation Drive doivent générer du trafic vers
*.googleapis.com. Toute autre binaire est un signal fort. Une règle Sysmon sur les connexions réseau corrélée au nom de processus suffit à sortir la liste. - Activer le blocage des tenants externes dans la console d’administration Workspace, pour Drive et Sheets et pas uniquement pour la messagerie. Un implant qui ne peut lire qu’un document de votre domaine perd son canal de commande.
- Journaliser les User-Agent inhabituels côté proxy. Les bibliothèques clientes Google (Python, Go, .NET) laissent une empreinte très différente de celle d’un navigateur. Cherchez les chaînes contenant
google-api-python-clientougzip(gfe)issues de postes utilisateurs. - Traquer les jetons OAuth embarqués. Un refresh token codé en dur dans un exécutable est un artefact analysable : intégrez la recherche de motifs
1//0etya29.dans vos règles YARA et votre scan de partages. - Déchiffrer sélectivement. Si l’inspection TLS globale des domaines Google est exclue, ouvrez une exception ciblée sur
sheets.googleapis.cometscript.googleapis.compour les postes non gérés par Workspace. - Surveiller les créations de comptes de service. Une campagne comme PATCHCORD suppose des identifiants Google valides quelque part : l’audit des comptes de service et de leurs clés doit être mensuel, pas annuel.
Une détection qui repose sur le comportement, pas sur la destination
Le C2 dans Google Sheets illustre une bascule que nous observons sur l’ensemble des campagnes récentes : l’indicateur de compromission n’est plus une IP ou un domaine, mais une relation anormale entre un processus et un service légitime. Aucune liste noire ne détectera PATCHCORD, parce qu’il n’y a rien à mettre sur liste noire.
C’est exactement le terrain sur lequel un SOC augmenté par l’IA apporte un gain mesurable : corréler un processus inconnu, une connexion sortante vers une API cloud autorisée et une absence d’activité utilisateur au même instant, c’est un raisonnement contextuel que les règles statiques ne savent pas produire. Chez ucyber.ai, ce croisement est traité par notre Agentic SOC, avec la télémétrie EDR CrowdStrike Falcon comme capteur.
Retenez la règle simple : votre périmètre n’est plus défini par les domaines que vous bloquez, mais par les processus que vous autorisez à parler au cloud. Tant que n’importe quel binaire peut ouvrir une session vers une API Google depuis un poste bureautique, un C2 dans Google Sheets restera un canal ouvert dans votre réseau.