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 Runne...

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 ...

TL;DR - I get told that I am too wordy, so if you want the summary, here are some steps to setup a virtual testing environment to test payloads to see if they can handle HTTP(S) proxies and if so, can they authenticate properly through them as well. This post will cover the proxy setup without authentication since that is the easier part, and I will do a second post shortly to hack together the authentication portion of it. Skip down to the actual setup here if you wanted to skip the fluff. Introduction: There have been times in my red teaming and pentesting experience that I have run into networks where direct outbound traffic to the internet (or in some cases out of the subnet) is completely restricted. When I say direct, I mean that all DNS traffic first goes to an internal DNS server, all web traffic goes through an internal proxy, email to an internal SMTP/IMAP server, etc. From the client workstation to any internet IP address is dropped for TCP, UDP, and ICMP....

The What: In this post, I want to talk about and show off a code execution method which was shown to me a little while back. This method allows one to create a DOCX document which will load up and allow a user to execute macros using a remote DOTM template file. This attack has been seen in the wild, is partially included in open-source offensive security tools , as has been blogged about by Cisco Talos , but in the blog post and the open-source tool, it is only seen as a credential stealing attack typically over the SMB protocol. This blog post will detail how to use this method to download a macro-enabled template over HTTP(S) in a proxy-aware method into a DOCX document. The Why: The benefit of this attack versus a traditional macro enabled document is multidimensional. When executing a phishing attack against a target, you able to attach the .docx directly to the email and you are very unlikely to get blocked based on the file extension. Many organizations block .doc or .do...