Last Updated: 2020-10-26 21:53:07 UTC
by Didier Stevens (Version: 1)
Excel 4 macros are composed of formulas (commands) and values stored inside a sheet.
Each sheet in a spreadsheet can be "visible", "hidden" or "very hidden". Malware authors will often make Excel 4 macro sheets hidden or very hidden.
In .xls files, spreadsheet data is stored in the Workbook stream as BIFF records. There is a BIFF record for sheets: the BOUNDSHEET record. The byte value at position 5 in a BOUNDSHEET record defines the visibility of a sheet: visible (0x00), hidden (0x01) or very hidden (0x02):
Encoding the visibility of a sheet is done with the 2 least significant bits. Per Microsoft's documentation, the 6 more significant bits are unused bits and must be ignored. In spreadsheets created with Excel, these bits are set to 0.
From time to time, I find malicious Excel 4 macro documents, where these bits are not zero:
oledump's plugin_biff will report this: "reserved bits not zero".
The "visibility" value is 0x0A, that's 0x08 + 0x02: thus the sheet is very hidden (0x02).
Excel has no problem at all opening a spreadsheet like this (the unused bits must be ignored). But if you use or develop detection rules like YARA, Suricata, ... ; be aware that these unused bits can be set to 1 in stead of 0.
You might wonder: 2 bits to encode visibility. Visible (0x00), hidden (0x01) or very hidden (0x02).
What about 0x03?
When a sheet's visibility is set to 0x03 (I do this by patching the .xls with a binary editor), my tests with Excel 2016 and 2019 show that an Excel 4 macro sheet will behave as "very hidden", and the macro code will be executed.
However, before a user is prompted to enable macros, that user will have to click through extra warnings: