Sidst opdateret: 28 Sept, 2026

Excel-fil sikkerhed forklaret: XLSX, XLSM og makro-risici
I årtier har Microsoft Excel stået som den universelle motor for forretningsdrift. Den balancerer virksomheders budgetter, visualiserer komplekse datasæt, sporer lagerbeholdning og driver analytiske pipelines på tværs af næsten alle brancher.
Alligevel gør netop denne beregningsmæssige fleksibilitet regneark til en vedvarende favorit blandt cybermodstandere. Angribere har udnyttet regneark siden de tidlige dage med makroviruser i slutningen af 1990’erne. Mens Microsoft og systemadministratorer har indført flere lag af forsvar — såsom filformatsegregering og standardblokerering af makroer — fortsætter social engineering og subtile arkitektoniske risici med at holde Excel‑fokuserede angreb relevante.
For at opbygge en robust sikkerhedsposition skal udviklere, administratorer og power‑brugere kigge under workbook‑grænsefladen. At forstå, hvordan det underliggende OpenXML‑format fungerer, hvordan .xlsx og .xlsm adskiller sig på et arkitektonisk niveau, og hvordan makro‑eksekveringsmekanikken virker, er afgørende for at forsvare moderne slutpunkter.
1. Anatomi af moderne Excel-filer: OpenXML dekonstrueret
Før udgivelsen af Microsoft Office 2007 gemte Excel primært filer i proprietære binære formater, mest bemærkelsesværdigt .xls‑formatet (styret af Binary Interchange File Format, eller BIFF8). I .xls‑filer blev dataregistre, formateringsdefinitioner, formler og Visual Basic for Applications (VBA)‑makrostrømme pakket ind i en enkelt struktureret lagringscontainer. Dette gjorde programmatisk inspektion vanskelig og tillod angribere at skjule ondsindede payload‑scripts inde i uigennemsigtige binære sektorer.
Fra og med Excel 2007 introducerede Microsoft Office Open XML (OOXML)‑standarden (standardiseret som ECMA-376 og ISO/IEC 29500). Under OOXML er Excel‑arbejdsbøger ikke længere monolitiske binære klumper. I stedet er de zip‑arkiver, der indeholder en hierarkisk struktur af XML‑dokumenter, relations‑tabeller og indlejrede medie‑ressourcer.
Inde i ZIP-beholderen
Hvis du tager en hvilken som helst standard moderne Excel-arbejdsbog og omdøber dens filtype til .zip, kan du udtrække dens indhold med ethvert standard dekomprimeringsværktøj:
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
Denne strukturelle ændring gav umiddelbare sikkerhedsfordele:
- DPI (Deep Packet Inspection) & Gateway-synlighed: Sikkerhedsapparater, proxyer og slutpunktagenter kan pakke arkivet ud i realtid og parse klartekst-XML-træer for at identificere mistænkelige strenge, eksterne URL’er eller indlejrede objekter.
- Deterministisk filvalidering: Hvis en fil hævder at være et OpenXML-dokument, men overtræder schemas begrænsninger, nægter Excel at åbne den eller kører den i en sandkasse-baseret gendannelsestilstand.
- Formatadskillelse: Microsoft adskilte almindelige beregningsregneark fra filer, der kan udføre indlejrede proceduremæssige scripts.
2. XLSX vs. XLSM: Den arkitektoniske grænse
Den primære forskel mellem .xlsx og .xlsm ligger i, om filstrukturen tillader inkludering af eksekverbare makroprojekter.
| Funktion / Dimension | .xlsx (Excel OpenXML-regneark) | .xlsm (Excel Makro-aktiveret regneark) |
|---|---|---|
| MIME-indholdstype | application/vnd.openxmlformats-officedocument.spreadsheetml.sheet | application/vnd.ms-excel.sheet.macroEnabled.12 |
| VBA-lagringscontainer | Strengt forbudt. Kan ikke gemme vbaProject.bin | Tilladt. Indeholder xl/vbaProject.bin |
| Risiko for indfødt udførelse | Ubetydelig for makroeksekvering; begrænset til formelindsprøjtning/DDE | Høj; kan køre automatiseret VBA-kode ved arbejdsbogsinteraktion |
| OpenXML Strengt Skema | Overholder strenge, makrofri XML-definitioner | Omfatter definitioner for ældre og moderne automatiseringsudvidelser |
| Bruger Visuel Indikator | Standard grøn regnearksikon | Regnearksikon med et udråbstegn |
Gennemførelsesmekanismen: Hvorfor XLSX ikke kan køre makroer
Et almindeligt spørgsmål blandt junioradministratorer og udviklere er: Hvad sker der, hvis en angriber tager en ondsindet .xlsm-fil, injicerer eksekverbar kode og omdøber filens udvidelse til .xlsx?
Det korte svar: Filen vil ikke udføre makroen.
Excel er ikke udelukkende afhængig af filudvidelsen for at bestemme eksekveringsregler. Når du åbner en fil med navnet .xlsx:
- Excel inspicerer zip-indholdet og refererer til
[Content_Types].xml. - I en ægte
.xlsx-fil repræsenterer alle definerede indholdstyper standarddataelementer (såsomworksheet,sharedStringsellerstyles). - Hvis en angriber manuelt injicerer en kompileret VBA-strøm (
xl/vbaProject.bin) i en.xlsx-pakke og opdaterer relationerne, støder Excel på en eksplicit schema-modstrid:- Den ser en
.xlsx-udvidelse bundet til indholdstyper, der indikerer makro‑funktionalitet. - Excel kaster en fatal integritetsfejl: "Excel kan ikke åbne filen ‘filename.xlsx’, fordi filformatet eller filudvidelsen ikke er gyldig. Bekræft at filen ikke er beskadiget…"
- Den ser en
- Hvis angriberen lader de interne typer være intakte uden at registrere den binære fil, behandler Excel
vbaProject.binsom en urefereret, forældreløs vedhæftning i zip-arkivet og kasserer den fuldstændigt under indlæsningscyklussen.
Følgelig kan en fil, der udelukkende fungerer som en ægte .xlsx-container, ikke køre indbygget VBA-kode. Det betyder dog ikke, at .xlsx-filer er fri for alle angrebsvektorer, som udforskes senere i denne vejledning.
3. Makro-risici & Angrebslivscyklussen
Makroer blev designet til at automatisere gentagne regnskabs-, finansmodel- og datamanipulationsopgaver via Visual Basic for Applications (VBA). Da VBA blev bygget til automatisering på arbejdspladsen, fik den omfattende adgang til det underliggende Windows-operativsystem gennem Component Object Model (COM), Windows Script Host (WSH) og direkte Win32 API‑kald.
Når en ikke‑betroet makro udføres, kører den med de præcis samme rettigheder som den loggede bruger. Den er ikke fanget i en virtualiseret JavaScript‑lignende browsersandkasse.
+--------------------------------------------------------------------------------+
| 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.
Almindelige makro-indtrængningsteknikker
Auto‑eksekverings‑hooks: Angribere placerer deres indgangspunkt i indbyggede hændelsesbehandlere såsom
Sub Auto_Open()ellerPrivate Sub Workbook_Open(). Så snart brugeren giver eksekveringsrettigheder, udløses disse rutiner uden at kræve nogen klik i regnearket.Obfuskering og Stomping:
- Strengobfuskering: Payloads skjuler URL’er og systemkald ved hjælp af tegnarrays, XOR-kodning, Base64-dekodning eller sammenkædning af miljøvariabler (f.eks.
Chr(112) & Chr(111) & Chr(119)...). - VBA Stomping: VBA findes i to former i
vbaProject.bin: fortolket kildekode og kompileret p-code (pseudo-kode målrettet den specifikke Office-version, der kompilerede den). Angribere kan slette den klare kildekode fuldstændigt og kun efterlade den kompilerede p-code. Mange grundlæggende antivirusløsninger og statiske analyser værktøjer inspicerer kun kilde‑strømmen, så p-code forbliver uopdaget indtil den eksekveres af en matchende Office-version.
- Strengobfuskering: Payloads skjuler URL’er og systemkald ved hjælp af tegnarrays, XOR-kodning, Base64-dekodning eller sammenkædning af miljøvariabler (f.eks.
Living off the Land (LotL): Moderne ondsindede makroer dropper sjældent en
.exe-fil direkte til disken, hvilket straks ville advare Endpoint Detection and Response (EDR)-agenter. I stedet interagerer de med indbyggede systemværktøjer:- Instantiere
WScript.Shellfor at udføre kommandolinjeargumenter. - Kald af
PowerShell.exemed eksekveringspolitikken omgået (-ExecutionPolicy Bypass -WindowStyle Hidden). - Kalder native Win32 API’er gennem
Declare PtrSafe Function CreateProcessellerVirtualAllocfor at injicere shellcode direkte i systemhukommelsen.
- Instantiere
4. Andre trusselsvektorer for regneark (Udover standard VBA)
At sikre et miljø mod .xlsm-filer er kun halvdelen af kampen. Modstandere bruger også mekanismer, der fungerer uafhængigt af traditionel VBA.
Dynamisk dataudveksling (DDE) og CSV injektion
Excel har en ældre protokol kaldet Dynamic Data Exchange (DDE), designet til at muliggøre datadeling mellem kørende programmer (for eksempel at streame live aktiekurser fra et separat program ind i en Excel-celle).
- Hvordan formelinjektion fungerer:
Når en regnearkscelle begynder med tegn som
=,@,+eller-, fortolker Excel indholdet som en formel. Hvis en angriber kontrollerer input, der eksporteres til et regneark (såsom et usanitiseret “Comments”-felt i en webapplikation, der eksporteres til CSV eller XLSX), kan de injicere:=cmd|'/C powershell.exe -w hidden -enc <base64_payload>'!A0 - Når den åbnes, evaluerer Excel formlen, advarer brugeren med en prompt om at starte et eksternt program, og hvis den godkendes, kører den systemskallen.
Excel 4.0 (XLM) ældre makroer
Før VBA blev introduceret i 1993, brugte Excel et formelbaseret makrosystem kendt som Excel 4.0 (XLM) makroer. Disse makroer findes i dedikerede makroark i stedet for et separat VBA-projekt.
Fordi XLM-makroer er skrevet som celleformler (såsom =EXEC("calc.exe")), omgår de mange standard VBA‑statiskinspektionsmotorer. Angribere foretrak XLM-makroer i slutningen af 2010’erne og begyndelsen af 2020’erne for at undgå automatiseret detektion, før Microsoft deaktiverede dem som standard i moderne virksomheds‑builds.
Ondsindede eksterne forbindelser og OLE-objekter
En almindelig .xlsx-projektmappe kan stadig udgøre en risiko gennem eksterne ressourcer:
- Indlejrede OLE-pakker: En angriber kan indsætte en eksekverbar fil maskeret som et indlejret PDF-ikon direkte i regnearket.
- Eksterne projektmappe‑links & web‑forespørgsler: En XLSX kan indeholde eksterne referencer, der automatisk initierer HTTP GET‑anmodninger til angriber‑styrede command-and-control (C2)-servere ved filåbning, primært brugt til rekognoscering eller netNTLM‑hash‑indsamling angreb.
5. Virksomhedshærdning og dybdegående forsvarsstrategier
Forsvar mod Excel‑bårne trusler kræver en lagdelt tilgang, der dækker netværksinspektion, systemkonfiguration, adgangskontroller og operationelle processer.
+─────────────────────────────────────────────────────────+
| 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. Gennemtving Mark of the Web (MotW) makroblokkering
I 2022 opdaterede Microsoft standardadfærden for Office-programmer: makroer i filer, der stammer fra internettet, er blokeret som standard.
Når en bruger downloader en fil via en browser eller ekstern klient, mærker Windows filen med en alternativ datastrøm (ADS) kaldet Zone.Identifier (Zone 3 angiver internettet). For filer med dette mærke deaktiverer Excel makroer fuldstændigt og viser et rødt sikkerhedsbanner: > “SIKKERHEDS RISIKO: Microsoft har blokeret makroer fra at køre, fordi kilden til denne fil er upålidelig.”
Administrativ handling: Sørg for, at denne adfærd håndhæves via gruppepolitik og ikke kan tilsidesættes af slutbrugere:
- GPO-sti:
User Configuration > Administrative Templates > Microsoft Excel 2016 > Excel Options > Security > Trust Center - Indstilling: Aktiver “Blokér makroer fra at køre i Office-filer fra internettet”.
2. Konfigurer regler for reduktion af angrebsflade (ASR)
Organisationer, der bruger Microsoft Defender for Endpoint, bør aktivere kerne-regler for reduktion af angrebsflade, som er designet specifikt til Office-programmer:
Blokér Office-programmer fra at oprette underprocesser(GUID:D4F940AB-401B-4EFC-AADC-AD5F3C50688A)- Forhindrer Excel i at starte PowerShell, CMD eller script-motorer.
Blokér Office‑programmer fra at injicere kode i andre processer(GUID:75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84)Blokér Win32 API‑kald fra Office‑makroer(GUID:92E6390C-CF9E-43CE-BD8C-0E6F0FE66680)
3. Udnyt Antimalware Scan Interface (AMSI)
Moderne versioner af Microsoft 365 integrerer VBA‑eksekvering direkte med AMSI. Selv hvis en angriber anvender kompleks strengobfuskering eller VBA‑stomping, sender VBA‑runtime‑motoren de rekonstruerede, ukrypterede kommandoer til din installerede antivirus/EDR‑motor på nøjagtigt det millisekund før udførelse. Sørg for, at din endpoint‑beskyttelse aktivt overvåger AMSI‑runtime‑begivenheder.
4. Overgå til betroede placeringer og digitale certifikater
For organisationer, der er afhængige af automatiserede regneark til den daglige drift:
- Eliminer løse XLSM‑filer i brugernes Download‑ eller skrivebordsmapper.
- Brug betroede placeringer: Begræns makroeksekvering udelukkende til skrivebeskyttede netværksdelinger, der administreres af IT‑administratorer.
- Kodeunderskrift: Påkræv, at alle internt udviklede makroer kryptografisk signeres med et certifikat udstedt af virksomhedens Public Key Infrastructure (PKI). Konfigurer Excel til kun at køre digitalt signerede makroer og stiltiende blokere usignerede.
6. Udviklerens perspektiv: Byg sikker automatisering
Hvis du bygger software, der parser, genererer eller bruger Excel-filer (f.eks. Python-pipelines ved brug af pandas/openpyxl, Node.js-mikrotjenester eller C#/.NET-applikationer), skal du anvende disse udviklingssikringer:
Afvis uventede filformater ved upload-grænsen: Hvis din applikation forventer finansrapporter, skal du strengt validere, at indkommende filer overholder
.xlsx. Undersøg de interne magiske bytes (standard zip‑header50 4B 03 04) og bekræft, at der ikke findesvbaProject.bin-poster i arkivindekset, før du gemmer dem i cloud‑spande eller databaser.Rens data mod formel‑injektion: Når du eksporterer bruger‑genereret input til CSV‑ eller XLSX‑filer, skal du foranstille et apostrof (
') eller et mellemrum til enhver celle, der begynder med farlige tegn (=,+,-,@,\t,\r):def sanitize_for_spreadsheet(value: str) -> str: if value and value[0] in ('=', '+', '-', '@', '\t', '\r'): return f"'{value}" return valueMigrer fra VBA til Office Scripts eller web‑add‑ins: For moderne virksomhedsautomatisering skal du fjerne den ældre VBA fuldstændigt:
- Office Scripts: Skrrevet i TypeScript kører Office Scripts i et sandbox‑cloud‑miljø og fungerer problemfrit på både web‑ og desktop‑udgaver uden at eksponere native OS‑systemkald.
- Office Web Add-ins: Bygget ved hjælp af standard HTML, CSS og moderne JavaScript, kommunikerer web‑add‑ins via styrede JavaScript‑API’er og er isoleret fra det lokale operativsystem.
7. Opsummerings-tjekliste for regnearks-sikkerhed
- Gennemtving
.xlsxsom standard: Kræv, at alle standard brugerarbejdsgange gemmes som makrofri.xlsx. - Blokér makroer fra internettet: Bekræft, at MotW‑politikken er implementeret i hele organisationen via GPO eller Intune.
- Aktivér ASR‑regler: Forbyd Office‑produkter at starte kommandofortolkere eller underprocesser.
- Fas ned Excel 4.0 (XLM): Sørg for, at ældre XLM‑makro‑motorer er permanent deaktiveret på alle arbejdsstationer.
- Sanitér applikations‑eksport: Beskyt CSV‑ og Excel‑genereringsrutiner mod CSV/formel‑injektion.
- Skift mod Office Scripts: Overfør ældre administrative makroer til TypeScript‑baserede Office Scripts og styrede API’er.
Ved at betragte regneark ikke blot som dokumentfiler, men som strukturerede software‑containere med eksekveringsmuligheder, kan sikkerhedsteams og udviklere effektivt neutralisere en af de ældste angrebsvektorer i virksomhedens IT.
Ofte stillede spørgsmål (FAQ)
Q1: Kan en fil, der ender på .xlsx, køre en ondsindet makro?
Nej, OpenXML-standarden forbyder strikt makrokode i .xlsx-filer, og Excel vil afvise eller fjerne ethvert VBA-projekt, der er indsprøjtet i en ægte .xlsx-container.
Q2: Hvad skal jeg gøre, hvis en Excel-fil beder mig om “Aktiver redigering” eller “Aktiver indhold”?
Giv kun tilladelser, hvis du kender afsenderen og forventede filen; denne prompt er det primære kontrolpunkt, der tillader utroværdige makroer at udføre kode.
Q3: Hvordan bestemmer Microsoft Excel, om en fil kommer fra internettet?
Windows vedhæfter en skjult “Mark of the Web” (Zone.Identifier)-strøm til downloadede filer, hvilket signalerer til Excel at åbne dem i Beskyttet visning og som standard blokere makroer.
Q4: Er CSV-filer sikrere end XLSX og XLSM filer?
CSV-filer kan ikke indeholde indfødte VBA-makroer, men de er stadig sårbare over for formel‑injektionsangreb, hvis de indeholder ondsindede kommandoer, der udføres af Excel ved åbning.
Q5: Hvordan adskiller moderne Office Scripts sig fra traditionelle VBA-makroer?
Office Scripts kører på TypeScript inden for et sandkasse‑runtime‑miljø, hvilket forhindrer dem i at få adgang til dit lokale filsystem, kommandolinje eller operativsystem‑API’er.