How to Inspect a Macro-Enabled Excel File Before You Trust It
A practical guide for anyone who’s ever hovered over “Enable Content” and wondered if they should.
You receive an .xlsm file from a vendor, a colleague, or a download. It asks you to enable macros. Before you click that button, there’s a better question to ask: what does this macro actually do?
This guide walks through a repeatable process for inspecting macro-enabled Office files — without running them first.
Why This Matters
Macros are Visual Basic for Applications (VBA) programs embedded in Office documents. They can automate legitimate tasks like building Gantt charts or generating reports, but they can also execute system commands, download files from the internet, or exfiltrate data. The problem is that Office gives you no way to tell the difference before you enable them.
Making things worse: files can be password-protected, which locks the VBA editor inside Office and prevents you from reading the code through normal means. This is sometimes legitimate (vendors protecting IP), sometimes suspicious.
The good news is that password protection only blocks the Office UI — it doesn’t protect the underlying binary.
What You’ll Need
olevba is the primary tool. It’s part of the oletools Python package, developed by Philippe Lagadec, and it reads VBA source code directly from the file binary, bypassing password protection entirely.
Windows
Open a command prompt and run pip install oletools. That’s it.
Mac — Read This First
Mac requires a couple of extra steps. macOS ships with Python 2 (or no Python at all on newer versions), and running pip install oletools will either fail or try to install into a system location Apple doesn’t want you touching.
Step 1: Install Python 3 via Homebrew
If you don’t have Homebrew installed yet, open Terminal and run this command:
/bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)”
Then install Python 3 with brew install python3 and verify with python3 –version.
Step 2: Create a virtual environment
macOS will block pip install at the system level with an externally-managed-environment error. The fix is to install into a virtual environment instead — an isolated folder that doesn’t touch system Python at all.
Create the environment once with python3 -m venv oletools-env, then activate it with source oletools-env/bin/activate. Your prompt will change to show (oletools-env). Now run pip install oletools.
When you’re done, run deactivate to exit the environment. Next time you want to use olevba, just run source oletools-env/bin/activate first.
Step 1: Run the Basic Scan
Run olevba your_file.xlsm replacing the filename with your actual file. This extracts all VBA modules and produces a summary table at the bottom flagging suspicious keywords. It looks something like this:
Type: AutoExec — Keyword: Workbook_Open — Runs when the Excel Workbook is opened
Type: Suspicious — Keyword: Shell — May run an executable file or system command
Type: Suspicious — Keyword: CreateObject — May create an OLE object
Type: IOC — Keyword: https://example.com — URL
Don’t panic at this table. Every flag needs to be read in context — a Shell call that opens a saved PDF is very different from one that executes a downloaded payload.
Step 2: Read the Actual Code
The summary table tells you what keywords exist. The code tells you what they do. Scroll up from the summary and read through each module.
Here’s what to look for:
AutoExec Triggers
These run automatically without any user interaction. The function is called Workbook_Open and it executes the moment macros are enabled. Pay close attention to Workbook_Open, Auto_Open, and Document_Open — these are the entry points. Start reading here.
Shell and Command Execution
This is the most dangerous class of behavior. A legitimate use opens a known application like Windows Explorer with a file path. A suspicious one passes an encoded string to PowerShell — something like Shell “powershell -enc ” & encodedCommand. Encoded PowerShell is a significant red flag. It means the author is deliberately hiding what’s being executed.
Network Activity
Code that creates a WinHttpRequest object and calls a URL isn’t automatically malicious — license validation, version checks, and telemetry are common. The question is: what URL, and what data is being sent? Check whether any sensitive data like usernames, file contents, or environment variables is included in the request.
Obfuscation
Legitimate code rarely needs to hide itself. Watch for long chains of Chr() calls building strings character by character, Base64-encoded strings being decoded at runtime, and variables with meaningless names holding fragments of a URL or command. For example, a string of Chr() calls decoding to “powershell” is a serious warning sign. Run olevba –decode to attempt automatic deobfuscation.
Step 3: Understand VBA Stomping
olevba sometimes flags VBA Stomping — a condition where the stored source code and the compiled P-code differ. This matters because Office can execute either version, and they may not do the same thing. When detected, the summary will flag it as suspicious with the message “VBA source code and P-code are different.”
This has two common explanations:
- Vendor IP protection — commercial software vendors sometimes strip or obfuscate the source while keeping the compiled P-code intact. The macro works, but you can’t easily read it.
- Deliberate evasion — malware authors use this to show scanners one thing while actually executing another.
Context matters here. A stomped file from a known vendor with a plausible business reason is very different from a stomped file that arrived via email from an unknown sender.
Step 4: Check for the Real Red Flags
After reading the code, here are the things that should genuinely concern you, regardless of context:
| Finding | Why It’s Concerning |
|---|---|
| Encoded PowerShell (-enc, -encodedCommand) | Actively hiding executed commands |
| Downloads to %TEMP% then executes | Classic dropper behavior |
| Reads Office credentials or saved passwords | Data theft |
| Sends data to an unexpected external URL | Exfiltration |
| CreateObject(“Scripting.FileSystemObject”) writing files | Persistent malware installation |
| Multiple layers of deobfuscation | Evasion of security tools |
And here are things that look suspicious but usually aren’t:
| Finding | Likely Explanation |
|---|---|
| Shell opening a known application | Opening exported files, launching browser |
| CreateObject(“WinHttp…”) | License validation, update checks |
| Environ(“computername”) | License tying, telemetry |
| Mac-specific popen / libc.dylib calls | Cross-platform compatibility code |
| VBA Stomping on a commercial product | Vendor IP protection |
Step 5: For High-Stakes Files, Go Further
If the file is from an untrusted source or contains something you still can’t explain after reading the code, use these additional steps:
Run in an isolated environment. A virtual machine with no network access and no access to your real files is the safest way to observe runtime behavior. Tools like Any.run or Cuckoo Sandbox can automate this.
Rename and extract. .xlsm files are ZIP archives. Change the extension to .zip, extract, and look at xl/vbaProject.bin alongside the XML files in xl/. You can sometimes find hardcoded strings, URLs, or file paths that aren’t obvious in the VBA source.
Search the hash. Run the file through VirusTotal. If it’s a known malicious file or a known legitimate commercial product, you’ll often find it there.
A Complete Example Workflow
Windows: Run pip install oletools, then olevba suspicious_file.xlsm to scan. Add –decode to the command if you see encoded strings. Pipe to a text file with olevba suspicious_file.xlsm > analysis.txt to save the output for sharing.
Mac: Activate your environment first with source oletools-env/bin/activate, then run the same olevba commands above. The same commands work on .docm and .pptm files too.
The Decision Framework
After completing the analysis, the decision comes down to three questions:
- Can I explain every suspicious flag? If yes, and the explanations are plausible given the source of the file, enable with confidence.
- Is there anything I can’t explain? If yes, don’t enable until you can. Reach out to the vendor, check community forums, or run it in isolation first.
- Does the source match the behavior? A license validation call to shop.knownvendor.com from a file you downloaded from that vendor’s website is fine. The same call in a file that arrived unsolicited from an unknown email address is not.
Summary
Enabling macros without inspection is a habit worth breaking. The tools to do this properly are free, install in seconds, and bypass password protection that would otherwise stop you. A ten-minute review is usually enough to either confirm a file is safe or surface something that warrants a closer look.
The goal isn’t to become a malware analyst — it’s to develop enough familiarity with what legitimate macro code looks like that you can recognize when something doesn’t fit.
Tools referenced: oletools by Philippe Lagadec — free, open source, actively maintained.
Categories: Security, Cybersecurity, Productivity, Microsoft Office, How-To Guides
Tags: olevba, oletools, VBA macros, Excel security, macro analysis, xlsm, malware analysis, phishing, office documents, VBA stomping, Python, Homebrew, virtual environment, venv, macOS setup, Windows security, file inspection, enable macros, password protected files, WinHTTP, CreateObject, AutoExec, obfuscation, base64, PowerShell, VirusTotal, sandboxing, threat analysis, IT security, enterprise security