Sécurité des fichiers Excel expliquée : XLSX, XLSM et risques de macros

Depuis des décennies, Microsoft Excel est le moteur universel des opérations commerciales. Il équilibre les budgets d’entreprise, visualise des ensembles de données complexes, suit les stocks et alimente les pipelines analytiques dans pratiquement tous les secteurs.

Pourtant, cette même flexibilité computationnelle fait des feuilles de calcul un favori durable des cyber‑adversaires. Les attaquants utilisent les feuilles de calcul comme arme depuis les débuts des virus macro à la fin des années 1990. Bien que Microsoft et les administrateurs système aient introduit plusieurs couches de défense — comme la ségrégation des formats de fichiers et le blocage par défaut des macros — l’ingénierie sociale et les risques architecturaux subtils continuent de maintenir les attaques ciblant Excel pertinentes.

Pour établir une posture de sécurité résiliente, les développeurs, les administrateurs et les utilisateurs avancés doivent regarder au‑delà de l’interface du classeur. Comprendre le fonctionnement du format OpenXML sous‑jacent, la différence architecturale entre les fichiers .xlsx et .xlsm, ainsi que les mécanismes d’exécution des macros est essentiel pour protéger les points de terminaison modernes.

1. Anatomie des fichiers Excel modernes : OpenXML décomposé

Avant la sortie de Microsoft Office 2007, Excel enregistrait les fichiers principalement au moyen de formats binaires propriétaires, notamment le format .xls (régis par le Binary Interchange File Format, ou BIFF8). Dans les fichiers .xls, les enregistrements de données, les définitions de mise en forme, les formules et les flux de macros Visual Basic for Applications (VBA) étaient regroupés dans un seul conteneur de stockage structuré. Cela rendait l’inspection programmatique difficile et permettait aux attaquants de dissimuler des scripts de charge utile malveillants à l’intérieur de secteurs binaires opaques.

À partir d’Excel 2007, Microsoft a introduit la norme Office Open XML (OOXML) (normalisée sous les références ECMA-376 et ISO/IEC 29500). Avec OOXML, les classeurs Excel ne sont plus de simples blocs binaires monolithiques. Ils sont plutôt des archives compressées contenant une structure hiérarchique de documents XML, de tables de relations et de ressources multimédias intégrées.

À l’intérieur du conteneur ZIP

Si vous prenez n’importe quel classeur Excel moderne standard et que vous renommez son extension en .zip, vous pouvez extraire son contenu avec n’importe quel utilitaire de décompression standard :

my_workbook.xlsx (extracted)
│
├── [Content_Types].xml        <-- Registry of MIME types and structural parts
├── _rels/                     <-- Package-level relationship mappings
│   └── .rels
├── docProps/                  <-- Metadata (author, creation date, revision)
│   ├── app.xml
│   └── core.xml
└── xl/                        <-- Core spreadsheet contents
    ├── workbook.xml           <-- Workbook-level parameters and sheet list
    ├── styles.xml             <-- Cell styles, fonts, and borders
    ├── sharedStrings.xml      <-- Unique string index for performance optimization
    ├── _rels/
    │   └── workbook.xml.rels  <-- Sheet and component dependencies
    └── worksheets/
        ├── sheet1.xml         <-- Raw cell values, formulas, and grid geometry
        └── sheet2.xml

Ce changement structurel a apporté des avantages de sécurité immédiats :

1. DPI (Inspection Profonde des Paquets) & Visibilité de la Passerelle : Les appareils de sécurité, les proxys et les agents de point de terminaison peuvent décompresser l’archive à la volée et analyser les arbres XML en texte clair pour identifier des chaînes suspectes, des URL externes ou des objets intégrés.
2. Validation Déterministe des Fichiers : Si un fichier prétend être un document OpenXML mais enfreint les contraintes du schéma, Excel refuse de l’ouvrir ou l’exécute en mode de récupération sandboxé.
3. Séparation des Formats : Microsoft a dissocié les feuilles de calcul computationnelles classiques des fichiers capables d’exécuter des scripts procéduraux intégrés.

2. XLSX vs. XLSM : La frontière architecturale

La distinction principale entre .xlsx et .xlsm réside dans le fait que la structure du fichier autorise ou non l’inclusion de projets de macros exécutables.

