Sunday, October 30, 2011

Siam Commercial Bank Phish in the Wild

Targeted Phishing attacks for banking and financial domains are a popular way for attackers to steal sensitive data from customers. To counter these attacks, banks and other financial institutions are driving various campaigns to educate their customers. Recently, I found a live phishing page for the “Siam Commercial Bank” of Thailand.

Naturally, a key ingredient in any phishing attack involves creating a nearly identical site that will convince the user that they’re at a legitimate site. Let’s take look at the phishing page for SCB:

You can observe areas marked in the picture above, which differentiate it from the legitimate SCB website. When a victim enters a username and password, the phishing webpage sends these credentials to a webserver controlled by the attacker.

Let’s enter fake credentials and see how these are sent to the cyber-criminals.

Legitimate sites use SSL encryption to secure sensitive information entered by the users, while this phishing site sends the data in clear text, presumably because the attackers were too cheap to pay for a signed SSL certificate.

Lets take a look at the legitimate webpage of SCB and observe the same marked areas:

We have observed numerous similar phishing pages. Recently, Umesh blogged about a phishing scam targeting Gmail users. It’s always a good idea to directly surf to a page before entering sensitive information, rather than clicking on a link that may take you to a fake site. I hope our blogs helps you to identify common red flags that reveal phishing pages.

Beware SCB Customers!


Thursday, October 27, 2011

Now “” free domains are being used to host malicious code

A few months back, I posted a blog on “” domains being used by attackers to host malicious code . We had identified number of different domains being used to carry out attacks using heavily obfuscated JavaScript. Now it appears that attackers are leveraging free “” domains. Likewise, we have identified a number of domains exploiting various known client side vulnerabilities. Here are a few of the URL’s being used:


The aforementioned domains suggest that random domain names are being registered to host these attacks. Once visited, the victim will be presented with obfuscated JavaScript code, formatted in such way to evade IDS, IPS and antivirus solutions. The numbers in the arrays used by the scripts are intentionally spread across separate lines. This way the size of HTML file becomes huge and the total code spans 29K lines. Here is the snapshot of the first part of the malicious code:
Look at the array variable. As can be seen, the numbers used in the array are spread over separate lines. Here is the last part of the script:

Once the above code is decoded, it turns out be related to the Blackhole exploit kit which exploits a variety of known client side vulnerabilities. Here is a small screenshot of the decoded script:
Attackers keep registering different random domains to spread their attacks, often targeting free registration services. Due to obfuscation used by the attackers, security solutions relying on regular expressions designed to match known patterns can often be evaded due to the code being spread of over numerous lines.

Stay safe!!!

Wednesday, October 26, 2011

IPAbuseCheck Stats

Last week, we announced our IPAbuseCheck lookup tool. We see lots of infected/abusive hosts on the Internet attempting to proxy abusive web transactions through our proxies. Rather than just ignoring these transactions, we’ve decided to provide this lookup utility for security professionals and organizations to query and identify abusive/infected hosts within their networks – based on some feedback, the service has been well received. This follow-up post provides a brief summary of the top offenders that we see in our database to date (July 1 – October 25, 2011).

Top Abuse Breakdown by Geography
The top 15 countries account for over 75% of the abusive clients that we have seen- with the US, China, Russia, Germany, Venezuela, and India accounting for half of the abusive clients that we have seen to date.

Top Abuse Breakdown by Organization (ASN)

ASN by Abusive ClientsASN by Abusive Transactions
ASN% of Clients
AS4812 China Telecom6.32%
AS4134 Chinanet5.16%
AS8048 Servicios, Venezuela3.82%
AS4837 CNCGROUP 2.54%
AS15857 Telefonia Dialog S.A.2.53%
ASN% of Transactions
AS14618, Inc.25.16%
AS8069 Microsoft Corp10.23%
AS8075 Microsoft Corp9.92%
AS4134 Chinanet5.02%
AS28753 Leaseweb Germany4.28%

