This blog is about two chained bugs: Stage one is a DLL Hijacking bug caused by the remapping of ROOT drive and stage two is an Activation Cache Poisoning bug managed by the CSRSS server.

Impacket 0.12 is now available! A lot of work has been done since version 0.11, and this new release includes improvements to libraries and examples,  new examples, and more.Encoding UpdatesSome encoding issues were still present after transitioning from python 2 to python 3, primarily caused by transitions between bytes and str object types.Version 0.12 features encoding updates  in several examples and libraries when receiving non ascii text parameters. 

In this blog post, I will explain a vulnerability in the Microsoft Windows Desktop Windows Manager (DWM) Core library that I analyzed when the exploit for Core Impact was being developed. This vulnerability allows an unprivileged attacker to execute code as a DWM user with Integrity System privileges (CVE-2024-30051).

IntroductionCVE-2024-6768 is a vulnerability in the Common Log File System (CLFS.sys) driver of Windows, caused by improper validation of specified quantities in input data. This flaw leads to an unrecoverable inconsistency, triggering the KeBugCheckEx function and resulting in a Blue Screen of Death (BSoD). The issue affects all versions of Windows 10 and Windows 11, Windows Server 2016, Server 2019 and Server 2022 despite having all updates applied.

One of Core Impact’s most valuable features is its certified exploit library. Fortra’s Core Security has a team of expert exploit writers that conduct research, evaluating and prioritizing the most relevant vulnerabilities in order to update the library with critical and useful exploits.  Additionally, the QA team creates its own clean environment to validate each exploit before its release to ensure our standards and validate that it is safe and ready to use.

One of Core Impact’s most valuable features is its certified exploit library. Fortra’s Core Security has a team of expert exploit writers that conduct research, evaluating and prioritizing the most relevant vulnerabilities in order to update the library with critical and useful exploits.  Additionally, the QA team creates its own clean environment to validate each exploit before its release to ensure our standards and validate that it is safe and ready to use.

While reading the amazing Inline-Execute-PE by Octoberfest7, I noticed that to obtain the output from the PE being executed, the author needed to allocate a console, which results in a process being created (conhost.exe).

After the latest Impacket release, we have continued the process of integrating functionality submitted during the gap between the 0.10 and 0.11 releases. In this blog, we will highlight three items that were in our backlog during that period, which are now in the process of being fully implemented into the tool. All of them are related to kerberos functionality.

We are thrilled to announce a new version of Impacket! After months of hard work and dedication, Impacket v0.11.0 is now available and has a bunch of new and exciting features. We can’t wait for you to explore and enjoy the added capabilities that come with this version! Let’s take a look at everything new included in this release.

Recently, the Nokoyawa ransomware group, which has been active since In February 2022, was found to be exploiting a Windows zero-day vulnerability in one of its attacks. This vulnerability targets the Common Log File System (CLFS) and allows attackers to escalate privileges and potentially fully compromise an organization’s Windows systems. In April 2023, Microsoft released a patch for this vulnerability and the CNA CVE-2023-28252 was assigned.

In this article we would like to share the analysis and work done on CVE-2022-37969 to build a functional PoC based on previously published information by Zscaler.

In part 14, we began discussing how to analyze the difficulty of creating a rop depending on the scenario. In this part, we’ll continue that discussion with a rop that is not as simple as the ones we have seen in previous parts. As we did last time, we’ll start by using radare in visual mode to practice. Reversing with Radare, Exercise 2: 32 Bits As a reminder, the exercises are available here:

In part 13, we analyzed and adapted the RESOLVER for 64 bits. In this part, we’ll discuss how to analyze the difficulty of creating a rop depending on the scenario.

When we think about EDR or AV evasion, one of the most widespread methods adopted by offensive teams is the use of system calls (syscalls) to carry out specific actions. This technique is so common and effective simply because most AVs/EDR have userland hooks to track and intercept requests userland processes make. However, we found that a key userland API, CreateProcess, is still extensively used even in offensive tools to create processes.

I wanted to write this article to demonstrate the analysis I did while developing the Core Impact exploit “Windows Network File System Remote” that abuses the CVE-2022-30136 vulnerability.

The F5 BIG-IP iControl REST vulnerability, a critical authentication bypass vulnerability that leads to unauthenticated remote code execution, is quite simple to exploit and provides an attacker with a method to execute arbitrary system commands as root.

In this blogpost, we’ll briefly describe how we developed a DoS module for CVE-2022-21907. Instead of viewing it in a result-oriented way, we’ll approach it from a research standpoint, describing the process of developing this module for Core Impact.

In part 12, we completed the ROP bypass of the DEP in 64 bits. In this part, we’ll analyze and adapt the RESOLVER for 64 bits.  Resolution of the 64-Bit Exercise As a quick point of clarification, the shellcode is not mine. However, it is quite public, so it was simply adapted for this example.

I wanted to write this blog to show the analysis I did in the context of developing the Core Impact exploit “Win32k Window Object Type Confusion” that abuses the CVE-2022-21882 vulnerability. It’s based on the existing Proof of Concept (POC), which is both interesting and quite complex.

In part 11, we completed the ROP bypass of the DEP. In this part, we’ll begin our first exercise compiled in 64 bits. Before beginning, we’ll go over a few concepts in detail, because this exercise requires a new frame of reference. While the base is the same, it’s important to know the differences between 32 and 64 bits in order to be successful in reversing.

This post focuses on creating Cobalt Strike Beacon Object Files using the MinGW compiler on Linux. We will discuss several ideas and best practices that will increase the quality of your BOFs. Flexibility Compiling to Both Object Files and Executables While writing a BOF is great, it’s always worth making the code compile to both BOF and EXE.

The Log4Shell vulnerability, a serious remote code execution vulnerability in the Apache Log4j2 library, is one of the best candidates for winning several Pwnie awards in 2022.

Motivation

In part 10, we started exploring different protections and mitigations that we may find. In this part, we’ll continue this exercise, completing the ROP bypass of the DEP. Roping Step by Step Typically, there are tools that, in simple cases can automatically build a ROP. However, in difficult cases, these tools generally can’t fully build one, or can only partially do so, leaving one to complete by hand the work that the tool could not do.

In the previous parts of this series, we went through some basic examples of exploitation and reversing. Now we’ll take a step forward, gradually adding different protections and mitigations that we will find.