Cedric Van Bockhaven

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

Secure Enclaves for Offensive Operations (Part I)

|

This blog post was co-authored by Matteo Malvica (Researcher at OffSec and External OST developer) and Cedric Van Bockhaven (OST developer and researcher at Outflank).

This article is the first in a two-part series in which we investigate the anatomy of Virtualization-Based Security (VBS) enclaves, their internals, and the unique ways they could be leveraged for offensive operations on Windows systems.

Enclaves provide a software-based Trusted Execution Environment (TEE) and are isolated memory regions. Only code that runs within the enclave can access data within the same enclave. TEEs protect sensitive operations in computing and are designed to keep unauthorized actors away from confidential information, whether that actor is malware with user-mode or kernel-mode access or even someone with physical access to the data center.

You can imagine that being able to hide away data and code into an enclave is a powerful capability and could also be used for offensive purposes,

Read full post

Will the real #GrimResource please stand up? – Abusing the MSC file format

|

In this blog post we describe how the MSC file format can be leveraged to execute arbitrary code via MMC (Microsoft Management Console) for initial access or lateral movement purposes. A sample payload that implements this technique was publicly shared recently. This sample was generated using our Outflank Security Tooling (OST) offering and hence we decided to publish additional details on this method and its discovery.

Read full post

Mapping Virtual to Physical Addresses Using Superfetch

|

With the Bring Your Own Vulnerable Driver (BYOVD) technique popping up in Red Teaming arsenals, we have seen additional capabilities being added like the ability to kill (EDR) processes or read protected memory (LSASS), all being performed by leveraging drivers operating in kernel land.

Sooner or later during BYOVD tooling development, you will run into the issue of needing to resolve virtual to physical memory addresses. Some drivers may expose routines that allow control over physical address ranges. While this is a powerful capability, how do we make the mapping between virtual and physical addresses? Mistakes can be costly and result in BSODs. That’s what we’re exploring in this blog post. We will document a technique that relies on a Windows feature referred to as “Superfetch”.

Read full post

Listing remote named pipes

|

On Windows, named pipes are a form of interprocess communication (IPC) that allows processes to communicate with one another, both locally and across the network. Named pipes serve as a mechanism to transfer data between Windows components as well as third-party applications and services. Both locally as well as on a domain. From an offensive perspective, named pipes may leak some information that could be useful for reconnaissance purposes. Since named pipes can also be used (depending on configuration) to access services remotely – they could allow remote exploits (MS08-067).

In this post we will explore how named pipes can be listed remotely in offensive operations, for example via an implant running on a compromised Windows system.

Read more: Listing remote named pipes

Several tools already exist to list named pipes.

Read full post