a word macro claimed harmless, olevba proved otherwise

somebody sent you a "harmless" invoice.docm

you've heard this line before. someone forwards a document, swears it's fine, maybe even opened it themselves and "nothing happened." cool story. you're not going to take their word for it, because word (the program) is the worst possible tool for checking if a word document is safe. it'll happily run macros before you've even finished reading the subject line. instead, you're going to read the file's actual contents without ever letting office anywhere near it.

what a .docm file actually is

a .docm is just a zip archive wearing a trenchcoat. inside that zip is a folder structure, and if the file has macros, one of those parts is a compiled vba project. static analysis means reading that vba code straight out of the archive, never executing it, never opening it in an office app, never giving it a chance to touch your system.

that's exactly what olevba does. it's part of the oletools suite, built specifically for pulling macros out of office documents and showing you what they do, in plain text, with zero risk of detonation.

breaking down the command

olevba invoice.docm

run that against a suspicious document and it dumps every vba module it finds, plus a summary of "suspicious keywords" it flagged along the way. in this case the output showed something like:

Sub AutoOpen()     <-- ran the moment the document did

AutoOpen    | Runs when the document is opened
Shell       | May run an executable
PowerShell  | May run PowerShell
Base64      | Base64-encoded strings

each of those lines matters on its own, but together they tell a story:

AutoOpen is a special vba function name. word doesn't need a button click or a macro-enabled prompt bypassed twice, it just runs AutoOpen the instant the document opens, assuming macros are enabled. that's the trigger.

Shell means the macro can launch an external program. legitimate macros almost never need this. invoices definitely don't.

PowerShell tells you the payload isn't just "run notepad," it's spinning up a scripting engine capable of downloading, executing, and hiding just about anything.

Base64 means part of the command is obfuscated. attackers encode their real payload so a quick glance at the macro source doesn't reveal a raw url or command line sitting in plaintext.

put those four together: autoopen plus shell plus powershell plus base64 is a textbook downloader. the document isn't the malware, it's the delivery truck.

decoding the actual callback

olevba can also decode those base64 strings for you instead of leaving you to copy-paste into a decoder by hand:

olevba --decode invoice.docm | grep -io 'http[^"]*'

the --decode flag tells olevba to automatically decode any base64, hex, or other obfuscated strings it detects inside the macro. piping that into grep -io 'http[^"]*' just filters the giant wall of output down to anything that looks like a url, case-insensitively. in this example, it revealed:

http://185.199.4.71/a.ps1

that's the payload's actual home address. the macro's whole job was to quietly fetch a powershell script from that ip and run it, no download prompt, no warning, no antivirus popup if the timing was right. "the macro was harmless" turns out to mean "the macro was a loader for whatever that ip wants to push next."

the takeaway

you don't need to trust a document, a coworker's reassurance, or word's own security prompts. you need a static analysis tool that reads the code without running it. olevba does that in seconds, for free, and it works the same way whether you're checking one suspicious invoice or triaging a folder full of them.

to protect your own systems: disable macros by default org-wide (group policy or intune, block macros from internet-downloaded files specifically), scan incoming office attachments with oletools before they ever reach a mail client, and treat any AutoOpen plus Shell plus base64 combo as an automatic quarantine, no exceptions, no "just this once." if you ever find a live callback ip like the one above, block it at the firewall and check your logs for any host that already tried to reach it, because if one machine got the invoice, more than one probably opened it.