Using memory analysis to hunt more malware

CERT-LatestNews ThreatsActivists

I recently published a blog on Hunting Malware with Memory Analysis. Well, it is about time to dive back in to some memory analysis fun. This time, however, we will use memory analysis techniques to retrieve the Dyre Trojan configuration. While Dyre is a bit old and no longer in the wild, the concepts used here are still relevant to current malware.

Dyre was a well-known banking Trojan that harvests credentials, primarily targeting online banking. It did this by using man-in-the-browser functionality and dynamic web injects to manipulate content on a financial institution’s website and intercept credentials and sensitive information of the victim. This is where the configuration file comes in. The configuration file contains the proxy server(s) controlled by the attackers and the target bank URLs that trigger the man-in-the-browser to redirect the connection to the designated proxy server. Dyre’s configuration file looks like the following:

Because the plain text configuration file is held in memory, this is the easiest approach to retrieving it. There are two different approaches you can take here. The first is that you can do a full memory dump of the system or you take the second approach, and dump only the process memory of the injected process. If you take the full memory dump approach, you can use the volatility plugin dyrescan. I’ve had issues with the plugin actually dumping the configuration file contents at times, but it will help identify the injected process, which is typically the top most svchost process. In this example, it is injected into the explorer.exe process.

For the first approach, you can dump the explorer.exe (2180) process using volatility to start the extraction process.

However, if you want to start with the second approach and just dump the injected process memory of an infected host, you can use Windows Sysinternals Process Explorer. After using it, right-click the injected process, then select Create Dump/Create Full Dump.

Now that we have a memory dump to work with, we can get the contents of the configuration file. The configuration file typically starts with the string “<serverlist>” and ends with “</localitems>”. Using the strings command and sed stream editor, we are able to retrieve the configuration. From here you can copy and paste or redirect the output to a text file.

Now let’s look at what else can we get from memory related to Dyre. For many researchers, tracking the Dyre Trojan is done with the “botid” or campaign. The botid is typically contained in the command-and-control (C2) uniform resource identifier (URI) structure immediately following the domain or IP address. The configuration file is retrieved as part of the initial communication performed by Dyre, so the URI structure is contained in memory. The string typically starts with “tps:”. Using this knowledge we can extract those strings, like so:

By using awk and sed, we can pull just the botid for the strings above.

If you are interested in getting a list of the bank URLs that are targeted by Dyre to perform victim redirection you can dump them all as shown below.

The following is an example of putting all of this together to make life a little easier. It’s not perfect and could probably use some additional work, but it does the job. <!–[if !supportLineBreakNewLine]–> <!–[endif]–>

There may be other ways to figure out the exact impact that Dyre is having on your environment. But, checking what Dyre says it is doing may be the most effective way. And, I thinking dumping Dyre’s configuration file from memory is a pretty good way to see what Dyre is actually doing. Again, Dyre is old and no longer in the wild but keep in mind that malware continues to evolve and any techniques to retrieve the configuration files and additional memory contents might need to change with the evolution.

Be calm and memory on.