Google Play Protect is a built-in Android solution that enhances devices’ security. Its main job is to detect and block malware on Android devices. Several malware families were known for bypassing Play Protect checks in recent years. This brings us to an important question: “Is Google Play Protect a Reliable Malware Detector?”. This blog post shows how Play Protect deals with various Android malware in different scenarios. I deal with Play Protect as a black box.
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.
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).
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.
Anti-Virus Software
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”
After our last blogpost regarding Emotet and several other Emotet and Ransomware samples that we encountered, we recently stumbled across a variant belonging to the Gozi, ISFB, Dreambot respectively Ursnif family. In this blogpost, we want to share our insights from the analysis of this malware, whose malware family is mainly known for being a banking trojan that typically tries to infect browser sessions and sniff/redirect data. In particular, we are going to provide details about the first stage Word Document, the embedded JavaScript/XSL document, an in-depth runtime analysis of the downloaded executable, and some details regarding detection.
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.
If you are interested in a hands-on analysis of Incidents and malicious files, we are giving another round of our Incident Analysis workshop at Troopers20.
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.
