Posts

Introducing Striker and the Payload Automation Libraries

TL;DR – Striker, Compyler, Artifactor, Sleepy, and Detemplate are a set of Python libraries we created to help make building custom payloads faster, more consistent, and more OPSEC safe and allow for better IoC tracking during Red Team operations. The libraries can be found on GitHub here: https://github.com/emcghee/PayloadAutomation . Introduction During an operation, we were creating a custom initial access payload which would execute a Cobalt Strike Beacon. The payload was fairly complex with multiple components coming together and multiple steps to obfuscate the shellcode before embedding it into the payload. During the preparation phase of the operation, we went through multiple profile and listener variations and needed to test our initial access payload with each variation. This meant that I had to go into the GUI for Cobalt Strike, generate the shellcode and save it to a file, manually encrypt and obfuscate it, embed it in my payload, then compile. This process tended to be

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

Image
  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

Image
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 https://support.microsoft.com/en-us/help/4576630/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

Image
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:   https://github.com/anthemtotheego/C_Shot Who Is It For: When designing this tool I envisioned C_Shot b

Popular posts from this blog

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

Executing Macros From a DOCX With Remote Template Injection

No Shells Required - a Walkthrough on Using Impacket and Kerberos to Delegate Your Way to DA