Visual Basic Script (VBS) is one of the languages of time. It is a deprecated scripting language that exists in Microsoft Windows and surprisingly many parts of the Windows OS still execute it. There is Cscript, Wscript, and not to mention all of the different Microsoft Office applications that use it as a programming language for Macro components to handle automation in the document. This language, despite being well documented and well scanned, seems to still be a grand target for malware development.

Something I would like to try and explore is why is there so much malware in this space despite there being AMSI. You might say “you could disable AMSI then what?” and while you are right, a lot of these JScript, VBScript, and PowerShell script don’t go to the extent of disabling the AMSI hooks. Instead they focus immensely on obfuscation. Don’t get me wrong, scripted malware is a lot easier to execute and get rolling in memory than a binary executable. It also is easier to obfuscate in its entirety where a compiled binary, even in .NET, will have artifacts that are easily extracted and are terribly difficult to remove from the final artifact. Just this past week I was focusing a ton on a VisualBasic matryoshka doll which included embedded VBScript payloads which were string replaced and otherwise deobfuscated in memory before evaluation. To make matters worse, the payload itself contained a lot of dead code as well as code that should not evaluate correctly. This was a feature, not a bug as the top of the script is On Error Resume Next which is responsible for ensuring the script continues execution despite there being weird hiccups. This could cause lots of silly issues to occur if not careful but if done correctly it can cause a lot of automated analysis to break on the script enabling some really jank control flow obfuscation.

Some things I had talked with my collegues about was how to perform analysis of VBScript specifically when it is being heavily obfuscated in the way it is with the sample I was looking at. I personally wanted to do static analysis since that would require less system dependencies and can be handled just with a “simple” script. That proved weird since there are a lot of weird dependencies I have to account for as well as system updates which may be hard to resolve when not on a Windows machine. That is also just a Windows thing if you have ever debugged powershell or .NET programs. So another possible solution was to go from a dynamic approach. Instead of hooking the script itself in some weird re-writing way, you can use a debugging framework such as FRIDA to hook the interpreter. This would allow you to hook specific calls to evaluations in the interpreter for things like:

  • String concatenations
  • Function calls
  • Decodings
  • File operations
  • etc…

Then you can dump those operations or interesting strings based on rules you make out and write it to disk similar to something like Tiny Tracer. I may try to implement something like this in my own time or if I do it at work it’ll just be stuck there. Idk. We will see. In any case I do tend to like doing static analysis more if I can but just the need to handle every little thing to do small light emulation vs letting something that has already implemented everything and all you need to do is hook it can be painstaking. So time, effort, is it worth it, pain. It seems like a fun project that once I get it working it would prove a useful addition to Linux based analysis tools and it is another analysis I can get rid of Windows out of the equation lol.