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

Last week, our friends from Norman published a great report on a cyber espionage campaign named Operation Hangover. 

We have released some Yara rules to detect most of the payloads mentioned on the paper. You can download the rules from our Github space:

Captura de pantalla 2013-05-23 a la(s) 12.20.00

 

On the other hand the Hangover attackers have been using several payloads with network capabilities to steal data including documents, keystrokes and downloading other payloads.  Following are some examples of network traffic performed by these payloads:

- Smackdown Minapro

Captura de pantalla 2013-05-23 a la(s) 12.31.30

- Hangover

Captura de pantalla 2013-05-23 a la(s) 12.33.32

- Several keyloggers and data harvesters

 

Captura de pantalla 2013-05-23 a la(s) 12.37.43

Some of the network requests made by these payloads were covered by Snort rules (Emerging Threats) months before the Operation Hangover was uncovered) so our product was alerting on these connections from at least several weeks.

Captura de pantalla 2013-05-23 a la(s) 12.42.49

 

AlienVault Unified Security Management (USM) will detect all the threats mentioned on the blog post (and it’s available as a Free 30 day trial download).

 

 

 

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

Last month Adobe released a fix to patch a vulnerability that was being exploited in the wild. Kaspersky found that the 0day was being used by a very sophisthicated group to target different governments  using a malware called MiniDuke.

Alienvault Labs have detected that a different group of attackers have been using this vulnerability to target non-governmental and human rights organizations.

Together with our partner Kaspersky Labs we are releasing an analysis of this campaign. You can read his report here.

Based on the samples we found we believe this group has been running a SpearPhishing campaign from the last few weeks. The files we have analyzed are PDF files that contain code to exploit CVE-2013-0640. Once the victim opens the file, the system gets infected and a lure document is displayed to the victim. Some of the PDF lures we have found are:

 

 

 

 

 

 

 

 

 

 

 

 

Some of the exploit filenames:

  • 2013-Yilliq Noruz Bayram Merikisige Teklip.pdf
  • 联名信.pdf
  • arp.pdf

Based on the lures we found it seems the same group is targeting both Tibet and Uyghur activists in the same campaign.

The Javascript code inside the PDF files is very similar to the one found in the Itaduke samples but part of the initial variables and the obfuscation has been removed from the original one.

The shellcode will create the file AcroRd32.exe in the Temp folder. That file decrypts an encrypted block using XOR operations with the key “0l23kj@nboxu”.

The malicious payload will perform the following operations:

- Copy \WINDOWS\system32\wuauclt.exe to %APPDATA%\wuauclt\wuauclt.exe
- Drop a malicious DLL under %APPDATA%\wuauclt\clbcatq.dll
- Execute %APPDATA%\wuauclt\wuauclt.exe

Note that wuauclt.exe is a benign system executable. Once the system file is executed, the malicious DLL will be loaded. This technique is known as DLL search order hijacking.

The malicious DLL will be loaded when wuauclt.exe is executed. It is important to show that clbcatq.dll is not exporting all the methods that the original clbcatq.dll has. It only implements the ones that are required to run the malicious code:

Original DLL                                                                       Malicious DLL

 

 

 

 

 

 

 

 

 

 

 

Once the malicious DLL is loaded, the malicious code will generate the following HTTP request:

 

 

 

 

 

The server will reply with an encrypted block of code that will be decrypted. The decrypted content is actually a DLL that exports the following functions:

  • GetWorkType
  • InfectFile

The payload will drop the following files:

  • \WINDOWS\system32\wbem\4BA5E980.PBK
  • \WINDOWS\system32\wbem\mstd32.dll

The InfectFile function will modify some code in the system library WINDOWS\system32\mswsock.dll. If we take a look at the patched DLL:

Original version

 

 

 

 

 

 

 

 

 

Modified version:

 

 

 

If we take a look at WSPStartup_0:

 

 

 

 

 

 

We can see how the malicious DLL mstd32.dll will be loaded everytime the system library mswsock.dll is loaded by a program.

The file mstd32.dll is signed using a certificate issued to “YNK JAPAN Inc. We have seen that certificate being used to sign malware dropped in several NGO attacks in the past.

 

 

 

 

 

 

Then the malicious code will perform the following HTTP request every few seconds:

 

 

 

 

 

The final payload is detected as Trojan.Win32.Swisyn and it has a lot of functionality to monitor and steal data from the infected system.

We have identified the following C&C servers for both payloads:

  • ly.micorsofts.net
  • ip.micrsofts.com
  • xdx.hotmal1.com
  • hy.micrsofts.com
All the DNS names are pointing to 60.211.253.28 at this time.

 

 

 

 

 

 

 

 

 

 

Both domains have been registered using the same mail address:

