Ultimo aggiornamento: 28 set, 2026

Sicurezza dei file Excel spiegata: XLSX, XLSM e rischi delle macro

Per decenni, Microsoft Excel è stato il motore universale delle operazioni aziendali. Bilancia i budget aziendali, visualizza set di dati complessi, tiene traccia dell’inventario e alimenta le pipeline analitiche in praticamente tutti i settori.

Tuttavia, quella stessa flessibilità computazionale rende i fogli di calcolo una scelta duratura tra gli avversari informatici. Gli aggressori hanno armato i fogli di calcolo fin dai primi giorni dei virus macro alla fine degli anni ‘90. Sebbene Microsoft e gli amministratori di sistema abbiano introdotto più livelli di difesa — come la segregazione dei formati di file e il blocco predefinito delle macro — l’ingegneria sociale e i rischi architetturali sottili continuano a mantenere rilevanti gli attacchi incentrati su Excel.

Per costruire una postura di sicurezza resiliente, sviluppatori, amministratori e utenti avanzati devono guardare al di sotto dell’interfaccia della cartella di lavoro. Comprendere come funziona il formato OpenXML sottostante, come .xlsx e .xlsm differiscono a livello architettonico e come funzionano i meccanismi di esecuzione delle macro è fondamentale per difendere gli endpoint moderni.

1. Anatomia dei moderni file Excel: OpenXML decostruito

Prima del rilascio di Microsoft Office 2007, Excel salvava i file principalmente utilizzando formati binari proprietari, in particolare il formato .xls (regolato dal Binary Interchange File Format, o BIFF8). Nei file .xls, i record dei dati, le definizioni di formattazione, le formule e i flussi di macro Visual Basic for Applications (VBA) erano confezionati in un unico contenitore di storage strutturato. Questo rendeva difficile l’ispezione programmatica e consentiva agli aggressori di nascondere script di payload dannosi all’interno di settori binari opachi.

A partire da Excel 2007, Microsoft ha introdotto lo standard Office Open XML (OOXML) (standardizzato come ECMA-376 e ISO/IEC 29500). Con OOXML, le cartelle di lavoro di Excel non sono più blocchi binari monolitici. Invece, sono archivi zip contenenti una struttura gerarchica di documenti XML, tabelle di relazioni e risorse multimediali incorporate.

All’interno del contenitore ZIP

Se prendi qualsiasi cartella di lavoro Excel moderna standard e ne rinomini l’estensione in .zip, puoi estrarre i suoi contenuti con qualsiasi utility di decompressione standard:

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

Questo cambiamento strutturale ha fornito immediatamente benefici di sicurezza:

1. DPI (Ispezione Profonda dei Pacchetti) & Visibilità del Gateway: I dispositivi di sicurezza, i proxy e gli agenti endpoint possono decomprimere l’archivio al volo e analizzare gli alberi XML in chiaro per identificare stringhe sospette, URL esterni o oggetti incorporati.
2. Validazione Deterministica del File: Se un file dichiara di essere un documento OpenXML ma viola i vincoli dello schema, Excel rifiuta di aprirlo o lo esegue in modalità di recupero sandbox.
3. Separazione del Formato: Microsoft ha separato i fogli di calcolo computazionali regolari dai file in grado di eseguire script procedurali incorporati.

2. XLSX vs. XLSM: Il confine architettonico

La principale differenza tra .xlsx e .xlsm risiede nel fatto che la struttura del file consenta o meno l’inclusione di progetti macro eseguibili.

Il meccanismo di applicazione: Perché XLSX non può eseguire macro

Una domanda comune tra gli amministratori junior e gli sviluppatori è: Cosa succede se un aggressore prende un file .xlsm maligno, inietta codice eseguibile e rinomina l’estensione del file in .xlsx?

La risposta breve: Il file non eseguirà la macro.

Excel non si basa esclusivamente sull’estensione del file per determinare le regole di esecuzione. Quando si apre un file chiamato .xlsx:

1. Excel esamina il contenuto zip e fa riferimento a [Content_Types].xml.
2. In un file .xlsx genuino, tutti i tipi di contenuto definiti rappresentano elementi di dati standard (come worksheet, sharedStrings o styles).
3. Se un aggressore inietta manualmente un flusso VBA compilato (xl/vbaProject.bin) in un pacchetto .xlsx e aggiorna le relazioni, Excel incontra una contraddizione esplicita dello schema:
   • Vede un’estensione .xlsx legata a tipi di contenuto che indicano la capacità di macro.
   • Excel genera un errore fatale di integrità: “Excel non può aprire il file ‘filename.xlsx’ perché il formato del file o l’estensione del file non è valido. Verifica che il file non sia stato corrotto…”
