Hi folks,
today I’d like to share a nice trick to unprotect password protected VB scripts into Office files. Nowadays it’s easy to find out malicious contents wrapped into OLE files since such a file format has the capability to link objects into documents and viceversa. An object could be a simple external link, a document itself or a more complex script (such as Visual Basic Script) and it might easily interact with the original document (container) in order to change contents and values.
Attackers are frequently using embedded VB Scripts to perform malicious actions such as for example (but not limited to): payload downloading, landing steps, environment preparation and payload execution. Such a technique needs “the user agreement” before the execution takes place, but once the user gave the freedom to execute (see the following image) the linked code on the machine, the VB script would be free to download content from malicious website and later on to execute it the victim machine.
 |
| Enable “Scripting” Content |
Cyber Security Analysts often need to read “raw code” by opening it and eventually digging into obfuscation techniques and anti-code analysis in order to figure out what it really does. Indeed contemporary malware performs evasive techniques making the simple SandBox execution useless and advanced attackers are smart enough to block VB code through complex and strong passwords. Those techniques make the “raw code analysis” hard if the unlocking password is unknown. But again, the a Cyber Security Analyst really needs to open the document and to dig into “raw code” in oder to defend victims. How would I approach this problem ?
Following a simple method to help cyber security analysts (NB: this is a well known technique) to bypass password protected VB Scripts.
Let’s suppose you have an Excel file within Visual Basic code, and you want to read the password protected VB Script. Let’s call such a first Excel file: victim_file.
As a first step you need to open the victim_file. After opening it you need to create a additional excel file. Let’s call it: injector_file.xlsm. Open the VB editor and add the following code into Module1.
https://gist.github.com/marcoramilli/8e5157af532f4b3d50359d5a4b99f9f1.js
Now create a new module: Module2 with the following code. It represents the “calling function”. Run it and don’t close it.
https://gist.github.com/marcoramilli/471b7a23375b5e66e04bcba96d2f7fd5.js
It’s time to come back to your original victim_file, let’s open the VB Editor and: here we go ! Your code is plain clear text !
At that point you are probably wondering how this code works. So let’s have a quick and dirty explanation about it. Once the VBProject gets opened it visualizes a dialogBox asking for a password (a String). The WinAPI eventually checks if the input string is equals to the encoded static string (file body not code body) and it returns “True” (if the strings are equals) or “False” (if the strings are not equals). The function Hook() overrides the User32.dll DialogBoxParamA returning parameter by making it returns always the value “True”.
Technically speaking:
- Raw 45 saves the original “call” (User32.dll DialogBoxParamA) parameters into TmpBytes
- If the password is correct TempBytes(0) gets the right pointer to the current process
- If the password is not correct the script saves the original bytes into OriginalBytes (length 6)
- Raw 50 takes the address of MwDialogBoxProgram
- Raw 52 forces the right handler
- Raw 53 saves the current value
- Raw 54 forces the return par as True
- Raw 56 moves the just crafted parameters into the right location into user32.dll
Have nice VBA Password un-protection 😀
Disclaimer:
This is a well-known method: it is not new.
I wrote it down since it becomes useful for cyber security analyst to fight against Office Macro malware. Don’t use it unlawfully.
Do not use it to break legal documents.
I am not assuming any responsibility about the usage of such a script.
It works on my machine 😀 and I will not try to get it working on your 😀 (programming Horror humor)
