As a number of major U.S. financial institutions deal with the aftermath of what was perhaps the largest DDoS campaign ever, researchers at FireEye are reporting on a separate phishing attack that establishes a channel of malicious communications on its victims’ computers.
The attack is affecting at least two banking institutions, though FireEye does not name them in their report. Threatpost reached out to FireEye for clarification on how and if this attack is related to the recent DDoS campaign and who exactly is affected by it. FireEye had not responded by the time of publication.
“To summarize,” FireEye researchers Abhishek Singh and Michael Vincent wrote, “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.”
More specifically, in order for the attack to be successful, the attackers must compel their victim to download a JAR file containing class files and a blob named ‘NNMUGKCW’ (MD5 sum a2a070341dc97e159e12cc8b5a97bc05). FireEye notes that the pl.class within the class file has some interesting code, which you can see in its decompiled form here.
The class file goes on to create a random .htm file in the temp directory, then the class file reads the blob ‘NNMUGKCW,’ decrypts it, and writes it back to the randomly generated .htm file, which in FireEye’s case was 3461356738928279.htm.
Once the researchers at FireEye opened 3461356738928279.htm in a hex editor, they realized that it was a DLL file with a .htm extension. They then opened it in a debugger, where it called the ‘LoadBitmapA’ function, which loaded resource 345 of the DLL, which showed up as this image. It also makes a call to another function that FireEye identifies as ‘GetDIBits.’ ‘GitDIBits’ grabs bitmap and copies them into a buffer as DIB.
The buffer is then stored in the variable named ‘result.’ Meanwile, another call is made to the ‘VirtualProtect‘ function that changes the permission of memory guided by ‘result’ to ‘execute read write.’ Because of this, the researchers checked the buffer and determined that its contents had been copied from resource 345 to the DLL.
Once the DLL is executed, the contents of resource 345 are copied to a memory location where they are used as an executable to execute read and write by ‘VirtualProtect.’
The researchers found that the executable then imports an API to perform malicious communication between the victim and the attackers.
You can read FireEye’s entire analysis of the attack here.
