Bezpečnost souborů Excel vysvětlená: XLSX, XLSM a rizika maker

Po desetiletí je Microsoft Excel považován za univerzální motor obchodních operací. Vyvažuje firemní rozpočty, vizualizuje složité datové sady, sleduje zásoby a pohání analytické pipeline napříč téměř všemi odvětvími.

Přesto tato stejná výpočetní flexibilita činí tabulky trvalým favoritem mezi kybernetickými protivníky. Útočníci zneužívají tabulky již od počátků makrovirů koncem 90. let. Zatímco Microsoft a správci systémů zavedli více vrstev obrany — například oddělení formátů souborů a výchozí blokování maker — sociální inženýrství a jemná architektonická rizika nadále udržují útoky zaměřené na Excel relevantní.

Pro vybudování odolného bezpečnostního postoje musí vývojáři, administrátoři a pokročilí uživatelé nahlédnout pod rozhraní sešitu. Porozumění tomu, jak funguje podkladový formát OpenXML, jak se na architektonické úrovni liší .xlsx a .xlsm, a jak fungují mechaniky spouštění maker, je zásadní pro obranu moderních koncových bodů.

1. Anatomie moderních souborů Excel: OpenXML rozebráno

Před vydáním Microsoft Office 2007 ukládal Excel soubory převážně pomocí proprietárních binárních formátů, nejčastěji formát .xls (spravovaný Binary Interchange File Format, nebo BIFF8). V souborech .xls byly záznamy dat, definice formátování, vzorce a proudy maker Visual Basic for Applications (VBA) zabaleny do jediného kontejneru strukturovaného úložiště. To ztížilo programovou inspekci a umožnilo útočníkům skrýt škodlivé skripty s nákladem uvnitř neprůhledných binárních sektorů.

Od Excelu 2007 Microsoft představil standard Office Open XML (OOXML) (standardizovaný jako ECMA-376 a ISO/IEC 29500). V rámci OOXML nejsou sešity Excelu již monolitické binární bloky. Místo toho jsou to zipované archivy obsahující hierarchickou strukturu XML dokumentů, tabulky vztahů a vložená mediální aktiva.

Uvnitř ZIP kontejneru

Pokud vezmete libovolnou standardní moderní sešit Excelu a přejmenujete jeho příponu na .zip, můžete jeho obsah rozbalit pomocí libovolného standardního nástroje pro dekompresi:

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

Tato struktura změna přinesla okamžité bezpečnostní výhody:

1. DPI (hloubková inspekce paketů) & Viditelnost brány: Bezpečnostní zařízení, proxy servery a koncové agenty mohou archiv rozbalit za běhu a analyzovat textové XML stromy k identifikaci podezřelých řetězců, externích URL nebo vložených objektů.
2. Deterministické ověřování souborů: Pokud soubor tvrdí, že je dokument OpenXML, ale porušuje schémata, Excel odmítne jej otevřít nebo jej spustí v režimu sandboxované obnovy.
3. Oddělení formátu: Microsoft oddělil běžné výpočetní tabulky od souborů schopných spouštět vložené procedurální skripty.

2. XLSX vs. XLSM: Architektonická hranice

Hlavní rozdíl mezi .xlsx a .xlsm spočívá v tom, zda struktura souboru umožňuje zahrnutí spustitelných makro projektů.

Mechanismus vynucení: Proč XLSX nemůže spouštět makra

Častá otázka mezi juniorními administrátory a vývojáři je: Co se stane, když útočník vezme škodlivý soubor .xlsm, vloží spustitelný kód a přejmenuje příponu souboru na .xlsx?

Krátká odpověď: Soubor makro nespustí.

Excel se nepouští výhradně na příponu souboru při určování pravidel spouštění. Při otevření souboru s názvem .xlsx:

1. Excel prozkoumá zipový obsah a odkazuje na [Content_Types].xml.
2. Ve skutečném souboru .xlsx všechny definované typy obsahu představují standardní datové prvky (například worksheet, sharedStrings nebo styles).
3. Pokud útočník ručně vloží zkompilovaný VBA stream (xl/vbaProject.bin) do balíčku .xlsx a aktualizuje vztahy, Excel narazí na explicitní rozpor ve schématu:
   • Vidí příponu .xlsx spojenou s typy obsahu, které naznačují schopnost makra.
   • Excel vyhodí fatální chybu integrity: “Excel nemůže otevřít soubor ‘filename.xlsx’, protože formát souboru nebo jeho přípona není platná. Ověřte, že soubor nebyl poškozen…”
