More About Attacks on Financial Industries…

On Sept. 17, the FBI issued a warning about the possibility of cyber attacks on the financial industry. Recently, we observed another kind of an attack (not Distributed Denial of Service or Denial of Service attack) across at least two major financial institutions. The attack, if successful, will result in the establishment of a malicious communication channel on the victim’s computer. The purpose of this blog is to share the finer technical details about the level of obfuscation which was done to hide the malicious executable in the attack.

 

As a part of the first step, a user is tricked into downloading a JAR file. The JAR file contains class files and a blob named NNMUGKCW (MD5 sum a2a070341dc97e159e12cc8b5a97bc05). Among the class file, pl.class seems interesting. The decompiled code of the class file is shown in Figure 1.

Figure1.0

Figure 1. Decompiled pl.class file

Per the code, the class file creates a file with randomnumber.htm in tmp directory. In our setup, the name of the html file is 3461356738928279.htm. The class file then reads the blob “NNMUGKCW,” decrypts it per the decryption routine show in the Figure 1, and writes the content to the 3461356738928279.htm.

When the file 3461356738928279.htm is opened in a Hex editor, as shown in Figure 2, it becomes evident that the decrypted file is a dll file having the extension .htm.

Figure2.0

Figure 2. Content of 3461356738928279.htm file

When the file 3461356738928279.htm is opened in a debugger as shown in Figure 3, it makes a call to function LoadBitmapA to load the resource 345 of the dll.

Figure3.0

Figure 3. Code loading the resource 345

When resource 345 is viewed using resource hacker, as shown in Figure 4, it is a colorful image.

Figure4.0

Figure 4. Resource of 345 of the dll

Later in the code, there is a call to the function GetDIBits. The function GetDIBits retrieves the bits of the specified compatible bitmap and copies them into a buffer as a DIB using the specified format.

Figure5.0

Figure 5. Call to GetDIBits to copy the bits containing exploit

The pointer to the buffer as shown in the Figure 5 is stored in the variable named Result.  As shown in Figure 6, a call to the function VirtualProtect is later made to change the permission of memory pointed by Result.

Figure6.0

Figure 6. Call to VirtualProtect to change the permission of memory pointed by Result

Since the permission of memory is changed to execute read write, it becomes obvious to check the content of buffer pointed by result. This buffer, as mentioned above, had contents copied from the image in the resource section of the dll.

Figure7.0

Figure 7. Content of memory for which the permission is set to execute read write

As shown in Figure 7, when the dll is executed in Ollydbg, the contents from image at resource 345 is copied to a memory location at address 00084EA8. The content at 00084EA8 is an executable file, the permission of which is set to execute read and write by the VirtualProtect.

A quick look inside the executable file shows that the executable imports APIs to perform malicious communication.

Figure8

Figure 8. APIs imported by the executable file hidden in image

To summarize, the downloaded JAR file contains a blob and class files. The class file contains the code to decrypt the blob using a customized algorithm. The decrypted blob is a dll file. The dll file contains an image in the resource section. Hidden inside the image is a malicious executable which imports APIs to perform malicious communication.

 


 

This post was written by Abhishek Singh & Michael Vincent.