It was interesting to see some well known organizations like Amazon and Microsoft near the top for organizations that have sent us the most abusive transactions. Rather than these being infected corporate systems, it appears to be a handful of hosting service systems that are being abused either directly from the customer or from an infection. Here is a snapshot of a report from our database of a Microsoft IP that we reported to their Abuse Dept. once we started digging into this data:
OriginAS: AS8075

Screenshot of Abuse Report

The transactions observed were hundreds of thousands of brute-force attempts against file sharing sites like Megaupload, Hotfile, Filesonic, and Rapidshare.

Top Abuse Breakdown by Client
Clients in our database that have the longest time range of abuse seen tend to be those clients that are scanning the Internet looking for open web proxies. These were the top 5 clients that we have seen with the longest date range from:

Top 5 Abusive Hosts by Date Range
HostFirst SeenLast SeenBehavior 07:0010/25/11 06:54Proxy Scanning 07:0010/25/11 06:51Proxy Scanning 07:0610/25/11 06:57Proxy Scanning 07:0710/25/11 06:56Proxy Scanning 07:0810/25/11 06:54Proxy Scanning

The following table lists the top 5 abusive hosts by transaction count - these tend to be hosts that attempt to forward bulk transactions through proxies, like forum spam and brute-force attempts. Related to the previous section of organizations with the top abusive transactions - you can see that two Amazon EC2 systems (, 248) are at the top of the list.

Top 5 Abusive Hosts by Transactions
HostTransaction %Behavior Spam Spam Spam

Top Web Services Targeted in Abuse
The following lists the top 5 most targeted web sites/services abused by number of transactions and number of unique abusing clients.

Top 5 Abused Web Services by:
Abusive Transactions:
Abusive Clients:
The bulk of the top sites by transaction are forum spam sites - in the top instances, the forums being abused are in Vietnam. One brute-forcing target is in the top 5, which is the Rapidshare file host. The bulk of the top services being used/abused by number of clients are proxy checkers - the Chinese service was also listed in the top as a spam bot / brute-forcing target.

The above post provides some insight into the types of information that can be extracted from this service, and we'll continue to update the database regularly with the latest abusing clients.

Naked Emma Watson video used to spread malware

Fake videos with funny or sexual content, have long been used to entice users to download and install malware. The technique is used by hackers to convince users that they need to install additional codecs, or software, in order to play the video.

I've found several websites redirecting to "Emma Watson never seen before home video" hosted on various domains:,, etc. The page looks very similar to a YouTube page, with related videos on the left, and fake comments below the player.

Emma Watson never seen before home video

A click on the Play button, or any link on the page, shows a warning that the Flash player is out of date and a new version needs to be installed in order to play the video.

Warning about outdated Flash version
The warning is very well designed. It feels like a desktop software with an animated download function, despite being part of the web page. The user is enticed into downloading and installing a file called scandsk.exe.

Malicious executable
Once again, the malicious executable has a very low detection rate amongst AV vendors: only 7 out of 42 detect the threat.

Virustotal report

Be aware of any update done outside of official vendor websites.

-- Julien

Wednesday, October 19, 2011

IPAbuseCheck: Clients Abusing Web Proxies

IPAbuseCheck was designed to provide a simple, free web interface to query your IP addresses against a database that we have built containing unauthenticated IP addresses that have attempted to forward abusive or unwanted traffic through one or more of our proxies. The database contains abusive IPs identified from July to present, and contains well over 20K unique IP addresses. Here is a screenshot showing an example report of an IP listed in our DB:

