We were recently asked by a customer how to block PowerShell from launching via macros embedded in MS Office files (xlx, doc, ppt, etc.). I did some research and found a handy tool for creating a bad Excel document that would launch PowerShell from a macro and connect back to my Kali box. That script can be located here:
I opened the malicious Excel file on my end user machine, and after disabling EMET protections (DEP protections effectively blocked this attack) I was able to successfully launch PowerShell from the macro inside Excel. Even though I had created a specific rule in Bit9 to block powershell.exe when launched as a child of excel.exe/word.exe/powerpoint.exe, it did not block the execution.
Turning to Carbon Black, I was able to determine the problem by searching for the powershell.exe process.
Digging into the code helped to further explain why the rule above wasn’t working. Instead of the macro calling powershell.exe directly from within excel, it writes a series of commands out to config.txt (standard text file), renames it from config.txt to config.vbs (Visual Basic Script) executes it. The windows scripting engine takes over and launches the .vbs file and as a result, powershell.exe is a child process of wscript.exe, not excel.exe. I modified the original rule, adding wscript.exe as the parent process and re ran my test.
Now, PowerShell is BLOCKED!
Doing a little bit more researched yielded another process to include: cscript.exe
Wscript.exe and cscript.exe are almost exactly identical, except that one is flagged as a windows application and the other is flagged as a console application.
Adding a rule to specifically block powershell.exe from being spawned by wscript.exe or cscripte.exe will work, but the real problem is MS Office products launching wscript.exe or cscript.exe especially considering the Windows Scripting Engine is almost as powerful as PowerShell.
If you are wanting to block MS Office products from launching powershell.exe and cmd.exe, you may want to consider adding a rules to block wscript.exe and cscript.exe as child processes.
In most cases MS Office products should not be spawning powershell.exe, cmd.exe, cscript.exe or wscript.exe. Having these rules in place will further protect your endpoints.