Excel-Dateisicherheit erklärt: XLSX, XLSM und Makro-Risiken

Seit Jahrzehnten ist Microsoft Excel das universelle Werkzeug für Geschäftsabläufe. Es balanciert Unternehmensbudgets, visualisiert komplexe Datensätze, verfolgt Bestände und treibt analytische Pipelines in praktisch jeder Branche an.

Doch genau diese rechnerische Flexibilität macht Tabellenkalkulationen zu einem dauerhaften Favoriten von Cyber‑Gegnern. Angreifer nutzen Tabellen seit den frühen Tagen der Makroviren in den späten 1990er‑Jahren als Waffe. Während Microsoft und Systemadministratoren mehrere Verteidigungsebenen eingeführt haben – wie die Trennung von Dateiformaten und das standardmäßige Blockieren von Makros – halten Social Engineering und subtile architektonische Risiken Excel‑bezogene Angriffe weiterhin relevant.

Um eine belastbare Sicherheitslage aufzubauen, müssen Entwickler, Administratoren und Power‑User unter die Arbeitsmappen‑Oberfläche blicken. Das Verständnis, wie das zugrunde liegende OpenXML‑Format funktioniert, wie sich .xlsx und .xlsm auf architektonischer Ebene unterscheiden und wie die Mechanik der Makroausführung funktioniert, ist entscheidend für die Verteidigung moderner Endpunkte.

1. Anatomie moderner Excel-Dateien: OpenXML zerlegt

Vor der Veröffentlichung von Microsoft Office 2007 speicherte Excel Dateien hauptsächlich in proprietären Binärformaten, insbesondere im .xls‑Format (gesteuert durch das Binary Interchange File Format, kurz BIFF8). In .xls‑Dateien wurden Datenaufzeichnungen, Formatdefinitionen, Formeln und Visual Basic for Applications (VBA)‑Makro‑Streams in einem einzigen strukturierten Speichercontainer zusammengefasst. Dies erschwerte die programmgesteuerte Inspektion und ermöglichte Angreifern, bösartige Payload‑Skripte in undurchsichtigen Binärsektoren zu verbergen.

Ab Excel 2007 führte Microsoft den Office Open XML (OOXML)‑Standard ein (standardisiert als ECMA‑376 und ISO/IEC 29500). Unter OOXML sind Excel‑Arbeitsmappen keine monolithischen Binärblobs mehr. Stattdessen handelt es sich um ZIP‑Archive, die eine hierarchische Struktur aus XML‑Dokumenten, Beziehungstabellen und eingebetteten Medien‑Assets enthalten.

Im ZIP-Container

Wenn Sie eine beliebige moderne Standard‑Excel‑Arbeitsmappe nehmen und ihre Erweiterung in .zip umbenennen, können Sie deren Inhalt mit jedem gängigen Dekomprimierungs‑Utility extrahieren:

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

Diese strukturelle Änderung brachte sofortige Sicherheitsvorteile:

1. DPI (Deep Packet Inspection) & Gateway Visibility: Sicherheitsgeräte, Proxys und Endpunkt‑Agenten können das Archiv unterwegs entpacken und Klartext‑XML‑Bäume analysieren, um verdächtige Zeichenketten, externe URLs oder eingebettete Objekte zu identifizieren.
2. Deterministische Dateivalidierung: Wenn eine Datei behauptet, ein OpenXML‑Dokument zu sein, aber Schema‑Beschränkungen verletzt, verweigert Excel das Öffnen oder führt sie im sandbox‑basierten Wiederherstellungsmodus aus.
3. Formattrennung: Microsoft hat reguläre Berechnungs‑Tabellen von Dateien getrennt, die eingebettete prozedurale Skripte ausführen können.

2. XLSX vs. XLSM: Die architektonische Grenze

Der wesentliche Unterschied zwischen .xlsx und .xlsm besteht darin, ob die Dateistruktur die Einbindung ausführbarer Makro‑Projekte zulässt.

Der Durchsetzungsmechanismus: Warum XLSX keine Makros ausführen kann

Eine häufige Frage unter Junior-Administratoren und Entwicklern ist: Was passiert, wenn ein Angreifer eine bösartige .xlsm-Datei nimmt, ausführbaren Code injiziert und die Dateierweiterung in .xlsx umbenennt?