Le mécanisme d’application : pourquoi le XLSX ne peut pas exécuter de macros

Une question fréquente parmi les administrateurs et développeurs juniors est : Que se passe-t-il si un attaquant prend un fichier .xlsm malveillant, y injecte du code exécutable et renomme l’extension du fichier en .xlsx ?

La réponse courte : Le fichier n’exécutera pas la macro.

Excel ne se base pas exclusivement sur l’extension du fichier pour déterminer les règles d’exécution. Lors de l’ouverture d’un fichier nommé .xlsx :

1. Excel inspecte le contenu zip et fait référence à [Content_Types].xml.
2. Dans un fichier .xlsx authentique, tous les types de contenu définis représentent des éléments de données standard (comme worksheet, sharedStrings ou styles).
3. Si un attaquant injecte manuellement un flux VBA compilé (xl/vbaProject.bin) dans un package .xlsx et met à jour les relations, Excel rencontre une contradiction explicite du schéma :
   • Il voit une extension .xlsx liée à des types de contenu indiquant la capacité de macro.
   • Excel génère une erreur d’intégrité fatale : “Excel ne peut pas ouvrir le fichier ‘filename.xlsx’ car le format du fichier ou son extension n’est pas valide. Vérifiez que le fichier n’a pas été corrompu…”
4. Si l’attaquant laisse les types internes intacts sans enregistrer le binaire, Excel considère vbaProject.bin comme une pièce jointe non référencée et orpheline dans l’archive zip et la supprime entièrement pendant le cycle de chargement.

En conséquence, un fichier fonctionnant strictement comme un véritable conteneur .xlsx ne peut pas exécuter de code VBA natif. Cependant, cela ne signifie pas que les fichiers .xlsx sont exempts de tous les vecteurs d’attaque, comme exploré plus loin dans ce guide.

3. Risques des macros & le cycle d’attaque

Les macros ont été conçues pour automatiser des tâches répétitives de comptabilité, de modélisation financière et de manipulation de données via Visual Basic for Applications (VBA). Parce que VBA a été créé pour l’automatisation en milieu professionnel, il bénéficie d’un accès étendu au système d’exploitation Windows sous-jacent via le Component Object Model (COM), Windows Script Host (WSH) et les appels directs à l’API Win32.

Lorsqu’une macro non fiable s’exécute, elle fonctionne avec les exactes mêmes privilèges que l’utilisateur connecté. Elle n’est pas confinée dans un bac à sable de navigateur virtualisé de type JavaScript.

+--------------------------------------------------------------------------------+
|                             ATTACK LIFECYCLE                                   |
+--------------------------------------------------------------------------------+
                                       │
                                       ▼
  [ Delivery & Evasion ]  ──────► Spear-phishing email with .xlsm, .xlam, or .zip.
                                       │
                                       ▼
  [ Social Engineering ]  ──────► Lures victim to bypass Protected View ("Enable Content").
                                       │
                                       ▼
  [ Auto-Execution ]      ──────► Auto_Open() or Workbook_Open() triggers automatically.
                                       │
                                       ▼
  [ System Invocation ]   ──────► VBA creates COM objects (WScript.Shell, WinHttp.WinHttpRequest).
                                       │
                                       ▼
  [ Payload Retrieval ]   ──────► Spawns hidden PowerShell/cURL to fetch staging binary.
                                       │
                                       ▼
  [ Post-Exploitation ]   ──────► In-memory execution, credential theft, lateral movement.

Techniques courantes d’intrusion de macros

1. Crochets d’auto-exécution : Les attaquants placent leur point d’entrée dans les gestionnaires d’événements intrinsèques tels que Sub Auto_Open() ou Private Sub Workbook_Open(). Dès que l’utilisateur accorde les autorisations d’exécution, ces routines se déclenchent sans nécessiter de clics dans la feuille de calcul.