In this case, a client IP at a very large software company is infected and attempted to issue tens of thousands of login POST requests through our proxies to Megaupload servers (and others such as Rapidshare, Hotfiles, and Yahoo webmail) using the "Googlebot" user-agent. Note: URL parameter values have been stripped from the URLs in our database. This particular client IP is not listed in any IP blacklists (checked using Very often IP blacklists list client IP addresses visible from the server perspective - in this case, it would have been our proxy IP if we let these transactions through. Our database provides a bit of a different perspective from many of these existing blacklists, in that we are listing abusive clients that are using proxies.

The goal of this free service is to provide those interested (ISPs, companies/organizations, security professionals, etc.) with this data to identify and clean-up clients that are participating in this form of abuse. Clients leverage proxies to distribute and/or mask their origin when conducting forms of abuse, such as:
  • Brute-force web-based logins
  • Search Engine Optimization (SEO)
  • Forum spamming
  • Pay-per action cheating
  • Open proxy scanning
  • Bulk account registration
  • Site popularity / voting inflation
  • other forms of abuse (DDoS and web-site scraping)
Client IPs listed include both those that are intentionally used for abuse and those that are from infected hosts that are unknowingly abusing proxies on the Internet. Zscaler's service provides policy and security enforcement through its proxies from its customers - valid customers must first authenticate to the Zscaler service before being able to use our proxies. Transactions listed in this database are from unauthenticated clients attempting to utilize our proxies in an open manner to distribute and mask traffic for their abuse.

The idea for this service stemmed from two Zscaler blog posts:
We attempted to remove anything that we deemed to be a false-positive of abuse, but since this listing based on a few things like regular expressions and behavioral patterns it is still possible that the database contains false-positives. Use this information at your own discretion.

Fake free AVG download sites

Fake antivirus sites are a very common way to trick people into installing malware on their computers. Another technique is to repackage popular software with adware or malware, and offer them for download.

AVG is a popular Antivirus vendor that offers a free version of it's product at Rather than getting money by bundling this free spammer with pay-per-install adware, scammers have created websites to sell (free) AVG!


hxxp:// (Official)

The three fake sites redirect the users to a payment form. The first page gathers names and e-mail addresses. Even if the user decides not to pay, the scammer can still spam the user, or resell their e-mail address. This is no small profit!


Then, the user is required to pay for the software. The payment is actually not for AVG itself, but for a monthly maintenance fee:

Monthly "maintenance" fee

The real Free AVG antivirus product is completely free of course, including access to the antivirus definition file updates.

A search for "free avg" shows a lot of other spam sites, most of which are fortunately harmless.

As always, users should make sure they download their software from the official site. AVG flagged these three sites, but Google Safe Browsing and Internet Explorer did not. Of course, people looking for Free AVG clearly don't have AVG installed yet.

-- Julien

Tuesday, October 18, 2011

Beware of fake websites stealing credit card information

People often uses credit cards online to purchase products but many people fail to validate the site address and proceed with submitting sensitive information such as card numbers. Attackers can then steal credit card information along with the associated CVV number. Here is an example of one such fake website, hosting supposedly ‘free’ services - hxxp://

Once a victim visits this website, he will be presented with popup box portraying the site as AOL’s billing center:
The message indicates that the user needs to update credit card and billing information, or their account will be ‘voided and cancelled’. When victim clicks on the OK button, he will be taken to another webpage where he is asked to enter his credit card details.
Once the victim enters their sensitive and personal information, the webpage smartly displays another popup stating “AOLBilling will now validate your credit card”. This is again done to convince user that the site is a legitimate AOL billing website. Nothing is actually validated against AOL and credit card information is sent to attacker. The webpage collects and sends a POST request with all user details. Here is packet capture of the request sent:

For the purpose of this blog, we have entered fake information. If you look at the above POST request, you will also notice a recipient email address of “”. This means all sensitive information is sent to this email address. The victim is then redirected to the error page.

Users should never enter credit card details without being 100% confident that the form is hosted at the correct domain and traffic is sent via HTTPS.


Wednesday, October 12, 2011

"1.php" Group Intrusion Set Paper

Update: report links now go straight to the paper versus the general Whitepaper page.

ThreatLabZ has just released a report that provides a summary of incident information related to the "1.php" Group. Historically, this Group used command and control servers (C&Cs) with "/1.php?" for the checkin URL path - which is the reason for the informal name used. They have repeatedly targeted one of our customers - so I worked to compile some research on this group. There is evidence to show that the group has been operating at least since 2008 and that they tend to target China/US relations experts, Defense entities, and Geospatial entities using spear phishing with a malicious PDF attachment or a link to a ZIP that decompresses a malicious SCR. The payload is often a PoisonIvy remote access tool/trojan (RAT) or something similar. They have varied their C&C checkin behavior, but it is usually over the web - sometimes it is HTTPS, sometimes it is HTTP with different checkin parameters/paths. The Group either registers their own domains or uses No-IP dynamic DNS domains for their C&Cs.

For further details on the "1.php" Group research, please register and view the report HERE.

One challenge with doing this research is who/how to share the information. Responsible disclosure is pretty well defined at this point for vulnerability information, but it is not in terms of incident response information (particularly when the "APT" term is used).

This report provides high-level indicators of compromise (such as general network behavior and malicious domains) without the release of specifics, such as victim information. The purpose is to establish a community of awareness so that organizations can better detect and protect against these and similar threats. Additional specifics of the attacks were limited to stakeholders (victims and those chartered with protecting them).

If you have additional details on this Group or would like to exchange information with Zscaler - please contact us at our threatlabz email address.

Thursday, October 6, 2011

Building Zscaler Likejacking Prevention for different browsers

Facebook Likejacking Prevention is the second plug-in that I've released for multiple browsers (Google Chrome, Safari and Firefox). It is technically much more complex than the previous one, Zscaler Safe Shopping.

Each browser offered different challenges. As promised in the previous blog post, I will provide details of what was required to port the plugin to different platforms.

Facebook Likejacking Prevention 1.0.8

Before I start on the technical details, I'd like to remind all users to upgrade to the latest version of the add-on (currently 1.0.8). In Firefox and Chrome, go to Add-ons or Extensions, and check for updates. For Safari users, please install the latest version from our website. I have fixed a couple of bugs, and made several improvements in the detection of suspicious pages.

This is a fairly long and technical post. Don't hesitate to post a comment if some points are not clear.

The Architecture

There are two main components in the plugin. The first feature involves finding  the Facebook widgets inside a page. These widgets are iframes hosted on Then the plugin needs to inspect the containers, the HTML elements that contain the IFRAME, to figure out if the widget is hidden or not. The protection (widget removal or explicit confirmation) needs to be applied on each widget, as chosen by the user.

The second element involves displaying relevant information to the user: a quick view indicating whether the page is suspicious or not and a more detailed view for additional information.

Google Chrome

Extensions on Google Chrome are comprised of two parts:
  • A background page which has access to the browser: local storage, extension options, tab events, etc., but it does not have access to the content of the tabs, i.e the HTML content
  • A content script injected in each page/frame/iframe, which has access to the HTML content (read and write), but does not have access to the browser or other tabs. The content script injected in one frame does not have access to other frames or iframes, even within the same tab.
The background page and the content scripts can communicate with each other by sending messages.

In Zscaler Likejacking Prevention, the content scripts are charged with finding the Facebook widgets, inspecting the containers, and sending the information back to the background page. The background page aggregates  the information for each tab, and decides which action to take on the tab content depending upon the options and whether or not suspicious elements where found.

This architecture works well for the add-on, except in these two scenarios:

Layers of Frames/Iframes

Facebook widgets can be loaded inside an iframe or a frame, which can itself be loaded inside an iframe, etc. In order to inspect the container, the content script would have to cross the boundaries of the frame/iframe it was injected in. But this is not allowed by the browser. So doing the DOM inspection for the container from bottom (the Facebook widget) to top (the main document) by each injected script is not possible.

Instead, container inspection has to be done with a mix of bottom up and top down. The content script in the main document does have read access to all the frames/iframes which it resides in. After all Facebook iframes are found, the container inspection is done from the widget to its containing iframe (bottom up).

The parent container is found with the parentNode property of a DOM element in Javascript. Unfortunately, the parentNode of an iframe is shown as null.  In order to find the container of an iframe, it has to be found from the top document down to the iframe based on it's SRC attribute. Finally, a new score is computed by the main document and sent back to the background page. If an action needs to be taken, the background page sends a message to all injected scripts inside the tabs.

Late loading

The page is inspected as soon as it is loaded, in order to apply the protection quickly. However, Facebook widgets can be inserted at any time, including after a page has finished loading. So the page score must be recalculated every time a new iframe is loaded.

To solve the problem, when the background page gets a message from an injected script inside a Facebook iframe, it checks if any Facebook widgets were already found in this tab. If not, the background page asks for a new evaluation of the page.

Icon and Popup

Chrome has the best architecture for showing information for a specific page. It was very easy to show an icon associated with a popup for a given tab. No problem there.


Safari (Opera and Firefox Mobile as well)  has the same plug-in architecture as Google Chrome, with the separation between the background page (referred as global page by Safari) and content script. Therefore, it did offer the same challenges as Chrome.

However, some technical limitations in Safari did bring a few more issues...

One way communication

While each injected script can send a message to the global page, the global page can only send a message to the main page, not to each frame/iframe. To be more specific, the global page can reply back to a message from a frame/iframe, but cannot initiate the message to them. That means once it has aggregated the information from all content scripts, it can push a message to apply the protection to the main page only. To get around this limitation, each frame/iframe has to send a message to the global page regularly to check if there is any action to be taken.

Storing the aggregate information

In Chrome, each tab has a unique ID. The aggregate information is associated with the tab ID. There is no such ID in Safari. Instead, the information can be saved as a property of the tab. Unfortunately, if the tab is moved to a new window by the user, the associated property is reset, and the information is lost. I have to save the information as a tab property (the most accurate way), but also based on the URL in case the tab is moved. If there are different tabs with the same URL, but different content, the data can be mixed up.

Limited UI

I had to find a creative way to get around the UI limitations of Safari. First of all, it is not possible to have an icon in the URL bar as I do in Chrome and Firefox. Then, toolbar buttons are black and white only, and can have only 2 states. I need 3 states for the button: no Facebook widgets on the page, safe page with Facebook widgets and suspicious page.

Instead of an icon or button, I had to use a toolbar. I also had to take care when it came to hiding and showing the toolbar when the user switched tabs, loaded a new URL, etc.

I actually had to use two toolbars, because each is limited to a fixed height of 30 pixels. One toolbar is not enough for all the information and links I want to show. The detailed information and actions have to be shown on a second toolbar!


Firefox has a centralized plugin architecture: the browser and all the tabs, including their content with read and write permissions are available from the same JavaScript file. That made it much easier to inspect DOM elements with several layers of frames/iframes.

However, it was harder to detect new frames/iframes being loaded or added by just listening to page load events. The solution I use is to listen to HTTP requests for HTML documents and re-inspect the tab every time a new element was sent.


The UI was a bit more tricky than in Google Chrome. There are icons associated with a popup called Page action. Unfortunately, the popup content is limited to a piece of text and one button. This does not work with the information and actions I needed to offer.

Instead, I had to create my own "Page Action" by adding and removing an icon in the URL bar as needed and showing a toolbar at the top of the tab when the user clicks on the icon for more information. Overall, it required a bit more work than Google Chrome, but was much easier than for Safari


It was interesting to see the impact of the different browser architectures and limitations on my plugin. Safari was by far the hardest platform to work with. DOM inspection and manipulation was the easiest in Firefox, while displaying information in the UI was best done in Google Chrome.

It is a bit disappointing that it was not possible to have the plugin look the same in the different browsers. Google has the layout I really wanted and I found the UI restrictions in Safari very problematic.

-- Julien