EDR Internals for macOS and Linux

Many public blogs and conference talks have covered Windows telemetry sources like kernel callbacks and ETW, but few mention macOS and Linux equivalents. Although most security professionals may not be surprised by this lack of coverage, one should not overlook these platforms. For example, developers using macOS often have privileged cloud accounts or access to intellectual property like source code. Linux servers may host sensitive databases or customer-facing applications. Defenders must have confidence in their tools for these systems, and attackers must understand how to evade them. This post dives into endpoint security products on macOS and Linux to understand their capabilities and identify weaknesses.

Tags: , ,

Read full post

OST Release Blog: EDR Tradecraft, Presets, PowerShell Tradecraft, and More 

Malicious actors continuously deploy new or improved techniques. Red teams must maintain an equally rapid pace of development of their tooling arsenal to remain effective at testing evolving defensive measure and preparing organizations for advanced threats. With the dedicated research and development efforts from the Outflank team, OST is constantly evolving, with additions of new, leading-edge tools unique to the market as well as regular enhancements to our existing tools. 

In this quarterly release blog, we’ll summarize some of the latest updates we’ve made over the past few months.  

EDR Tradecraft

Over the last few years we have clearly seen the big EDR names in the market up their game. Generally, we can say that they are doing a great job and that EDR-bypasses are becoming harder. However, EDRs can’t be expected to do magic,

Tags: , , ,

Read full post

Unmanaged .NET Patching

To execute .NET post-exploitation tools safely, operators may want to modify certain managed functions. For example, some C# tools use the .NET standard library to terminate their process after execution. This may not be an issue for fork&run implementations that spawn a sacrificial process, but executing in-process will terminate an implant. One could write a small .NET program that resolves and patches these functions, but we were interested in an unmanaged approach (i.e. a unmanaged implant executing managed code in-process). While our example targets System.Environment.Exit, a similar technique should work for any managed function.


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

Reflecting on a Year with Fortra and Next Steps for Outflank

When we debuted OST back in 2021, we wrote a blog detailing both the product features and the rationale for investing time into this toolset. In 2022, we joined forces with Fortra and we can hardly believe it’s been over a year already. It was a big decision to go from being a small team of red teamers to becoming part of a large company, but we’re very pleased with the switch. In this reflection on the past 12 months, we want to provide an update on our mission, detail our continued dedication to OST, discuss the process of growing the Outflank community, and touch on where we’re headed next.  

Read more: Reflecting on a Year with Fortra and Next Steps for Outflank

A Product Oriented Focus

One of our biggest challenges when we joined Fortra was the decision to put most of our energy into Outflank Security Tooling (OST).

Tags: , , , ,

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

Solving The “Unhooking” Problem

For avoiding EDR userland hooks, there are many ways to cook an egg:

Direct system calls (syscalls), Indirect syscalls, unhooking, hardware breakpoints, and bringing and loading your own version of a library. These methods each have advantages and disadvantages. When developing a C2 implant it’s nice to work with a combination of multiple of these. For instance, you could use a strong (in)direct syscall library for direct usermode to kernel transition, then use unhooking or hardware breakpoints for user mode-only (to bypass AMSI, ETW e.g.) functions.

Regarding system calls, excellent research has already been done. A small selection of relevant blog posts is Klezvirus’ post on syswhispers, MDSec’s post on direct invocation of system calls and our own blog post on combining direct system calls srdi.


Tags: , , , , , ,

Read full post

Cobalt Strike and Outflank Security Tooling: Friends in Evasive Places

This is a joint blog written by the Cobalt Strike and Outflank teams. It is also available on the Cobalt Strike site.

Over the past few months there has been increasing collaboration and knowledge sharing internally between the Cobalt Strike and Outflank R&D teams. We are excited about the innovation opportunities made possible by this teamwork and have decided to align Cobalt Strike and Outflank Security Tooling (OST) closely going forward. Although we are actively collaborating, Cobalt Strike will continue to be the industry standard Command & Control (C2) framework, while OST will continue to offer a red team toolbox for all environments containing custom tradecraft that is OPSEC safe, evasive by design, and simple to use. Our vision is that Cobalt Strike and OST together will provide the best red team offering on the planet. 

Tags: , , , , , ,

Read full post

So you think you can block Macros?

For the purpose of securing Microsoft Office installs we see many of our customers moving to a macro signing strategy. Furthermore, Microsoft is trying to battle macro malware by enforcing Mark-of-the-Web (MotW) control on macro-enabled documents. In this blog we will dive into some of the quirks of Microsoft Office macro security, various commonly used configuration options and their bypasses.

  • In the first part of the blog we will discuss various Microsoft Office security controls on macros and add-ins, including their subtleties, pitfalls and offensive bypasses.
  • In the second part of this blog the concept of LOLdocs is further explained, detailing how vulnerabilities in signed MS Office content might be abused to bypass even strictly configured MS Office installs.

This blog is related to our BruCON talk on LOLdocs: legitimately signed Office documents where control flows can be hijacked for malicious purposes.

Tags: , , , , , , , , ,

Read full post