It’s no secret that phishing is the most widely used and most successful attack vector in breaches and targeted attack campaigns. Between the DNC breach, ransomware campaigns, and other high profile cases, we as an industry, are seeing it more and more often. It should come as no surprise that, as a result, penetration testers are turning to this attack vector more and more as well. To combat all this phishing, there are a number of controls and mitigations that can be applied. From spam filtering and DMARC, to user awareness training, all of these improvements also make our job, as pentesters, harder as well. One of the most common payloads in phishing attacks are MS Office documents laden with malicious VBA macros. A common countermeasure to this technique is to use an automated sandbox to open the document and execute the macro, in order to identify malicious behavior, and thereby protect the target user. This post will discuss one way to work around this technique.
Full disclosure, I did not come up with this idea by myself. The first person I heard mention it was kaospunk. He identified it and reported it to a particular vendor and, as a result, was not able to disclose specifics, such as PoC code, due to an NDA. However, he was able to discuss the general technique. What is described in this post is my (hackish) implementation.
So, you need to send an attachment that is going to get scrutinized by an automated sandbox. Some malware uses techniques to determine if it is being analyzed and prevent, or stop, execution. Others try to hide their malicious activity in some way. What if we could always let the macro execute through completion, but control when the malicious activity occurred? That’s the technique we will attempt today. One way this may be possible is by encrypting the malicious content, and decrypting it on the host. The issue we have here, is that the host needs to have the encryption key, and if we send it with our attachment, or in the macro itself, it does us no good. The way for dealing with this is to use a key that is known to us externally, and also known to the target, but not known to the sandbox. Think about this for a few moments and you’ll probably come to the realization that certain environment variables could serve this purpose. For our example were are going to go with the Active Directory domain name. For information on how to determine this externally, check out our post on the ntlm_info_enum Metasploit module.
So assuming we know the internal AD domain name, now our task is to get an Empire agent deployed through an Office VBA macro. The xor_macro.py script will read in a command (i.e. an Empire launcher) from a file and output some base64 encoded text to paste into your macro. This is actually the provided command, encrypted using the XOR cipher.
Disclosure: this is where things get hackish.
The macro we will use needs to have the capability of decrypting the code before it can execute. So we need base64 decryption and XOR capabilities. Now I’m no VBA expert, but I could not find any documentation for either of this functionality in any standard VBA library, so I turned to the Internet. The first of these capabilities I found provided in the format of an importable module, authored by Christian d’Heureuse, and hosted here: http://www.source-code.biz/snippets/vbasic/Base64Coder.bas.txt
The second feature, I did find, but could not attribute it to an author. As such, I have added it as a gist for reference.
The base of our macro is here. Take that and add in the output of the Python script, replacing the “’UPDATE HERE!!!” on line 9. Now, insert a new module in the VBA editor and the complete macro in as module 1. Next, insert an additional module and paste in the contents of Base64Coder.bas.txt there. With your two modules configured, you are all set to send the phish and collect your shell.
The beauty of this technique is that no matter what, the macro will XOR and execute the encrypted string. The only way the string will decrypt correctly is if the environment variable is the same as the encryption key (AD domain). As most sandboxes are implemented in virtual machines, it is unlikely that it will be on the same domain.
While this technique is definitely useful for bypassing a sandbox, there are other use cases as well. In particular, an attacker who had prior knowledge of an organization’s username schema could target specific users with specific payloads, making it impossible for one payload to execute against another user.
We have used this technique numerous times with great success. Hopefully others will find it as useful as we have. Happy hunting!
