Since SharpShooter, CactusTorch and a couple of other offensive security tools are leveraging DotNetToJscript to execute the payloads in memory using C#, in this quick lab I wanted to simply use the DotNetToJscipt framework just to get a feel of the process and see if there are any easy to spot artefacts this technique leaves behind on the target system that could help defenders catch the attackers.
Compile it (review the code before you do). It will spit out two binaries:
ExampleAssembly.dll - the C# assembly that will be given to DotNetToJscript.exe. In default project configuration, the assembly just pops a message box with the text "test"
Execute DotNetToJscript.exe and supply it with the ExampleAssembly.dll, specify the output file and the output type:
\\VBOXSVR\Experiments\DotNetToJScript\DotNetToJScript\bin\Debug\DotNetToJScript.exe \\VBOXSVR\Experiments\DotNetToJScript\ExampleAssembly\bin\Debug\ExampleAssembly.dll -l vbscript -o \\VBOXSVR\Experiments\DotNetToJScript\DotNetToJScript\test.vbs
We got a test.vbs created and if we look inside it, we can see that at a high level:
the C# binary is now present as a base64 encoded data blob
the data blobob will be deserialized and invoked using
which will create a new instance of the
which will kick off the
MessageBox as defined in the
entry_class = "TestClass"Dim fmt, al, d, oSet fmt = CreateObject("System.Runtime.Serialization.Formatters.Binary.BinaryFormatter")Set al = CreateObject("System.Collections.ArrayList")al.Add EmptySet d = fmt.Deserialize_2(Base64ToStream(s))Set o = d.DynamicInvoke(al.ToArray()).CreateInstance(entry_class)
Let's now run the test.vbs - it pops the message box as expected:
Looking at the loaded modules of the wscript.exe, we can see a number of .NET assemblies in the process memory, which makes sense if you think about it:
Now, what happens if we try executing a simple vbscript that pops a message box and inspect the loaded modules of the wscript.exe again? Bingo, no .NET assemlies loaded:
Looking from the defensive point of view, it may be worth checking the environment for machines executing wscript (or jscript or cscript) which load .NET assemblies in their memory space and make sure the activity is benign.
Since .js or .vbs may be one of the payload delivery methods used in phishing using file smuggling through browsers, you may also want to check your environment for wscript (or cscript or jscript) launching files scripts from the user's download folder which is the default browser download location.
Know of any other hlepful artefacts? Let me know.