Tried, Tested and Proven


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.


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