Utoljára frissítve: 2026. szeptember 28.

Excel fájlok biztonsága magyarázva: XLSX, XLSM és makrók kockázatai

Évtizedek óta a Microsoft Excel az üzleti műveletek univerzális motorjaként szolgál. Kiegyensúlyozza a vállalati költségvetéseket, megjeleníti a komplex adatállományokat, nyomon követi a készleteket, és elemző csővezetékeket hajt végre szinte minden iparágban.

Mégis, ez a számítási rugalmasság a táblázatokat állandó kedvenccé teszi a kibertámadók körében. A támadók már a 1990-es évek végi makróvírusok korától kezdve fegyverkeztek a táblázatokkal. Bár a Microsoft és a rendszergazdák több védelmi réteget vezettek be – például fájlformátum szétválasztást és alapértelmezett makróblokkolást –, a társadalmi mérnökség és a finom architekturális kockázatok továbbra is relevánssá teszik az Excelre irányuló támadásokat.

A reziliens biztonsági helyzet kiépítéséhez a fejlesztőknek, rendszergazdáknak és haladó felhasználóknak a munkafüzet felülete mögé kell nézniük. Fontos megérteni, hogyan működik az alapul szolgáló OpenXML formátum, hogyan különböznek az .xlsx és .xlsm architekturális szinten, valamint hogyan működnek a makró végrehajtási mechanizmusok a modern végpontok védelme érdekében.

1. A modern Excel fájlok felépítése: OpenXML lebontva

A Microsoft Office 2007 kiadása előtt az Excel elsősorban saját tulajdonú bináris formátumokkal mentette a fájlokat, leginkább a .xls formátummal (amelyet a Binary Interchange File Format, vagy BIFF8 szabályoz). A .xls fájlokban az adatrekordok, formázási definíciók, képletek és a Visual Basic for Applications (VBA) makrófolyamok egyetlen strukturált tároló konténerbe voltak csomagolva. Ez megnehezítette a programozott vizsgálatot, és lehetővé tette a támadók számára, hogy rosszindulatú payload szkripteket rejtsenek el átláthatatlan bináris szektorokban.

Az Excel 2007-től a Microsoft bevezette a Office Open XML (OOXML) szabványt (ECMA-376 és ISO/IEC 29500 szabványként). Az OOXML alatt az Excel munkafüzetek már nem monolitikus bináris blokkok, hanem zip-archívumok, amelyek hierarchikus XML dokumentumok, kapcsolati táblák és beágyazott médiaelemek struktúráját tartalmazzák.

A ZIP konténerben

Ha bármelyik szabványos modern Excel munkafüzetet a .zip kiterjesztésre nevezed át, akkor a tartalmát bármely szabványos kitömörítő programmal ki tudod csomagolni:

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

Ez a struktúraváltás azonnali biztonsági előnyöket hozott:

1. DPI (Deep Packet Inspection) & Gateway Visibility: A biztonsági eszközök, proxyk és végpont ügynökök valós időben ki tudják csomagolni az archívumot, és szöveges XML fákban kereshetnek gyanús karakterláncokat, külső URL-eket vagy beágyazott objektumokat.
2. Deterministic File Validation: Ha egy fájl azt állítja, hogy OpenXML dokumentum, de megsérti a séma korlátozásait, az Excel megtagadja a megnyitását, vagy egy sandboxolt helyreállítási módban futtatja.
3. Format Separation: A Microsoft szétválasztotta a hagyományos számítási táblázatokat az olyan fájloktól, amelyek képesek beágyazott eljárásos szkriptek végrehajtására.

2. XLSX vs. XLSM: Az architekturális határ

Az .xlsx és .xlsm közötti fő különbség az, hogy a fájlszerkezet engedélyezi-e a végrehajtható makróprojektek beillesztését.

A végrehajtási mechanizmus: Miért nem futtathat makrókat az XLSX

Egy gyakori kérdés a junior rendszergazdák és fejlesztők körében: Mi történik, ha egy támadó egy rosszindulatú .xlsm fájlt vesz, végrehajtható kódot injektál, és átnevezi a fájl kiterjesztését .xlsx-re?

Rövid válasz: A fájl nem fogja végrehajtani a makrót.