Kurzantwort: Die Datei wird das Makro nicht ausführen.

Excel verlässt sich nicht ausschließlich auf die Dateierweiterung, um Ausführungsregeln zu bestimmen. Beim Öffnen einer Datei mit dem Namen .xlsx:

1. Excel prüft das ZIP-Payload und verweist auf [Content_Types].xml.
2. In einer echten .xlsx-Datei repräsentieren alle definierten Inhaltstypen Standarddatenelemente (wie worksheet, sharedStrings oder styles).
3. Wenn ein Angreifer manuell einen kompilierten VBA-Stream (xl/vbaProject.bin) in ein .xlsx-Paket injiziert und die Beziehungen aktualisiert, stößt Excel auf einen expliziten Schema-Widerspruch:
   • Es erkennt eine .xlsx-Erweiterung, die an Inhaltstypen gebunden ist, die Makrofähigkeit anzeigen.
   • Excel wirft einen fatalen Integritätsfehler: “Excel kann die Datei ‘filename.xlsx’ nicht öffnen, weil das Dateiformat oder die Dateierweiterung ungültig ist. Stellen Sie sicher, dass die Datei nicht beschädigt wurde…”
4. Wenn der Angreifer die internen Typen unverändert lässt, ohne die Binärdatei zu registrieren, behandelt Excel vbaProject.bin als eine nicht referenzierte, verwaiste Anlage im Zip-Archiv und verwirft sie vollständig während des Ladevorgangs.

Folglich kann eine Datei, die ausschließlich als echter .xlsx-Container fungiert, keinen nativen VBA-Code ausführen. Das bedeutet jedoch nicht, dass .xlsx-Dateien frei von allen Angriffsvektoren sind, wie später in diesem Leitfaden erläutert wird.

3. Makro‑Risiken & der Angriffslebenszyklus

Makros wurden entwickelt, um wiederkehrende Buchhaltungs-, Finanzmodellierungs- und Datenmanipulationsaufgaben über Visual Basic for Applications (VBA) zu automatisieren. Da VBA für die Automatisierung am Arbeitsplatz konzipiert wurde, erhielt es umfangreichen Zugriff auf das zugrunde liegende Windows-Betriebssystem über das Component Object Model (COM), Windows Script Host (WSH) und direkte Win32-API-Aufrufe.

Wenn ein nicht vertrauenswürdiges Makro ausgeführt wird, läuft es mit genau denselben Berechtigungen wie der angemeldete Benutzer. Es ist nicht in einer virtualisierten, JavaScript-ähnlichen Browser‑Sandbox gefangen.

+--------------------------------------------------------------------------------+
|                             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.

Gängige Techniken zum Makro‑Einstieg

1. Auto‑Ausführungs‑Hooks: Angreifer platzieren ihren Einstiegspunkt in intrinsische Ereignis-Handler wie Sub Auto_Open() oder Private Sub Workbook_Open(). Sobald der Benutzer Ausführungsberechtigungen erteilt, werden diese Routinen ausgelöst, ohne dass ein Klick innerhalb der Tabelle erforderlich ist.

2. Verschleierung und Stomping:

   • String-Verschleierung: Payloads verbergen URLs und Systemaufrufe mithilfe von Zeichenarrays, XOR-Codierung, Base64-Dekodierung oder der Verkettung von Umgebungsvariablen (z. B. Chr(112) & Chr(111) & Chr(119)...).
   • VBA-Stomping: VBA existiert in zwei Formen innerhalb von vbaProject.bin: interpretierter Quellcode und kompilierter P-Code (Pseudo-Code, der auf die spezifische Office-Version abzielt, die ihn kompiliert hat). Angreifer können den Klartext-Quellcode vollständig entfernen und nur den kompilierten P-Code belassen. Viele einfache Antivirenlösungen und statische Analysatoren prüfen nur den Quellcode‑Strom, sodass der P-Code bis zur Ausführung durch eine passende Office-Version unentdeckt bleibt.

3. Living off the Land (LotL): Moderne bösartige Makros legen selten eine .exe-Datei direkt auf die Festplatte, da dies sofort Endpoint Detection and Response (EDR)-Agenten alarmieren würde. Stattdessen interagieren sie mit integrierten Systemwerkzeugen:

   • Instanziieren von WScript.Shell, um Befehlszeilenargumente auszuführen.
   • Aufrufen von PowerShell.exe mit Umgehung der Ausführungsrichtlinie (-ExecutionPolicy Bypass -WindowStyle Hidden).
   • Aufrufen nativer Win32-APIs über Declare PtrSafe Function CreateProcess oder VirtualAlloc, um Shellcode direkt in den Systemspeicher zu injizieren.

