injection – Insinuator.net

Misc

September 6, 2023 by Frank Block

Identification of (malicious) modifications in memory-mapped image files

I’m happy to announce the publication of the paper Windows memory forensics: Identification of (malicious) modifications in memory-mapped image files at this years DFRWS USA, and the release of the corresponding volatility plugin. With this research came also an update to the Ptenum family (affecting especially the ptemalfind plugin), which makes the plugins reliable in identifying modified pages despite memory combining, so make sure to grab the newest version from the Github repository.

This blog post will mainly cover the imgmalfind plugin and some use cases. For detailed information on the theory behind the plugins, see the paper.

Continue reading “Identification of (malicious) modifications in memory-mapped image files”

Breaking

June 13, 2023 by Dennis Heinze

Jasper Reports Library Code Injection

During the past year we had several projects where our target application used Jasper Reports in some way. In a few of the cases we found an API that offered to render a template along with some arguments into a PDF file. This was done with the help of the Jasper Reports Java library. Due to the way the library and the expression mechanism works, this endpoint gave us the possibility to inject Java code and gain remote code execution on the target systems.

In this blog post we want to provide an overview over the Jasper Reports Java library in terms of security especially with regard to expression injection attacks.

TL;DR; If you come across an API that lets you freely define a Jasper Report template you very likely have code execution. Or to put it differently: Never let Jasper Report templates be user or attacker controlled.

Continue reading “Jasper Reports Library Code Injection”

Breaking

September 29, 2022 by Frank Block

Some experiments with Process Hollowing

Process Hollowing is a technique used by various malware families (such as FormBook, TrickBot and Agent Tesla) to hide their malicious code within a benign appearing process. The typical workflow for setting up such a hollowed process is as follows:

Create a new process (victim) using a benign executable, in suspended state.
Unmap the executable from that process.
Allocate memory for the malicious executable at the address of the previously mapped victim executable.
Write the malicious executable to the new memory area and potentially apply relocations.
Adjust the entry point.
Resume process.

We will refer to this as the “normal” Process Hollowing workflow. There are also variants of this technique, one being to not unmap the original executable and to allocate the new memory somewhere else. We will call this one no-unmap. But wait, why does malware not simply overwrite the existing executable but creates a new memory area which stands out due to its characteristics? In this blog post we will have a closer look at this overwrite approach but also on the no-unmap method, their effects on analysis/detection tools and on some tricks to make the detection harder. We are also releasing Proof of Concept implementations of all mentioned tools/plugins (the links are at the end of this post).

Continue reading “Some experiments with Process Hollowing”