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.
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).
Spymax is a mobile Remote Administration Tool (RAT) that enables an attacker to control victims’ devices through an Android malware. Once the malware is installed on a phone, the attacker can execute many attacks that highly impact the confidentiality and integrity of the victim’s data, as well as the victim’s privacy. It is powerful, widely available, and does not require root privileges on the victim’s device. In this blogpost, I show the capabilities of this RAT and analyze how its Android malware works.
I’m happy to announce the release of several plugins for Volatility 3 that allow you to dig deeper into the memory analysis. One of those plugins is PteMalfind, which is essentially an improved version of malfind. Another one is PteResolve which, similarly to the WinDBG command !pte, allows you to inspect Page Table Entry (PTE) information for e.g., a given virtual address. In this blog post we will have a closer look at these and more plugins, and the PteEnumerator base class and what you can do with it. The memory dump used for this blog post is available here. Some of the injection tools used in this blog post can be gathered from here.
I am glad to announce the release of the ERNW whitepaper 71 containing information about quarantine file formats of different AV software vendors. It is available here.
I took quarantine files from real-life incidents and created some in a lab environment. Afterwards I tried to identify metadata, like timestamps, path names, malware names, and the actual malicious file in the quarantine files. One goal was to use this information to support our incident analyses: Using the results, we can now easily create timelines showing information about quarantined files, extract the detected malware, and sometimes even find information about processes that created the malicious files. Continue reading “ERNW Whitepaper 71 – Analysis of Anti-Virus Software Quarantine Files”
Also, with this blog post, we are releasing a Rekall plugin called pointerdetector that enumerates all exported functions from all DLLs and searches the memory for any pointer to them (essentially a search for dynamically resolved APIs). This plugin can assist in identifying dynamically resolved APIs and especially memory regions containing DLLs loaded with techniques such as reflective DLL injection. This blog post will contain some examples illustrating the usage of this plugin, as well.
After the Emotet Incident at Heise, where ERNW has been consulted for Incident Response, we decided to start a blogpost series, in which we want to regularly report on current attacks that we observe. In particular we want to provide details about the utilized pieces of malware, different stages, and techniques used for the initial infection and lateral movement. We hope that this information might help you to detect ongoing incidents, apply countermeasures, and in the best case to figure out proactive countermeasures and security controls beforehand.
I am amazed by how this years BlackHoodie unraveled. Three days that included a pre-conference of lightening talks and two parallel tracks with a total of 64 enthusiastic members. The very spirit of BlackHoodie is nothing other than the quest to gain deep knowledge. Reverse engineering is one of the hardest fields in security. It touches on all fields of computing, starting from assembly, programming, file formats, operating systems, networks and what not. This makes it hard but an extremely fulfilling experience to spend time learning it. For me, the very idea of staring at a binary till you understand what it does is a magical feeling.
While doing heap research on Linux processes (results are going to be published soon), I came across the bot from the Mirai Botnet. As already mentioned in the blog post by Brian, the Mirai bot uses obfuscated configuration data which contains e.g. the CnC server. When now confronted only with a bot (e.g. in the context of a running task or the ELF binary), but without the according source code, the decryption of this configuration data for e.g. incident analysis purposes might not be easily possible (with the python script from the blog post), if the key has been changed.
But in this case that is not a problem at all, because Continue reading “A short Addendum on the Mirai Botnet Blog Post”