micorsofts.net

Created: 2008-05-12 01:51:10
Expires: 2013-05-12 01:51:10
Last Modified: 2012-05-02 13:26:38

Registrant Contact:
GW SY
li wen li wen (lcb_jn@sina.com)
zq dj
jiningshi, shandongsheng, cn 272000
P: +86.05372178000 F: +86.05372178000

hotmal1.com

Created: 2008-12-30 03:53:18
Expires: 2013-12-30 03:53:18
Last Modified: 2012-12-26 15:32:15

Registrant Contact:
GW SY
li wen li wen (lcb_jn@sina.com)
zq dj
shixiaqu, beijingshi, cn 272000
P: +86.02227238836601 F: +86.02227238836601

Profile of the user on 20cn.net

We – Alienvault Labs- have written some Snort rules to match the network behavior:

 

You can use the following Yara rule to match the malicious binaries:

 

 

 

 

 

 

 

 

And this one to detect the malicious PDF files:

 

 

 

 

 

 

Finally, we are releasing some OpenIOC indicators as well:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

You can find all the content in our GitHub repository.

The rules have been included in the EmergingThreats ruleset as well as in our Open Source SIEM.

 

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

Tracking down the author of the PlugX RAT

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

Some days ago, TrendMicro published some information about a new version of a RAT called PlugX. From the last few months we have been tracking a group using the PlugX RAT that has been attacking different targets especially in Japan, Taiwan, Korea and against Tibetan organizations and individuals.

In this post we will focus on the intelligence we have extracted from the payloads of the attacks and how we used this information to track the author of the RAT that is very likely to be involved in the attacks as well.

During the past few months we have seen some spearphishing campaigns against Tibetan targets using mainly Microsoft Office Exploits (CVE-2012-0158). Those documents used a very tricky technique; the payload dropped was a benign Nvidia executable (NvSmart.exe), a DLL (NvSmartMax.dll) and a binary file (boot.ldr) This technique was explained by Symantec as well.

NvSmart.exe

https://www.virustotal.com/file/523d28df917f9d265cd2c0d38df26277bc56a535145100ed82e6f5fdeaae7256/analysis/

 

As we can see the binary file is signed by Nvidia since it is a benign file used on some Nvidia applications. Once NvSmart.exe is executed, it loads NvSmartMax.dll. The attackers drop a modified version of NvSmartMax.dll which executes the binary content present on boot.ldr that contains the actual malicious code.

Since NvSmart.exe is configured to run when the computer starts and it contains a valid digital signature, it will bypass some of the OS restrictions and the malicious code will be executed when the system boots.

Once the payload is executed, a decoy file is shown to the user as in most of the attacks we have seen in the past few years.

Here is an example of some of the decoy content used by the attackers:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

It happens that in most of the boot.ldr files we have found the RAT called PlugX.

At the beginning of our investigations some months ago, we found out that in some of the PlugX binaries we were able to extract some debug paths like:

Hash: c1c80e237f6fbc2c61b82c3325dd836f3849ca036a28007617e4e27ba2f16c4b

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

Compilation date: 6/17/2012 16:44:58

 

Hash: 1a091c2ddf77c37db3274f649c53acfd2a0f14780479344d808d089faa809a_HHDL’s Birthday Celebration.doc

Debug Path: d:\work\Plug3.0(Gf)UDP\Shell6\Release\Shell6.pdb

Compilation date: 6/17/2012 16:44:58

 

Hash: 42813b3a43611efebf56239a1200f8fc96cd9f3bac35694b842d9e8b02a

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

Compilation date: 5/26/2012 7:16:08

 

Hash: 28762c22b2736ac9728feff579c3256bd5d18bdfbf11b8c00c68d6bd905af5b8

Debug Path: d:\work\plug3.1(icesword)\shellcode\shellcode\XPlug.h

Compilation date: 6/14/2012 6:06:00
It seems that there are several versions of the RAT and if you take a look at the binaries you will realize that there are some changes and new capabilities in each version.

We searched through our collection to see if we could find other XPlug samples apart from the ones dropped by the malicious documents we had. We found some other samples:

Hash: 3b01677582e7a56942a91da9728c6251- financial_report.exe

Debug Path: C:\Users\whg\Desktop\Plug\FastGui(LYT)\Shell\Release\Shell.pdb

Compilation date: 6/17/2012 16:44:58

 

Hash: 60ee900d919da8306b7b6dbe7e62fee49f00ccf141b2e396f5a66be51a00e34f

Debug Path: C:\Documents and Settings\whg\\Plug\FastGui(LYT)\Shell\Release\Shell.pdb

Compilation date: 2012-03-12 07:04:12

 