4. Pokud útočník ponechá interní typy nedotčené a nezaregistruje binární soubor, Excel považuje vbaProject.bin za neodkazovanou, osiřelou přílohu v zip archivu a během načítacího cyklu ji zcela zahodí.

V důsledku toho soubor fungující výhradně jako pravý kontejner .xlsx nemůže spouštět nativní VBA kód. Nicméně to neznamená, že soubory .xlsx jsou osvobozeny od všech útočných vektorů, jak je podrobně rozebráno dále v tomto průvodci.

3. Rizika maker & životní cyklus útoku

Makra byla navržena k automatizaci opakujících se úkolů v účetnictví, finančním modelování a manipulaci s daty pomocí Visual Basic for Applications (VBA). Protože VBA bylo vytvořeno pro automatizaci pracovního prostředí, poskytovalo rozsáhlý přístup k podkladovému operačnímu systému Windows prostřednictvím Component Object Model (COM), Windows Script Host (WSH) a přímých volání Win32 API.

Když se spustí nedůvěryhodné makro, běží s přesně stejnými oprávněními jako přihlášený uživatel. Není zachyceno ve virtualizovaném sandboxu prohlížeče ve stylu JavaScriptu.

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

Běžné techniky vstupu maker

1. Háčky pro automatické spuštění: Útočníci umisťují svůj vstupní bod do vnitřních obslužných rutin událostí, jako jsou Sub Auto_Open() nebo Private Sub Workbook_Open(). Jakmile uživatel povolí spouštění, tyto rutiny se spustí, aniž by bylo potřeba jakýchkoli kliknutí v tabulce.

2. Zamaskování a Přepisování:

   • Zamaskování řetězců: Nákladní data skrývají URL a systémová volání pomocí polí znaků, XOR kódování, dekódování Base64 nebo spojování proměnných prostředí (např. Chr(112) & Chr(111) & Chr(119)...).
   • VBA Stomping: VBA existuje ve dvou formách uvnitř vbaProject.bin: interpretovaný zdrojový kód a zkompilovaný p-code (pseudo-kód cílený na konkrétní verzi Office, která jej zkompilovala). Útočníci mohou zcela vymazat čitelný zdrojový kód a ponechat jen zkompilovaný p-code. Mnoho základních antivirových řešení a statických analyzátorů kontroluje pouze zdrojový tok, takže p-code zůstává neodhalen až do jeho spuštění odpovídající verzí Office.

3. Využívání vestavěných nástrojů (LotL): Moderní škodlivé makra zřídka uložení soubor .exe přímo na disk, což by okamžitě upozornilo agenty Endpoint Detection and Response (EDR). Místo toho komunikují s vestavěnými systémovými nástroji:

   • Instanciace WScript.Shell pro spuštění argumentů příkazového řádku.
   • Vyvolání PowerShell.exe s obcházením zásad provádění (-ExecutionPolicy Bypass -WindowStyle Hidden).
   • Volání nativních Win32 API pomocí Declare PtrSafe Function CreateProcess nebo VirtualAlloc za účelem injekce shellcode přímo do systémové paměti.

4. Další vektory hrozeb v tabulkách (mimo standardní VBA)

Zajištění prostředí proti souborům .xlsm je jen polovinou boje. Útočníci také používají mechanismy, které fungují nezávisle na tradičním VBA.

Dynamic Data Exchange (DDE) a CSV injekce

Excel obsahuje starý protokol nazvaný Dynamic Data Exchange (DDE), který je určen pro sdílení dat mezi běžícími aplikacemi (například streamování živých dat burzovního tickeru z externího programu do buňky v Excelu).

• Jak funguje injekce vzorců: Když buňka tabulky začíná znaky jako =, @, + nebo -, Excel interpretuje obsah jako vzorec. Pokud útočník kontroluje vstup exportovaný do tabulky (například nevyčištěné pole „Comments“ ve webové aplikaci exportované do CSV nebo XLSX), může injektovat:

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

• Po otevření Excel vyhodnotí vzorec, upozorní uživatele výzvou ke spuštění externí aplikace a po schválení spustí systémový shell.

Excel 4.0 (XLM) starší makra

Před tím, než byl v roce 1993 představen VBA, Excel používal makrosystém založený na vzorcích, známý jako Excel 4.0 (XLM) makra. Tato makra jsou uložena v dedikovaných listách makr, nikoli v samostatném projektu VBA.