Az Excel nem kizárólag a fájl kiterjesztésre támaszkodik a végrehajtási szabályok meghatározásához. Egy .xlsx nevű fájl megnyitásakor:

1. Az Excel megvizsgálja a zip tartalmat, és hivatkozik a [Content_Types].xml fájlra.
2. Egy valódi .xlsx fájlban az összes definiált tartalomtípus szabványos adat elemeket képvisel (például worksheet, sharedStrings vagy styles).
3. Ha egy támadó manuálisan injektál egy lefordított VBA adatfolyamot (xl/vbaProject.bin) egy .xlsx csomagba, és frissíti a kapcsolódásokat, az Excel egy egyértelmű séma ellentmondással szembesül:
   • Látja, hogy a .xlsx kiterjesztés olyan tartalomtípusokhoz van kötve, amelyek makróképességet jeleznek.
   • Az Excel súlyos integritási hibát dob: “Excel cannot open the file ‘filename.xlsx’ because the file format or file extension is not valid. Verify that the file has not been corrupted…”
4. Ha a támadó érintetlenül hagyja a belső típusokat a bináris regisztrálása nélkül, az Excel a vbaProject.bin-t egy hivatkozás nélküli, árva mellékletnek tekinti a zip archívumban, és a betöltési ciklus során teljesen eldobja.

Ennek következtében egy fájl, amely szigorúan valódi .xlsx konténerként működik, nem képes natív VBA kódot futtatni. Azonban ez nem jelenti azt, hogy a .xlsx fájlok mentesek lennének minden támadási vektortól, ahogyan ezt a későbbi útmutatóban részletezzük.

3. Makrók kockázatai & a támadás életciklusa

A makrókat úgy tervezték, hogy automatizálják az ismétlődő könyvelési, pénzügyi modellezési és adatmanipulációs feladatokat a Visual Basic for Applications (VBA) segítségével. Mivel a VBA a munkahelyi automatizálásra készült, kiterjedt hozzáférést kapott az alatta lévő Windows operációs rendszerhez a Component Object Model (COM), a Windows Script Host (WSH) és a közvetlen Win32 API hívások révén.

Amikor egy nem megbízható makró végrehajtódik, azonos jogosultságokkal fut, mint a bejelentkezett felhasználó. Nem kerül egy virtualizált, JavaScript-szerű böngésző homokozóba.

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

Gyakori makró bejutási technikák

1. Automatikus végrehajtási horogok: A támadók a belső eseménykezelőkben, például a Sub Auto_Open() vagy a Private Sub Workbook_Open() függvényekben helyezik el a belépési pontot. Amint a felhasználó engedélyezi a végrehajtást, ezek a rutinok kattintás nélkül aktiválódnak a táblázaton belül.

2. Obfuszkáció és Stomping:

   • Karakterlánc obfuszkáció: A hasznos terhek URL-eket és rendszerhívásokat rejtenek el karaktertömbök, XOR kódolás, Base64 dekódolás vagy környezeti változók összefűzése (pl. Chr(112) & Chr(111) & Chr(119)...).
   • VBA Stomping: A VBA két formában létezik a vbaProject.bin fájlban: értelmezett forráskód és lefordított p-kód (pseudokód, amely a konkrét Office verzióra van célzva, amely lefordította). A támadók teljesen törölhetik a tiszta szöveges forráskódot, csak a lefordított p-kódot hagyva meg. Sok alapvető antivírus megoldás és statikus elemző csak a forrásfolyamot vizsgálja, így a p-kód addig észrevétlen marad, amíg egy megfelelő Office verzió nem hajtja végre.

3. A rendszer erőforrásainak kihasználása (LotL): A modern rosszindulatú makrók ritkán helyeznek el közvetlenül egy .exe fájlt a lemezen, ami azonnal riasztaná a Végpont Felismerő és Válaszoló (EDR) ügynököket. Ehelyett beépített rendszereszközökkel lépnek interakcióba:

   • WScript.Shell példányosítása a parancssori argumentumok végrehajtásához.
   • A PowerShell.exe meghívása a végrehajtási politika megkerülésével (-ExecutionPolicy Bypass -WindowStyle Hidden).
   • Natív Win32 API-k hívása a Declare PtrSafe Function CreateProcess vagy a VirtualAlloc segítségével, hogy shellkódot injektáljon közvetlenül a rendszer memóriájába.