2. Obfuscation et Stomping :

   • Obfuscation de chaînes : Les charges utiles cachent les URL et les appels système en utilisant des tableaux de caractères, le codage XOR, le décodage Base64 ou la concaténation de variables d’environnement (par ex., Chr(112) & Chr(111) & Chr(119)...).
   • VBA Stomping : Le VBA existe sous deux formes dans vbaProject.bin : le code source interprété et le p‑code compilé (pseudo‑code ciblant la version spécifique d’Office qui l’a compilé). Les attaquants peuvent effacer complètement le code source en clair, ne laissant que le p‑code compilé. De nombreuses solutions antivirus de base et les analyseurs statiques n’inspectent que le flux source, laissant le p‑code non détecté jusqu’à ce qu’il soit exécuté par une version d’Office correspondante.

3. Living off the Land (LotL) : Les macros malveillantes modernes déposent rarement un fichier .exe directement sur le disque, ce qui alerterait immédiatement les agents de détection et de réponse des points de terminaison (EDR). À la place, elles interagissent avec les outils système intégrés :

   • Instanciation de WScript.Shell pour exécuter des arguments en ligne de commande.
   • Invocation de PowerShell.exe avec contournement de la stratégie d’exécution (-ExecutionPolicy Bypass -WindowStyle Hidden).
   • Appeler les API Win32 natives via Declare PtrSafe Function CreateProcess ou VirtualAlloc pour injecter du shellcode directement dans la mémoire système.

4. Autres vecteurs de menace des feuilles de calcul (au‑delà du VBA standard)

Sécuriser un environnement contre les fichiers .xlsm n’est que la moitié du combat. Les adversaires utilisent également des mécanismes qui fonctionnent indépendamment du VBA traditionnel.

Échange dynamique de données (DDE) et injection de CSV

Excel propose un protocole hérité appelé Dynamic Data Exchange (DDE), conçu pour permettre le partage de données entre applications en cours d’exécution (par exemple, diffuser en temps réel des données de cours boursiers depuis un programme séparé vers une cellule Excel).

• Comment fonctionne l’injection de formules : Lorsqu’une cellule de feuille de calcul commence par des caractères tels que =, @, + ou -, Excel interprète le contenu comme une formule. Si un attaquant contrôle les données exportées vers une feuille de calcul (par exemple, un champ “Commentaires” non désinfecté dans une application web exporté en CSV ou XLSX), il peut injecter :

  =cmd|'/C powershell.exe -w hidden -enc <base64_payload>'!A0
  

• Lors de l’ouverture, Excel évalue la formule, alerte l’utilisateur avec une invite concernant le lancement d’une application externe et, si elle est approuvée, exécute le shell système.

Macros héritées d’Excel 4.0 (XLM)

Avant l’introduction de VBA en 1993, Excel utilisait un système de macros basé sur des formules appelé macros Excel 4.0 (XLM). Ces macros résident dans des feuilles de macro dédiées plutôt que dans un projet VBA séparé.

Comme les macros XLM sont écrites sous forme de formules de cellule (par exemple =EXEC("calc.exe")), elles contournent de nombreux moteurs d’inspection statique VBA standard. Les attaquants ont privilégié les macros XLM à la fin des années 2010 et au début des années 2020 pour échapper à la détection automatisée avant que Microsoft ne les désactive par défaut dans les versions d’entreprise modernes.

Connexions externes malveillantes et objets OLE

Un classeur .xlsx ordinaire peut encore présenter un risque via des ressources externes :

• Packages OLE intégrés : Un attaquant peut insérer un exécutable déguisé en icône PDF intégrée directement dans la feuille de calcul.
• Liens externes de classeur & requêtes Web : Un XLSX peut contenir des références externes qui déclenchent automatiquement des requêtes HTTP GET vers des serveurs de commandement et contrôle (C2) contrôlés par l’attaquant lors de l’ouverture du fichier, principalement utilisées pour la reconnaissance ou les attaques de collecte de hachages netNTLM.

5. Renforcement d’entreprise et stratégies de défense en profondeur

Se défendre contre les menaces provenant d’Excel nécessite une approche en couches couvrant l’inspection réseau, la configuration du système, les contrôles d’accès et les processus opérationnels.

