While investigating the malware and shellcode that were associated with the recent Adobe Flash Player, Adobe Reader, and Acrobat 'authplay.dll' Remote Code Execution Vulnerability (BID 40586), we came across some interesting similarities to the malware and shellcode that were used in the Microsoft Internet Explorer 'iepeers.dll' Remote Code Execution Vulnerability (BID 38615) targeted attacks from March 2010.
The first similarity is in the shellcode
The image below is the function-hooking shellcode that was used in the targeted attacks against the Microsoft Internet Explorer 'iepeers.dll' Remote Code Execution Vulnerability in March 2010:
Below is the function-hooking shellcode that was used in the targeted attacks against the Adobe Flash Player, Adobe Reader, and Acrobat 'authplay.dll' Remote Code Execution Vulnerability from earlier this month:
The function names in the images are different, but the contents are the same. In fact, we used the PatchDiff2 tool to find the differences between these shellcode samples and found that all of the functions were almost identical. There are very few differences, except for a few improvements. This can be seen below; once again the names are different, but they are just the names that an analyst adds when reverse-engineering the assembly code:
Both of these shellcode samples hook UnhandledExceptionFilter, MessageBeep, and LdrShutdownThread, and are fairly advanced. It appears that the goal of the shellcode author was to protect the zero-day and hide the attack from the victim. We have seen this shellcode before! We wrote about it in 2008 in the blog titled "Protecting Zero-Day." It was used in a targeted attack against the Microsoft Internet Explorer XML Handling Remote Code Execution Vulnerability (BID 32721). That makes three attacks using this private shellcode to target zero-days over a period of two years. It is quite common to have a shellcode that is used in many attacks; for this reason, we started to examine the similarities between the malware used in both of the attacks.
The second similarity is in the dropped malware
The image below illustrates a comparison (using PatchDiff2) of just one of the functions of the initial malware that is dropped in this attack and one that is dropped by the malicious code in the IEPeers attack. These functions are almost identical:
So, we invested some time to check the similarities between the malware that is installed in one of the attacks against the Adobe Flash zero-day from this month and the malware used in the targeted IEPeers attack from March. All of the major functions are identical in the first stage malware:
Both of the malware samples involved have a first stage binary that accepts the following parameters:
The malware in both attacks also extracts a DLL from the resources section of the binary into the Windows %TEMP% directory and begins to scan for the following processes:
• iexplore.exe (Microsoft Internet Explorer)
• firefox.exe (Mozilla Firefox)
• outlook.exe (Microsoft Outlook)
When any of these processes are found, the DLL is injected into the process. This is true for both attacks; in fact, the below image is a screenshot from our analysis of the malware from the IEPeers attacks. You can see the malicious DLL ‘wshipl.dll’ injected into the iexplore.exe process:
Funnily enough, the filename for the DLL used in the IEPeers attack is 'wshipl.dll' and the filename for the DLL that was used in this recent attack is 'wshipm.dll', suggesting an incremental version increase in versions from ”l” to ”m.” This is all very interesting. It is difficult to look at these similarities without drawing the conclusion that these attacks are linked by methodology and tool chain.
Of course it is impossible to say for sure, but it certainly seems like the attacker(s) that targeted the Adobe Flash Player, Adobe Reader, and Acrobat 'authplay.dll' Remote Code Execution Vulnerability this month also participated in the IEPeers attack from March 2010, and potentially even participated in the targeted attack against the Microsoft Internet Explorer XML Handling Remote Code Execution Vulnerability in 2008. The term Advanced Persistent Threat (APT) is fashionable at the moment—and we hesitate to use it—but an active attacker that uses a zero-day to target their victims over such a long period of time seems to be the kind of attacker that this term applies to, which should be a concern for those who are working to protect their infrastructure and assets.
As always, Symantec recommends that users stay up to date with vendor patches and product updates whenever possible. In the event that a software patch is not available, such as in the case of a zero-day vulnerability, users should endeavor to follow any mitigation strategies or workarounds listed in vendor security advisories as soon as they are available.