4. Egyéb táblázat-fenyegetési vektorok (a szabványos VBA-n túl)

A környezet .xlsm fájlok ellenőrzése csak a harc felét jelenti. A támadók olyan mechanizmusokat is használnak, amelyek a hagyományos VBA-tól függetlenül működnek.

Dinamikus adatcsere (DDE) és a CSV befecskendezés

Az Excel egy örökölt protokollt, a Dynamic Data Exchange (DDE) nevűt tartalmazza, amelyet az alkalmazások közötti adatmegosztásra terveztek (például egy külön programból élő tőzsdei ticker adatok streamelése egy Excel cellába).

• Hogyan működik a képletinjekció: Amikor egy táblázatcellában a =, @, + vagy - karakterekkel kezdődik a szöveg, az Excel a tartalmat képletként értelmezi. Ha egy támadó irányítja a táblázatba exportált bemenetet (például egy nem szűrt „Megjegyzések” mezőt egy webalkalmazásból, amely CSV vagy XLSX formátumba exportál), akkor képes injektálni:

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

• Megnyitáskor az Excel kiértékeli a képletet, figyelmeztető üzenetet jelenít meg a külső alkalmazás indításáról, és ha a felhasználó jóváhagyja, elindítja a rendszer parancsértelmezőjét.

Excel 4.0 (XLM) örökölt makrók

Mielőtt a VBA 1993-ban megjelent volna, az Excel egy képlet-alapú makrórendszert használt, amelyet Excel 4.0 (XLM) makrók néven ismernek. Ezek a makrók dedikált makrólapokon helyezkednek el, nem pedig külön VBA projektben.

Mivel az XLM makrókat cellaképletekként (például =EXEC("calc.exe")) írják, megkerülik a legtöbb szabványos VBA statikus ellenőrző motorját. A támadók a 2010-es évek vége és a 2020-as évek eleje során részesítették előnyben az XLM makrókat, hogy elkerüljék az automatikus észlelést, mielőtt a Microsoft alapértelmezés szerint letiltotta volna őket a modern vállalati kiadásokban.

Kártevő külső kapcsolatok és OLE-objektumok

Egy hagyományos .xlsx munkafüzet továbbra is kockázatot jelenthet külső erőforrások révén:

• Beágyazott OLE csomagok: A támadó egy futtatható fájlt helyezhet el, amely beágyazott PDF ikonként van álcázva, közvetlenül a munkalapba.
• Külső munkafüzet hivatkozások és weblekérdezések: Egy XLSX tartalmazhat külső hivatkozásokat, amelyek a fájl megnyitásakor automatikusan HTTP GET kéréseket indítanak a támadó által irányított parancs‑ és vezérlő (C2) szerverek felé, elsősorban felderítéshez vagy netNTLM hash-gyűjtő támadásokhoz.

5. Vállalati megerősítés és mélységi védelem stratégiái

Az Excel által terjesztett fenyegetések elleni védekezéshez réteges megközelítés szükséges, amely magában foglalja a hálózati ellenőrzést, a rendszerkonfigurációt, a hozzáférés-ellenőrzéseket és a működési folyamatokat.

+─────────────────────────────────────────────────────────+
|                  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. A Web jelölés (MotW) makróblokkolásának érvényesítése

2022-ben a Microsoft frissítette az Office-alkalmazások alapértelmezett viselkedését: az internetről származó fájlokban lévő makrók alapértelmezés szerint blokkolva vannak.

Amikor egy felhasználó egy fájlt letölt egy böngészőn vagy külső kliensen keresztül, a Windows egy alternatív adatfolyammal (ADS) jelöli a fájlt, amelynek neve Zone.Identifier (a 3-as zóna az Internetet jelöli). Az ilyen jelzéssel ellátott fájlok esetén az Excel teljesen letiltja a makrókat, és egy piros biztonsági sávot jelenít meg: > “BIZTONSÁGI KOCKÁZAT: A Microsoft blokkolta a makrók futtatását, mert a fájl forrása nem megbízható.”