Protože jsou XLM makra psána jako buňkové vzorce (například =EXEC("calc.exe")), obcházejí mnoho standardních statických inspekčních enginů VBA. Útočníci upřednostňovali XLM makra koncem 2010. let a začátkem 2020. let, aby se vyhnuli automatické detekci, než je Microsoft ve výchozím nastavení zakázal v moderních podnikových verzích.

Zlovolné externí připojení a OLE objekty

Běžná sešit .xlsx může i nadále představovat riziko prostřednictvím externích zdrojů:

• Vložené OLE balíčky: Útočník může vložit spustitelný soubor maskovaný jako ikona vloženého PDF přímo do listu.
• Externí odkazy na sešity a webové dotazy: XLSX může obsahovat externí odkazy, které při otevření souboru automaticky spustí HTTP GET požadavky na servery řízené útočníkem (C2), což se primárně používá pro průzkum nebo útoky na sběr netNTLM hashů.

5. Zpevnění podniku a strategie obrany v hloubce

Obrana proti hrozbám šířeným prostřednictvím Excelu vyžaduje vrstvený přístup zahrnující síťovou inspekci, konfiguraci systému, řízení přístupu a provozní procesy.

+─────────────────────────────────────────────────────────+
|                  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. Vynutit značku webu (MotW) blokování maker

V roce 2022 společnost Microsoft aktualizovala výchozí chování aplikací Office: makra v souborech pocházejících z internetu jsou ve výchozím nastavení blokována.

Když uživatel stáhne soubor pomocí prohlížeče nebo externího klienta, Windows označí soubor alternativním datovým proudem (ADS) nazvaným Zone.Identifier (zóna 3 označuje Internet). Pro soubory s tímto označením Excel kompletně zakáže makra a zobrazí červený bezpečnostní banner: > “BEZPEČNOSTNÍ RIZIKO: Microsoft zablokoval spouštění maker, protože zdroj tohoto souboru není důvěryhodný.”

Administrativní akce: Zajistěte, aby toto chování bylo vynuceno pomocí Group Policy a nemohlo být uživateli přepsáno:

• Cesta GPO: User Configuration > Administrative Templates > Microsoft Excel 2016 > Excel Options > Security > Trust Center
• Nastavení: Povolit “Blokovat spouštění maker v Office souborech z internetu”.

2. Konfigurovat pravidla pro snížení útočného povrchu (ASR)

Organizace používající Microsoft Defender for Endpoint by měly aktivovat základní pravidla pro snížení útočného povrchu (Attack Surface Reduction), která jsou navržena speciálně pro aplikace Office:

• Block Office applications from creating child processes (GUID: D4F940AB-401B-4EFC-AADC-AD5F3C50688A)
  • Zabraňuje Excelu spouštět PowerShell, CMD nebo skriptovací enginy.
• Zablokovat aplikace Office před vkládáním kódu do jiných procesů (GUID: 75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84)
• Zablokovat volání Win32 API z maker Office (GUID: 92E6390C-CF9E-43CE-BD8C-0E6F0FE66680)

3. Využít rozhraní pro skenování antimalwaru (AMSI)

Moderní verze Microsoft 365 integrují spouštění VBA přímo s AMSI. I když útočník použije složitou obfuskaci řetězců nebo VBA stomping, běhový engine VBA předá rekonstruované, nešifrované příkazy vašemu nainstalovanému antivirovému/EDR enginu v přesně poslední milisekundě před spuštěním. Zajistěte, aby vaše ochrana koncových bodů aktivně sledovala události runtime AMSI.

4. Přechod na důvěryhodná umístění a digitální certifikáty

Pro organizace, které se spoléhají na automatizované tabulky pro každodenní operace:

• Odstraňte volně umístěné soubory XLSM ve složkách Stažené soubory uživatele nebo na ploše.
• Použijte důvěryhodná umístění: Omezte spouštění maker výhradně na jen pro čtení síťové sdílené složky spravované IT administrátory.
• Podepisování kódu: Požadujte, aby všechna interně vyvíjená makra byla kryptograficky podepsána pomocí certifikátu vydaného podnikové infrastruktury veřejných klíčů (PKI). Nakonfigurujte Excel tak, aby spouštěl pouze digitálně podepsaná makra a tiše blokoval nepodepsaná.

6. Perspektiva vývojáře: budování bezpečné automatizace

