Red XOR Blue

TL;DR I have expanded the payload_automation Python libraries to allow for synchronously controlling actions in a Cobalt Strike Beacon by adding the Beacon class. This enables you to script out Cobalt Strike actions purely in Python and avoid coding anything in Sleep completely (at least for things I’ve already implemented).  One important fact to take note of is that the actions happen synchronously. Those who have worked in Sleep/Aggressor know that it’s a fire and forget language in most cases, so waiting until an action is completed or adding logic based on the results of an action is notoriously difficult to accomplish. With this library, we can synchronize the actions and in most cases, easily capture the output of a specific action in Python and perform actions based on that output. This is a big step in simplifying the automation of Cobalt Strike Beacons and gives way for many different applications.  As an example of how this can be leveraged, I wrote a Threat Runner Python

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

  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

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