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

  • Mobile Vulnerabilities

  • Zero-Day Alerts

  • Recent Posts

  • Calendar

    September 2015
    S M T W T F S
    « Aug    
  • Email Subscription

  • About Us

    11:47 pm (UTC-7)   |    by

    Detecting banking malware has become part and parcel of the security industry, so cybercriminals are continuously looking to gain the upper hand in the battle against the financial industry and security vendors. In the BlackHat presentation Winning the Online Banking War last August 5, Sean Park proposed the use of a new online banking security framework for banks and web app developers called “Malware Inject Prevention System.”

    The advent of ZeuS ignited the renaissance of banking Trojans a few years ago. The ZeuS source leak enabled the underground community to competitively develop new variants and even pushed the creation of fresh banking Trojan families such as Carberp. This boom of banking Trojans was possible because the ZeuS model was a modular approach that separates the malware from its money-stealing web application logic—which is called the ‘webinject’ or sometimes, ‘injects’ or ‘injections’. This enables cybercriminals to steal online banking customer credentials and to perform transaction manipulation and webinjects while bypassing two-factor authentication. (See also Automating Online Banking Fraud.)

    Although a significant part of the cat-and-mouse battle between the security industry and cybercriminals has to do with detecting the malware binary and evading detection, the detection of webinjects and the subsequent creation of evasion tactics has become a hot new battle ground between the banking industry and cybercriminals.

    Battling it out in the DOM space

    Currently, many security products and financial institutions rely on online banking page integrity checks to detect the presence of banking malware. This technique works due to the inherent mechanics of banking malware injecting itself into the browser’s Document Object Model (DOM) space. For instance, it is quite common for an online banking victim to give away the secure code when he encounters the message below during an online banking session.

    Figure 1. Sample webinject

    An HTML message that’s combined with a piece of JavaScript code injected by the banking malware renders the above screen. It is this injected JavaScript that many banks or vendors use as an artefact in order to detect the infected online banking session via DOM scan.

    However, this purely web-based DOM scan method can be subverted in many ways:

    • Exploiting invalid memory reference patterns

    The webinject can go undetected by exploiting invalid memory reference patterns. When the webinject removes its own script node from the DOM while its reference is kept elsewhere, it causes an invalid memory reference. This is because JavaScript’s garbage collector won’t be able to free the memory object whose reference count is positive. Using this technique, a webinject can register an event handler to an object within the online banking page, remove itself from DOM, and still remain “alive.” More importantly, the naïve script enumeration technique will not be able to see the removed script node.

    • Detection script evasion

    One of the major attack vectors in this threat environment is manipulating the detection script. Once the attackers reverse engineer the detection script, they can forge the intelligence transmitted by the detection script through a replay attack and manipulate the functions implemented by the detection script. This is possible because the banking malware has full visibility and access to all online banking web applications as well as the detection script. The attackers can insert their code at an arbitrary location, replace the detection script functions, or manipulate the detection code. This renders the detection script unable to perform its intended function, unless further remediation is taken.

    • Use of rootkits

    In the world of operating systems, rootkits allow malware to hide malicious components by intercepting the normal control flow of API functions. Rootkit are therefore another viable technique the fraudsters can take advantage of. The webinject can hook functions provided by DOM and the libraries (i.e. jQuery), and tamper with the information they return. This is what I call DOM rootkit (or JavaScript rootkit). For instance, evading the naïve script scan method is as easy as hooking getElementsByTagName DOM function and removing the malicious script from the list before it gets returned. Likewise, this rootkit technique can be applied to any functions used by the detection script. Therefore, it is critical that the detection script runs with a correct view of the operating environment (i.e., without any malicious code interfering with its control flow).

    The need for a paradigm shift

    Any complex code included in the detection script is fully exposed to the attacker. This makes it subject to reverse-engineering and subsequent evasion techiniques on the part of the cybercriminals. Defenders can defeat this by randomization of the detection script with algorithmically heterogeneous implementations with the goal of increasing the attack cost per randomization. In effect, the detection script is obfuscated from the attacker, and attempts to remove this obfuscation would impose a significant computational burden.

    The blind application of traditional metamorphism and polymorphism won’t help increase the difficulty of the attack. Carefully designed strategic defense mechanisms are necessary for each attack vector as described in the paper. In addition, it is critical to acquire a correct system view and ensure that existing defense mechanisms aren’t being subverted. Rootkit detection and code integrity checks can help here.


    In the BlackHat paper, the author outlined the different stealth and evasion techniques that cybercriminals use and the appropriate defensive measures that the banking industry should implement. The author also introduced the creation of MIPS, a hypothetical online banking security framework that works in the web application level instead of the operating system level. This means that instead of trying to discover webinjects in the browser’s virtual memory space, MIPS attempts to find out the JavaScript and associated artefacts injected by the malware. The full presentation is available for download [PDF] at the BlackHat 2015 briefings page.

    Banks need to go through a rigid set of tests before any change is released, which can take up more time than a banking malware’s webinject release cycle. In order to win the online banking war, it is crucial to set up strategic defense rather than short term ad-hoc patching since the overall update structure is not in favor of the defenders in the online banking war.

    When it comes to addressing online banking malware, it is not enough to be reactive to incidents as they occur. Strategic planning and the use of multiple layers of defense can go a long way.

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

    When it was announced that Microsoft Edge would replace Internet Explorer in Windows 10, a lot of members in the tech industry took notice. Internet Explorer has been, admittedly, a well-known target for vulnerabilities for years. We noted that in 2014 alone, a total of 243 memory corruption vulnerabilities in Internet Explorer were disclosed and patched.

    But weeks after its official release, it seems like Microsoft Edge is still working out some kinks, as one of the “Critical” security updates for this month applies to the new browser. MS15-091 is a cumulative security update for Microsoft Edge. According to the bulletin, the update addresses vulnerabilities, the most severe of which could “allow remote code execution if a user views a specially crafted webpage using Microsoft Edge.”

    This month’s Patch Tuesday brings another cumulative security update for Internet Explorer (MS15-079). Like that of Microsoft Edge’s, the patch addresses vulnerabilities that could allow remote code execution. The two other “Critical” updates also involve remote code execution: one for Microsoft Office (MS15-081) and the other for a Microsoft graphics component (MS15-080). Aside from the four “Critical” vulnerabilities, this month’s Patch Tuesday has ten “Important” updates, bringing the total to fourteen for August.

    Adobe has also released a security update (APSB15-19), which addresses vulnerabilities for Adobe Flash Player. According to the bulletin, the updates “address critical vulnerabilities that could potentially allow an attacker to take control of the affected system.”

    Users are strongly advised to update their software and systems with the latest patches from Microsoft and Adobe. For additional information on these security bulletins, visit our Threat Encyclopedia page.

    Trend Micro solutions

    Trend Micro Deep Security and Vulnerability Protection protect user systems from threats that may leverage these vulnerabilities with the following DPI rules:

    • 1006624-Microsoft Office Component Use After Free Vulnerability (CVE-2015-1642)
    • 1006928-Microsoft Internet Explorer Memory Corruption Vulnerability (CVE-2015-2442)
    • 1006929-Microsoft Internet Explorer Memory Corruption Vulnerability (CVE-2015-2443)
    • 1006930-Microsoft Internet Explorer Memory Corruption Vulnerability (CVE-2015-2444)
    • 1006931-Microsoft Internet Explorer Memory Corruption Vulnerability (CVE-2015-2446)
    • 1006932-Microsoft Internet Explorer Memory Corruption Vulnerability (CVE-2015-2448)
    • 1006933-Microsoft Internet Explorer Memory Corruption Vulnerability (CVE-2015-2450)
    • 1006934-Microsoft Internet Explorer Memory Corruption Vulnerability (CVE-2015-2451)
    • 1006935-Microsoft Internet Explorer Memory Corruption Vulnerability (CVE-2015-2452)
    • 1006936-Microsoft Office Graphics Component Remote Code Execution Vulnerability (CVE-2015-2431)
    • 1006937-Microsoft Office Memory Corruption Vulnerability (CVE-2015-2467)
    • 1006938-Microsoft Office Memory Corruption Vulnerability (CVE-2015-2468)
    • 1006939-Microsoft Office Memory Corruption Vulnerability (CVE-2015-2469)
    • 1006940-Microsoft Office Integer Underflow Vulnerability (CVE-2015-2470)
    • 1006941-Microsoft Office Memory Corruption Vulnerability (CVE-2015-2477)
    • 1006944-Microsoft Windows OpenType Font Parsing Vulnerability (CVE-2015-2432)
    • 1006945-Microsoft Windows TrueType Font Parsing Vulnerability (CVE-2015-2456)
    • 1006946-Microsoft Windows OpenType Font Parsing Vulnerability (CVE-2015-2458)
    • 1006947-Microsoft Windows OpenType Font Parsing Vulnerability (CVE-2015-2459)
    • 1006948-Microsoft Windows OpenType Font Parsing Vulnerability (CVE-2015-2460)
    • 1006949-Microsoft Windows OpenType Font Parsing Vulnerability (CVE-2015-2461)
    • 1006950-Microsoft Windows OpenType Font Parsing Vulnerability (CVE-2015-2462)
    • 1006951-Microsoft Windows TrueType Font Parsing Vulnerability (CVE-2015-2463)
    • 1006952-Microsoft Windows TrueType Font Parsing Vulnerability (CVE-2015-2464)
    • 1006955-Microsoft Windows TrueType Font Parsing Vulnerability (CVE-2015-2435)
    • 1006956-Microsoft Windows TrueType Font Parsing Vulnerability (CVE-2015-2455)
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  

    Two newly discovered Android vulnerabilities can potentially be used to mess up specific messaging functions in phones and tablets. The first, designated as CVE-2015-3839, may allow attackers to insert malicious messages in the system messaging app and cause it to crash, thus blocking users from sending or receiving messages. Meanwhile, the second flaw, designated as CVE-2015-3840, allows attackers to tamper with the sent/received statuses of SMS and MMS messages, may lead to multiple send charges for users.

    Unlike the recently disclosed “Stagefright” and a couple of other vulnerabilities targeting the mediaserver component in Android, the two new bugs deviate by targeting messaging components instead. Both flaws can be exploited in all Android versions, including the latest Android 5.1.1 Lollipop, but directly affects the plain Vanilla Android version more. (Vanilla Android here refers to the pure, non-customized OEM version of Android, the one directly coming from Google.) This is because the “pure” Vanilla OS typically still uses the original messaging app which these vulnerabilities target, as opposed to non-Vanilla Android versions which have probably been upgraded to use customized or alternate messaging apps.

    We have reported both vulnerabilities to Google and they have included our suggested patches to address the bugs. Both vulnerabilities are assigned with a low severity rating. We are continually monitoring for possible attacks.

    CVE-2015-3839 Helps Crash Messaging App

    This bug is a slightly more focused version of the previously reported Android vulnerability that traps phones in endless reboots. Similar to the Android mediaserver bug, attackers can exploit CVE-2015-3839 by tricking users into installing a malicious app without any permission required. The difference is this bug may allow attackers to perform  a Denial-of-Service (DoS) attack only on the messaging app and not the whole device. As a result, users can’t send or receive messages using the messaging app.

    This flaw originates from a null pointer exception (NPE) when updating the message status. Android devices use the “updateMessageStatus” function after sending text messages to update the status of the message in the SMS-STATUS-REPORT PDU (Protocol Data Unit) format. However, there are pieces of code in this function that do not properly handle exceptions, allowing attackers an opening to crash the messaging app.

    Figure 1. Piece of code that can not handle exceptions

    To do this, attackers would have to bypass the null checking part in the “updateMessageStatus” function. They can do this by getting the “createfromPdu” function, which is used to parse incoming PDUs and store the message object, to return a new “smsMessage” object. This function does not validate the message object “wrappedMessage” and always returns with a new “SmsMessage” object for both the  3GPP (GSM) and 3GPP2 (CDMA) formats.

    Figure 2. “createfromPDU” function that returns with a new “SmsMessage” object

    This will definitely bypass the null checking part in “updateMessageStatus”. However, if the “wrappedMessage” happens to be null, invoking “getStatus” can also cause a “NullPointerException” error. Since the caller function “updateMessageStatus” does not handle exceptions, the whole app will crash and be terminated.

    Figure 3. Crash stack of NullPointerException in

    Attackers need only insert malicious PDUs to cause a “NullPointerException” error. We have done this by injecting a simple malicious PDU to “MessageStatusService”:

    //Malicious PDU in bytes

    {00, 02, 00, 02, D0, 65, 61, 60, 80, 90, 25, 12, 23, 61, 60, 80, 01, 25, 12, 23, 00, FF};

    The following demo videos show how this can be done on Android 4.4.4 and 5.1.1 :

    CVE-2015-3839 Proof-of-concept attack on an Android 4.4.4 device

    CVE-2015-3839 Proof-of-concept attack on an Android 5.1.1 emulator

    CVE-2015-3840 Allows for Tampering, May Lead to Multiple Send Charges

    This bug can be exploited to modify SMS/MMS without the according “WRITE_SMS” permission required. Attackers may use an unprivileged, malicious app to a privilege escalation attack to the Android security model to modify the received status and date of SMS/MMS.

    The flaw originates from a vulnerable “MessageStatusReceiver” service in the AndroidManifest.XML file.  This service triggers message status updates according to the incoming SMS-STATUS-REPORT PDU. Since it has neither permission protection nor intent protection, it allows any unprivileged third-party app to send fake broadcasts and compromise SMS/MMS data.

            <receiver android:name=”.transaction.MessageStatusReceiver”>            <intent-filter>                <action android:name=”” />            </intent-filter>        </receiver

    Vulnerable receiver that can be compromised to update message status

    As a result, attackers can tamper with a received message and tag it as “unsuccessful,” possibly tricking the user into resending the message. In a worst-case where the attackers use a malicious app to monitor and modify conversations, they can have the users continually send messages to a premium service number and charge the users for it.

    To exploit this vulnerability, we injected the following malicious PDU and broadcasted it to the vulnerable receiver:

    • Inject malicious PDU to mark SMS status as received

    // malicious PDU in bytes

    {00, 02, 00, 02, D0, 65, 61, 60, 80, 90, 25, 12, 23, 61, 60, 80, 01, 25, 12, 23, 00}

    • Inject malicious PDU to mark SMS status as unsuccessful

    // malicious PDU in bytes

    {00, 02, 00, 02, D0, 75, 71, 60, 80, 70, 42, 34, 56, 61, 60, 80, 01, 25, 14, 15, 40}


    The following demo videos show how this can be done on Android 4.4.4 and 5.1.1 :

    CVE-2015-3840 Proof-of-concept attack on Android 4.4.4 device

    CVE-2015-3840 Proof-of-concept attack on Android 5.1.1 emulator


    Android device patching is typically fragmented, and so, end users should consider using alternate messaging apps while patches are underway. Installing mobile protection solutions that block this specific threat should also be considered.

    Trend Micro covers end users with solutions that detect the attack and protect from this vulnerability. Trend Micro™ Mobile Security and the cloud-based Mobile App reputation Service will detect malware that may attack CVE-2015-3839 as AndroidOS_MsgDoS.A and CVE-2015-3840 as AndroidOS_MsgCrack.A.

    Disclosure Timeline 

    This vulnerability was disclosed to Google, with details outlined below:

    • June 4: We disclosed detailed reports to Google.
    • June 7: Google confirmed the issue and assigned CVE-2015-3839 and CVE-2015-3840.
    • July 20: We provided Google with code that would remedy the vulnerability.
    • Aug 7: Google accepted the patches and merged them into the AOSP master branch.
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  

    This year’s Black Hat and DEF CON gave us a good glimpse of the future: what we can expect, what we need to fear, and most especially what we need to do.

    The Dream of Internet Freedom

    Jennifer Granick’s keynote speech during the first day of Black Hat 2015 captured the theme of this year’s conference. Granick is the Director of Civil Liberties at the Stanford Center for Internet and Society and is known for representing Kevin Poulsen and Aaron Swartz before US criminal courts. In her speech, entitled The Lifecycle of a Revolution, she spoke of the dream of Internet freedom: the freedom to exist without judgment (be it based on age, race, class, or gender), the freedom to communicate with anyone, anywhere, the freedom to access information, and the hands-on imperative – the freedom to explore and understand the technologies around us.

    She talked about how that dream does not seem to fit into the Internet today and how we will most likely see the end of that dream if we don’t act now. We’re now seeing a centralized, regulated Internet – one that is controlled based on decisions of those in power. This shouldn’t be the case; it goes against the values that started the Internet years ago. Globalization through the Internet should not be regulated by those with local concerns.

    Figure 1. The way to achieve Internet Freedom, from Jennifer Garnick’s Black Hat keynote speech

    This point was also driven home by CloudFlare CEO Matthew Prince in his talk The Battle for Free Speech on the Internet. He discussed how he’d repeatedly encountered instances whereas governments and companies tried to define what is good and bad, based on their own needs. As the CEO of a company that provided services to deal with denial-of-service attacks, his talk highlighted the need for a more objective sense of control around the policies that decide which content ends up online.

    The State of Android (In)security

    The dismal state of Android security was in the spotlight in many different ways throughout both Black Hat and DEF CON. Adrian Ludwig’s talk on the Android Security State of the Union discussed the various security strategies and solutions that Google has put in place to secure the OS. As expected, however, there were more talks about threats than solutions.

    Joshua Drake presented how he was able to find Stagefright. The vulnerability in Android had made the news prior to Black Hat, primarily because it can be used to install malware on an Android device through a multimedia message. Trend Micro researchers, who also independently discovered the vulnerability, reported that Stagefright can also be exploited through an app, or a specially crafted URL. Wen Xu’s talk on universal rooting in Android tackled how their team was able to use a kernel UAF (User-After-Free) vulnerability in Linux to root most Android devices. This was particularly interesting as Xu shared how they are able to root even 64-bit Android devices – something that hasn’t been done before.

    Another talk that discussed Android threats was Certifi-gate. The research by Ohad Bobrov and Avi Bashan focused on how the customization done on the Android platform by different vendors lead to vulnerabilities that leave millions of users at risk. These findings add to the recent string of vulnerabilities being reported affecting Android users, making the issue of fragmentation more relevant now. As more vulnerabilities are being found, it is much more critical for Google and the device manufacturers to be able to roll out updates as soon as possible. (In fact, during the week of Black Hat/DEF CON, it was announced that Google, Samsung, and LG would all start pushing regular monthly security updates.)

    Car Hacking and Beyond

    As Charlie Miller and Chris Valasek put it, saying that anything is unhackable will just make one look ridiculous, and this was proven in various ways throughout the week.

    Car hacking was one of the main themes in both Black Hat and DEF CON, with the latter even introducing a new Car Hacking Village to allow people to explore vehicle electronic systems. The Remote Exploitation of an Unaltered Passenger Vehicle talk by Miller and Valasek was well attended at both conferences. Their presentation went into detail on how they were able to achieve such control, from studying vulnerabilities in the car’s system, to leveraging mobile networks to achieve remote access. Samy Kamkar’s presentation delved more into other stages involved in stealing cars, such as hacking garage door openers to achieve physical access.

    Another key highlight was Marc Rogers’s and Kevin Mahaffey’s talk on hacking a Tesla Model S. Calling the Tesla “the most connected car in the world”, the researchers shared how they were able to achieve control of the vehicle, primarily through tinkering with the vehicle’s hardware. Rogers and Mahaffey also noted how difficult it was for them to successfully achieve this, highlighting the strategies taken by Tesla in to keep the Model S secure. (A surprise attendee at the talk: Tesla’s CTO JB Straubel, who thanked the pair for their efforts.)

    Cars weren’t the only ones that were hacked during the week. Runa A. Sandvik and Michael Auger presented how they were able to hack a Linux-powered TrackingPoint TP750 sniper rifle. Although their research indicated that remotely pulling the trigger through the system is not possible, changing the information returned to the scope was. Our own GasPot research showed that fuel tanks are being attacked as well.


    Overall, both Black Hat and DEF CON showed good examples of how researchers exercise the hands-on imperative – the right to explore, disassemble, analyze, and understand the technologies around us. Done for the sake of security, such research will help us secure the different platforms that are increasingly being used in our everyday lives.

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

    During the first quarter of 2015, we saw how ransomware variants have evolved to do more than just encrypt valuable system files. CryptoFortress targeted files in shared network drives while TeslaCrypt targeted gamers and mod users. Now we are seeing another feature rapidly gaining ground in the world of ransomware: the ability to increase the ransom price on a deadline.

    Time-Sensitive Crypto-Ransomware in AU Spam Run

    A recent attack on an Australian company revealed a new TorrentLocker variant that can double the price of decryption after a deadline of five days.

    The cyber attack started with a business email. We noted a TorrentLocker spam run targeting Australia that probably delivered the infected email. TorrentLocker is a persistent threat in the region, as we have mentioned early this year.

    After clicking on one of these infected emails, a manager’s system ended up with the crypto-ransomware TROJ_CRYPLOCK.XW. Nothing happened at first. The manager deleted the email and thought nothing of it until hours later. By then, it was too late.

    The malware has already encrypted 226 thousand files before it popped the warning and all IT admins can do is stare at a screen asking them for AU $640 in five days, after which the price will double to AU $1280.

    Figure 1. Screenshot of TROJ_CRYPLOCK.XW showing deadlines and prices

    The malware can encrypt text, image, data, web, database, video, web, backup, and other file formats. It encrypted the local drives alphabetically, starting with the C drive. With the network drives, it encrypted alphabetically based on the network workstation names, then share names.

    Once done, it deleted traces of itself from the machine and left only the .ZIP file in the temporary Internet files and some HTML warnings.

    Since the business owner did not engage with the cybercriminal, the company lost thousands of valuable files, including business-related databases.

    Time Options in New Ransomware Platform

    In the theme of time-sensitive threats, we also saw a new ransomware platform, Encryptor RaaS (Ransomware as a Service), which incorporates options to set deadlines and amounts for the increase in ransom price. This is detected as TROJ_CRYPRAAS.A.

    Figure 2. Welcome page of the RaaS ransomware platform

    After encrypting the user’s files, malware launches Internet Explorer to access the decryption URL using a Tor2Web site, decryptoraveidf7[.] onion[.] to. Tor2Web sites allows users access to Tor sites or  hidden services using a normal web browser.  The malware also drops the ransom note in the desktop folder.

    Figure 3. Ransom note of the RaaS ransomware platform

    Encryptor RaaS encrypts text, audio, video, data, web, compressed, backup, developer, and other file formats.

    Figure 4. Decryptor page of the RaaS ransomware platform

    Figure 5. Successful payment page of the RaaS ransomware platform

    Encryptor RaaS follows in the footsteps of the notorious Tox by offering ransomware as a service and taking 20% of the Bitcoin earnings. However, unlike Tox, the Bitcoin earnings go straight to the platform users’ Bitcoin wallets and not to the platform creator.

    Given news that the creator of Tox is looking to sell his platform, it is likely for cybercriminals to flock to Encryptor RaaS to build their own ransomware for free.


    We have been seeing ransomware variants incorporate deadlines in their routines for a time now. This feature is rapidly becoming prevalent in the world of ransomware.  Continuing upgrades in crypto-ransomware show that users need to be vigilant with attack vectors that may be used to get the malware in their machines.

    While installing security software to protect all endpoints is paramount to security, it is equally important to use a multi-layered approach.

    • Always have a backup strategy, most efficiently by following the 3-2-1 rule as we previously discussed during World Backup Day.
    • Trust products proven to detect ransomware before it reaches your system—either as a bad URL, a malicious email, or via unpatched exploits.
    • Noting the way that the Australian company was hacked, it pays to also educate employees about safe email and Web browsing procedures.

    With additional analysis and insights by Jonh Chua, Maydalene Salvador, Nazario Tolentino II, Michael Marcos, Kurt Baeten, and Jon Oliver

    Update as of August 11 2015, 12:15 A.M. PDT (UTC-7)

    TROJ_CRYPRAAS.A has been renamed to RANSOM_CRYPRAAS.SM.

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


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