Hash: c00cd2dcddbb24383a3639ed56e68a24dc4561b1248efa4d53aa2b68220b4b2a

Debug Path: C:\Users\whg\Desktop\Plug\FastGui(LYT)\Shell\Release\Shell.pdb

Compilation date: 3/12/2012 14:23:58

As we can see the debug paths found on those files are a bit more interesting since the path contains a username “whg”. We have two different paths, “C:\Documents and Settings\whg\” and  “C:\Users\whg\” so it is likely that in the first case the author is using a Windows XP system and in the second one he is using a Vista/7 system.

With this information, we began to search binary files that contain similar debug paths. Our search found an application called SockMon that leads us to http://www.cnasm.com/view.asp?classid=49&newsid=320 and http://www.cnasm.com/view.asp?classid=49&newsid=315.

The debug paths that we found in files that belong to a different SockMon version are the following ones:

C:\Users\whg\Desktop\SockMon2011\SockMon\UnitCache.pas

c:\Documents and Settings\whg\SockMon2010\RunProtect\Release\RunProtect.pdb

c:\Documents and Settings\whg\\SockMon2010\SmComm\Release\SmComm.pdb

We also found another library called vtcp (http://www.cnasm.com/vtcpsdk/) that contains the following debug path:

C:\Users\whg\Desktop\vtcp11.0lib\vtcpT0\UnitMain.pas

Does this all look familiar to you?. It seems that the user “whg” has compiled these components and he is also running a couple of machines with different paths that correspond to the ones we found on the XPlug RAT.

If we take a look at cnasm.com we can find the following contact information:

email: whg0001 at 163.com

QQ: 312016

So the mail address also coincide with the username we found in the debug path of the RAT samples.

Let’s see what we find about whg0001 at 163.com. The mail address was used as the administrative contact of the domain chinansl.com back in 2000:

Domain Name      : chinansl.com

PunnyCode        : chinansl.com

Creation Date    : 2000-08-08 00:00:00

Updated Date     : 2012-02-29 11:26:22

Expiration Date  : 2013-08-08 00:00:00

 

Registrant:

Organization   : chinansl technology co.,itd

Name           : lishiyun

Address        : Room E8BC , XiangFu Garden , 3rd Southern portion of 2nd ringroad , Chengdu , Si

City           : chengdushi

Province/State : sichuansheng

Country        : china

Postal Code    : 610041

 

Administrative Contact:

Name           :

Organization   : chinansl technology co.,itd

Address        :

City           : chengdushi

Province/State : sichuansheng

Country        : china

Postal Code    : 610041

Phone Number   :

Fax            : 086-028-85459578

Email          : whg0001@163.com

In this link you can find more information about the company, overview:

Company Name: CHINANSL TECHNOLOGY CO.,LTD.

Address: Chengdu National Information Security Production Industrialization Base , 2nd Floor ,No.8 Chuangye   Road

Telephone: 02866853362

Custom Code: 5101730218773

Company Code: 730

Account-opening Bank: Xisanqi Sub-branch, Beijing Branch, Bank of China

Account Name: Beijing Lingtong Economic Consulting Co., Ltd

Account Number: 813715881608091001

 

 
 

 
 

 
 
 
 

From the information we collected it seems to be a Chinese company related to the security industry. Of course!

We also found a software component called “Parent Carefree Filter”

https://www.virustotal.com/file/3babb326615b899e976a1a9dc51ec04118701a5de702494f1d363194060c5db7/analysis/

publisher…………….: CHINANSL

product………………: Parent Carefree Filter

internal name…………: FamHook

file version………….: 3, 0, 0, 1

original name…………: FamHook.dll

copyright…………….: CHINANSL

description…………..: Parent Carefree Filter

And of course we found similar debug paths on the file:

c:\Documents and Settings\whg\Pnw(all)\Pc()\FamHook\Release\FamHook.pdb

You can find some advisories that Chinansl published back to 2000:

CHINANSL Security Advisory(CSA-200110)

Tomcat 4.0-b2 for winnt/2000 show “.jsp” source Vulnerability

CHINANSL Security Advisory(CSA-200011)

PHP AND APACHE Vulnerability

CHINANSL Security Advisory(CSA-200012)

Ultraseek Server 3.0 Vulnerability

CHINANSL Security Advisory(CSA200013)

IBM WCS local user exceed his authority to access another file

CHINANSL Security Advisory(CSA-200105)

Tomcat 3.0 for win2000 Directory traversal Vulnerability

CHINANSL Security Advisory(CSA-200106)

JavaServer Web Dev Kit(JSWDK)1.0.1 for win2000 Directory traversal Vulnerability

CHINANSL Security Advisory(CSA-200108)

Tomcat 3.2.1 for win2000 Directory traversal

CHINANSL Security Advisory(CSA-200107)

IBM WCS 4.0.1 + Application Server 3.0.2 for Solaris 2.7 show “.jsp” source Vulnerability.

CHINANSL Security Advisory(CSA-200109)

Tomcat 4.0-b1 for winnt/2000 show “.jsp” source Vulnerability.

 

About whg0001 we can find several references on the Internet about him.

https://www.xfocus.net/bbs/index.php?act=ST&f=1&t=54500

http://bbs.krshadow.com/thread-58032-1-1.html

They describe him as “Virus expert. Proficient in assembly.”.

And finally here is the CSDN profile where you can find a photo of him:

 

 

 

 

 

 

 

 

At this point you must be thinking we cannot accuse whg of being related to the XPlug RAT and the targeted campaigns just for a couple of debug paths inside the binary, can we?

Ok, here is the final touch. After searching for more versions of the PlugX RAT we found these two samples:

2ba7f1cc1f46a17ccfbef6b327d8c4e47f9d56922debcad27e5db569f4cf818d

51e50d810172591ee04e12cfce0792f3154356588eacadc01288e3a4fda915fb

They contains this debug path:

i:\work\plug2.0()\shellcode\shellcode\XPlug.h

and the following URL:

http://tieba.baidu.com/f?kz=866965377

that seems to be used as a test or to check connectivity (more info in future posts).

Surprisingly when you open the URL you can see the following:

 

 

 

 

 

 

 

is this guy familiar to you?

With the information we have, we can say that this guy is behind the active development of the PlugX RAT. We can also say he has probably some inside of the operations since this path

“d:\work\plug4.0(nvsmart)\shellcode\shellcode\XPlug.h” tells us that he knew the RAT was going to be weaponized through the Nvsmart technique to be used in the spearphishing campaigns.

According to the information on this research  a previous version of this malware also called Thoper/Tvt/Sogu was used to compromise SK Communications in South Korea back in 2011.

 

 

 

 

 

 

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

Win32/Coswid

June 14th, 2012 | Posted by jaime.blasco in APT | Attacks | Malware | Snort - (2 Comments)

Continuing the research on the last spearphishing campaign we published yesterday,  we found that the same group is using another downloader named Win32/Coswid. The dropper is similar to the one we described in the previous report.

The main difference is that instead of using an html file to hide the configuration, it gets the config values from a PNG file.

Once running, the dropper will send a request to a remote server and will try to download the PNG file.

 

 

 

 

 

 

 

 

 

We noted that the first part of the User-Agent header is the name of the computer running the dropper and the second part is a static string as seen in the code:

 

 

 

 

This is useful to write an IDS signature based on the User-Agent. You can also find an anomaly on the Accept header (*/*,,,,,).

The PNG file is a valid image:

 

 

 

 

 

 

 

 

 

 

But if you open the file you will find something interesting at the end of that file:

 

 

 

 

 

 

 

 

 

The dropper scans the file for content between “<!–” and “–!>” and performs a base64 decode. This version of the dropper supports only two commands:

- s [sleep], example s:20

- d [download], example: d:173.10.48.242 /html/AcroRd32.gif

 

 

 

 

 

 

 

 

 

 

 

 

 

If the dropper finds the download command, it will grab the file specified on the configuration entry. Then it will decrypt and execute it.

There are IDS rules on both Snort Sourcefire and EmergingThreats Pro to cover the HTTP requests:

1:22103 <-> ENABLED <-> BACKDOOR Win32.Coswid.klk runtime detection (backdoor.rules)
2804876 – ETPRO TROJAN Win32/Coswid.A Checkin (trojan.rules)

We have found several configuration files containing the following values:

d:173.10.48.242/html/AcroRd32.gif

d:66.109.23.156 /temp/smss.gif

d:66.109.23.156 /images/update.gif

d:65.105.157.28 /mama/winupdate.gif

d:69.84.35.39 /netaphex/Acrod32.gif

d:69.84.35.39 /netaphex/Acrod.gif

d:69.84.35.39 /netaphex/update.gif

d:69.84.35.39 /netaphex/google.gif

d:yulepx.com /inc/update.gif

 

Most of these payloads are the same trojan discussed in our previous analysis and also known as Trojan.Cookies.

Some of the Coswid files we were able to find are:

726ef24b8eff4c4121c73861756fb9a3

a4ba6540520c375875bf46cf8e19cb7d

09fd067b6d944bf111857f6f60b7471e

b5cf509ec072aa281e5bdb1f7c7a36ea

06cd694d383e4951e274878b975b5785

eab862be60fdfe98ce415d38e41889bf

f791d1ad81601aac3e3d32a683189c06

 

 

 

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