Pokud vytváříte software, který parsuje, generuje nebo konzumuje soubory Excel (např. Python pipeline používající pandas/openpyxl, Node.js mikroservisy nebo aplikace v C#/.NET), použijte tato vývojová opatření:

1. Odmítněte neočekávané formáty souborů na hranici nahrávání: Pokud vaše aplikace očekává finanční zprávy, přísně ověřte, že příchozí soubory odpovídají formátu .xlsx. Prohlédněte interní magické bajty (standardní zip hlavičku 50 4B 03 04) a ověřte, že v indexu archivu neexistují žádné položky vbaProject.bin před uložením do cloudových bucketů nebo databázových úložišť.

2. Sanitizujte data proti injekci vzorců: Při exportu vstupu vytvořeného uživatelem do souborů CSV nebo XLSX přidejte apostrof (') nebo mezeru na začátek každé buňky, která začíná nebezpečnými znaky (=, +, -, @, \t, \r):

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

3. Přesuňte se z VBA na Office Scripts nebo webové doplňky: Pro moderní podnikovou automatizaci postupně odstraňte staré VBA úplně:

   • Office Scripts: Psány v TypeScriptu, Office Scripts běží v sandboxovaném cloudovém prostředí a fungují hladce napříč webovými i desktopovými verzemi, aniž by odhalovaly nativní systémové volání OS.
   • Office Web Add-ins: Vytvořeny pomocí standardního HTML, CSS a moderního JavaScriptu, webové doplňky komunikují přes spravované JavaScript API a jsou izolovány od místního operačního systému.

7. Souhrnný kontrolní seznam pro zabezpečení tabulek

• Vynutit .xlsx jako výchozí: Vyžadovat, aby všechny standardní uživatelské pracovní postupy ukládaly jako .xlsx bez maker.
• Blokovat makra pocházející z internetu: Ověřte, že vynucení politiky MotW je nasazeno v celé organizaci prostřednictvím GPO nebo Intune.
• Povolit pravidla ASR: Zakázat produktům Office spouštět interpretery příkazů nebo podprocesy.
• Zrušit podporu Excel 4.0 (XLM): Zajistit, aby staré XLM makro enginy byly trvale vypnuty na všech pracovních stanicích.
• Sanitizovat exporty aplikací: Chrání rutiny generování CSV a Excel před injekcí CSV/formulí.
• Přesunout se k Office Scripts: Převést stará administrativní makra na Office Scripts řízené TypeScriptem a spravovaná API.

Když se tabulky považují nejen za dokumentové soubory, ale za strukturované softwarové kontejnery, které nesou spouštěcí schopnosti, mohou bezpečnostní týmy a vývojáři efektivně neutralizovat jeden z nejstarších vektorů útoků v podnikovém výpočetním prostředí.

Často kladené otázky (FAQ)

Q1: Může soubor končící na .xlsx spustit škodlivý makro?

Ne, standard OpenXML přísně zakazuje makro kód v souborech .xlsx a Excel odmítne nebo odstraní jakýkoli VBA projekt vložený do skutečného kontejneru .xlsx.

Q2: Co mám dělat, pokud mě soubor Excel požádá o “Povolit úpravy” nebo “Povolit obsah”?

Oprávnění udělujte pouze, pokud znáte odesílatele a soubor jste očekávali; tato výzva je hlavním kontrolním bodem, který umožňuje nedůvěryhodným makrům spouštět kód.

Q3: Jak Microsoft Excel určuje, zda soubor pochází z internetu?

Windows připojuje ke staženým souborům skrytý proud “Mark of the Web” (Zone.Identifier), který Excelu signalizuje, aby je otevřel v chráněném zobrazení a ve výchozím nastavení blokoval makra.

Q4: Jsou soubory CSV bezpečnější než soubory XLSX a XLSM?

Soubory CSV nemohou obsahovat nativní VBA makra, ale jsou stále zranitelné vůči útokům injekcí vzorců, pokud obsahují škodlivé příkazy, které Excel spustí při otevření.

Q5: Jak se moderní Office Scripts liší od tradičních VBA maker?

Office Scripts běží na TypeScriptu v sandboxovaném runtime prostředí, což jim brání přistupovat k vašemu místnímu souborovému systému, příkazové řádce nebo API operačního systému.

Viz také

• CSV vs XLSX vs ODS v roce 2026: Nejlepší formát tabulek pro vývojáře
• XLS vs XLSX vs XLSM vs XLSB – Výběr správného formátu tabulek
• Co je Excel? Klíčové informace, které potřebujete vědět
• Formáty souborů Excel: XLSX, XLSM, XLS, XLTX, XLTM
• Rozdíl mezi XLS a XLSX