Introduction
Stageless Mode
By default, Sharpshooter’s stageless mode only generates a single script file (JScript, XSL, VBS) which embeds both the serialized Sharpshooter object as well as the final payload (we used reverse tcp shellcode from msfvenom). As the core Sharpshooter code was analysed in the previous post we’ll provide just a brief overview in this article.
The code above can be summarized in a few steps:
- The serialized Sharpshooter object is deserialized and loaded into memory through the use of the dotNetToJscript technique.
- The variable containing the shell code would be used as a parameter for the deserialized object “Go” function call.
- The “Go” function would thereby allocate and write the shell code into a memory region with READ_WRITE_EXECUTE permissions.
One of the biggest differences between the staged and stageless modes is that the stageless mode does not need to perform any form of code compilation since the shellcode is embedded directly within the script and not in a separate C# source code file. This difference helps lower the forensic footprint of stageless mode making it a more stealthy option.
Enter Squiblytwo (Technique 1)
In this mode, Sharpshooter generates three sets of files to perform the attack – a html file, a vbs stager and an XSL script containing the serialized Sharpshooter object and a msfvenom reverse shell shellcode.
Attack analysis
The gif below shows the high level steps involved during delivery.
The main steps are:
- Attacker coerces the victim to visit a malicious webpage hosting the VBScript
- VBScript is dropped onto victim’s machine through the use of the embedinHtml technique.
- Attacker coerces victim into opening the VBScript
- VBScript creates a new Outlook COM object instance which in turn spawns a wmic process
- Subsequently, the wmic process retrieves the XSL script from the attacker’s machine and executes it in memory
- The XSL script utilises the dotnetTojscript technique to deserialise the Sharpshooter object which in turn loads and executes the msfvenom shellcode in memory to achieve a reverse shell.
Code analysis
As the embedinHtml and dotnetTojscript techniques were analysed in the previous post, they will not be discussed here, instead we will focus our analysis on the VB script. The script starts by using the “GetObject” function (with Outlook’s CLSID as a parameter) to instance a new Outlook COM object [2].
GetObject is often used to reference files but using COM provides a nice way to minimise footprint and avoid detection. The “new” parameter is used to create a new COM instance as opposed to using an existing instance.
It is now possible to reference the Outlook COM object and execute commands through a WScript shell. At this point the Squiblytwo technique is used with “wmic process get brief“ sending a http request to retrieve and execute the XSL script containing the serialised Sharpshooter object and the msfvenom shell code.
Detecting Squiblytwo
In terms of detection many of the indicators are the same as those already covered in the previous article. Instead, we’ll look at the indicators that are more specific to Squiblytwo.
Script execution
Examining process executions is a great starting point to hunt for possible indicators. For example you could hunt for the presence of script execution from the Downloads folder as seen in the Sysmon example below:
GetObject function
The Squiblytwo mode makes use of the GetObject function to create a new instance of an Outlook COM object, this causes svchost with the DcomLaunch parameter to launch Outlook as a child process. Subsequently, Outlook was used to launch wmic which would in turn download and execute the XSL script. From a detection perspective it’s important to note that although the VBScript contained the wmic commands, on execution wmic is instead launched by Outlook.
The Windows registry contains a mapping between each CLSID key and its associated COM class which is housed within its corresponding DLL/EXE. In our scenario, the code for Outlook’s COM class resides within Outlook.exe. Thus, Outlook.exe has to be loaded into memory before a new instance of the COM class can be created and wmic launched.
Although in this instance Outlook was used, it may be possible to use other CLSIDs/programs to execute code so any detection rules should account for this.
Memory analysis
Similar to Sharpshooter’s staged mode, the Squiblytwo mode leaves traces in memory as well as seen in the image below:
A private memory region is allocated with RWX permissions and we can see hex matching our Metasploit shellcode. Since the XSL script executed within the wmic process space, the memory indicators would be found within the wmic process.
XMLDOM Com (Technique #2)
Similar to the Squiblytwo mode, Sharpshooter will generate 3 files for this attack. The only difference is that a HTA file is used instead of a VB script. The attack vectors used in this mode are similar to Squiblytwo but are stealthier leaving less forensic evidence.
Attack analysis
The gif below shows the high level steps involved during delivery.
The attack shown in the image above can be summarised as follows:
- Attacker coerces the victim into visiting a malicious webpage hosting the HTA file
- HTA file is dropped onto victim’s machine through the use of the embedinHtml technique
- Attacker coerces victim to open the HTA file
- HTA file creates a new instance of a XMLDOM object which in turn retrieves the XSL script from the attacker’s machine and executes it in memory
- Subsequently, the XSL script utilises the dotnetTojscript technique to deserialise the Sharpshooter object which in turn loads and executes the msfvenom shellcode in memory to obtain a reverse shell
Code analysis
Similar to Squiblytwo we’ll just be focusing on the HTA delivery mechanism below as opposed to the core Sharpshooter payload which was described in the previous article. The HTA contains a few key function calls, the first is the creation of a new XMLDOM object.
The remote XSL payload is then retrieved with the “load” function and processed using “transformNode to essentially execute the payload in memory.
Detecting XMLDOM
Process analysis
Compared to Squiblytwo, there is a lot less process activity generated and no new child processes are created. MSHTA usage in general is a useful low false positive indicator for most organisation, combining with the Downloads folder can give even higher fidelity alerts. The image below shows the HTA execution:
As the HTA file executes the outbound network connection used to retrieve the XSL file can be seen. This is again another high fidelity indicator.
Subsequently, mshta was shown to send an http request, indicating that exploit.hta contains an instruction to issue an http request.
Memory analysis
Similar to Squiblytwo, the XMLDOM technique leaves traces of memory injection as well:
Since the XSL script executed within the MSHTA process, the memory indicators would be found within mshta.exe memory regions.
Thread analysis
Due to the small number of anomalies, we were interested to see if there were other indicators we could potentially hunt for. Using module load information or thread analysis we found it was possible to detect the presence of .NET code execution within MSHTA.
Specifically when using .NET payloads we observed the loading and use of mscorwks.dll, a core Microsoft .NET runtime dll, within mshta.exe.
HTA files typically contain Javascript or HTML code and thus should not require the usage of this DLL at all. Evidence of such modules being loaded in MSHTA (or other processes) may indicate suspicious behavior and should warrant a further investigation.
Conclusion
In this post, we have discussed the various techniques used by the stageless Sharpshooter payloads. Both SquiblyTwo and XMLDOM modes provide ways to bypass traditional preventative controls and present challenges for monitoring teams who are unaware of such modern techniques. Nevertheless, as shown in this post even these techniques have a handful of simple indicators that provide an easy way to spot such activity. Importantly though it’s only through ongoing research and understanding Windows internals, that Blue teams can detect these attacks both now and into the future.
As before we want to thank MDSec for making such an awesome tool and would recommend checking it out if you haven’t already.
References
1. Dominic Chell (2018, June 25) FreeStyling with Sharpshooter v1.0. Retrieved from: https://www.mdsec.co.uk/2018/06/freestyling-with-Sharpshooter-v1-0/
2. Microsoft (2018, May 31) COM Class Objects and CLSID. Retrieved from: https://docs.microsoft.com/en-us/windows/desktop/com/com-class-objects-and-clsids
Categories