Assembly.Lie – Using Transactional NTFS and API Hooking to Trick the CLR into Loading Your Code “From Disk”

  Introduction: Assembly.Load, a method that has been one of the primary reasons for the meteoric rise in offensive tooling written in C# over the past few years.  Its most commonly used overload in offensive tooling – Assembly.Load(byte[]) allows for memory-only loading of .Net assembly objects (.exe / .dll) directly from a byte array representing the object’s contents, effectively granting the ability to reflectively load and execute a program entirely in memory in just 2-3 lines of code. This has enabled all sorts of multi-staged payloads, modular program functionality, and fileless post-exploitation operations.  A few months back some tooling I was working on caused me to take a closer look into the mechanisms behind loading assemblies into the .net Common Language Runtime (CLR).  I found that while Assembly.Load has several overloads that all correspond to the same managed method, the unmanaged functions they call vary quite drastically.  Through this process, I attempted to deter

One Click to Compromise -- Fun With ClickOnce Deployment Manifests

Note: I submitted a report to MSRC regarding the hash-disclosure vulnerability associated with ClickOnce deployment manifests. After review I got a response back earlier in July where it was noted that the vulnerability did not meet the bar for immediate servicing and was given the green light to disclose. Edit 9/22:  MS has remediated the NTLM-disclosure part of this issue as of KB4576630   However, this method will still work as a delivery mechanism for stage-0 payloads. TL;DR ClickOnce Deployment Manifests are a relatively unknown way to both get an initial payload into an environment as well as remotely retrieve NTLM challenge-response hashes over HTTP.  Hash retrieval occurs on initial file open (before any warnings pop) meaning that even if the user opts to close out on the warning, we still have a hash we can attempt to crack.   IE also has some interesting interactions with these files and will automatically execute

C_Shot - Just What The Doctor Ordered

C_Shot TL;DR What Is It? C_Shot is an offensive security tool written in C which is designed to download a remote shellcode binary file (.bin) over HTTP/HTTPS, inject the shellcode and execute it.  C_shot can accomplish this two different ways: 1. Injects the shellcode into its own process With this method, C_Shot becomes your sacrificial process to inject into.  The C_Shot process will remain running until whatever you launched is finished running. 2. Injects the shellcode into a child process using parent process spoofing With this method, C_Shot is able to spoof a parent process of your choosing, open a child process of your choosing underneath that parent process, then inject and execute your shellcode within that child process.  You also have the ability to add command line arguments to add some authenticity to the child process.  Code can be found here: Who Is It For: When designing this tool I envisioned C_Shot b