Последно актуализирано: 28 септември, 2026

XLSX vs. XLSM Security: How Spreadsheet Macros Expose Your Network

Обяснение на сигурността на Excel файлове: XLSX, XLSM и рискове от макроси

В продължение на десетилетия Microsoft Excel е универсален двигател на бизнес операциите. Той балансира корпоративните бюджети, визуализира сложни набори от данни, следи инвентара и захранва аналитичните процеси във почти всяка индустрия.

Въпреки това, същата изчислителна гъвкавост прави електронните таблици постоянен фаворит сред киберпротивниците. Нападателите използват електронни таблици като оръжие още от ранните дни на макровирусите в края на 1990‑те. Докато Microsoft и системните администратори са въвели множество слоеве защита — като разделяне на файлови формати и блокиране на макроси по подразбиране — социалното инженерство и фините архитектурни рискове продължават да поддържат атаките, насочени към Excel‑focused, релевантни.

За да се изгради устойчива сигурност, разработчиците, администраторите и напредналите потребители трябва да погледнат под интерфейса на работната книга. Разбирането как функционира подлежащият OpenXML формат, как .xlsx и .xlsm се различават на архитектурно ниво и как работят механиките за изпълнение на макроси е от съществено значение за защитата на съвременните крайни точки.

1. Анатомия на съвременните Excel файлове: OpenXML разграден

Преди издаването на Microsoft Office 2007, Excel запазваше файловете главно с проприетарни бинарни формати, най-известният от тях е форматът .xls (регулиран от Binary Interchange File Format, или BIFF8). В .xls файловете записите на данни, дефинициите за форматиране, формулите и потоците на макроси на Visual Basic for Applications (VBA) бяха пакетирани в един структуриран контейнер за съхранение. Това правеше програмната инспекция трудна и позволяваше на нападателите да скриват зловредни скриптове за полезен товар в непрозрачни бинарни сектори.

Започвайки с Excel 2007, Microsoft въведе стандарта Office Open XML (OOXML) (стандартизиран като ECMA-376 и ISO/IEC 2950). При OOXML работните книги на Excel вече не са монолитни бинарни блокове. Вместо това те са zip архиви, съдържащи йерархична структура от XML документи, таблици за връзки и вградени медийни ресурси.

Вътре в ZIP контейнера

Ако вземете каквато и да е стандартна съвременна Excel работна книга и преименувате разширението й на .zip, можете да извлечете съдържанието ѝ с всяко стандартно средство за декомпресиране:

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

Това структурно изменение донесе незабавни ползи за сигурността:

  1. DPI (Дълбока проверка на пакети) & Видимост на шлюза: Сигурностните устройства, прокситата и агентите на краен пункт могат да разопаковат архива в движение и да анализират XML дървета в чист текст, за да идентифицират подозрителни низове, външни URL адреси или вградени обекти.
  2. Детерминистична проверка на файлове: Ако файл твърди, че е OpenXML документ, но нарушава схематичните ограничения, Excel отказва да го отвори или го стартира в режим на възстановяване в пясъчник.
  3. Разделяне на формати: Microsoft отдели обикновените изчислителни електронни таблици от файлове, способни да изпълняват вградени процедурни скриптове.

2. XLSX vs. XLSM: Архитектурната граница

Основната разлика между .xlsx и .xlsm се състои в това дали файловата структура позволява включването на изпълними макро проекти.

Функция / Измерение.xlsx (Excel OpenXML електронна таблица).xlsm (Excel електронна таблица с макроси)
MIME тип на съдържаниетоapplication/vnd.openxmlformats-officedocument.spreadsheetml.sheetapplication/vnd.ms-excel.sheet.macroEnabled.12
Контейнер за съхранение на VBAСтрого забранено. Не може да съхранява vbaProject.binРазрешено. Съдържа xl/vbaProject.bin
Риск от нативно изпълнениеНе съществен за изпълнение на макроси; ограничен до вмъкване на формули/DDEВисок; може да изпълнява автоматизиран VBA код при взаимодействие с работната книга
Строга схема OpenXMLОтговаря на строги, безмакросни XML дефиницииВключва дефиниции за наследени и съвременни разширения за автоматизация
Визуален индикатор за потребителяСтандартна зелена икона за електронна таблицаИкона на електронна таблица с удивителен знак

Механизмът за прилагане: Защо XLSX не може да изпълнява макроси

Често задаван въпрос сред младши администратори и разработчици е: Какво се случва, ако нападателят вземе зловреден файл .xlsm, вмъкне изпълним код и преименува разширението на файла на .xlsx?

