Patrick Eisenschmidt
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.
Sessions
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.