11-18, 15:05–16:05 (Europe/Vienna), Badeschiff
Staying under the radar and remaining undetected is one of our priorities during Red Teaming assessments. After all, we’re simulating real threat actors and want to reach our objectives without raising any suspicion. This becomes a more and more challenging task as new defences are implemented, requiring us to add new tools and techniques to our tool belt. Occasionally, though, there is a new technique that brings a broad set of features and doesn’t leave countless traces. This talk is about one such technique: beacon object files (BOFs)!
BOFs aren’t exactly the new hot stuff, as a matter of fact, they’ve been around for more than two years now. In those two years, a de-facto BOF standard has been adapted by many C2 frameworks out there. But what happens when your C2 doesn’t support it? Will you need to fall back to other, potentially less safe, alternative techniques?
That’s a problem we faced and decided to solve when we worked with Brute Ratel C4, which doesn’t support Cobalt Strike’s de-facto BOF standard API. In this talk, we’ll dig deep into the COFF format, show how the Cobalt-Strike de-facto standard is incompatible with Brute Ratel’s and how we established full compatibility between the two. A tool that automates this task and a blog post series about it will be released, accompanying the talk.
The presentation is divided into four sections:
I. Intro: About C2s and BOFs: First we’ll make sure that everyone is on the same page by briefly discussing C2 frameworks (esp. CS and BR) and BOFs (esp. the format and why they’re useful).
II. BOF APIs: Not exactly best practice: In this section we’ll show that there is a de-facto standard to BOF APIs and how that standard isn’t compatible with Brute Ratel’s BOF API, resulting in a conceptual incompatibility between the two. Then we’ll show how others solved related problem in the past (e.g. TrustedSec’s COFFLoader) and how we can adopt and improve upon their approach.
III. Making it work: Sources & binaries: This section discusses two approaches we worked through to solve the problem at hand. The first approach we present is based on the idea that we can patch any BOF’s source code and make it include a compatibility layer. Then. we point out the advantages and disadvantages of this approach. The second approach addresses a shortcoming of the first approach and aims to patch compiled, binary BOFs instead of source code. We’ll show how we proceeded there and how and why we failed there.
IV. Where to go from here: At this point we’re summing up the talk and drawing conclusions. We’ll briefly go into the exact problem statement, how we approached it and how far we got. Eventually, we point out that (with some constraints), we managed to work out a workflow to finally (and semi-automatically) make CS BOFs work in BR.
Patrick has worked for several years in the offensive security sector. With his current role as Red Team Lead at NVISO ARES (Adversarial Risk Emulation & Simulation) he is taking care of high profile Red Teams and Tiber Assessments while also leading the exposure activities.
Additionally, he also likes to get his hands dirty with creating sophisticated spear phishing campaigns and improving the Red Team's life by maintaining open-source methodology and tooling.