Adminisztratív intézkedés: Győződjön meg arról, hogy ez a viselkedés a Csoportházirend révén van érvényesítve, és a végfelhasználók nem tudják felülírni:

• GPO útvonal: User Configuration > Administrative Templates > Microsoft Excel 2016 > Excel Options > Security > Trust Center
• Beállítás: Engedélyezze a “Makrók blokkolása az Internetről származó Office-fájlokban”.

2. Támadási felület csökkentés (ASR) szabályainak konfigurálása

Azok a szervezetek, amelyek a Microsoft Defender for Endpoint-et használják, aktiválják a Office-alkalmazásokra kifejezetten tervezett alapvető Támadási Felület Csökkentés szabályokat:

• Office-alkalmazások letiltása a gyermekfolyamatok létrehozásában (GUID: D4F940AB-401B-4EFC-AADC-AD5F3C50688A)
  • Megakadályozza, hogy az Excel PowerShellt, CMD-t vagy szkriptmotorokat indítson el.
• Blokkold az Office alkalmazásokat, hogy ne injektáljanak kódot más folyamatokba (GUID: 75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84)
• Blokkold a Win32 API hívásokat az Office makrókból (GUID: 92E6390C-CF9E-43CE-BD8C-0E6F0FE66680)

3. Az Antimalware Scan Interface (AMSI) kihasználása

A Microsoft 365 modern verziói közvetlenül az AMSI-vel integrálják a VBA végrehajtását. Még ha egy támadó összetett karakterlánc-eltitkosítást vagy VBA stompingot is alkalmaz, a VBA futásidejű motor a rekonstruált, titkosítatlan parancsokat a telepített antivírus/EDR motorhoz továbbítja a végrehajtás pontosan egy ezredmásodperccel előtti pillanatban. Győződjön meg arról, hogy a végpontvédelme aktívan figyeli az AMSI futásidejű eseményeket.

4. Átállás megbízható helyekre és digitális tanúsítványokra

Azoknak a szervezeteknek, amelyek a mindennapi működéshez automatizált táblázatokra támaszkodnak:

• Távolítsa el a felhasználók Letöltések vagy asztali mappáiban lévő laza XLSM fájlokat.
• Használjon megbízható helyeket: Korlátozza a makrók végrehajtását kizárólag az IT adminisztrátorok által kezelt csak olvasható hálózati megosztásokra.
• Kódaláírás: Kötelezővé tegye, hogy minden belső fejlesztésű makrót kriptográfiai aláírással lássanak el, egy vállalati nyilvános kulcsú infrastruktúra (PKI) által kiadott tanúsítvánnyal. Állítsa be az Excelt úgy, hogy csak digitálisan aláírt makrókat hajtson végre, és csendben blokkolja a nem aláírtakat.

6. A fejlesztő nézőpontja: Biztonságos automatizálás kiépítése

