Click to Enable Content
ADVISORY: The techniques and tools referenced within this blog post may be outdated and do not apply to current situations. However, there is still potential for this blog entry to be used as an opportunity to learn and to possibly update or integrate into modern tools and techniques.
Evading anti-virus scanners has become a bit of a sport around BHIS. When we do C2 testing for our customers we start with a host on the internal network and create a reverse connection out to our C2 server. We then proceed to send various types of data in and out to see if we get caught. The goal is to demonstrate how well their defenses prevent and/or detect our shenanigans. Our success rate is quite high (meaning we usually are able to exfil data out of the network) and the primary reason for that is because identifying evil traffic can be very difficult! Attackers can obfuscate their traffic so that anti-virus scanners and other security devices do not detect a hint of wrong-doing. Typically, anti-virus scanners and intrusion prevention/detection engines block or alert on known bad signatures or behaviors. This is a blacklist approach. So as long as we can change our traffic from known bad to anything else we can cruise right on by. So how do we get that initial connection out from the internal network to our C2 server without being noticed? Sometimes a simple PowerShell script that connects out to a Metasploit listener will do the trick. And other times we have to try a little harder.
On a recent test I was working on, we used a malicious PowerPoint presentation masquerading as an interesting slideshow that promised to reveal irresistible company gossip. The “urge to click” rating was high. Embedded in the PowerPoint presentation were Visual Basic commands that invoked a PowerShell script to connect out to a C2 server. The script was obfuscated using the awesome Veil-Evasion tool. Here is the run down….
First, we set up the listener on our C2 server. In this example, we are listening on port 443 using a reverse TCP connection. We selected port 443 because it is normally allowed outbound.
Next, we created our payload using Veil-Evasion. We only had to tell Veil-Evasion the address and port we wanted to connect to as well as the type of payload and it did all the rest.
The script generated by Veil-Evasion looks like this:
Veil-Evasion Obfuscated Script
As you can see above, Veil-evasion creates the script but there is one problem; the script is a one-liner that in this case consists of 2300 characters:
2300 Characters, One Line Script
The Visual Basic editor in Office will not be happy about this at all. As a matter of fact, this will cause an error. We need to find a way to break this script into smaller pieces that the VB compiler can deal with. Fortunately, someone has already done that for us. Macro_safe.py is a neat little python script written to solve just this problem. After running the output through the macro_safe.py script we get a version of our malicious script that PowerPoint will happily digest.
Macro_safe.py Breaks Long Lines Into Shorter Lines for Visual Basic
The next step then is to open up our PowerPoint presentation and add the “macro safe” code. First, we make sure we have access to the “Developer” tab in PowerPoint by adding it to the Ribbon if necessary. This can be done via the PowerPoint Options.
Enabling Developer Tab in PowerPoint
Before PowerPoint will allow us to create a Macro, we need to save the presentation as type .pps (PowerPoint 97-2003 Show) or .ppsm (PowerPoint Macro-Enabled Show). I like the legacy.pps extension because the “m” in newer versions of Office gives yet another clue that something is fishy. Then we click on the Developer tab, open up the Visual Basic interface and insert a new module. This is where we paste in the “macro safe” output containing the properly formatted Veil-Evasion script. These steps are shown below.
Once the macro exists in the document we need to find a way to trigger its execution. Microsoft Word and Excel both have options for running Macros automatically when the file is opened but PowerPoint does not. I have heard and read about hacks to accomplish the same in PowerPoint but, in this case, we will simply use Custom Actions in the presentation to trigger execution of the code when the user clicks inside the slideshow. I have created one text box that covers the entire first slide and applied the “On Mouse Click” action there. So when the user opens the presentation and clicks anywhere in the textbox on the first slide the macro executes and an outbound connection is created. One could also choose to execute the macro “On Mouse Over” as well, however, this may be a bit noisier as it will likely create multiple outbound connections.
But wait, macros are typically not enabled by default so the user would have to agree to this, right? Yep. It turns out that PowerPoint will display a very clear warning that this document could be malicious. “You should leave this content disabled unless the content provides critical functionality and you trust its source”. You might think this is a descriptive, understandable warning and would be enough to prevent users from enabling the unknown content. But it turns out…..
…if you send it – they will click. That is what the attackers are counting on. Now don’t get me wrong. I am not saying that users should always know better. The Internet is full of warnings and security personnel regularly allow untrusted certificates to be used that users are told to “click through”. Let’s face it – users get mixed messages so often that it is no surprise they have error message fatigue. Basically, when a user really wants to view the contents of a document s/he will click through almost any warning without realizing that very quietly in the background, something bad is happening – in this case their machine is reaching out to our C2 server.
With initial access to the machine the attacker can then proceed to upload or download files, attempt to elevate privileges, pivot to other machines, etc.
Our goal at BHIS is to educate our customers about the dangers of trusting anti-virus products to catch everything, as well as, the potential consequences of ignoring security warnings. So to that end, this Veil-Evasion obfuscated PowerPoint document was scanned with the Gmail scanner, Windows Defender, McAfee A/V and Symantec A/V. None of these tools detected malicious content. Check it out:
Gmail Fails to Detect the Malicious Document
McAfee Fails
Windows Defender Fails
Symantec …….. Nope
The bottom line? The only sign of trouble in our example here was a single warning from PowerPoint about enabling active content on a PowerPoint presentation and it was up to the end user to decide whether or not to proceed. If users must make these decisions they must be continuously educated on the potential dangers with which they are faced.
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
