Free Training: Microsoft Office Offensive Tradecraft for Red Teamers
We are hosting a free training on Microsoft Office Offensive Tradecraft aimed at red teamers. Head over here for more details and for registration.
Uncategorized
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”.
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: cobalt strike, Development, Fortra, OST, red teaming
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.
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.
So,
Tags: BOF, detect hooks, LoadLibrary, OPSEC safe, OST, syscalls, Unhooking
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: announcements, c2, cobalt strike, developments, integrations, red team, yara
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: DLL, LOLdocs, Macro, MotW, Office, Phishing, Signing, VBA, XLAM, XLL
Attacking Visual Studio for Initial Access
In this blog post we will demonstrate how compiling, reverse engineering or even just viewing source code can lead to compromise of a developer’s workstation. This research is especially relevant in the context of attacks on security researchers using backdoored Visual Studio projects allegedly by North Korean actors, as exposed by Google. We will show that these in-the-wild attacks are only the tip of the iceberg and that backdoors can be hidden via much stealthier vectors in Visual Studio projects.
This post will be a journey into COM, type libraries and the inner workings of Visual Studio. In particular, it serves the following goals:
- Exploring Visual Studio’s attack surface for initial access attacks from a red teamer’s perspective.
- Raising awareness on the dangers of working with untrusted code, which we as hackers and security researchers do on a regular basis.
A phishing document signed by Microsoft – part 2
This is the second part of our blog series in which we walk you through the steps of finding and weaponising other vulnerabilities in Microsoft signed add-ins. Our previous post described how a Microsoft-signed Analysis Toolpak Excel add-in (.XLAM) was vulnerable to code hijacking by loading an attacker controlled XLL via abuse of the RegisterXLL function.
In this post we will dive deep into a second code injection vulnerability in the Analysis Toolpak in relation to the use of the ExecuteExcel4Macro function in a Microsoft-signed Excel add-in. Furthermore, we will show that the Solver add-in is vulnerable to a similar weaknesses with yet another vector. In particular, we will discuss:
- Walkthrough of the Analysis Toolpak code injection vulnerability patched by CVE-2021-28449
- Exploitation gadgets for practical weaponisation of such a vulnerability
- Weakness in Solver Add-in
- Our analysis of Microsoft’s patch
Tags: Excel, Excel4, Macro, Office, Phishing, Signing, VBA, WebDAV, XLAM
A phishing document signed by Microsoft – part 1
This blog post is part of series of two posts that describe weaknesses in Microsoft Excel that could be leveraged to create malicious phishing documents signed by Microsoft that load arbitrary code.
These weaknesses have been addressed by Microsoft in the following patch: CVE-2021-28449. This patch means that the methods described in this post are no longer applicable to an up-to-date and securely configured MS Office install. However, we will uncover a largely unexplored attack surface of MS Office for further offensive research and will demonstrate practical tradecraft for exploitation.
In this blog post (part 1), we will discuss the following:
- The Microsoft Analysis ToolPak Excel and vulnerabilities in XLAM add-ins which are distributed as part of this.
- Practical offensive MS Office tradecraft which is useful for weaponizing signed add-ins which contain vulnerabilities,