4. Andere Bedrohungsvektoren für Tabellenkalkulationen (jenseits von Standard‑VBA)

Das Sichern einer Umgebung gegen .xlsm‑Dateien ist nur die halbe Miete. Gegner nutzen zudem Mechanismen, die unabhängig von traditionellem VBA funktionieren.

Dynamic Data Exchange (DDE) und CSV-Injektion

Excel enthält ein veraltetes Protokoll namens Dynamic Data Exchange (DDE), das entwickelt wurde, um den Datenaustausch zwischen laufenden Anwendungen zu ermöglichen (zum Beispiel das Streamen von Live-Aktienkursdaten aus einem separaten Programm in eine Excel‑Zelle).

• Wie Formelinjektion funktioniert: Wenn eine Tabellenzelle mit Zeichen wie =, @, + oder - beginnt, interpretiert Excel den Inhalt als Formel. Wenn ein Angreifer Eingaben kontrolliert, die in eine Tabelle exportiert werden (z. B. ein nicht bereinigtes Feld „Kommentare“ in einer Webanwendung, das als CSV oder XLSX exportiert wird), kann er Folgendes injizieren:

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

• Beim Öffnen wertet Excel die Formel aus, warnt den Benutzer mit einer Eingabeaufforderung zum Starten einer externen Anwendung und führt bei Zustimmung die System‑Shell aus.

Excel 4.0 (XLM) Legacy‑Makros

Bevor VBA 1993 eingeführt wurde, nutzte Excel ein formelbasiertes Makrosystem, das als Excel 4.0 (XLM)-Makros bekannt ist. Diese Makros befinden sich in dedizierten Makroblättern und nicht in einem separaten VBA-Projekt.

