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

    ZeuS/ZBOT has been one of the most talked about malware families for several years, and with good reason. It has continued to evolve, is very successful in hijacking online banking credentials, and added a variety of features designed to counter  various solutions that are supposed to mitigate it. It is estimated that ZBOT has enabled cybercriminals to steal more than $100 million US dollars since its inception.

    Zeus was designed to automate most of the information stealing behavior, and was specifically built to steal online baking credentials. However, we are seeing a type of under-the-radar online fraud carried out by simple, off-the-shelf keyloggers like Predator Pain and Limitless that are being used to perform corporate email fraud.

    The scale of this fraud is significant – the Commercial Crime Bureau of Hong Kong Police Force estimates this kind of fraud has netted attackers up to $75 million US dollars in the first half of this year, from Hong Kong alone. Consider: this means that cybercriminals in a single city, within six-months, equaled all the losses from ZBOT up to the present.

    Unlike Zeus, Predator Pain and Limitless are relatively simple keyloggers. They indiscriminately steal web credentials and mail client credentials, as well as capturing keystrokes and screen captures. The output is human readable, which is good if you are managing a few infected machines only, but the design doesn’t scale well when there are a lot of infected machines and logs involved.

    This simplicity belies the cunning of the operators behind these keyloggers. Experienced in 419 scams, the operators have the time and determination to target corporations, capture webmail accounts, monitor on-going business transactions, and, when the time is right, hijack the transaction to redirect payments to accounts they control.

    The tools these fraudsters use are not advanced. Combined, clever targeting, patience, cunning and simple keyloggers have netted these cybercriminals large sums of money. These highlight that cybercrime activities are dependent not only on the sophistication of the tools used, but on how well organized the entire scheme is. A sophisticated, well-designed scam can net its operators significant sums of money, as seen here.

    Our paper titled Predator Pain and Limitless: When Cybercrime Turns into Cyberspying discusses our findings about these tools, as well as what we know about the attacks that are being carried out with them.

    The following graphs show the distribution of the victims that we observed, both by country and by industry:

    Figure 1. Predator Pain/Limitless Victims by Country

    Figure 1. Predator Pain/Limitless Victims by Country

    Note that the country distribution graph is biased towards Malaysia because one of the actors involved targets South East Asian countries, with a bias towards Malaysia.

    Figure 2. Predator Pain/Limitless Victims by Industry

    Figure 2. Predator Pain/Limitless Victims by Industry


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

    The Sandworm vulnerability, also known as CVE-2014-4114, is an interesting vulnerability for two reasons. For one, it is related to the timing of the vulnerability life cycle.  In this blog post, we will tackle vulnerability analysis, and user awareness on what actions to take when they are under attack.  Note that all dates and times discussed here are based on publicly available information and in the internal metadata of the sample files. Here’s a timeline:


    Click image to enlarge

    *1: New CVE-2014-4114 Attacks Seen One Week After Fix

    CVE-2014-4114 is also related to the OLE design by itself. We can classify it as a Command Injection in the OLE infrastructure. This area is sufficiently complex and its hard to evaluate the scope of the attack surface; this caused the release of an incomplete fix and the release of CVE-2014-6352. This is because an attacker can control two external variables to invoke different paths inside the affected component package.dll. The variables are: OLE Verbs and Embedded File Type.

    Vulnerability time cycle

    Looking at the timelines is always helpful to understand and correlate major events. Sandworm became known to the public when iSIGHT released a blog entry on October 14 discussing the vulnerability and how it was being used in targeted attacks. It was fixed on the same day as part of the scheduled Patch Tuesday release, in MS14-060. A week later, on October 21, it was disclosed that under certain circumstances the patch could be bypassed, resulting in Microsoft Security Advisory 3010060 and published workarounds.

    What was in the patches? We found that they contained a new version of the file packager.dll. The following image shows the Windows properties of the file:


    Figure 1. Package.dll updated version (6.3.9600.17341) Windows file properties

    This file was created on September 13 – which is reasonable, since iSIGHT first spotted this attack on September 3. Other security vendors indicate they reported this flaw to Microsoft on September 2.

    The email campaign of Sandworm (or BlackEnergy) that targeted this vulnerability took place from August 13 onwards, as reported in various articles. These emails used a PPSX attachment with two embedded files. These embedded files contain an internal property informing the modification and created time.  The following image shows this property:


    Figure 2. OLE Compound tree structure.  Here we can see the ModifyTime is highlighted.

    A known file (SHA256 hash: 70b8d220469c8071029795d32ea91829f683e3fbbaa8b978a31a0974daee8aaf) used in this campaign is detected by Trend Micro as TROJ_MDLOAD.PGTY. The embedded files oleObject1 and OleObject2 have the modified date/time of 8/7/2014 1:15:59 PM.  Following the timeline until here, this would seem like a valid and logical date.  On October 16, 2014, Trend Micro reported that the same type of attack is being used to exploit SCADA systems.  The said attack employed the same technique – Command Injection in the OLE infrastructure – and used the same file origin. In this case two OLE files were used: devlist.cim and config.bak. Both files were created on 10/4/2013.

    There are several samples in VirusTotal related to this campaign. Some of these samples are directly related to the attacks, while others are simple modification to the attacks done by analysts. Extracting the attack IPs from all the samples we can get the following list:

    • \\10[.]0[.]0[.]34\public\slide1.gif
    • \\10[.]0[.]0[.]34\public\slide1.inf
    • \\10[.]0[.]0[.]27\share\xxx.inf
    • \\10[.]0[.]0[.]27\share\xxx.gif
    • \\10[.]80[.]65[.]87\impct\losslides.gif
    • \\216[.]66[.]74[.]22\/root/smb4k/teamths\ths.inf
    • \\216[.]66[.]74[.]22\/root/smb4k/teamths\ths.gif
    • \\210[.]209[.]86[.]152\p\z\slides.inf
    • \\210[.]209[.]86[.]152\p\z\slides.gif
    • \\185[.]29[.]8[.]212\share\sliiides.inf
    • \\185[.]29[.]8[.]212\share\sliiides.exe
    • \\121[.]166[.]55[.]120\file\lint.inf
    • \\121[.]166[.]55[.]120\file\head.gif
    • \\121[.]166[.]55[.]12\file\head.gif
    • \\192[.]168[.]10[.]10\shared\msf\XrHI.inf
    • \\192[.]168[.]10[.]10\shared\msf\XrHI.inf
    • \\192[.]168[.]10[.]10\shared\msf\TBSZ.gif
    • \\192[.]168[.]1[.]122\Support\xxx.gif
    • \\192[.]168[.]1[.]11\share\xxx.inf
    • \\192[.]168[.]1[.]11\share\xxx.gif
    • \\192[.]168[.]187[.]147\xpl\calc.gif
    • \\192[.]168[.]15[.]4\rdb\blah.gif
    • \\192[.]168[.]58[.]95\rdb\test.gif
    • \\192[.]168[.]58[.]95\rdb\test.inf
    • \\192[.]157[.]198[.]1\public\word.gif
    • \\118[.]99[.]13[.]236\docs\partyhis.gif
    • \\37[.]59[.]5[.]18\11\test.gif
    • \\109[.]163[.]233[.]151\public\aaaa.gif
    • \\109[.]163[.]233[.]151\public\aaaa.inf
    • \\94[.]185[.]85[.]122\public\slide1.inf (This is from the sample mentioned before)
    • \\94[.]185[.]85[.]122\public\slide1.gif (This is from the sample mentioned before)
    • \\94[.]185[.]85[.]122\public\default.txt (This is the sample attacking SCADA Systems)

    First patch and second attack

    In this blog post  we analyzed how the attacker can control the OLE Verb to execute the file once the PPSX is run. However, another interesting part of the attack is how the attacker control the file type to bypass the Mark on the Web (MOTW) and avoid the alert message in Windows showing the file as untrusted.  The user can control the file type using the CLSID in the OLE compound document.  The said property is under /Root Entry of the embedded object. The following image shows one example. In this case, the embedded type is 0x22602.


    Figure 3. OLE RootEntry property CLSID. The first value is the embedded type(0x22602).

    When package.dll is processing embedded files, the actual operation or extraction of the file depends on the file type. There are several type of files. The following image shows a big picture on how this works.


    Figure 4. Call paths inside package.dll.

    The attack for CVE-2014-4114 used 0x22602 as file type. This allows the attacker to bypass the MOTW protection. The OLE infrastructure will call CPackage::Load for each embedded file included in the PPSX file. This method calls ReadClassStg to get the embedded file type, which is 0x22602 in both cases. This type is MPlayer. Next, CPackage::Load will call LoadMMSStorage. The method LoadMMSStorage calls OLE2MPlayerReadFromStream or OLE1SoundReadFromStream depending on the OLE file type returned by ReadClassStg, which is MPlayer in this case.

    The problem is that methods call to CopyFileW or CopyStreamToFile both will result in creating the temporary file without MOTW. This is because the first patch from Microsoft changed the “XXReadFromStream” methods to call MarkFileUnsave. After the first patch the protection looks like the following screenshot:


    Figure 5. Protection using MOTW after patch.

    Note that the automatic execution using specific OLE Verb was not patched. The patch only added MOTW protection for these methods.

    For the attack related to CVE-2014-6352, the protection MOTW is not bypassed, as seen in the image before, but the execution will take place showing the following message to the user:


    Figure 6. . Pop-up message alerting the user when the file is protected with MOTW.

    The MOTW protection will create one NTFS stream to the created file that Windows will use to check to launch the warning message. The created NTFS stream is seen in the following image:


    Figure 7. NTFS stream of a file with MOTW activated.


    The attack technique for Command Injection in the OLE Infrastructure has been around since at least October 2013. If the attack happens in a system where the patch MS14-060 has been applied, the user will see the warning message shown in Figure 6.

    Trend Micro secures users from this threat via detecting the exploit and malware payload via the Smart Protection Network.  Trend Micro Deep Security and Office Scan with the Intrusion Defense Firewall (IDF) plugin protect user systems from threats that may leverage this vulnerability via the following DPI rules:

    • 1006290 – Microsoft Windows OLE Remote Code Execution Vulnerability (CVE-2014-4114)
    • 1006291  Microsoft Windows OLE Remote Code Execution Vulnerability (CVE-2014-4114) – 1

    Users are strongly advised to patch their systems once Microsoft releases their security update for this. In addition, it is recommended for users and employees not to open PowerPoint files from unknown sources as this may possibly lead to a series of malware infection.

    With additional insights from Pawan Kinger

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

    3:10 am (UTC-7)   |    by

    In an earlier blog post, we tackled what Wirelurker malware is and its security implications and risks for iOS and OSX devices.  Within hours of the discovery of this malware, a Windows-based malware (detected as TROJ_WIRELURK.A) that performs the same attack was also seen in the wild. In this blog post, we’d like to share practices and recommendations for users and enterprises in order secure their devices from this threat.

    The following are some simple steps for users to check whether their Apple devices are infected by this malware.

    For Mac computers:

    You may check whether the following launch daemons exist in your Mac:

    • /Library/LaunchDaemons/
    • /Library/LaunchDaemons/
    • /Library/LaunchDaemons/
    • /Library/LaunchDaemons/
    • /Library/LaunchDaemons/
    • /Library/LaunchDaemons/
    • /Library/LaunchDaemons/
    • /Library/LaunchDaemons/

    For jailbroken devices:

    You may use SSH to connect to your device and check whether the following file exists:

    • /Library/MobileSubstrate/DynamicLibraries/sfbase.dylib

    For non-jailbroken iOS devices:

    • Check whether there are any suspicious apps you did not install.
    • Open the “Settings” app, click the “Profile,” and check whether there are any suspicious profiles.

    Below are guideline to help you protect your Mac and iOS devices:

    1. Do not jail break your iOS device.
    2. Make sure your Mac and iOS are up-to-date.
    3. Do not install any pirated software or software from untrusted sources. Only install software from the official App store.


    Figure 1. Users can switch an option in “System Preferences” then select “Security & Privacy” to make sure only apps from official Mac App Store can be installed

    Users who need to install software from other sources (and opt to select Mac App Store and identified developers) are strongly advised to practice extreme caution before installing them, and to make sure that the installers are from trusted sources and not tampered with.

    4. Install security software on your Mac and make sure you always have the latest update.

    5. Make sure you only connect your iOS devices to computers that you trust.

    6. Pay attention to the installation request from enterprise provisioning applications. Allow only those from trusted sources to be installed on your device.

    7. Remove any suspicious profiles from your iOS devices.

    Figure 2.  Users can check the profiles installed in their iOS device in “Settings”> “General” > “Profile(s)”

    8. Carefully review any iOS application’s request for access to your camera, contacts, microphone, location information, and other sensitive data.

    Figure 3. Review the privacy setting for each app in “Setting”.  Users can prevent an app from accessing private information in “Settings” > “Privacy”

    Enterprises that have joined Apple’s enterprise developer program can may boost their security with the following steps:

    • Make sure you properly secure your private key.
    • Make sure only those necessary employees can access the private key.
    • Remember to deny former employees or team members access to the private key.
    • Revoke your certificate(s) as soon as possible if you feel your private key has been compromised.

    Revoking certificates is important as we have seen Windows malware that have been signed by stolen certificates. If enterprises lose their certificates, attackers could use the said certificates to impersonate them and use them to sign malware. Such actions may not only damage the enterprise’s reputation but also cost them a lot of resources in handling follow-ups.

    Trend Micro protects users from this threat via its Trend Micro Antivirus for Mac that detects the malware in OS X devices. We also detect the malicious apps installed onto jailbroken iOS devices as IOS_WIRELURKER.A.

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

    2:15 am (UTC-7)   |    by

    Last year, as part of our predictions for 2014 we said there would be one major data breach every month. At the time, many people said that our prediction was overly pessimistic. It was one prediction I would have been happy to have gotten wrong.

    Unfortunately, I haven’t been proven wrong. We’ve seen major data breaches hit large institutions left and right. In many cases, these breaches have been due to attacks by point-of-sale (PoS) malware that hit these companies. In other cases, attackers got into their networks directly and stole the information of their users.

    People may think that financial information is the most valuable information that can be lost, but that’s not always the case. Banks and other financial institutions are very good about not letting consumers eat the cost of financial fraud, so even if, say, your credit card number gets stolen and used by cybercriminals, you won’t have to bear the final cost.

    In some ways, in fact, your personal information getting leaked is more dangerous. I can change my credit card easily, but unless I move I can’t change my address.  Neither can I change my birthday. Personally identifiable information does not only identify the user, it is also frequently difficult, if not impossible, to change.

    These kinds of attacks can be used to make future social engineering attacks “better”. For example, a future attack can now give me my address, phone number, and other personal information and sound more convincing. Many users will be fooled and fall victim to all sorts of attacks.

    To many governments, it looks like companies are not protecting the information they have on their users. This may be why we’re seeing moves to impose regulations on how companies should protect the data of their users.

    For example, in Europe, the new EU Data Protection Regulations could mean that companies could face severe fines if they were breached – fines of up to 100 million Euros. Other countries are imposing their own sets of regulations, with their own sets of penalties.

    If you’re a company doing business in various countries, these will be some difficult times, as you will now have to cope with differing sets of rules and regulations, increasing the cost of compliance to your company.

    There is a silver lining to this, however. Maybe when company directors everywhere realize the cost of being breached, they’ll finally approve putting in place Intrusion Detection Systems and the other tools needed in today’s threat landscape.

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

    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  


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