4. Se l’attaccante lascia intatti i tipi interni senza registrare il binario, Excel tratta vbaProject.bin come un allegato non referenziato e orfano all’interno dell’archivio zip e lo scarta completamente durante il ciclo di caricamento.

Di conseguenza, un file che opera strettamente come un vero contenitore .xlsx non può eseguire codice VBA nativo. Tuttavia, ciò non significa che i file .xlsx siano privi di tutti i vettori di attacco, come esplorato più avanti in questa guida.

3. Rischi delle macro e il ciclo di vita dell’attacco

Le macro sono state progettate per automatizzare attività ripetitive di contabilità, modellazione finanziaria e manipolazione dei dati tramite Visual Basic for Applications (VBA). Poiché VBA è stato creato per l’automazione in ambito lavorativo, è stato dotato di ampio accesso al sistema operativo Windows sottostante attraverso il Component Object Model (COM), Windows Script Host (WSH) e chiamate dirette alle API Win32.

Quando una macro non attendibile viene eseguita, funziona con gli stessi privilegi esatti dell’utente connesso. Non è confinata all’interno di una sandbox virtualizzata in stile browser 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.

Tecniche comuni di ingresso di macro

1. Hook di auto-esecuzione: Gli aggressori inseriscono il loro punto di ingresso nei gestori di eventi intrinseci come Sub Auto_Open() o Private Sub Workbook_Open(). Non appena l’utente concede i permessi di esecuzione, queste routine si attivano senza richiedere alcun clic all’interno del foglio di calcolo.

2. Offuscamento e Stomping:

   • Offuscamento di Stringhe: I payload nascondono URL e chiamate di sistema usando array di caratteri, codifica XOR, decodifica Base64 o concatenazione di variabili d’ambiente (ad es., Chr(112) & Chr(111) & Chr(119)...).
   • VBA Stomping: VBA esiste in due forme all’interno di vbaProject.bin: codice sorgente interpretato e p-code compilato (pseudo-codice mirato alla specifica versione di Office che lo ha compilato). Gli aggressori possono cancellare completamente il codice sorgente in chiaro, lasciando solo il p-code compilato. Molte soluzioni antivirus di base e gli analizzatori statici ispezionano solo il flusso sorgente, lasciando il p-code non rilevato fino a quando non viene eseguito da una versione di Office corrispondente.

3. Sfruttare le risorse di sistema (LotL): Le macro dannose moderne raramente rilasciano un file .exe direttamente su disco, il che avvertirebbe immediatamente gli agenti di Endpoint Detection and Response (EDR). Invece, interagiscono con gli strumenti di sistema integrati:

   • Istanziare WScript.Shell per eseguire argomenti da riga di comando.
   • Invocare PowerShell.exe con l’aggiramento della politica di esecuzione (-ExecutionPolicy Bypass -WindowStyle Hidden).
   • Chiamare le API native Win32 tramite Declare PtrSafe Function CreateProcess o VirtualAlloc per iniettare shellcode direttamente nella memoria di sistema.

4. Altri vettori di minaccia per i fogli di calcolo (oltre VBA standard)

Proteggere un ambiente dai file .xlsm è solo metà della battaglia. Gli avversari utilizzano anche meccanismi che operano indipendentemente dal VBA tradizionale.

Scambio dinamico di dati (DDE) e iniezione di CSV

Excel include un protocollo legacy chiamato Dynamic Data Exchange (DDE), progettato per consentire la condivisione di dati tra applicazioni in esecuzione (ad esempio, lo streaming di dati in tempo reale di un ticker azionario da un programma separato in una cella di Excel).

• Come funziona l’iniezione di formule: Quando una cella di un foglio di calcolo inizia con caratteri come =, @, + o -, Excel interpreta il contenuto come una formula. Se un aggressore controlla l’input esportato in un foglio di calcolo (ad esempio, un campo “Commenti” non sanitizzato in un’applicazione web esportato in CSV o XLSX), può iniettare:

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

• Quando viene aperto, Excel valuta la formula, avvisa l’utente con una richiesta di avvio di un’applicazione esterna e, se approvata, esegue la shell di sistema.

Macro legacy di Excel 4.0 (XLM)

Prima che VBA fosse introdotto nel 1993, Excel utilizzava un sistema di macro basato su formule noto come Excel 4.0 (XLM) macro. Queste macro risiedono all’interno di fogli macro dedicati anziché in un progetto VBA separato.