Ha olyan szoftvert fejlesztesz, amely Excel fájlokat elemez, generál vagy felhasznál (pl. Python csővezetékek a pandas/openpyxl használatával, Node.js mikroszolgáltatások vagy C#/.NET alkalmazások), alkalmazd ezeket a fejlesztési óvintézkedéseket:

1. Tagadja el a nem várt fájlformátumokat a feltöltési határon: Ha az alkalmazásod pénzügyi jelentéseket vár, szigorúan ellenőrizd, hogy a bejövő fájlok megfelelnek-e a .xlsx formátumnak. Vizsgáld meg a belső varázsbájtokat (a szabványos zip fejléc 50 4B 03 04), és ellenőrizd, hogy nincs-e vbaProject.bin bejegyzés az archívum indexében, mielőtt a felhő tárolókba vagy adatbázisokba mentenéd.

2. Adatok tisztítása a képletinjekció ellen: Felhasználó által generált bemenet CSV vagy XLSX fájlokba exportálásakor helyezz egy aposztrófot (') vagy egy szóközt minden olyan cella elejére, amely veszélyes karakterrel kezdődik (=, +, -, @, \t, \r):

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

3. Váltás a VBA-ról Office Scripts vagy Web Add-inokra: A modern vállalati automatizálás érdekében teljesen szüntesd meg a régi VBA használatát:

   • Office Scripts: TypeScript-ben írt Office Scripts egy szandboxolt felhő környezetben fut, és tisztán működik a webes és asztali kiadásokon anélkül, hogy natív operációs rendszer hívásokat exponálná.
   • Office Web Add-ins: Szabványos HTML, CSS és modern JavaScript használatával épülnek, a webes kiegészítők a kezelt JavaScript API-kon keresztül kommunikálnak, és elkülönülnek a helyi operációs rendszertől.

7. Összefoglaló ellenőrzőlista a táblázatbiztonságról

• Alapértelmezés szerint .xlsx kényszerítése: Követelje meg, hogy minden szabványos felhasználói munkafolyamat .xlsx formátumban, makróktól mentesen mentse.
• Internet‑eredetű makrók blokkolása: Erősítse meg, hogy a MotW irányelv végrehajtása a szervezeténél GPO vagy Intune segítségével telepítve van.
• ASR szabályok engedélyezése: Tiltja meg az Office termékeknek, hogy parancsértelmezőket vagy gyermekfolyamatokat indítsanak.
• Az Excel 4.0 (XLM) elavulttá nyilvánítása: Biztosítsa, hogy a régi XLM makrómotorok végleg le legyenek tiltva minden munkaállomáson.
• Alkalmazás exportok tisztítása: Védje a CSV és Excel generálási rutinokat a CSV/képlet injekció ellen.
• Átállás az Office Scripts felé: A régi adminisztratív makrókat TypeScript‑alapú Office Scripts és kezelt API-k felé irányítsa át.

Ha a táblázatkezelőket nem csupán dokumentumfájlként, hanem végrehajtási képességekkel rendelkező strukturált szoftverkonténereként kezeljük, a biztonsági csapatok és fejlesztők hatékonyan semlegesíthetik a vállalati számítástechnikában létező legrégebbi támadási vektorok egyikét.

Gyakran Ismételt Kérdések (GYIK)

Q1: Futtathat-e egy .xlsx végződésű fájl rosszindulatú makrót?

Nem, az OpenXML szabvány szigorúan tiltja a makrókódot a .xlsx fájlokban, és az Excel elutasítja vagy eltávolítja a valódi .xlsx tárolóba befecskendezett VBA projektet.

Q2: Mit tegyek, ha egy Excel-fájl azt kéri, “Enable Editing” vagy “Enable Content”?

Csak akkor adjon engedélyt, ha ismeri a feladót és várt a fájlt; ez a felugró ablak az elsődleges ellenőrzőpont, amely lehetővé teszi a nem megbízható makrók kód végrehajtását.

Q3: Hogyan határozza meg a Microsoft Excel, hogy egy fájl az internetről származik-e?

A Windows egy rejtett “Mark of the Web” (Zone.Identifier) adatfolyamot csatol a letöltött fájlokhoz, amely jelzi az Excelnek, hogy védett nézetben nyissa meg őket, és alapértelmezés szerint blokkolja a makrókat.

Q4: Biztonságosabbak-e a CSV-fájlok, mint a XLSX és a XLSM fájlok?

A CSV fájlok nem tartalmazhatnak natív VBA makrókat, de sebezhetők a képletinjekciós támadásokra, ha rosszindulatú parancsokat tartalmaznak, amelyeket az Excel a megnyitáskor végrehajt.

Q5: Miben különböznek a modern Office Scripts a hagyományos VBA-makróktól?

Az Office Scripts a TypeScript-en fut egy sandboxolt futtatókörnyezetben, megakadályozva, hogy hozzáférjenek a helyi fájlrendszerhez, a parancssorhoz vagy a operációs rendszer API-jaihoz.

Lásd még

• CSV vs XLSX vs ODS 2026-ban: A legjobb táblázatformátum fejlesztőknek
• XLS vs XLSX vs XLSM vs XLSB – A megfelelő táblázatformátum kiválasztása
• Mi az Excel? A legfontosabb információk, amelyeket tudnia kell
• Excel fájlformátumok: XLSX, XLSM, XLS, XLTX, XLTM
• Az XLS és XLSX közötti különbség