+─────────────────────────────────────────────────────────+
|                  ENTERPRISE DEFENSE LAYERS               |
+─────────────────────────────────────────────────────────+
|  PERIMETER: Drop inbound .xlsm, .xla, and .xltm at mail |
|  gateway unless cryptographically signed or exempted.   |
+---------------------------------------------------------+
|  IDENTITY & POLICY: Enforce ASR rules and apply         |
|  Mark of the Web (MotW) macro execution blocks.         |
+---------------------------------------------------------+
|  RUNTIME: Hook AMSI into Office to evaluate dynamic     |
|  VBA buffers directly before execution.                 |
+---------------------------------------------------------+
|  STORAGE: Restrict macro execution exclusively to       |
|  managed, centralized Trusted Locations.                |
+─────────────────────────────────────────────────────────+

1. Appliquer le Marquage du Web (MotW) pour le blocage des macros

En 2022, Microsoft a mis à jour le comportement par défaut des applications Office : les macros dans les fichiers provenant d’Internet sont bloquées par défaut.

Lorsque qu’un utilisateur télécharge un fichier via un navigateur ou un client externe, Windows étiquette le fichier avec un flux de données alternatif (ADS) nommé Zone.Identifier (la zone 3 indique Internet). Pour les fichiers portant cette marque, Excel désactive complètement les macros et affiche une bannière de sécurité rouge : > “RISQUE DE SÉCURITÉ : Microsoft a bloqué l’exécution des macros car la source de ce fichier n’est pas fiable.”

Action administrative : Assurez-vous que ce comportement est appliqué via la stratégie de groupe et ne peut pas être contourné par les utilisateurs finaux :

• Chemin GPO : User Configuration > Administrative Templates > Microsoft Excel 2016 > Excel Options > Security > Trust Center
• Paramètre : Activez “Bloquer l’exécution des macros dans les fichiers Office provenant d’Internet”.

2. Configurer les règles de réduction de la surface d’attaque (ASR)

Les organisations utilisant Microsoft Defender for Endpoint devraient activer les règles principales de réduction de la surface d’attaque conçues spécifiquement pour les applications Office :

• Bloquer les applications Office de créer des processus enfants (GUID : D4F940AB-401B-4EFC-AADC-AD5F3C50688A)
  • Empêche Excel de lancer PowerShell, CMD ou des moteurs de script.
• Bloquer les applications Office d’injecter du code dans d’autres processus (GUID: 75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84)
• Bloquer les appels API Win32 des macros Office (GUID: 92E6390C-CF9E-43CE-BD8C-0E6F0FE66680)

3. Exploiter l’interface de numérisation antimalware (AMSI)

Les versions modernes de Microsoft 365 intègrent l’exécution VBA directement avec AMSI. Même si un attaquant applique une obfuscation de chaînes complexe ou du « VBA stomping », le moteur d’exécution VBA transmet les commandes reconstruites et non chiffrées à votre moteur antivirus/EDR installé à la milliseconde exacte précédant l’exécution. Assurez-vous que votre protection des points de terminaison surveille activement les événements d’exécution AMSI.

4. Passer aux emplacements de confiance et aux certificats numériques

Pour les organisations qui dépendent de feuilles de calcul automatisées pour leurs opérations quotidiennes :

• Éliminer les fichiers XLSM non contrôlés dans les dossiers Téléchargements ou Bureau des utilisateurs.
• Utiliser les emplacements de confiance : Restreindre l’exécution des macros exclusivement aux partages réseau en lecture seule gérés par les administrateurs informatiques.
• Signature de code : Obliger toutes les macros développées en interne à être signées cryptographiquement à l’aide d’un certificat délivré par une infrastructure à clé publique (PKI) d’entreprise. Configurer Excel pour exécuter uniquement les macros signées numériquement et bloquer silencieusement les non signées.

6. Perspective du développeur : créer une automatisation sécurisée