Краткият отговор: Файлът няма да изпълни макроса.

Excel не разчита изключително на разширението на файла, за да определи правилата за изпълнение. При отваряне на файл с име .xlsx:

  1. Excel проверява zip съдържанието и се позовава на [Content_Types].xml.
  2. В истински .xlsx файл всички дефинирани типове съдържание представляват стандартни данни (като worksheet, sharedStrings или styles).
  3. Ако нападателят ръчно вмъкне компилиран VBA поток (xl/vbaProject.bin) в .xlsx пакет и актуализира връзките, Excel среща явен конфликт в схемата:
    • Той вижда разширение .xlsx, свързано с типове съдържание, които указват възможност за макрос.
    • Excel генерира фатална грешка на целостта: "Excel не може да отвори файла ‘filename.xlsx’, защото форматът на файла или разширението не е валидно. Проверете дали файлът не е повреден…"
  4. Ако нападателят остави вътрешните типове непроменени, без да регистрира бинарния файл, Excel третира vbaProject.bin като нереферирано, осиротено прикачено файлче в zip архива и го отхвърля изцяло по време на цикъла на зареждане.

Следователно, файл, който функционира стриктно като истински .xlsx контейнер, не може да изпълнява нативен VBA код. Въпреки това, това не означава, че .xlsx файловете са свободни от всички вектори на атака, както е разгледано по-късно в това ръководство.

3. Рискове от макроси & Жизненият цикъл на атаката

Макросите бяха създадени за автоматизиране на повтарящи се задачи в счетоводството, финансовото моделиране и манипулирането на данни чрез Visual Basic for Applications (VBA). Тъй като VBA беше изграден за автоматизация на работното място, му беше предоставен обширен достъп до подлежащата Windows операционна система чрез Component Object Model (COM), Windows Script Host (WSH) и директни повиквания към Win32 API.

Когато се изпълни недоверен макрос, той работи с точно същите привилегии като влезлия потребител. Той не е затворен в виртуализирана браузърна пясъчница в стил 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.

Общи техники за навлизане на макроси

  1. Куки за автоматично изпълнение: Нападателите поставят точката си за влизане във вградените обработващи събития, като Sub Auto_Open() или Private Sub Workbook_Open(). Веднага след като потребителят предостави разрешения за изпълнение, тези рутинни се задействат без да се изискват кликвания в електронната таблица.

  2. Обфускация и Stomping:

    • Обфускация на низове: Полезните товари скриват URL адреси и системни извиквания, използвайки масиви от символи, XOR кодиране, Base64 декодиране или конкатенация на променливи от средата (например Chr(112) & Chr(111) & Chr(119)...).
    • VBA Stomping: VBA съществува в две форми в vbaProject.bin: интерпретиран изходен код и компилиран p-code (псевдо‑код, насочен към конкретната версия на Office, която го компилира). Нападателите могат напълно да изтрият изходния код в чист текст, оставяйки само компилирания p-code. Много базови антивирусни решения и статични анализатори проверяват само потока от изходен код, като оставят p-code недетектиран, докато не бъде изпълнен от съвпадаща версия на Office.
  3. Използване на вградените ресурси (LotL): Съвременните злонамерени макроси рядко пускат .exe файл директно на диска, което би сигнализирало незабавно на агентите за откриване и реакция на крайни точки (EDR). Вместо това, те взаимодействат с вградените системни инструменти:

    • Създаване на инстанция на WScript.Shell за изпълнение на аргументи от командния ред.
    • Извикване на PowerShell.exe с заобикаляне на политиката за изпълнение (-ExecutionPolicy Bypass -WindowStyle Hidden).
    • Извикване на родни Win32 API чрез Declare PtrSafe Function CreateProcess или VirtualAlloc за вмъкване на шелкод директно в системната памет.

4. Други вектори на заплаха за електронни таблици (извън стандартния VBA)

Осигуряването на среда срещу файлове .xlsm е само половината от битката. Противниците също използват механизми, които работят независимо от традиционния VBA.

Динамичен обмен на данни (DDE) и CSV инжекция

Excel разполага със наследен протокол, наречен Dynamic Data Exchange (DDE), създаден за споделяне на данни между работещи приложения (например, поточно предаване на живи данни от борсов тикер от отделна програма в клетка на Excel).

  • Как работи инжектирането на формули: Когато клетка в електронна таблица започне със знаци като =, @, + или -, Excel интерпретира съдържанието като формула. Ако нападателят контролира входните данни, експортирани в електронна таблица (например, неочистено поле „Comments“ в уеб приложение, експортирано в CSV или XLSX), той може да инжектира:
    =cmd|'/C powershell.exe -w hidden -enc <base64_payload>'!A0
    
  • При отваряне Excel оценява формулата, предупреждава потребителя с диалог за стартиране на външно приложение и, ако бъде одобрено, изпълнява системната обвивка.

