Thursday, July 28, 2011

Current Trojan Ambler Activity

Update with sinkhole results:
About 24 hrs later from registering the one Trojan Ambler .net domain mentioned below and monitoring the sinkhole, I only saw about a dozen infected unique client IPs "correctly" check-in. I did see a few other transactions, but the user-agent and behavior made it obvious that these weren't infections but were from other researchers stopping by (e.g., TrendMicro and Google). Not a huge botnet at all - it was interesting to see that all of the infections were from Australian hosts (,,,, It is interesting that this particular threat seems isolated to one particular region.

Original Post:
During the course of analysis to try to identify some interesting beaconing behaviors, I noticed some “low” and “slow” activity tied to a malware threat that didn’t have a whole lot of information documented in one place. I’ll try to tie it all together in this post. The beaconing activity is “low” in that very little network activity takes place (generally, saw a 108 byte request and only 260 bytes of response data), and “slow” in that the beacons are not very frequent or regular (though this may have to do with the uptime of the victim too). For example, I saw an exact 3-hour beacon followed by another over 15 hours later.

In the activity observed, I saw the requests going to:, resolving to, did not resolve

Note: It appears in most instances of the malware it tries to beacon to a .com / .net domain pair – but in the cases that I’ve seen only the .com is actually registered. I went ahead and registered the above .net domain and will monitor and update this post with any data I find.

URL paths:


Note: the user id appears to be a historical timestamp (DDMMYYYY_HHMMSS) from 2011, possibly related to the time of infection. The above two URL paths are quick and easy ways of identifying infections in your network – I didn’t see these patterns in EmergingThreats.

Doing Google searches for the above two domains does not reveal much of anything. However, there is some open-source information that can be pulled-in to tie this to an identified malware family:

To start with, there is a “Trojan.Win32.Generic” GFI Sandbox report that identifies HTTP beaconing to the domain pair and on the same IP above. Using the MD5 from this report, we can pull a VirusTotal report which shows it to be detected as a Trojan by 19/41 A/V vendors. Doing a bit more digging shows a few additional reports, for example a Malware-Control report from late June 2011 showing that the malware family is frequently classified as “Ambler” or “Amber” Trojan Spy variant – which can steal passwords and log key-strokes. This is an older malware family, and appears to have some ties to Russia. While it is an older malware family, this current variant shows that it is still in use and exhibits some different patterns possibly allowing infections to fly under the radar.

I downloaded a very recent version of malware from one of the involved domains, and it has very poor A/V detection:
MD5: 2936b54a55615ae85f585c3c6dc1f81b
V/T report: 4/43
The binary itself ends the file with a series of “PADDINGPADDINGXX” strings … which a quick Google shows some malware reports from Anubis. It appears to be an IRCbot used to further download other malware, such as the Ambler Trojan.

Combining open-source reports along with some DNS information provides this list of suspected domain infrastructure used to support this campaign:

Note: some of the "older" domains used now appear to be re-purposed, for example: appears to be a possible work from home / mule scam.

Tuesday, July 26, 2011

Malware distribution using fake YouTube pages

Attackers often create fake YouTube pages in an effort to lure a victim into downloading malicious binaries. During our research, we recently found an example of such a site. When a victim visits the page, a security warning will pop up saying “The application’s digital signature cannot be verified. Do you want to run the application?”. Should a victim accept the prompts, they will download and run a malicious binary on their system. Here is a screenshot of the page:

The page is designed to mimic the YouTube service. If however you inspect the source code of this page, you can identify the malicious binary behind this attack. Here is what the source code looks like:

The webpage includes a Java applet that runs a “YouTube.jar” file, which will then download “ser.exe” from the server. If you visit the homepage of above site, you will also see a separate Java applet being combined with VBScript to download and run the same malicious binary with a slightly different name “serv.exe”, which will later saved as “update.exe”. Here is screenshot of that script:

While the malicious files are currently detected by some antivirus products, the malicious website is not blocked by Google Safe Browsing. It is never advisable to download or run any executable from an untrusted source unfortunately, this relatively simple social engineering technique clearly still works.


Monday, July 25, 2011

Zscaler Safe Shopping for Safari

After Firefox, Firefox Mobile, Opera and Google Chrome, Zscaler Safe Shopping is now available for Safari. You can download it from our website. The features are the same as the other platforms - a warning is displayed when the user is visiting a compromised or fake online store.

Zscaler Safe Shopping warning in Safari
Safari extensions follow the same process as Opera and Google Chrome. Safari includes an extension builder that make easy to create the extension, package it and test it. The documentation for developers is quite good.

However, the submission process is completely obscure. I submitted the plugin over four weeks ago and I have no idea what Apple did with it. I don't have any reference number or any way to track it. This may explain why this is the only browser with a 3rd party website dedicated to browser extensions at I plan to submit Zscaler Safe Shopping to this site shortly.

Install Zscaler Safe Shopping for Safari

Zscaler Safe Shopping for Safari installed

Here is a video showing the extension in action:

-- Julien

Thursday, July 21, 2011

Manually De-obfuscating malicious content

Most of the time, malicious obfuscated JavaScript is injected at the bottom of a webpage. Obfuscation is leveraged both to hide the true purpose of the code from prying human eyes and in an attempt to bypass security scans. As a researcher, you may have to conduct a manual analysis of such JavaScript, if certain automated tools like Malzilla fail to decode the obfuscated content. Let’s take a look at an example of one infected Indian university website. Here is the home page of the infected website:

The malicious obfuscated JavaScript is injected right after the closing HTML tag. Here is the screenshot of injected malicious code:

The above malicious JavaScript is heavily obfuscated and it’s hard to determine what it is trying to do, just from a manual inspection. Most of the time, the obfuscated code contains links to malicious websites hosting malware. Let’s complete a manual analysis of this malicious content to identify any links to malicious sites. To conduct a manual analysis, you need to understand JavaScript and basic HTML. Let’s format this code for better reading. You can find the formatted code here.

As you can see, the code still appears heavily obfuscated with numerous variables defined. You will also notice some JavaScript functions like “.substr”, “document.body.appendChild” which are commonly found in malicious code. Many of the variables defined receive a return value from function “D()” such as:

D() is clearly an interesting function, so we’ll begin there. We can see that function “D()” takes two parameters and returns a value. Let’s quickly find the “D()” function and look into the code. Here is what function “D()” looks like:

So function “D()” will do some string operations on the passed in parameters. We can now copy and paste this function and copy the variables, which use this function into a new HTML file called “test.html”. The goal is to identify return values from this function. For this function to work, we also need two variables, “Y” and “v”, which are used inside this function. These variables are available from the main script. Copy and paste those variables into the D() function. Now, we will call another JavaScript function called “alert()” to display the return value. Open the new “test.html” file we created in Internet explorer. The JavaScript function “alert()” will pop up the message box displaying the return value, as shown below:

Insert all of the variables, which use this function and read out all the strings returned by this function. Here is what our new “test.html” file looks like:

I have already added the strings returned by this function in the code comments. The above malicious code points to the malicious website “hxxp://”.


Monday, July 18, 2011

Brazilian bank targeted by phishing site and DNS poisoning

Update 7/26: See post on our Scrapbook blog about details surrounding a recently poisoned BR nameserver involved in this fraud. -- Mike

Santander, a well-known banking site, has often been the target of phishers. In fact, Santander UK often makes the top-10 list of most popular targets according to Phishtank. Last week, we found a phishing site for the Brazilian branch,, that was receiving traffic from a DNS cache poisoning attack.

The phishing site hosted on looks identical to the original site. The attackers have replicated the entire login process in order to gather the login, password, and security code of the bank users.

Santander Brazil phishing site

Original Santander Brazil home page

The DNS poisoning made this attack much more effective. The hijacked DNS servers were resolving to (phishing site) instead of or (legitimate sites). In such a situation, phsishers do not need to blast e-mails to random Brazilian e-mail accounts. They just need to wait for the Santander customers to login into their bank account, when accessing the site via the poisoned DNS servers.

DNS poisoning also renders virtually all browser phishing defenses useless. Google Safe Browsing (Firefox, Safari, Chrome, etc.) and Phishtank (Opera, etc.) both rely on a blacklist, which is a list of URLs or domains to block. It can be very hard for the user to realize that this is a phishing site because it looks exactly like the real site, and the URL shows the correct domain.

In this attack, there were only 2 oddities that an advanced users could spot. First, the phishing site did not support HTTPS traffic. Advanced users should know that credentials should be sent over secure HTTPS sessions only and banking sites always redirect to HTTPS enabled pages when the user must log in. The second clue is in the source of the page: the last line, an HTML comment, shows that the page was copied from the original site:

Last few liens of the HTML code of the phishing site

A week later, the phishing site is still up. it is not blocked by Phishtank or Google Safe Browsing. However, the hijacked DNS servers have been cleaned up, making this site a lot less dangerous.

-- Julien

Thursday, July 14, 2011

Obfuscated Exploits continue to target CVE-2010-0806 and CVE-2010-3962

A pair of “use-after-free” aka “uninitialized memory corruption” vulnerabilities (CVE-2010-0806 and CVE-2010-3962) in Internet Explorer were reported in November 2010 and remain among the favored client-side attack vectors currently seen in the wild. Recently during my research, I have noticed a gradual increase in attacks targeting these vulnerabilities. Often these two vulnerabilities are combined into a single exploit, as both the vulnerabilities target Internet Explorer 6 and 7. Combining exploit code will of course increase the probability of a successful attack.

Lets analyze one sample that I came across recently.

Source code



De-obfuscated Code Analysis

De-obfuscation of the above code, shows how the exploitation of the two vulnerabilities is carried out. Lets go through each one of them sequentially.

Both exploits work in following way

  • Initiate a heap spray

  • Exploit causes a use-after-free error

  • Assembly code running at the time of the “use-after-free error” causes the CPU to execute shellcode thanks to the heap spray.

Version check – This is required to initialize the address of the shellcode. The full address is computed when heap spray is carried out.

Shellcode - Common for both the vulnerabilities.

The heap spray is carried out by different functions for the different vulnerabilities.

Exploiting CVE-2010-0806

Exploiting CVE-2010-3962

Other samples that target these vulnerabilities, which I observed during my research varies in terms of the way the Javascript code is obfuscated. However, the overall process remains the same. This again tells us why it’s important to update your browser with latest security patches.

Further research on the domain “” reveals that the IP address bound to this domain has hosted various other malicous domains carrying out alternate attacks.

Hosting multiple malicious domains on one IP address is common practice for attackers.