I was recently playing around with Excel and found a way of executing macros in default Office installations regardless of the macro setting level. Essentially, this represents an application whitelisting bypass and allows a user to tap into the Windows APIs with malicious intent via the macro.
The only requirements for the technique to work are to have a Windows desktop session and Microsoft Office installed on the host.
The finding was reported to Microsoft who determined that this behaviour was by design and kindly provided some mitigations that will stop the technique. These are detailed at the bottom of this post.
Personally, I don’t think this is expected behaviour and suspect it will affect a large number of organisations who do not want users to execute macros. I replied to them, saying as much and that I wanted to write a blog post about the technique if their view remained the same. Microsoft again confirmed this behaviour was by design and gave their blessing for a blog post, so here we are :-)
The method itself is nothing 1337, in fact it feels very script-kiddie like, and I was quite surprised it works…..but it does ¯\_(ツ)_/¯
I’ll simply walk through the steps to get a macro running before going into some caveats and mitigations. Although the run-through uses Excel, this technique also works in Word and PowerPoint with minor modification.
I tested this on a fully up-to-date version of Office 365 MSO (16.0.13426.20352) 64bit, but have been able to get it working on other versions as well. Therefore, I expect this will be a pretty universal application whitelisting bypass/LOLBIN when you have an RDP session.
The Method
On a Windows desktop with Office installed, start Excel and confirm that Macro settings are at their highest security in Trust Center i.e. “Disable all macros without notification”. Feel free to set anything else to try and tighten up settings further e.g. disabling trusted locations and so on; doing that didn’t make a difference for me.
Now, create a new workbook but do not save it. If you try to view macros in the document, you should find the buttons are all disabled, and it won’t be possible to create or run them.
Click the Cancel button and find the Macros button in the View toolbar. Click the button and select Record Macro
In the resulting popup box, leave everything as is and just select Ok.
Next, just click Stop Recording under the Macros button View in the toolbar.
If you now click View Macros under the same Macros button you should be presented with the macros box again... except this time, your newly created macro should be there and the edit, run etc buttons all enabled.
Clicking the Edit button, we can now edit the macro and then run it via the Run button.
Surprised? I was when it first happened!
At this point, we can execute macros within the constraints of any other security controls in place on the host. This includes being able to call Windows APIs in our VBA code (which I won’t go in to in this article). From here, it isn’t a great leap to get any of our pen testing tools running.
Caveats
Interestingly, after recording the macro, saving the workbook and reopening it, the macro still exists and can be edited, or new ones recorded. However, it is no longer possible to run them. Microsoft confirmed that the full macro security settings only take effect when opening an existing document as opposed to being in effect in a brand-new unsaved document. Therefore, this technique can’t be used for a remote attack. I will definitely still be using it to get some of my tools running if I have an RDP session though!
Mitigations
There are several mitigations to prevent this bypass, though it feels like they should be implemented automatically when macro settings are changed. Note that implementing these mitigations as detailed below will prevent all macros being executed on a host and doing so may break things e.g. running of digitally signed macros that are needed for specific functions.
Reading the mitigation information provided by Microsoft and posted on their website about disabling VBA in Office, it appeared that implementing any of the below mitigations could cause some usability problems such as an inability to use ActiveX controls or some wizards. I haven’t encountered any issues myself though. Further details can be found here:
Mitigation Option 1: Windows Registry
Per this post by Microsoft, setting the VBAOFF DWORD value to 1 in following registry subkey will also prevent macro execution, noting that the [OFFICE_VERSION] value will need to be replaced with the version of office that has been installed:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Office\[OFFICE_VERSION]\Common
If the value isn’t already there, it can just be added. This will prevent all users on a host from executing macros.
If only specific users should be prevented, then the HKCU registry hive can be used instead. Note though that users could override this setting themselves due to having write privileges in the HKCU registry hive.
Once this registry value is set, it is no longer possible to record or view macros in the UI:
Mitigation Option 2: Block VBE7.DLL or VBEUI.DLL
Running Process Hacker showed several VBA related DLLs being loaded into the Excel process while going through the bypass steps. Specifically, these were:
- VBE7.DLL
- VBEUI.DLL
- VBEUIRES.DLL
The location of these DLLs will vary depending on the system Excel is installed on (e.g. 32 or 64 bit), however on my host they were located in:
C:\Program Files\Microsoft Office\root\vfs\ProgramFilesCommonX64\Microsoft Shared\VBA\VBA7.1
Blocking either VBE7.DLL or VBEUI.DLL will prevent macros from being recorded and an error popup like the one below will occur when you try to:
Blocking VBEUIRES.DLL did not prevent a macro from being recorded, but it did prevent access to the UI in which they could be edited and then run. I didn’t look in into this any further, but it felt like simply preventing access to the UI may not mitigate the issue as it may have only prevented the ability to edit/execute macros via the GUI as opposed to actually prevent their execution.
Given the above, perhaps the best way to prevent bypass with this mitigation would be to simply prevent access to the DLLs’ parent folder.
Mitigation Option 3: Do Not Install VBA During Office Setup Process
Choose not to install VBA during the Office setup process. Clearly, this option will not help organisations that have already installed Office.
Conclusion
As I mentioned before, I was very surprised that this technique worked. The fact that it does, irrespective of macro security settings, isn’t insignificant in my view as it likely leaves many organisations exposed to what is effectively an application whitelisting bypass.
Hopefully this post will help make the issue more widely known and the mitigations will assist organisations in raising their security posture. In the meantime, with defences getting better and better, I will definitely be using this technique where the opportunity presents itself!