I've been running into 'next-gen' endpoint security controls much more regularly on client engagements recently. Many of these controls monitor process execution and look at parent processes for anomalous activities (ex. child processes spawning out of an office process). This combined with application whitelisting was stopping many traditional methods of initial compromise that have been go-to’s in the past, such as using macro-enabled office documents to launch other processes, either directly through a powershell call or loading & executing a remote file (such as methods that utilize regsvr32 or similar functionality).

As a basic bypass to these security measures that doesn’t require prior admin access and as an alternative to shellcode injection methods (which can sometimes trigger AV), I've created a new stager that splits the process of getting a shell into two parts. During the initial macro run, no child processes are spawned. Instead, the macro uses vbscript functionality to backdoor targeted shortcuts on the user's desktop (by default targeting ie, chrome, and firefox), re-writing them to do a direct run of powershell the next time the user opens any modified shortcut. The next time the user clicks on a backdoored .lnk file powershell.exe is called in place of the original target, first opening the original target executable, then cleaning all detected backdoors from shortcuts, and finally using a download cradle to pull an aes 128 encrypted block from a pre-configured remote web server. When decrypted, this block contains an empire launcher that is then invoked, giving a full agent connection back. Due to the inherent persistent nature of this vector, a kill date (selected during generation of the macro) is also included in the powershell code, after which the code will still function to open the original target executable and clean all backdoors, but will no longer attempt to download code from a remote server. The macro itself is designed to attempt to be stealthy, with randomized variable names and strings used by the macro embedded in cells of the accompanying XLS document.

In order to attempt to evade detection and have as small of an on-disk footprint as possible, all logic for the backdoors is stored within the arguments of modified .lnk files, meaning the initial macro doesn’t have to write any values to the registry or additional files. However, due to this the script is constrained to a maximum length of 1024 characters (the maximum argument length for .lnk files in Windows). Although workarounds exist to bypass this limit, during testing it did not appear possible to do so from within the confines of the VBScript macro. This is also why I did not simply just include a full empire stager in the backdoor, as space constraints would not allow it.

Based on this maximum length of 1024 characters, there are several known limitations that exist currently. Foremost, it was not possible to base64 encode the backdoor, as this significantly increases the length of the script. Randomized capitalization has been used, but the backdoor itself is still in plaintext. Secondly, it was not possible to use the standard System.net.webclient cradle that the empire launcher utilizes due to the aforementioned space issues. In its place, I’ve used a much less verbose xml.xmldocument.load method (credits @subTee). While proxy-aware by default, it makes a very simple outbound http connection that doesn’t offer nearly the customization options of net.webclient. This means that a number of http headers, including user-agent, are not configured in the request, potentially leading to connectivity issues if networks are performing outbound filtering based on user agent (ex. only allowing outbound http traffic originating from certain browsers). Although this has not been an issue during any client engagements on which I have used this stager, and it does not appear to be a commonly applied setting (per my experience in testing), it may present periodic issues when the setting is configured.

As a workaround to this shortcoming, I’ve found that it is possible to utilize an IE COM object (credits @HarmJ0y) to remotely obtain the second stage payload (using an html in place of an xml). Since this method utilizes internet explorer it is inherently proxy-aware, and the http connections it makes have all expected headers, including user-agent. However, this method also has its own shortcomings – the IE COM object does not appear to function appropriately without office installed on the endpoint. Although the two seem to be unrelated, it appears as though the installation of office adds dll files necessary for proper functionality. Furthermore, it is also one additional process that is spawned during execution.

The current length of the code dropped into .lnk file arguments (when used with default options) ends up sitting around 790 characters, and when the IE COM object is used this number ends up sitting around 860, meaning that there is a slack of ~160-230 characters before hitting the maximum value of 1024. This slack is required in order to account for both a possibly longer URL and longer target executable path, as both of these are variable in length based on configured options. Currently I have variants of this stager that use both the xml.xmldocument and IE COM object methods, and can update the code accordingly based on feedback on which is preferred. Any recommendations / improvements on the code or methods I’m using are welcome.