Introducing Cobalt Strike Research Labs

|

This is a joint blog written by Stan Hegt, Pieter Ceelen, and Will Burgess.

Today, we’re launching Cobalt Strike Research Labs (CS:RL), a new Fortra offering that unites the research expertise of the Cobalt Strike and Outflank teams. CS:RL delivers cutting-edge, ready-to-use research tooling for Cobalt Strike, including custom UDRLs, Sleep Masks, UDC2 channels, and post-exploitation capabilities. Most importantly, it provides the Cobalt Strike team with a platform to deliver experimental beta features, test ideas, and gather feedback before moving proven features into the main product.

Read full post

macOS JIT Memory

|

The macOS Hardened Runtime prevents execution of unsigned code. Unsigned executables will not run, regardless of compilation settings. Processes cannot load unsigned shared libraries into apps with the Hardened Runtime. Nearly every app found on a modern system enables the Hardened Runtime, and Apple silicon processors enable memory protection for all apps. So, how does malware execute within such constraints?

  1. Valid signatures – There are a few examples of criminals signing their malware, but Apple can revoke certificates, and has done so quickly, even over the weekend.
  2. Script-based malware – Malware written in languages like Python and JavaScript for Automation (JXA) does not require a signature, though initial access delivery may be constrained.
  3. Hardened Runtime exceptions –

Tags:

Read full post

Red Macros Factory Is Joining OST (And So Am I!)

|

Hey everyone! I’m Mariusz Banach (mgeeky) and I’m excited to introduce myself as the newest member of the Outflank team.

For those who don’t know me, I’ve spent years in the trenches as a red teamer and have trained others to do the same, delivering public and private IT security trainings on malware analysis, initial access, evasion tactics, and more.

However, I have spent the last few years building and managing Red Macros Factory (RMF), an Initial Access Framework designed to take the pain out of the weaponization phase that kicks off every red team engagement. RMF represents three years of research-driven development, battle-tested across numerous engagements. The philosophy behind it is simple: red team tools, by a red teamer, for red teamers.

Sound familiar? That’s exactly why I’m here.

As part of joining Outflank,

Read full post

PatchGuard Peekaboo: Hiding Processes on Systems with PatchGuard in 2026

|

Introduction

I spent a few weeks (and could have spent even more) trying to find a reliable trick to intercept kernel activity while HVCI was breathing down my neck. Almost every approach I tried ended the same way: either a blunt “access denied” or an instant black screen that replaced everyone’s favorite blue one.

Windows is not playing games anymore; the era of clever inline hooks and creative PatchGuard dodges is largely over. Microsoft pushed the enforcement layer up into places a normal kernel driver simply can’t touch. We’re talking hardware-enforced, hypervisor-backed protections: “you don’t even have permission to ask for permission.”

This research centers on a specific objective: hiding processes from user-mode enumeration by manipulating kernel structures – specifically, the process linked lists that Windows uses to track active processes.

Tags: , ,

Read full post

Linux Process Injection via Seccomp Notifier

|

This post demonstrates the use of seccomp user notifications to inject a shared library into a Linux process. I haven’t seen this combination documented as a process injection technique before, and it has some benefits over alternatives. In summary, seccomp user notifications enable user-space injection from parent to child without any LD_* environment variables or privileged capabilities, regardless of the ptrace_scope configuration. However, seccomp user notifications have some notable limitations:

  1. Seccomp user notifications were introduced in Linux kernel version 5.0, but this PoC relies on SECCOMP_ADDFD_FLAG_SEND (Linux 5.14+) to avoid TOCTOU issues when hooking openat.
  2. Requires you to create the target process (parent-to-child injection only).
  3. The injected code runs with the same UID, namespaces, and LSM label as the target process.

Tags: ,

Read full post

Training Specialist Models: Automating Malware Development

|

This post complements the presentation I gave at Black Hat USA 2025.

Can a small, self-hosted LLM outperform state-of-the-art models at evasive malware development?
In this technical deep dive, we explore how reinforcement learning with verifiable rewards (RLVR) enables training compact specialist models that rival large generalists in domain-specific tasks.

In the first half of this post, we’ll break down the LLM training process and recent opportunities created by RLVR. The second half details our training methodology for Dante-7B, a 7 billion parameter model that generates functional, evasive Cobalt Strike shellcode loaders capable of bypassing Microsoft Defender for Endpoint (MDE). We’ve released Dante-7B on Hugging Face, complete with a demo app so anyone can experiment with the model.

Tags:

Read full post

Accelerating Offensive R&D with Large Language Models

|

At Outflank, we continually seek ways to accelerate our research and development efforts without compromising quality. In this pursuit, we’ve begun integrating large language models (LLMs) into our internal research workflows. While we’re still exploring the full potential of AI-powered offensive tooling, this post highlights how we’ve already used AI to speed up the delivery of traditional offensive capabilities.

By leveraging AI as a research accelerator, we can dedicate more time to refining, testing, and hardening the techniques that ultimately make it into our OST offering. This post is a case study of our AI-assisted exploration of the “trapped COM object” bug class.

Tags: , ,

Read full post

Async BOFs – “Wake Me Up, Before You Go Go”

|

Asynchronous BOFs: Enabling New Use Cases for Red Team Operators

The introduction of Beacon Object Files (BOFs) by Cobalt Strike in 2020 revolutionized the capabilities of red team operators and developers, offering a standardized interface for operator code to run within, and interact with, an implant. However, the current BOF standard was designed for synchronous operations, limiting its potential applications.

Asynchronous BOFs Execution Would Enable New Red Team Capabilities

Within this blog Cornelis (@Cneelis) and I introduce the concept and initial design of real-time monitoring for events (e.g. sleep until an admin logs in, sleep until a user starts his password vault) for Beacon Object Files. This new asynchronous design allows operators to roll out a network of sensors and stream these events to the C2 server for further processing – all while the implant is sleepmasked.

Tags: , , , , , ,

Read full post

BOF Linting for Accelerated Development

|

Creating Beacon Object Files (BOFs) allows operators to extend the functionality of a C2 framework, though their development may sometimes involve hidden complexities that only become apparent after the BOF is executed. Today, we introduce a BOF linting tool to address some of the common pitfalls.

BOFs are lightweight, in-memory modules used in Cobalt Strike and other post-exploitation/C2 frameworks such as Outflank C2 and Core Impact.  They are object files produced by a C compiler (COFF). Cobalt Strike parses this file and acts as a linker and loader for its contents. This approach allows you to write code for use in Beacon, without tedious gymnastics to manage strings and dynamically call Win32 APIs.

BOFs are powerful and flexible, but their minimalistic design inherently comes with strict constraints.

Read full post

Secure Enclaves for Offensive Operations (Part II)

|

This blog post is the second part in a series about using Secure Enclaves for Offensive Operations. The first part discussed the basics of how enclaves work, provided some ideas on how to develop your own enclave, as well as analyze and debug existing enclaves. We also hinted at how enclaves could potentially be used for offensive purposes. Remember: VTL0 is where the normal kernel lives, VTL1 is where the secure kernel operates (and our enclaves).

In this follow-up post, we will share what we discovered while digging into enclave internals. It’s been a hands-on journey filled with many (failed) experiments. We’ll walk you through some of the practical techniques we used to exploit a read-write primitive in a vulnerable enclave DLL, and how we managed to turn that into VTL1 code execution.

Read full post