ITSEC Newsletter 2023-10-05

"MSI installers are still pretty alive today. It is a lesser known feature, that a low privileged user can start the repair function of an installation which will run with SYSTEM privileges. What could go wrong? Quite a lot!"

"Leveraging .NET based tooling, by reflectively loading assemblies into memory, is a common post-exploitation TTP used by threat actors as well as red teams for many years already. The use of .NET is attractive for multiple reasons. First of all the .NET framework comes pre-installed with all recent versions of the Windows operating system, which allows for high portability and compatibility. In addition, .NET, especially C#, offers an easy development experience, with many libraries for common protocols and software, which allows for quick prototyping and PoCs. Hence, many of the most valuable tools for offensive operations, such as SharpHound, Certify or Rubeus, are written in or have been ported to C#.

At the latest with the release of Cobalt Strike 3.11 in 2018, which introduced the execute-assembly command to the framework, .NET based tradecraft became a stable in every red teamer's arsenal. However, defenders caught up with this trend in recent years, employing several techniques to detect in-memory .NET assembly execution.

This blog post will give a short overview of how in-memory .NET assembly execution commonly works and what detection mechanisms exist. One of the techniques that we at r-tec employ to evade these detections is obfuscation. The final part of this post will then showcase how we automate this approach through CI/CD / DevOps techniques in our internal obfuscation pipeline."

"Process injection is a family of malware development techniques allowing an attacker to execute a malicious payload into legitimate addressable memory space of a legitimate process.

These techniques are interesting because the malicious payload is executed by a legitimate process that could be less inspected by a security product such as an EDR.

However, in order to perform this injection, the attacker needs to use specific functions for memory allocation, and use execution primitives to write and execute his payload in the remote process. In standard process injection patterns, these functions are usually the following Win32API: VirtuallAllocEx, WriteProcessMemory and CreateRemoteThread.

Security products can use this the mandatory use of this type of functions to detect and fight against process injection by monitoring these API calls. Therefore, in order to keep this type of technique viable, attackers must find other ways to allocate, write and execute memory in a remote process.

This post aims to show an alternate technique allowing execution at an arbitrary memory address on a remote process that can be used to replace the standard CreateRemoteThread call."

“One major difficulty of doing low-level security research is the lack of a testing and debugging environments. When testing regular user space programs written in C and other high-level programming languages, there are a plethora of debugging tools like gdb to run, inspect, and modify a running process. Dynamically inspecting software becomes harder the lower the level of abstraction you go; while there are many resources for debugging user space programs, there is less information out there for kernels, bootloaders, and system firmware.

There are some good guides on how to get started with firmware development and many fascinating security research blogs about UEFI vulnerabilities, but when getting hands-on with UEFI security research recently, I found little overlap. This blog post is an attempt to fill that gap and quick start firmware security research for those new to the field. Getting a research environment is sometimes the hardest part of security research so we will start by building, running, and debugging emulated firmware. Then, to better understand the (in)security of UEFI, we'll inject a common vulnerability in our firmware and exploit it.“