Last time, I provided a method for encrypting macro payloads (https://warroom.rsmus.com/encrypt-macros-bypass-sandboxes/) to prevent them from executing correctly in the event they were analyzed in a sandbox. On a somewhat-related note, in this post, I will discuss another method which can help ensure your payload makes it successfully to your target: obfuscation. First, some caveats:
- This technique is not meant to solve the same problem as the encrypted payload.
- This technique is rather simple, and thus can be easily detected, by a human analyst, or by a thorough technical control.
If you are not familiar, “obfuscation” refers to the act of hiding something by manipulating the way it appears. One common method of obfuscating something is to use some type of encoding, such as Base64. Consider the following example in Python:
Obfuscation is not the same as encryption, and should not be considered a secure method of protecting sensitive information. However, sometimes it is an appropriate technique, depending on your goal, and sometimes it is the only technique that is accessible to you. For our purposes, we are going to be delivering a payload (Empire launcher in base64 encoded format) through either a VBA macro, or an HTA file. This post assumes familiarity with Empire and that the reader has successfully created a one-liner launcher saved in an arbitrary file (launcher.txt).
One way that malicious payloads like this are neutralized is through signatures, which are based on string recognition, as evidenced in https://warroom.rsmus.com/bypassing-gmails-malicious-macro-signatures/. Therefore, a potential way to avoid detection could be by ensuring your payload does not match any of the signatures in use. For this we will use a small tool to break up our malicious string, obfuscate_launcher.
This tool accepts a file containing a launcher as well as an option to specify the intended delivery mechanism, with VBA and HTA as options. Upon execution, the tool will randomly generate an ASCII pattern between 4 and 10 characters and prepend said pattern to every character in the original launcher. If a delivery mechanism is specified, the tool will output text in the specified format, including the routines to replace the inserted pattern and execute the launcher.
The provided delivery mechanisms are implemented as a Jinja2 templates, so it should be straight forward to add templates for additional delivery mechanisms if necessary.
Obviously, this solution is not perfect as there are still several static values in these delivery mechanisms that may be identified through signature-based detection. This technique was developed mainly for getting attachments through spam filters and other inspection tools. It is not intended to hold up to heavy scrutiny, and any type of runtime analysis will certainly detect the attack, but this has helped us out in certain situations. One example is, if you cannot determine an internal domain name and therefore cannot encrypt a payload using our previously-posted technique, this method is better than sending a launcher in its default state. Another example would be to send a phishing email directing the user to download a file hosted on a remote server, using this technique (and potentially others), it may be possible to get the file onto your target’s workstation without detection by some controls. This or similar techniques may also be useful on internal penetration tests where a NIDS is present.
As always, hopefully some of you will find this useful. Until next time, happy hunting!