Si vous développez un logiciel qui analyse, génère ou consomme des fichiers Excel (par exemple, des pipelines Python utilisant pandas/openpyxl, des microservices Node.js ou des applications C#/.NET), appliquez ces mesures de sécurité de développement :

1. Rejeter les formats de fichiers inattendus à la frontière de téléchargement : Si votre application attend des rapports financiers, validez strictement que les fichiers entrants sont conformes à .xlsx. Inspectez les octets magiques internes (l’en-tête zip standard 50 4B 03 04) et vérifiez qu’aucune entrée vbaProject.bin n’existe dans l’index de l’archive avant de les enregistrer dans des buckets cloud ou des bases de données.

2. Assainir les données contre l’injection de formules : Lors de l’exportation d’entrées générées par les utilisateurs vers des fichiers CSV ou XLSX, préfixez d’une apostrophe (') ou d’un espace toute cellule commençant par des caractères dangereux (=, +, -, @, \t, \r) :

   def sanitize_for_spreadsheet(value: str) -> str:
       if value and value[0] in ('=', '+', '-', '@', '\t', '\r'):
           return f"'{value}"
       return value
   

3. Migrer de VBA vers Office Scripts ou des compléments Web : Pour une automatisation d’entreprise moderne, éliminez complètement le VBA hérité :

   • Office Scripts : Écrits en TypeScript, les Office Scripts s’exécutent dans un environnement cloud sandboxé et fonctionnent de manière fluide sur les éditions web et desktop sans exposer les appels système natifs de l’OS.
   • Office Web Add-ins: Construit à l’aide du HTML, CSS standard et du JavaScript moderne, les compléments Web communiquent via des API JavaScript gérées et sont isolés du système d’exploitation local.

7. Liste de contrôle récapitulative pour la sécurité des feuilles de calcul

• Appliquer .xlsx par défaut : Exiger que tous les flux de travail utilisateur standard enregistrent au format .xlsx sans macro.
• Bloquer les macros d’origine Internet : Confirmer que l’application de la politique MotW est déployée dans votre organisation via GPO ou Intune.
• Activer les règles ASR : Interdire aux produits Office de lancer des interprètes de commandes ou des processus enfants.
• Déprécier Excel 4.0 (XLM) : S’assurer que les moteurs de macros XLM hérités sont désactivés de façon permanente sur toutes les stations de travail.
• Assainir les exportations d’application : Protéger les routines de génération CSV et Excel contre les injections CSV/formules.
• Passer aux Office Scripts : Faire migrer les macros administratives héritées vers des Office Scripts pilotés par TypeScript et des API gérées.

En considérant les feuilles de calcul non seulement comme des fichiers documentaires, mais comme des conteneurs logiciels structurés dotés de capacités d’exécution, les équipes de sécurité et les développeurs peuvent neutraliser efficacement l’un des vecteurs d’attaque les plus anciens de l’informatique d’entreprise.

Foire aux questions (FAQ)

Q1 : Un fichier se terminant par .xlsx peut‑il exécuter une macro malveillante ?

Non, la norme OpenXML interdit strictement le code macro dans les fichiers .xlsx, et Excel rejettera ou supprimera tout projet VBA injecté dans un véritable conteneur .xlsx.

Q2 : Que dois‑je faire si un fichier Excel me demande d’« Activer la modification » ou d’« Activer le contenu » ?

N’accordez les autorisations que si vous connaissez l’expéditeur et attendiez le fichier ; cette invite est le point de contrôle principal qui permet aux macros non fiables d’exécuter du code.

Q3 : Comment Microsoft Excel détermine‑t‑il si un fichier provient d’Internet ?

Windows ajoute un flux caché « Mark of the Web » (Zone.Identifier) aux fichiers téléchargés, ce qui indique à Excel de les ouvrir en mode Affichage protégé et de bloquer les macros par défaut.

Q4 : Les fichiers CSV sont‑ils plus sûrs que les fichiers XLSX et XLSM ?

Les fichiers CSV ne peuvent pas contenir de macros VBA natives, mais ils restent vulnérables aux attaques d’injection de formules s’ils contiennent des commandes malveillantes exécutées par Excel lors de l’ouverture.

Q5 : En quoi les Office Scripts modernes diffèrent‑ils des macros VBA traditionnels ?

Les Office Scripts s’exécutent en TypeScript dans un environnement d’exécution sandboxé, les empêchant d’accéder à votre système de fichiers local, à la ligne de commande ou aux API du système d’exploitation.

Voir aussi

• CSV vs XLSX vs ODS en 2026 : le meilleur format de feuille de calcul pour les développeurs
• XLS vs XLSX vs XLSM vs XLSB - Choisir le bon format de feuille de calcul
• Qu’est-ce qu’Excel ? Informations clés à connaître
• Formats de fichiers Excel : XLSX, XLSM, XLS, XLTX, XLTM
• Différence entre XLS et XLSX