Analyzing Sharpshooter – Part 1

How does Sharpshooter work?

Sharpshooter supports the ability to create payloads in a wide variety of formats – such as HTA, JScript, VBS, and WSF – to execute C# code on a Windows machine. These payloads can also either be staged (a small loader that retrieves an additional payload) or stageless (the full payload). In this post, we will examine the inner workings of Sharpshooter – in particular its staged mode functionality – and how to detect it.

Staged mode

In staged mode, Sharpshooter will generate three separate files to execute the attack flow:

1. An HTML web page that drops the stager onto a victim’s host machine;

2. A JScript/HTA/VBS stager. (In this post we will be using the JScript stager that connects back to the attacker’s machine, then downloads and executes C# code using DotNetToJavaScript. Sharpshooter provides two download mechanisms web delivery and DNS delivery. We will be analysing how Sharpshooter performs its web delivery.)

3. A C# source code file that will be downloaded, compiled and executed in memory. (In our example, we will be using an msfvenom Windows reverse Shell payload.)

The diagram below shows a visual representation of how the staged mode for Sharpshooter works:

As shown, Sharpshooter primarily operates in the delivery and exploitation phase of an attack. In the next section, we’ll take a closer look at how Sharpshooter’s staged mode actually works.

Delivery

Sharpshooter makes use of a technique known as EmbedInHtml (Arno0x, 2017), allowing it to embed an encrypted stager into an HTML page. To leverage this technique, an attacker would first coerce or phish an unsuspecting victim to visit the attacker’s page containing malicious HTML. When the page is visited, the stager would be both decoded and decrypted dynamically within the browser before being dropped onto the unsuspecting victim’s host machine.

When the file is dropped onto the victim’s machine, the browser will often give a prompt to indicate this. For instance, Chrome would give a prompt to the user as seen below in the image, although users will often click through.

EmbedInHtml helps limit the network footprint, as at no point will there be a dedicated HTTP request containing our stager (which is typically seen with file downloads). Moreover, this technique can also evade file-type or content inspection techniques as the stager is encrypted. The next few images below show snippets of code that performs this.

The code above shows the encrypted and encoded stager being stored in a variable, namely varStager.

Subsequently, the stager is both RC4 decrypted and base64 decoded before being stored as a Blob object.

Finally, the stager is dropped onto the victim’s machine. To achieve this, Sharpshooter makes use of a function called msSaveOrOpenBlob. When this function is called, a file download is triggered in the browser, causing the stager to be dropped onto the victim’s machine.

Stager

The JScript file contains a series of encrypted JScript commands within it. When the file is executed, these commands are dynamically decrypted and executed at runtime. Among these decrypted commands are the dotNetToJscript (Forshaw, 2017) commands to serialize and execute the .NET assembly. These are shown in the following snippets:

Serialized_obj is a variable that contains a base 64 encoded serialized .NET assembly, which can be de-serialized and executed at run time. This .NET assembly correspond to a Sharpshooter class upon de-serialization.

The code snippet above shows a series of JScript commands that encompass the dotNetToJscript technique. These commands do the following:

• De-serialize the Sharpshooter class by leveraging .NET BinaryFormatter, a class commonly used for remote procedure calls;
• Upon de-serialization, it will load the Sharpshooter class into memory.
• With the Sharpshooter class loaded into memory, a new Sharpshooter object can be created from the class. With it created, we can now run its function calls:

Execution (pre-compilation)

Now that a new Sharpshooter object is loaded in memory, the attacker’s first task would be to make use of the new object’s functions to connect back to his machine to download the malicious C# source code into memory. This C# code can contain either a payload generated by mfsvenom or self-crafted by the attacker; as mentioned previously, we will be using a Windows reverse shell. The following snippets of code will show how the C# code is downloaded, compiled, and loaded into memory.

Headers and configuration information are first set, we can see the default User-Agent is Firefox.

Then the “DownloadString” function is used to download the payload into Sharpshooter’s process memory.

Subsequently, .NET CodeDomProvider library is used to compile the source code in memory.

Thereafter, .NET reflection library would then be used to retrieve the compiled code’s program and main function. With the retrieved information, Sharpshooter is able to invoke the main function causing the MSFvenom payload to be executed.

Execution (post-compilation)

As the reverse shell payload is in its raw assembly format, it can be directly executed by Windows (commonly referred to as “unmanaged code” in .NET). In order to execute the payload, Sharpshooter makes use of “VirtualAlloc” which allows it to allocate executable memory to hold the payload.

The code above reserves a large enough memory region within the Sharpshooter’s process region to hold our reverse shell payload.

Next, the reverse shell payload is written to the memory region that we previously allocated above.

Indicators of compromise

Now that we have an understanding of how Sharpshooter works, let’s look at how we can go about detecting it.

Process Execution

One way to detect Sharpshooter is by monitoring its process behaviour. As Sharpshooter makes use of the EmbedInHtml technique to download files onto a victim’s machine, one key indicator to look for is process execution originating from the “Downloads” folder. For a better illustration, let’s take a closer look at the process logs with sysmon.

In the image above, we can see wscript being used to run exploit.js, which resides in the Downloads folder. Execution of JS files from the Downloads folder rarely occurs on most endpoints making this a useful indicator.

Another key indicator to consider would be the Parent process, which in this case is Google Chrome. Typically, most users would open a downloaded file from the browser itself. As such, this can serve as a way to spot potential phishing attempts, where users are tricked into clicking on a malicious JS file.

Network Connection

Another area where we can detect Sharpshooter would be in a network connection. As Sharpshooter makes use of either web or DNS delivery to download the C# source code, we can hunt for processes that are making outbound connections. It would be prudent to note that this indicator is only valid for the staged version of Sharpshooter as the stageless mode does not require the C# source code to be downloaded.

The image above shows wscript.exe creating an outbound HTTP request. Such behavior suggests that the script ran by wscript.exe contains code logic that performs an HTTP request. Although this activity alone is not enough to indicate malicious behavior, it can help raise fidelity when correlated with the other indicators discussed.

CodeDom Provider Compiler

Another indicator to hunt for is compilation behavior. As previously discussed, Sharpshooter makes use of CodeDomProvider to compile the C# source code. However, as with network connections, this indicator only exists for the staged mode of Sharpshooter.

As shown in the image above csc.exe (.NET command line compiler) is used for C# code compilation. This activity is commonplace in most organizations and due to the random temporary files generated will often not be a useful indicator on its own.

However, looking at the parent process we find a more useful indicator as WScript launching Csc is very anomalous, thus serving as another potential indicator of Sharpshooter.

Memory indicators

Sharpshooter makes use of VirtualAlloc to reserve memory to hold our reverse shell payload. Doing so can give rise to memory anomalies, which can also serve as potential indicators of Sharpshooter (and other malware).

The image above shows the memory region “0x24beffe0000” being allocated with the permission “EXECUTE_READWRITE”, which is required to both write and execute the reverse shell payload.

Another potential indicator to look for is the memory type, which in this case is set to MEM_PRIVATE. This indicates that the memory region is not file-backed, suggesting content has been loaded from memory as opposed to from disk.

Looking into the raw data we can see the memory region starts with the hexadecimal characters “FC E8”, which are often seen at the start of Windows stagers generated by Metasploit. These characters essentially correspond to OPCODE instructions which shall be described briefly below:

• FC: CLD – This instruction is essentially used to set the direction flag to 0. A direction flag is simply a bit field used to control the direction of strings processing.  Setting it to 0 would mean that strings would be processed from low to high address.
• E8 C1 00 00 00: CALL Start – This instruction is simply a call command towards the start label.

Hunting for such assembly instructions in memory can help you detect Metasploit Windows payloads. However, it is important to note that not all Windows payloads contain these signatures, especially if they are self-crafted.

Payload indicators

Ultimately, Sharpshooter serves as a mechanism to deliver a payload (in our case, it was a reverse shell payload) and as such, we can hunt for indicators of malicious behaviour after Sharpshooter has executed. However, do note that the following indicators below are not default behaviors and may change depending on the payload used.

Wscript (the process in which Sharpshooter resides) creating a remote thread towards rundll32.exe:

Which in turn creates cmd.exe.

Conclusion

Attackers are constantly evolving, finding new ways to attack systems and to avoid detection. The techniques used by Sharpshooter are a great example of how an attacker can evade traditional prevention/detection and compromise Windows machines. As such, it’s important for blue teamers to constantly improve themselves to keep up with attackers. In the next post – Analyzing Sharpshooter, Part 2 – we’ll look into some of the techniques used in Sharpshooter’s stageless mode.

Finally we want to thank MDSec for making such an awesome tool. We’d recommend checking it out if you haven’t already.

About the Author

Wee-Jing Chung is a member of F-Secure Countercept’s threat hunting team in Singapore. A tech enthusiast, he enjoys programming and researching new techniques employed by advanced attackers.

References

1. Dominic Chell (2018, March 7) Payload-generation-using-Sharpshooter. Retrieved from https://www.mdsec.co.uk/2018/03/payload-generation-using-Sharpshooter/
2.  Arno0x0x (2017, September 11) EmbedInHtml. Retrieved from https://github.com/Arno0x/EmbedInHtml
3.  James Forshaw (2017, April 9) DotNetToJScript. Retrieved from https://github.com/tyranid/DotNetToJScript