Da XLM-Makros als Zellformeln geschrieben werden (wie =EXEC(\"calc.exe\")), umgehen sie viele gängige VBA‑Statischanalyse‑Engines. Angreifer bevorzugten XLM-Makros Ende der 2010er‑Jahre und Anfang der 2020er‑Jahre, um automatisierte Erkennung zu umgehen, bevor Microsoft sie standardmäßig in modernen Enterprise‑Builds deaktivierte.

Bösartige externe Verbindungen und OLE-Objekte

Eine gewöhnliche .xlsx‑Arbeitsmappe kann weiterhin Risiken durch externe Ressourcen einführen:

• Eingebettete OLE-Pakete: Ein Angreifer kann eine ausführbare Datei, die als eingebettetes PDF‑Symbol maskiert ist, direkt in das Arbeitsblatt einfügen.
• Externe Arbeitsmappen‑Links & Web‑Abfragen: Ein XLSX kann externe Verweise enthalten, die beim Öffnen der Datei automatisch HTTP‑GET‑Anfragen an vom Angreifer kontrollierte Command-and‑Control‑(C2‑)Server auslösen, hauptsächlich für Aufklärungs‑ oder netNTLM‑Hash‑Ernte‑Angriffe verwendet.

5. Unternehmenshärtung & Defense-in-Depth-Strategien

Der Schutz vor Excel‑basierten Bedrohungen erfordert einen mehrschichtigen Ansatz, der Netzwerkinspektion, Systemkonfiguration, Zugriffskontrollen und betriebliche Prozesse abdeckt.

+─────────────────────────────────────────────────────────+
|                  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. Durchsetzung von Mark of the Web (MotW) Makro-Blockierung

Im Jahr 2022 hat Microsoft das Standardverhalten von Office-Anwendungen aktualisiert: Makros in Dateien, die aus dem Internet stammen, sind standardmäßig blockiert.

Wenn ein Benutzer eine Datei über einen Browser oder einen externen Client herunterlädt, versieht Windows die Datei mit einem alternativen Datenstrom (ADS) namens Zone.Identifier (Zone 3 steht für das Internet). Für Dateien mit dieser Markierung deaktiviert Excel Makros vollständig und zeigt ein rotes Sicherheitsbanner an: > “SICHERHEITSRISIKO: Microsoft hat Makros blockiert, weil die Quelle dieser Datei nicht vertrauenswürdig ist.”

Administrative Maßnahme: Stellen Sie sicher, dass dieses Verhalten über Gruppenrichtlinien durchgesetzt wird und von Endbenutzern nicht überschrieben werden kann:

• GPO-Pfad: User Configuration > Administrative Templates > Microsoft Excel 2016 > Excel Options > Security > Trust Center
• Einstellung: Aktivieren Sie “Makros blockieren, die in Office-Dateien aus dem Internet ausgeführt werden”.

2. Konfiguration von Attack Surface Reduction (ASR)-Regeln

Organisationen, die Microsoft Defender for Endpoint einsetzen, sollten die Kernregeln zur Reduzierung der Angriffsfläche aktivieren, die speziell für Office-Anwendungen entwickelt wurden:

• Office-Anwendungen daran hindern, Kindprozesse zu erstellen (GUID: D4F940AB-401B-4EFC-AADC-AD5F3C50688A)
  • Verhindert, dass Excel PowerShell, CMD oder Skript-Engines startet.
• Blockieren Sie Office-Anwendungen daran, Code in andere Prozesse zu injizieren (GUID: 75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84)
• Blockieren Sie Win32-API-Aufrufe von Office-Makros (GUID: 92E6390C-CF9E-43CE-BD8C-0E6F0FE66680)

3. Nutzung der Antimalware Scan Interface (AMSI)

Moderne Versionen von Microsoft 365 integrieren die VBA-Ausführung direkt in AMSI. Selbst wenn ein Angreifer komplexe Zeichenkettenverschlüsselung oder VBA-Stomping anwendet, übergibt die VBA-Laufzeitengine die rekonstruierten, unverschlüsselten Befehle an Ihre installierte Antivirus/EDR-Engine in der exakt gleichen Millisekunde vor der Ausführung. Stellen Sie sicher, dass Ihr Endpunktschutz AMSI-Laufzeitereignisse aktiv überwacht.

4. Umstellung auf vertrauenswürdige Speicherorte und digitale Zertifikate

Für Organisationen, die für den täglichen Betrieb auf automatisierte Tabellenkalkulationen angewiesen sind:

• Entfernen Sie lose XLSM-Dateien in den Downloads oder Desktop-Ordnern der Benutzer.
• Verwenden Sie vertrauenswürdige Speicherorte: Beschränken Sie die Makroausführung ausschließlich auf schreibgeschützte Netzwerkfreigaben, die von IT-Administratoren verwaltet werden.
• Code Signing: Verlangen Sie, dass alle intern entwickelten Makros kryptografisch mit einem von einer Unternehmens-PKI (Public Key Infrastructure) ausgestellten Zertifikat signiert werden. Konfigurieren Sie Excel so, dass nur digital signierte Makros ausgeführt und unsignierte stillschweigend blockiert werden.

6. Sicht des Entwicklers: Aufbau sicherer Automatisierung

Wenn Sie Software entwickeln, die Excel-Dateien analysiert, erzeugt oder verarbeitet (z. B. Python-Pipelines mit pandas/openpyxl, Node.js-Mikrodienste oder C#/.NET-Anwendungen), wenden Sie diese Entwicklungssicherheitsmaßnahmen an:

1. Unerwartete Dateiformate an der Upload-Grenze ablehnen: Wenn Ihre Anwendung Finanzberichte erwartet, validieren Sie streng, dass eingehende Dateien dem Format .xlsx entsprechen. Prüfen Sie die internen Magic‑Bytes (der Standard‑ZIP‑Header 50 4B 03 04) und vergewissern Sie sich, dass im Archiv‑Index keine vbaProject.bin‑Einträge vorhanden sind, bevor Sie sie in Cloud‑Buckets oder Datenbankspeichern ablegen.

2. Daten gegen Formeleinschleusung bereinigen: Beim Exportieren von benutzergenerierten Eingaben in CSV‑ oder XLSX‑Dateien fügen Sie einem jeder Zelle, die mit gefährlichen Zeichen beginnt (=, +, -, @, \t, \r), ein Apostroph (') oder ein Leerzeichen voran:

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

3. Von VBA zu Office Scripts oder Web‑Add‑ins migrieren: Für moderne Unternehmensautomatisierung sollten Sie das veraltete VBA vollständig auslaufen lassen:

   • Office Scripts: In TypeScript geschrieben, laufen Office Scripts in einer sandboxed Cloud‑Umgebung und funktionieren einwandfrei sowohl in Web‑ als auch in Desktop‑Editionen, ohne native Betriebssystemaufrufe offenzulegen.
   • Office Web Add-ins: Erstellt mit standardmäßigem HTML, CSS und modernem JavaScript, kommunizieren Web-Add-Ins über verwaltete JavaScript-APIs und sind vom lokalen Betriebssystem isoliert.

7. Zusammenfassende Checkliste für Tabellensicherheit

• .xlsx standardmäßig erzwingen: Alle gängigen Benutzer‑Workflows dazu verpflichten, im macro‑freien .xlsx zu speichern.
• Internet‑Ursprungs‑Makros blockieren: Bestätigen Sie, dass die Durchsetzung der MotW‑Richtlinie in Ihrer gesamten Organisation über GPO oder Intune bereitgestellt wird.
• ASR‑Regeln aktivieren: Verhindern Sie, dass Office‑Produkte Befehlsinterpreter oder Kindprozesse starten.
• Excel 4.0 (XLM) veralten lassen: Stellen Sie sicher, dass veraltete XLM‑Makro‑Engines auf allen Arbeitsplätzen dauerhaft deaktiviert sind.
• Anwendungs‑Exporte bereinigen: Schützen Sie CSV‑ und Excel‑Erzeugungsroutinen vor CSV‑/Formel‑Injection.
• Hin zu Office Scripts wechseln: Überführen Sie veraltete administrative Makros zu TypeScript‑basierten Office Scripts und verwalteten APIs.

Indem man Tabellenkalkulationen nicht nur als Dokumentdateien, sondern als strukturierte Software‑Container mit Ausführungsfähigkeiten betrachtet, können Sicherheitsteams und Entwickler einen der ältesten Angriffsvektoren in der Unternehmens‑IT wirksam neutralisieren.

Häufig gestellte Fragen (FAQ)

Q1: Kann eine Datei mit der Endung .xlsx ein bösartiges Makro ausführen?

Nein, der OpenXML-Standard verbietet strikt Makrocode in .xlsx‑Dateien, und Excel wird jedes in einen echten .xlsx‑Container injizierte VBA‑Projekt ablehnen oder entfernen.

Q2: Was soll ich tun, wenn eine Excel-Datei mich auffordert, “Bearbeitung aktivieren” oder “Inhalte aktivieren”?

Gewähren Sie Berechtigungen nur, wenn Sie den Absender kennen und die Datei erwartet haben; diese Eingabeaufforderung ist die zentrale Kontrollstelle, die unzuverlässigen Makros das Ausführen von Code ermöglicht.

Q3: Wie erkennt Microsoft Excel, ob eine Datei aus dem Internet stammt?

Windows fügt heruntergeladenen Dateien einen versteckten "Mark of the Web" (Zone.Identifier)-Stream hinzu, der Excel signalisiert, sie standardmäßig im geschützten Modus zu öffnen und Makros zu blockieren.

Q4: Sind CSV-Dateien sicherer als XLSX und XLSM Dateien?

CSV‑Dateien können keine nativen VBA‑Makros enthalten, sind jedoch anfällig für Formeleinspritzungsangriffe, wenn sie bösartige Befehle enthalten, die von Excel beim Öffnen ausgeführt werden.

Q5: Wie unterscheiden sich moderne Office Scripts von traditionellen VBA-Makros?

Office‑Scripts laufen in TypeScript innerhalb einer sandbox‑basierten Laufzeitumgebung, wodurch sie keinen Zugriff auf Ihr lokales Dateisystem, die Befehlszeile oder Betriebssystem‑APIs erhalten.

Siehe auch

• CSV vs XLSX vs ODS im Jahr 2026: Bestes Tabellenkalkulationsformat für Entwickler
• XLS vs XLSX vs XLSM vs XLSB – Auswahl des richtigen Tabellenkalkulationsformats
• Was ist Excel? Wichtige Informationen, die Sie wissen müssen
• Excel-Dateiformate: XLSX, XLSM, XLS, XLTX, XLTM
• Unterschied zwischen XLS und XLSX