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
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 malware will initially retrieve the local date/time in the following format: “d-m-y_h-m-s”. Continue reading
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
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
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 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
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
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
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