Tried, Tested and Proven

malware

Over the past few weeks, Portcullis has shared two parts of a three part series on “MutexName: “UFR_Stealer_2600″. The previous articles, part 1, focussed on a one-shot information stealing malware, while part 2, discussed “information gathering”.

In the very last article, part 3, we are going through the data-exfiltration steps that involve data compression and encryption, and finally we analyze the few Anti-Reversing tricks present in this
malware sample.

Data Ex-filtration

Now that the malware is finished collecting data from the host, it will go through a series of steps in order to compress, encrypt, and finally send the data over to the attacker’s FTP server. Continue reading

The following is part 2 of a series of 3 blog posts. In this article we go through the preparation stage that is undertaken to later exfiltrate the stolen data, which starts with connecting to a remote FTP server and goes on with temporarily storing the data in the host that will be later sent to the attacker.

Part 1 focussed on a one-shot information stealing malware. If you have missed the first article, please click here!

Connecting to the FTP server

The malware will initially retrieve the local date/time in the following format: “d-m-y_h-m-s”. Continue reading

The following is part 1 of a series of 3 blog posts, in which we go through an information stealing malware. We will be discussing the type of information it is interested in, as well as the way it stores and sends this information to the malicious FTP server. Furthermore, we will do an overview of a few Anti-Reversing tricks that we located during the analysis of this malware.

Introduction

Recently, we identified a malware sample, the sole purpose of which was to steal information, including login credentials and other host related information. This is, of course, nothing new. What we found interesting about this particular sample, was that the malware does not attempt to achieve persistence on the ‘infected’ host. Continue reading

Introduction

With hundreds of thousands of malware samples floating around the internet, AV companies have to struggle everyday in order to keep their detection signatures updated. These malware samples are not necessarily all functionally different to each other, but most of them try to appear different in an attempt to bypass AV products.

In reality, the concept of polymorphism is still much more popular than metamorphism. The reason for this is, that polymorphism as we know it today, through malware samples is far easier to achieve.

While metamorphism requires re-implementing parts of the code, while keeping the same functionality, polymorphism is generally applied by keeping the code intact but encrypting it each time with a different method or via the use of different encryption keys. Metamorphism also commonly uses the insertion of junk code that can be changed quickly, making it effective at defeating static detection, though the insertion of junk code. This could also be considered as ‘cheap metamorphism’ since no real re-implementation of the code was done, but the code does appear different. Continue reading

The following is part 2 of a series of 2 blog posts, which will discuss how our analysis leads to the automation of the identification of all the locations containing encrypted data and all the calls to the decryption routine, allowing us to manipulate the malware into calling the decryption routing for all the encrypted data hence revealing all the malware’s prized secrets.Part 1 focussed on a maliciously dropped DLL file. If you have missed the first article, please click here!

As discussed in part one, there are about 700 different locations where the decryption routine is called, each using different keys and data length parameters. Revealing this hidden data is an important step. It aids us in understanding the hidden functionality of the malware, it also helps us understand the aim of the malware, giving us an insight into how it undertakes reconnaissance, how it communicates with its controllers and how it accesses information once in place. Continue reading

The following is part 1 of a series of 2 blog posts, which will focus on a maliciously dropped DLL file. It will also analyse the selective on-the-fly-decryption of data based on the generic functions of the malware or its dynamic importing of the required Windows APIs.

Introduction

The analysis in this article will focus on a maliciously dropped DLL file discovered by the Portcullis CTADS team during an investigation.

The malware actions are based on the configuration that the dropper applies to the infected system, however, typically it will create a service to ensure that the malware will run on every system startup. Continue reading

Over the past few weeks, Portcullis has shared two parts of a three part series on “Static Analysis vs Dynamic Imports”. The previous articles, part 1, discussed in detail the reasons “why malware developers use dynamic imports”, while part 2, discussed “dynamic imports methodology used by a malicious driver”.

In the very last article, part 3, we will demonstrate to the reader, on how to modify the code of the ChecksumExportLocator function, in order to retrieve the names instead of the addresses. The investigation will also show how to make a simple tool that will automate the whole process for all the dynamically imported APIs.

This particular investigation required Portcullis analysts to write a custom tool to automate the resolving of checksums to API names and how it speeds up the analysis process. This can be used on subsequent malware investigations which use similar dynamic importing methods. A tool was necessary in order to automate the process of finding the matches between he checksum constants and the kernel function names. Even though, this tool is particularly targeting the custom checksum algorithm of this driver, it can be maintained by adding more functions corresponding to different malware families. Furthermore, it is highly possible that a future version of the same malware will incorporate the same dynamic importing method through the same algorithm. Continue reading

Portcullis have compiled a three part series on “Static Analysis vs Dynamic Imports”. Part 1 discussed in detail, the reasons why malware developers use dynamic imports. If you have missed the first article, please click here!

The following article in part 2, will discuss “Dynamic imports methodology used by a malicious driver”.

This article will take the reader through a partial analysis of an actual piece of malware found in the wild. The aim is to show how the malware author attempts to find the base address of the Windows Kernel module and how the malware tries to hide its intended purpose. This is interesting because it calls the address of ‘legitimate’ functions in order to calculate the address of the intended target, making the malware appear benign at first glance. Finally, a description is given as to how the malware uses custom checksums calculated from exported function names and compares them against hard-coded ones to retrieve kernel functions. Continue reading

The following is part 1 of a series of 3 blog posts, which will describe in detail the reasons why malware developers use dynamic imports, how drivers operate in Kernel mode and why they often require static analysis and the challenges these elements present.

In a recent investigation, Portcullis has had to undertake static analysis of malware, which acting as a driver performed dynamic imports of Windows APIs.

Dynamic imports are always an issue from the malware analyst’s perspective, especially while performing static analysis on various malicious components. We are going to focus on the Windows OS where there are mainly two different methods for achieving dynamic importing of Windows APIs. Continue reading