A walk down the memory lane

 A walk down the memory lane

A while ago we had to search for an old piece of code we had to check up something. During that, we woke up to the fact that we had literally hundreds of different code projects stashed away.

Some projects were simple, focused on doing a thing or another related to a specific piece of malware, like API name hashing, a technique quite commonly used by various malwares in order to hinder the analysis.

Some projects were not so simple, like extracting malware encryption keys directly from a live process memory, or brute forcing whatever the encryption was that a specific malware used.

We thought it'd be fun to dust off a few of the projects and share them. Even though the malware families they target are long gone, the techniques used in the projects still apply and can be adapted to malware families that roam the internet nowadays. All the source codes will be published over at Github. They will be shared under the MIT license, so feel free to do whatever you want with the sources. We'd love to hear if you adapt the code to do something new :)

So here we are, walking down the memory lane, starting the series with...

SpyEye

SpyEye emerged around 2010. Described by the Department of Justice as a "preeminent malware banking Trojan", it was used to infect over 50 million computers worldwide from 2010 to 2012, causing nearly $1 Billion in financial losses.

SpyEye used a technique that was called "man-in-the-browser". It basically injected itself into explorer.exe and processes that belonged to web browsers, hooking up several API's that it needed in order to monitor the what the user was browsing.

Certain web page forms were captures by the malware, and sent to it's creators. Also, whatever the victim had in the Autofill of the browser got snatched as well and sent onwards. So they got hold of banking id's and passwords that they could use later on steal all the moneys from victims.

SpyEye used a configuration file to get instructions on which banks it should target and how. The configuration resided in a modified ZIP-file that was protected with a 32 byte long alphanumeric password. You had to know the password in order to know what's in the configuration.

During it's peak, there were dozens of new SpyEye variants rolling in each and every day. Analyzing the samples by hand to extract the configuration was simply not a choice. Hence, we needed automation.

We created a DLL that would be injected into the running malware process. The DLL just sat and waited for the malware to decompress and deobfuscate itself.

Basically, when the actual malware.exe was executed it injected a copy of itself into the explorer.exe process and then killed it's original process.

Our DLL just waited for the moment when the OS would tell it to unload itself (DllMain() being called with DLL_PROCESS_DETACH flag), after which it scanned the process memory of the malware, looking for a potential password. If found, the password candidate was saved to a 'keyring' file and be later used to decrypt the configuration file.

Analyzing new SpyEye samples became a breeze and could be made in an automated fashion. We had hundreds of passwords in the keyring at the end, allowing us to decrypt virtually almost any SpyEye configuration that we got our hands on.

But what happened to SpyEye? In 2016, two individuals were sentenced to a combined 24 years and 6 months in prison for their roles in developing and distributing SpyEye.