Trend Micro Facebook TrendLabs Twitter Malware Blog RSS Feed You Tube - Trend Micro
Search our blog:

  • Recent Posts

  • Calendar

    November 2014
    S M T W T F S
    « Oct    
  • About Us

    The newly discovered Wirelurker malware affecting both OS X and iOS devices has been covered extensively in the media. While this is a significant incident, some of the coverage appears to have been exaggerated, and might lead users to unnecessary panic. Several points would be useful in helping calm down the worst fears of users and distilling what we need to learn from all this.

    First of all, Wirelurker is currently not an active threat. Known variants have already been blocked by OS X, and the command-and-control servers are offline as well. This significantly reduces the threat that this malware poses to users. The stolen certificate that enabled this attack has also been revoked by Apple, mitigating the most novel aspect of this threat (pushing apps onto non-jailbroken devices).

    Secondly, no new vulnerability was used to spread Wirelurker. It arrived on OS X machines via Trojanized (and pirated) apps; pirated apps have been a favored vector to spread malware for many years. We detect these malicious apps as OSX_WIRELURK.A.

    Similarly, the features used to transfer the malware onto iOS devices used features that are part of Apple’s mobile platform. For example, enterprise provisioning is used in enterprise environments to install custom apps onto the organization’s iOS devices. The problem here was that an organization (apparently a Chinese mobile app developer) lost control of their signing certificate, which allowed malicious apps to be signed and therefore, trusted.

    Thirdly, Wirelurker did succeed in installing apps on non-jailbroken devices. However, we haven’t discovered any malicious behavior on the part of these apps. The apps that contain malicious backdoor could only be installed onto jailbroken devices. In addition, iOS shows a pop up and asks for the user’s permission before installing an app via enterprise provisioning app. In non-jailbroken devices, these also run within their own sandbox, so they need permission to access contacts, location information, and other sensitive information.

    We cannot rule out that this was just a test of attacks via enterprise provisioning, and that the attacker may add malicious code in the future. However, such code is not yet present in the apps delivered to non-jailbroken devices. (We detect the malicious apps installed onto jailbroken devices as IOS_WIRELURKER.A.

    Wirelurker does not push malware onto affected, non-jailbrokem devices, only unwanted apps.  It becomes a question of controlling unwanted (but not malicious) apps – essentially an annoyance, but not a significant risk. However, jailbroken phones will be infected by malicious apps.

    Fourth, enterprise provisioning is a known attack vector against mobile devices, and has been for some time. For example, earlier this year at VB there was a demonstration of how a stealth backdoor could be installed onto an iOS device using enterprise provisioning. If Apple is not able to properly lock this aspect of iOS device management down, this could pose a problem in the long run.

    What Wirelurker demonstrates is that Macs and iOS devices can become victims of online threats just as Windows and Android devices are if users engage in unsecure behavior. Software piracy has been risky practically from day 1.Pirated apps aimed at users with jailbroken devices may also become a popular infection vector. The same can be said for iOS apps as well. No computing platform is “secure” if its users behave insecurely.

    We also note that while these attacks initially hit OS X users, we have also seen Windows-based malware that perform similar attacks. We detect these as TROJ_WIRELURK.A.

    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  

    As previously discussed Operation Huyao is a well-designed phishing scheme that relys on relay/proxy sites that pull content directly from their target sites to make their phishing sites appear to be more realistic and believable.

    Only one such attack, targeting a well-known Japanese site, has been documented. No other sites have been targeted by this attack.Publicly available information suggests that the persons who registered the domains used in this attack are located in China.

    Because Huyao has a very specific URL pattern, it is easy to identify web servers that were seving as Huyao proxies. Most of these were located in the United States, with smaller numbers located in Hong Kong and France.

    Table 1. Countries with Huyao-related servers

    Approximately 316 domains have been used by Huyao. These domains appear to have been created by the attackers, and there is no indication that any compromised sites were used. The Whois records for these sites indicate that the email addresses on file for the administrators of these domains belong to free mail providers: Hotmail, QQ, and Gmail were the most popular providers used by the attackers.

    Table 2. Email providers used in Huyao-related domain registration

    Lin Xiansheng ( and Lirong Shi ( were the two individuals most identified as owners of these domains

    According to Whois information, Lin is a resident of Xiamen, located in the southeastern province of Fujian in China. He appears to have registered a total of 196 domains, with four of these registrations already lapsed or otherwise no longer valid. (Below is some of the Whois information characteristic of the domains that were registered under this name, based on the Whois information of

    Registry Registrant ID:
    Registrant Name: xiansheng lin
    Registrant Organization: lin xiansheng
    Registrant Street: xiamenshisimingqu
    Registrant City: xiamen
    Registrant State/Province: Fujian
    Registrant Postal Code: 361000
    Registrant Country: cn
    Registrant Phone: +86.59112345678
    Registrant Phone Ext:
    Registrant Fax: +86.59112345678
    Registrant Fax Ext:
    Registrant Email:
    Registry Admin ID:
    Admin Name: xiansheng lin
    Admin Organization:
    Admin Street: xiamenshisimingqu
    Admin City: xiamen
    Admin State/Province: Fujian
    Admin Postal Code: 361000
    Admin Country: cn
    Admin Phone: +86.59112345678
    Admin Phone Ext:
    Admin Fax: +86.59112345678
    Admin Fax Ext:
    Admin Email:

    Figure 1. Whois search for

    Whois records of another domain (now seized due to abuse) also connect Lin to a second email address, Lin used a slightly different physical address for the domains linked to the address, but its location was still in Xiamen,

    Lirong Shi registered even more domains: 417 in total, with six of those no longer active. Whos records place him in the city of Jinjiang, also in Fujian province.

    Registry Registrant ID: DI_38689624
    Registrant Name: shilirong
    Registrant Organization: shilirong
    Registrant Street: jinjiangshi
    Registrant City: jinjiang
    Registrant State/Province: fujian
    Registrant Postal Code: 362200
    Registrant Country: CN
    Registrant Phone: +86.3202222
    Registrant Phone Ext:
    Registrant Fax:
    Registrant Fax Ext:
    Registrant Email:
    Registry Admin ID: DI_38689624
    Admin Name: shilirong
    Admin Organization: shilirong
    Admin Street: jinjiangshi
    Admin City: jinjiang
    Admin State/Province: fujian
    Admin Postal Code: 362200
    Admin Country: CN
    Admin Phone: +86.3202222
    Admin Phone Ext:
    Admin Fax:
    Admin Fax Ext:
    Admin Email:

    Other information confirms that Lirong Shi is located in China. Postings in online forums indicated that several years ago, he was allegedly buying devices from Japan and selling them in China:

    Figure 2. Previous advertisement by

    The Whois information strongly indicates that the individuals who registered the domains used in Operation Huyao are located in China. The fact that the domains linked to Operation Huyao were registered during working hours in China – with peaks at 9AM and 1PM – seems to support this conclusion. However, this alone cannot be regarded as conclusive proof.

    Figure 3. Time of domain registration


    For website owners, protection from such attacks boils down to one goal: rejecting the access of the unexpected. These countermeasures come down to blacklisting and monitoring the “URL: document.location” or “HTTP referrer: document.referrer.”

    In this scenario, blacklisting would mean blacklisting the site where the relay program was installed in. Blacklisting can be combined with a .htaccess access control file if Apache was involved.

    Using a URL or HTTP referrer can also be instrumental in attacks such as Huyao. The URL or HTTP referrer can be used to compare the values obtained through JavaScript of the legitimate site and the site that copied the content. The owners of the legitimate sites can check where the request for data/content is coming from. A discrepancy between the two values signals suspicious activity that can then be properly flagged.

    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  

    We see many kinds of vulnerabilities on a regular basis. These range from user-after-free (UAF) vulnerabilities, to type confusion, to buffer overflows, to cross-site scripting (XSS) attacks. It’s rather interesting to understand the root cause of each of these vulnerability types, so we looked at the root cause of an Internet Explorer vulnerability – CVE-2014-1772.

    We’d privately disclosed this vulnerability to Microsoft earlier in the year, and it had been fixed as part of the June Patch Tuesday update, as part of MS14-035. While this vulnerability was already patched some time ago, it is still a good example of UAF vulnerabilities in general.

    The code to trigger this vulnerability is below:

    Figure 1. HTML code to trigger vulnerability

    Before debugging, several flags must be set to make the job of analysis easier. Run the command gflags.exe /i iexplore.exe +hpa +ust to to enable the page heap (HPA) and user stack trace (UST) flags. This will make finding memory corruption and tracing heap allocation and frees easier. This file can be found in the Windbg installation folder. You can now run windbg, attach Internet Explorer, and use it to access the HTML file.

    Examining the JavaScript execution flow, when line 18 of the HTML code is executed, the crash happens:

    Figure 2. Output of crash

    We can see the EDI register point to a freed memory space, which leads to an access violation.

    What is the value of the EDI register? Let us look at the code below.

    Figure 3. Assembly code

    The above code tells us that the EDI is from the first argument, which is the CTreePos* type. We can assume the EDI is a pointer of CTreePos. Since the CTreePos object is freed, how can we get where the object is freed? Because the UST flag is set, we can use the !heap -p -a edi command in windbg.

    Figure 4. Call stack

    The above figure shows us the call stack of the CTreePos object freed. The call stack has a lot of information. We see the function CMarkup::FreeTreePos; this evidence gives us evidence that the freed object is CTreePos object and that this is a use-after-free issue.

    Since it is a UAF issue, we want to deeply understand the issue. We need to locate where the CTreePos object is created, where the object is freed, and where the freed object is used again. Figure 4 gives us where the object was freed. To find where is used again, we need to examine the crash point. The call stack is as follows:

    Figure 5. Call stack

    How do we find the location where the CTreePos object was created? There are many ways. I prefer to run the sample again, and break the object freed point and use the !heap -p -a xxxx command to trace back to where the object is created. The call stack is as follows:

    Figure 6. Call stack

    For UAF problems, I prefer to compare the 3 locations (create, free, use again) to find some clues.

    Figure 7. Call stacks

    There are 3 columns in Figure 7. They are call stack trace summaries: from left to right, it is when the object is created, freed, and used again. In the above example, the direction of the stack is from the bottom to the top.

    There is plenty of useful information here. First, we can find the relationship between the 3 parts. Under the yellow line, CDoc::CutCopyMove is the last identical function in the creation call stack trace and the free call stack trace. This means the execution flow creates the CTreePos object and then frees the object in CDoc::CutCopyMove. Under the red line, the execution flow frees the object and then uses it again (and crashes) in CSpliceTreeEngine::InsertSplice.

    In the second column, we find the execution flow in the CSpliceTreeEngine::InsertSplice function encounters a failure and call the Fire_onerror function. The function will call the JavaScript object’s onerror event. At the event, the execution will call CMarkupPointer::UnEmbed to free the object.

    Right away, we have four questions.

    1. Why does it trigger an onerror event?
    2. Why does it create the CTreePos object?
    3. Why does it free the CTreePos object?
    4. Why does it use the freed object again?

    Before answering these questions, I want to summarize some background knowledge about how Internet Explorer’s DOM tree implementation. Because IE is not open source, this information is gathered by reverse engineering, so it may not be 100% accurate.

    One page has a CMarkup object to represent the page’s skeleton or DOM tree. The CMarkup object contain a pointer to the root CElement object. This is the parent class of many concrete element classes. In Figure 1, the Javascript object e_1 and e_2 are the CObjectElement objects which are inherited from CElement. The CElement object has a pointer to a CTreeNode object. The CTreeNode object also has a pointer to a related CElement object. The CTreeNode’s object has a pair of pointer to CTreePos objects.

    Why is a CTreePos object needed? This is because IE uses a Splay Tree algorithm to manuiplate the DOM tree. In the Splay Tree, the CTreePos object is the node that is involved in the algorithm. The CMarkupPointer object represents a location in the CMarkup object (DOM tree). So the CMarkupPointer object has a pointer to CTreePos to represent its location. CMarkupPointer has several statuses which are related to UAF issues.

    • Embed status: this means CMarkupPointer created CTreePos, which is added to the Splay Tree.
    • Unembed status: this means CMarkupPointer removes the CTreePos from the Splay Tree and frees it.

    The following graph describes the interactions involving the splay tree.

    Figure 8. Splay tree graph

    Going back to our four questions, we can now attempt to answer them.

    Why does it trigger an onerror event?

    From Figure 1’s Javascript code, we can see e_2.onerror sets a handler function. At line 22, e_2.swapNode will trigger DOM tree’s changing; this calls the CObjectElement::CreateObject function. This function checks the object’s CLSID. Because e_2’s CLSID is not set, it triggers the onerror event handler.

    In the handler, at line 22, the Javascipt code r.insertNode(e_2) will change the DOM tree once again and change CObjectElement::CreateObject as well; because e_2 has no CLSID , it will again trigger the onerror event handler once again. The second time the this handler runs, at r.setEnd(document.all[1],0)” , it frees the CTreePos object.

    Why does it create the CTreePos object?

    From Figure 6, the CTreePos object is created in calling the CDomRange::InsertNode function. We can map this function to Figure 1’s line 19: r.insertNode(e_2). The CDomRange::InserNode function will insert elements into the DOM tree. The function is called Doc::CutCopyMove to modify the DOM tree and takes several arguments. The first CMarkupPointer type argument is the source start location in CMarkup (DOM tree) . The second CMarkupPointer type argument is the source end location in CMarkup (DOM Tree). The third CMarkupPointer type argument is the target location in CMarkup (DOM Tree).

    Doc::CutCopyMove will copy or move the source sub DOM tree to the target location in DOM tree. Because of the use of the Splay Tree algorithm (which uses CTreePos as a node), the function needs to create a CTreePos object and add it to the SplayTree for source CMarkup (DOM tree) and target CMarkup (DOM Tree). Doc::CutCopyMove calls CMarkup::DoEmbedPointers to let the CMarkupPointer change to embed status. Finally, the CTreePos object is created. The UAF CTreePos object is created for the e_1 JavaScript element.

    Why does it free the CTreePos object?

    From the call stack trace when the CTreePos object is freed (Figure 4), we can find CDomRange::setEnd. This function can be mapped to line 17 in Figure 1: r.setEnd(e_1,0). That means the CTreePos object is in the implementation of setEnd. The CDomRange::setEnd function wants to replace the original end point with a new end point. This function finally calls CMarkupPointer::MoveToPointer to move to the specific DOM tree location. It will first call CMarkupPointer::UnEmbed to change this CMarkupPointer object to unembed and remove CTreePos from the Splay Tree and free it. The JavaScript code r.setEnd‘s argument is the e_1 element. So the CTreePos object related with the e_1 element is freed.

    Why does it use the freed object again?

    In Figure 7, under the red line is the function call for CSpliceTreeEngine::InsertSplice. Column B is CSpliceTreeEngine::InsertSplice+0x13ff. Column C is CSpliceTreeEngine::InsertSplice+0x6EDD4A. Column B is the free call stack trace and Column C is the “used again” crash call stack trace. This means that both “free” and “used again” happen in one function called CSpliceTreeEngine::InsertSplice. We trace the execution flow in this function, and find the following:

    Figure 9. Assembly code

    Instruction 636898C4, eax is the address of the UAF CTreePos Objects. The function saves the address to a local variable var_1E4. Then, it proceeds to 6368AA9A.

    Figure 10. Assembly code

    At 6368AA9A, it calls a virtual function CObjectElement::Notify. We can find here the call stack trace from Figure 7’s column B. This means when running this call, it encounters an error and calls the onerror event handler . That frees the CTreePos object. However, the CSpliceTreeEngine::InsertSplice function local variable var_1E4 holds a reference to this freed object. It then proceeds to 63D7735B.

    At 63D7735B , it calls CElment::RecordTextChange ForTsf with var_1E4 as the second argument. When this function is run, if any instruction accesses the contents of the CTreePos object, a crash occurs.


    In brief, the UAF issue’s root cause is that under the event interaction context, CSpliceTreeEngine::InsertSplice doesn’t handle local variable reference validation properly.

    DOM is based on event mechanisms. Under complex event interaction contexts, it is a significant challenge to solve UAF issue completely. However, in recent patches Microsoft has introduced memory protection in Internet Explorer, which helps mitigate UAF issues (especially in cases where a UAF object is referenced from the call stack).

    This highlights one important reason to upgrade to latest versions of software as much as possible: frequently, new techniques that make exploits more difficult are part of newer versions, making the overall security picture better.

    Trend Micro Deep Security protects users against this particular threat. The following rule, released as part of the regular updates released in June is applicable:

    • 1006036 – Microsoft Internet Explorer Memory Corruption Vulnerability (CVE-2014-1772)
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  

    Included in our predictions for the upcoming year is that more severe online banking and other financially-motivated threats will arise. It seems that we didn’t have to wait for 2015 to see proof of this prediction. We recently came across banking malware that features new techniques to cast a wider net for victims and avoid detection. This malware, known as DRIDEX, is being touted as the successor of the banking malware CRIDEX.

    The appearance of DRIDEX comes a couple of years after CRIDEX’s entry in the threat landscape. Both CRIDEX and DRIDEX steal personal information, specifically related data to online banking. DRIDEX is considered as the successor because it uses a new way to steal information—via HTML injections.

    However, there is a major difference between the two. CRIDEX malware is one of the payloads associated with exploit kit spam attacks. DRIDEX, on the other hand, relies on spam to deliver Microsoft Word documents containing malicious macro code. The macro code downloads DRIDEX onto the affected system.

    The DRIDEX Infection Chain

    As mentioned, DRIDEX arrives via spammed messages. The messages, supposedly sent by legitimate companies, talk about matters related to finance. The attachments are often said to be invoices or accounting documents.

    Figure 1. Sample spammed message

    The attachment is a Word document containing the malicious macro code. Should the user open the document, they might see a blank document. We have seen other attachments stating that the content will not be visible unless the macro feature is enabled—which is disabled by default. Once this feature is enabled, the macro downloads DRIDEX malware, specifically TSPY_DRIDEX.WQJ, onto the computer.

    Figure 2. Malicious attachment instructing users to enable the macro feature

    Once executed, the malware then monitors for activity related to online banking. Its configuration file contains a list of banks, most of which are based in Europe. Some of the targeted banks include:

    • Bank of Scotland
    • Lloyds Bank
    • Danske Bank
    • Barclays
    • Kasikorn Bank
    • Santander
    • Triodos Bank

    It then performs information theft through methods like form grabbing, screenshots, and site injections.

    Macros Versus Exploit Kits

    The use of macros is a marked departure from CRIDEX’s infection chain, which relies on the Blackhole Exploit Kit.  The move to macros could be seen as one way of ensuring a higher chance of successful attacks.

    Attacks using exploit kits rely on vulnerabilities in order to be successful. If the affected system is not vulnerable, the attack will not be successful. Meanwhile, macros are commonly used in automated and interactive documents. If the macro feature was already enabled prior to the attack, the attack commences without any additional requirements. Otherwise, the attack must use a strong social engineering lure in order to convince the user to enable the feature.

    The reliance on social engineering could be seen as one advantage of macro spam. In exploit kit spam, if the system is no longer vulnerable, the possibility of a successful attack dwindles to nothing, even if it was able to trick the user into click the malicious link. In a macro spam attack, there is always that possibility that the user will be tricked into enabling the macro feature.

    The use of macros also poses challenges for detection because of the insertion of garbage/useless code.

    Figure 3. Garbage code found in DRIDEX malware

    Affected Countries

    Based on feedback from the Smart Protection Network, users from Australia are the most affected by DRIDEX, followed by users in the U.K. and the U.S.

    Figure 4. Top affected countries, based on data from September-October 2014

    We traced the spam sending to several countries. The top ten spam sending countries include Vietnam, India, Taiwan, Korea, and China.

    Figure 5. Top DRIDEX spam sending countries

    Best Practices

    Macro-based attacks were popular in the early 2000s but they appear to be experiencing a revival these days. This just shows that “newer” attacks can come in the form of old techniques, which can be successful especially if victims are not aware of these older techniques. For macro-based attacks, it’s best to make sure to enable the macro security features in Office applications. For organizations, IT administrators can enforce such security measures via Group Policy settings.

    It might be tempting to open emails that are related to finances but users should avoid opening such emails until they can confirm the legitimacy of the email. These attacks rely on social engineering for success so exercising some caution can mean the difference between protection and infection.

    Trend Micro, through the Smart Protection Network, protects users from all threats related to this attack. Our Web Reputation Service, which tracks the credibility and safety of web domains, blocks access to malicious URLs. The Email Reputation Service scans emails and blocks those that contain spam-like and malicious content, including links and attachments. Meanwhile, our File Reputation Service checks the reputation of files against our database and flags those that contain malicious and suspicious behavior.

    The following are the related hashes for the said attack:

    DRIDEX malware:

    • C2C980297D985C0E62E461B76FA584E79A6B3822
    • 4DAD1A0E024CCE9C3A11622B5E5BBE3EFBEFC4B9
    • CBD005DB36EFBDF3AEED5D26FAD54554CD734DA4
    • BDC7C47001852A8E915F29EAEBCF99FFA857C3B5
    • B4F4B426457124ECFEEC4D5B59B9C2A6C25BAAF7
    • B54B06E01C6F735E98D17B156EE8C7A2437B2D68
    • BF1FCA6F81B3D5A9054CEAB9A56C58F248560B34

    Malicious .DOC files:

    • A7B1A30386928E6320C31279B3473610E0E96192
    • 01EEB1DEBB21DC8933E7B6C1280F7E3F87A88DD0
    • 0F9C49E08683B811A6C713AFC1A37B3A33F58FD8
    • F3A65B6828BEE8DA06DAEB1619B9F1265C4C38C7
    • AE6FE7D7E80D7271B902A482D1ECE2A73F082EBA
    • 46FF15B415407BABB60BECC19D259752C2BE77CD
    • 911A77E67ABABC355A2AA169149DE88480AB1768
    • 7714F4D42C7B1608BE281CB288C07BAF8FF35501

    With additional insight from Joie Salvio.

    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  

    We’ve found a new phishing technique targeting online shopping sites that may significantly change the threat landscape for phishing sites. Conventional phishing sites require an attacker to replicate the targeted site; a more accurate copy is more likely to fool intended victims.

    This technique we found allows for the creation of nearly perfect copies – because the attacker no longer needs to create a copy of the site at all. Instead, the phishing page only contains a proxy program, which acts as a relay to the legitimate site. Only when any information theft needs to be carried out are any pages modified. The owners of the legitimate site would find it very difficult to detect these attacks against their customers.

    We decided to call this particular attack Operation Huyao. In Chinese, huyao means a monstrous fox. The rather sneaky behavior of this attack, together with the fact that we believe the creators of this attack are located in China, made this name feel rather appropriate.

    Conventional phishing attacks and Huyao attacks

    To carry out a conventional phishing attack, an attacker need to capture, copy, and modify the code for the target organization’s website and host it on their own site. This could be hosted either on a malicious site, or a compromised site (particularly a subdirectory or subdomain).

    Many legitimate shopping sites use subdirectories to divide their store into various sections. Something like this, for example, would be perfectly reasonable:

    • http://{legitimate site}/clothes/
    • http://{legitimate site}/food/
    • http://{legitimate site}/music/

    With a conventional attack, it’s likely that three phishing sites would need to be prepared. In Operation Huyao, a single malicious domain was used to target multiple stores, like so:

    • http://{malicious domain}/clothes/tslyphperaHR0cDov{BLOCKED}.html

    The URL contains an identifier which flags the URL as being used by these relay attacks – tslyphper. The rest of the HTML file’s name identifies the site that is the target of the attack, like so:

    Input parameter: aHR0cDovL3d3dy5zaG9wcGluZ21hbGwuY28uanAv
    After BASE64 decoding: {URL of legitimate shopping site}

    The URL of the targeted site is stored in the phishing URL and can be found after BASE64 decoding.

    How the attack proceeds

    Conceptually, the attack overall is simple. The attacker’s malicious site acts as a relay/proxy for the original site. So long as the would-be-victim is just browsing around the site, they see the same content as they would on the original site. It is only when any payment information is entered that modified pages are displayed to the user.

    It does not matter what device (PC/laptop/smartphone/tablet) or browser is used, as the attacker proxies all parts of the victim’s HTTP request and all parts of the legitimate server’s response.

    The overall flow of this attack is shown in the diagram below:

    Figure 1. Overall attack flow

    To get the user to the malicious site, various blackhat SEO techniques have been used to insert the malicious sites in question to various product-related searches, as seen in the screenshot below. (The targeted shopping site was in Japanese, which is why the sites are in Japanese as well.)

    Figure 2. Search results with malicious links

    The changes begin when the user is about to buy a product. The Add to Basket function has been written by the attacker in order to perform their attacks.

    Figures 3 and 4. Price on actual site versus price on phishing site

    Note the difference between the two pages – the price has been significantly reduced. This may have been done in order to lure in would-be savers. Clicking on the “Add to Basket” button on the legitimate site takes the user via HTTPS to the actual shopping basket. On the phishing site, the user goes to the following page via an unprotected HTTP connection:

    • http://{malicious domain}/cart/cart.php?site={malicious domain}&p=3073&nm=Item_Name<tr><td><span%20class=

    The URL above contains both the price (3073 yen) and the name of the item in question. All of the pages beyond this point are created by the attacker to carry out information theft.

    As is typical in a checkout process, the user is shown a series of pages where they have to enter their information.

    Figure 5. Page asking for personal information

    The information asked for in this page is:

    • Name
    • Pronounciation
    • Postal code
    • Prefecture
    • City or Country
    • Address
    • Phone number
    • Email address
    • Password

    The format of the above page would be regarded by Japanese users (the target of this attack) as completely normal.

    In the next page, the users are asked to enter their payment information:

    Figure 6. Page asking for credit card information

    Here, the users are asked to enter the following:

    • Payment method/card issuer
    • Card number
    • Card expiration date
    • Name of cardholder
    • Security code

    One more screen appears, which is designed to defeat card verification services provided by some card networks. These ask for a separate password meant to verify that the actual cardholder is authorizing the account. By acquiring this password, the attackers can get around this verification system.

    Oddly, these fake verification pages ask for an ID/user name of some sort, which is not part of the actual verification process. A “personal message” that is specified by the user is not present (as, obviously, the attacker would not have previous access to this).

    Figure 7. Page asking for credit card authentication password

    Finally, an email message thanking the user for their order is sent to the address provided earlier. The message also contains the items that the user supposedly ordered from the online store:

    Figure 8. Email with supposed transaction details

    All this leaves the user with the impression that they have carried out a successful transaction, unaware that they have fallen victim of a phishing attack.


    So far, we have only identified this attack targeting one specific online store in Japan. However, if this attack becomes more prominent, it could become a very worrying development: this makes phishing harder to detect by end users, as the phishing sites will be nearly identical to the original sites.

    In addition, attackers will no longer have to exert much effort into duplicating entire shopping sites. They will only have to duplicate the payment pages, which is an easier task.

    We will continue to monitor and block all phishing attacks that use this or other similar methodologies.

    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  


    © Copyright 2013 Trend Micro Inc. All rights reserved. Legal Notice