Poiché le macro XLM sono scritte come formule di cella (ad esempio =EXEC(\"calc.exe\")), eludono molti motori di ispezione statica VBA standard. Gli aggressori hanno preferito le macro XLM alla fine del 2010 e all’inizio del 2020 per evitare il rilevamento automatico prima che Microsoft le disattivasse per impostazione predefinita nelle versioni aziendali moderne.

Connessioni Esterne Malevole e Oggetti OLE

Un normale file di lavoro .xlsx può comunque introdurre rischi tramite risorse esterne:

• Pacchetti OLE incorporati: Un aggressore può inserire un eseguibile mascherato da icona PDF incorporata direttamente nel foglio di lavoro.
• Collegamenti a cartelle di lavoro esterne e query web: Un file XLSX può contenere riferimenti esterni che avviano automaticamente richieste HTTP GET verso server di comando e controllo (C2) controllati dall’aggressore all’apertura del file, utilizzati principalmente per ricognizione o attacchi di raccolta di hash netNTLM.

5. Rafforzamento Aziendale e Strategie di Difesa a Strati

Difendersi dalle minacce veicolate da Excel richiede un approccio a più livelli che copra l’ispezione di rete, la configurazione del sistema, i controlli di accesso e i processi operativi.

+─────────────────────────────────────────────────────────+
|                  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. Applicare il Mark of the Web (MotW) per il Blocco delle Macro

Nel 2022, Microsoft ha aggiornato il comportamento predefinito delle applicazioni Office: le macro nei file provenienti da Internet sono bloccate per impostazione predefinita.

Quando un utente scarica un file tramite un browser o un client esterno, Windows etichetta il file con un flusso di dati alternativo (ADS) chiamato Zone.Identifier (la Zona 3 indica Internet). Per i file che presentano questo segno, Excel disabilita completamente le macro e mostra un banner di sicurezza rosso: > “RISCHIO DI SICUREZZA: Microsoft ha bloccato l’esecuzione delle macro perché la fonte di questo file non è attendibile.”

Azione amministrativa: Assicurati che questo comportamento sia applicato tramite Criteri di gruppo e non possa essere sovrascritto dagli utenti finali:

• Percorso GPO: User Configuration > Administrative Templates > Microsoft Excel 2016 > Excel Options > Security > Trust Center
• Impostazione: Abilita “Blocca l’esecuzione delle macro nei file Office provenienti da Internet”.

2. Configurare le Regole di Riduzione della Superficie di Attacco (ASR)

Le organizzazioni che utilizzano Microsoft Defender for Endpoint dovrebbero attivare le regole principali di Riduzione della Superficie di Attacco progettate specificamente per le applicazioni Office:

• Block Office applications from creating child processes (GUID: D4F940AB-401B-4EFC-AADC-AD5F3C50688A)
  • Impedisce a Excel di avviare PowerShell, CMD o motori di scripting.
• Blocca le applicazioni Office dall'iniettare codice in altri processi (GUID: 75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84)
• Blocca le chiamate API Win32 dalle macro di Office (GUID: 92E6390C-CF9E-43CE-BD8C-0E6F0FE66680)

3. Sfruttare l’Interfaccia di Scansione Antimalware (AMSI)

Le versioni moderne di Microsoft 365 integrano l’esecuzione VBA direttamente con AMSI. Anche se un attaccante applica una complessa offuscazione di stringhe o VBA stomping, il motore di runtime VBA passa i comandi ricostruiti e non crittografati al tuo antivirus/EDR installato esattamente al millisecondo prima dell’esecuzione. Assicurati che la protezione del tuo endpoint monitori attivamente gli eventi di runtime AMSI.

4. Passare a Posizioni Fidate e Certificati Digitali

Per le organizzazioni che dipendono da fogli di calcolo automatizzati per le operazioni quotidiane:

• Elimina i file XLSM sparsi nelle cartelle Download o Desktop degli utenti.
• Usa Posizioni Attendibili: Limita l’esecuzione delle macro esclusivamente a condivisioni di rete in sola lettura gestite dagli amministratori IT.
• Firma del Codice: Richiedi che tutte le macro sviluppate internamente siano firmate crittograficamente usando un certificato emesso da un’infrastruttura a chiave pubblica (PKI) aziendale. Configura Excel per eseguire solo macro firmate digitalmente e blocca silenziosamente quelle non firmate.

6. Prospettiva dello Sviluppatore: Costruire Automazione Sicura

Se stai sviluppando software che analizza, genera o utilizza file Excel (ad esempio pipeline Python che usano pandas/openpyxl, microservizi Node.js o applicazioni C#/.NET), applica queste misure di sicurezza nello sviluppo:

1. Rifiuta Formati di File Inaspettati al Momento del Caricamento: Se la tua applicazione si aspetta report finanziari, valida rigorosamente che i file in ingresso siano conformi a .xlsx. Controlla i byte magici interni (l’intestazione zip standard 50 4B 03 04) e verifica che non esistano voci vbaProject.bin nell’indice dell’archivio prima di salvarli in bucket cloud o archivi di database.

2. Sanitizza i Dati Contro l’Iniezione di Formule: Quando esporti input generati dagli utenti in file CSV o XLSX, anteponi un apostrofo (') o uno spazio a qualsiasi cella che inizi con caratteri pericolosi (=, +, -, @, \t, \r):

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

3. Migra da VBA a Office Scripts o Web Add-in: Per l’automazione aziendale moderna, elimina completamente il VBA legacy:

   • Office Scripts: Scritti in TypeScript, gli Office Scripts vengono eseguiti all’interno di un ambiente cloud sandbox e operano senza problemi sia nelle versioni web che desktop, senza esporre chiamate di sistema native dell’OS.
   • Office Web Add-ins: Realizzati utilizzando HTML, CSS standard e JavaScript moderno, i componenti aggiuntivi web comunicano tramite API JavaScript gestite e sono isolati dal sistema operativo locale.

7. Checklist Riassuntiva per la Sicurezza dei Fogli di Calcolo

• Imponi .xlsx per impostazione predefinita: Richiedi a tutti i flussi di lavoro standard degli utenti di salvare come .xlsx senza macro.
• Blocca macro di origine Internet: Conferma che l’applicazione della politica MotW sia distribuita in tutta l’organizzazione tramite GPO o Intune.
• Abilita regole ASR: Vietare ai prodotti Office di avviare interpreti di comando o processi figli.
• Depreca Excel 4.0 (XLM): Assicurati che i motori macro XLM legacy siano disabilitati permanentemente su tutte le postazioni.
• Sanitizza le esportazioni dell’applicazione: Proteggi le routine di generazione di CSV ed Excel contro iniezioni CSV/formula.
• Passa a Office Scripts: Trasforma le macro amministrative legacy in Office Scripts basati su TypeScript e API gestite.

Considerando i fogli di calcolo non solo come file di documento, ma come contenitori software strutturati che possiedono capacità di esecuzione, i team di sicurezza e gli sviluppatori possono neutralizzare efficacemente una delle più antiche vettori di attacco nell’informatica aziendale.

Domande frequenti (FAQ)

Q1: Un file con estensione .xlsx può eseguire una macro dannosa?

No, lo standard OpenXML vieta rigorosamente il codice macro nei file .xlsx, e Excel rifiuterà o rimuoverà qualsiasi progetto VBA inserito in un contenitore .xlsx genuino.

Q2: Cosa devo fare se un file Excel mi chiede di “Abilitare la modifica” o “Abilitare il contenuto”?

Concedi le autorizzazioni solo se conosci il mittente e ti aspettavi il file; questo avviso è il punto di controllo principale che consente alle macro non attendibili di eseguire codice.

Q3: Come fa Microsoft Excel a determinare se un file proviene da Internet?

Windows aggiunge un flusso nascosto “Mark of the Web” (Zone.Identifier) ai file scaricati, il quale segnala a Excel di aprirli in Visualizzazione protetta e bloccare le macro per impostazione predefinita.

Q4: I file CSV sono più sicuri rispetto ai file XLSX e XLSM?

I file CSV non possono contenere macro VBA native, ma rimangono vulnerabili agli attacchi di iniezione di formule se contengono comandi dannosi eseguiti da Excel all’apertura.

Q5: In che modo gli Office Scripts moderni differiscono dalle macro VBA tradizionali?

Gli Office Scripts vengono eseguiti su TypeScript all’interno di un ambiente di runtime sandbox, impedendo loro di accedere al tuo file system locale, alla riga di comando o alle API del sistema operativo.

Vedi anche

• CSV vs XLSX vs ODS nel 2026: Il miglior formato di foglio di calcolo per gli sviluppatori
• XLS vs XLSX vs XLSM vs XLSB - Scegliere il formato di foglio di calcolo corretto
• Cos’è Excel? Informazioni chiave che devi conoscere
• Formati di file Excel: XLSX, XLSM, XLS, XLTX, XLTM
• Differenza tra XLS e XLSX