Excel 4.0 (XLM) наследени макроси

Преди въвеждането на VBA през 1993 г., Excel използваше макросна система, базирана на формули, известна като Excel 4.0 (XLM) макроси. Тези макроси се намират в специални листове за макроси, а не в отделен VBA проект.

Тъй като XLM макросите са написани като клетъчни формули (например =EXEC(\"calc.exe\")), те заобикалят много стандартни статични инспекционни механизми на VBA. Нападателите предпочитаха XLM макроси през късните 2010‑ти и началото на 2020‑те години, за да избегнат автоматично откриване, преди Microsoft да ги изключи по подразбиране в съвременните корпоративни версии.

Злонамерени външни връзки и OLE обекти

Обикновен .xlsx работен лист все още може да представлява риск чрез външни ресурси:

  • Вградени OLE пакети: Нападателят може да вмъкне изпълним файл, маскиран като вграден PDF икона, директно в работния лист.
  • Външни връзки към работни книги и уеб заявки: XLSX файл може да съдържа външни препратки, които автоматично изпращат HTTP GET заявки към контролирани от нападателя командно‑управляващи (C2) сървъри при отваряне на файла, като се използват главно за разузнаване или атаки за събиране на netNTLM хешове.

5. Укрепване на предприятието и стратегии за защита в дълбочина

Защитата срещу заплахи, произтичащи от Excel, изисква многослойен подход, обхващащ мрежова инспекция, конфигурация на системата, контрол на достъпа и оперативни процеси.

+─────────────────────────────────────────────────────────+
|                  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. Прилагане на маркировка на уеб (MotW) за блокиране на макроси

През 2022 г. Microsoft актуализираше стандартното поведение на Office приложенията: макросите във файлове, произхождащи от интернет, са блокирани по подразбиране.

Когато потребител изтегли файл чрез браузър или външен клиент, Windows маркира файла с алтернативен поток от данни (ADS) на име Zone.Identifier (Зона 3 указва Интернет). За файлове с тази маркировка, Excel изключва макросите изцяло и показва червено сигурностно съобщение: > "СИГУРНОСТЕН РИСК: Microsoft блокира изпълнението на макроси, защото източникът на този файл е недоверен."

Административно действие: Уверете се, че това поведение се прилага чрез Group Policy и не може да бъде променяно от крайните потребители:

  • Път към GPO: User Configuration > Administrative Templates > Microsoft Excel 2016 > Excel Options > Security > Trust Center
  • Настройка: Включете "Блокиране на макроси от изпълнение в Office файлове от Интернет".

2. Конфигуриране на правила за намаляване на атакуващата повърхност (ASR)

Организациите, използващи Microsoft Defender for Endpoint, трябва да активират основните правила за намаляване на атакуващата повърхност, проектирани специално за Office приложения:

  • Block Office applications from creating child processes (GUID: D4F940AB-401B-4EFC-AADC-AD5F3C50688A)
    • Предотвратява Excel от стартиране на PowerShell, CMD или скриптови двигатели.
  • Блокиране на Office приложенията от инжектиране на код в други процеси (GUID: 75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84)
  • Блокиране на Win32 API повиквания от Office макроси (GUID: 92E6390C-CF9E-43CE-BD8C-0E6F0FE66680)

3. Използване на интерфейса за сканиране на антивирусен софтуер (AMSI)

Съвременните версии на Microsoft 365 интегрират изпълнението на VBA директно с AMSI. Дори и атакуващият да приложи сложна обфускация на низове или VBA stomping, изпълнителната среда на VBA предава реконструираните, некриптирани команди към вашия инсталиран антивирусен/EDR двигател точно в последната милисекунда преди изпълнението. Уверете се, че вашата защита на крайните точки активно следи събитията на AMSI по време на изпълнение.

4. Преминаване към доверени местоположения и цифрови сертификати

За организации, които разчитат на автоматизирани електронни таблици за ежедневните операции:

  • Премахнете разхвърляни XLSM файлове в папките „Downloads“ или „Desktop“ на потребителите.
  • Използвайте доверени местоположения: Ограничете изпълнението на макроси изключително до мрежови споделяния само за четене, управлявани от ИТ администраторите.
  • Подписване на код: Налагайте всички вътрешно разработени макроси да бъдат криптографски подписани с сертификат, издаден от корпоративна инфраструктура за публични ключове (PKI). Конфигурирайте Excel да изпълнява само цифрово подписани макроси и тихо да блокира неподписаните.

6. Перспективата на разработчика: Създаване на сигурна автоматизация

Ако създавате софтуер, който анализира, генерира или консумира Excel файлове (например Python конвейери, използващи pandas/openpyxl, Node.js микросервизи или C#/.NET приложения), приложете тези мерки за разработка:

  1. Отхвърляне на неочаквани файлови формати при границата на качване: Ако вашето приложение очаква финансови отчети, стриктно проверявайте дали входящите файлове отговарят на .xlsx. Прегледайте вътрешните магически байтове (стандартният zip хедър 50 4B 03 04) и се уверете, че в индекса на архива няма записи vbaProject.bin, преди да ги запишете в облачни кофи или бази данни.

  2. Дезинфекция на данните срещу инжекция на формули: При експортиране на потребителски вход в CSV или XLSX файлове, добавете апостроф (') или интервал пред всяка клетка, започваща с опасни знаци (=, +, -, @, \t, \r):

    def sanitize_for_spreadsheet(value: str) -> str:
        if value and value[0] in ('=', '+', '-', '@', '\t', '\r'):
            return f"'{value}"
        return value
    
  3. Преминаване от VBA към Office Scripts или уеб добавки: За модерна корпоративна автоматизация, премахнете напълно наследения VBA:

    • Office Scripts: Написани на TypeScript, Office Scripts се изпълняват в изолирана облачна среда и работят безпроблемно както в уеб, така и в настолните версии, без да излагат системните повиквания на ОС.
    • Office Web Add-ins: Изградени с използване на стандартен HTML, CSS и съвременен JavaScript, уеб добавките комуникират чрез управлявани JavaScript API‑та и са изолирани от локалната операционна система.

7. Обобщен контролен списък за сигурност на електронните таблици

  • Налагане на .xlsx по подразбиране: Изисква всички стандартни потребителски работни процеси да се запазват като макрос‑без .xlsx.
  • Блокиране на макроси, произхождащи от интернет: Потвърдете, че прилагането на политика MotW е внедрено във вашата организация чрез GPO или Intune.
  • Активиране на правила ASR: Забранява на Office продуктите да създават командни интерпретатори или подпроцеси.
  • Отмяна на Excel 4.0 (XLM): Уверете се, че наследените XLM макрос двигатели са постоянно изключени на всички работни станции.
  • Пречистване на експорти от приложението: Защитете процедурите за генериране на CSV и Excel от CSV/инжектиране на формули.
  • Преминаване към Office Scripts: Преобразувайте наследените административни макроси в Office Scripts, управлявани от TypeScript, и използвайте управлявани API‑та.

Като третираме електронните таблици не само като документни файлове, а като структурирани софтуерни контейнери, които притежават възможности за изпълнение, екипите по сигурност и разработчиците могат ефективно да неутрализират един от най-старите вектори на атака в корпоративните изчисления.

Често задавани въпроси (FAQ)

Въпрос 1: Може ли файл, завършващ на .xlsx, да изпълни злонамерен макрос?

Не, стандартът OpenXML стриктно забранява макро код в .xlsx файлове и Excel ще отхвърли или премахне всеки VBA проект, вмъкнат в истински .xlsx контейнер.

Въпрос 2: Какво да направя, ако Excel файл ме попита да “Разреша редактиране” или “Разреша съдържание”?

Дайте разрешения само ако познавате подателя и очаквахте файла; това съобщение е основната проверка, която позволява на недоверени макроси да изпълняват код.

Въпрос 3: Как Microsoft Excel определя дали файлът е дошъл от интернет?

Windows прикрепя скрит поток “Mark of the Web” (Zone.Identifier) към изтеглените файлове, което сигнализира на Excel да ги отвори в Защитен изглед и по подразбиране да блокира макросите.

Въпрос 4: По-сигурни ли са CSV файловете от XLSX и XLSM файлове?

CSV файловете не могат да съдържат вградени VBA макроси, но остават уязвими към атаки с инжектиране на формули, ако съдържат злонамерени команди, изпълнявани от Excel при отваряне.

Въпрос 5: Как се различават съвременните Office Scripts от традиционните VBA макроси?

Office Scripts се изпълняват на TypeScript в изолирана среда за изпълнение, което им пречи да достъпват вашата локална файлова система, командния ред или API‑тата на операционната система.

Вижте още