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

  • Recent Posts

  • Calendar

    October 2014
    S M T W T F S
    « Sep    
     1234
    567891011
    12131415161718
    19202122232425
    262728293031  
  • About Us

    One of the bulletins that was part of the October 2014 Patch Tuesday cycle was MS14-063 which fixed a vulnerability in the FAT32 disk partition driver that could allow for an attacker to gain administrator rights on affected systems, with only a USB disk with a specially modified file system. This vulnerability as also designated as CVE-2014-4115.

    Why is this vulnerability unusual?

    We pay close attention to file system drivers because these can be used to attack systems via USB drives. Consider the earlier Stuxnet vulnerability: that was spread using one vulnerability in Windows shortcuts to easily run Windows shell code; a second vulnerability was used to gain administrator rights. A vulnerability in the file system driver can be used to perform what would normally be two separate step in just one.

    CVE-2014-4115 is found in the file system driver (FASTFAT.SYS) of Windows Vista, Server 2003, and Server 2008. This driver is responsible for handling fast FAT file systems (like FAT32). This vulnerabily can be triggered when handling boot sectors with a specific BIOS Parameter Block (BPB) in FAT32-formatted drives.

    FAT32 is still commonly used today in USB flash disks. Because of this, a targeted attack can be carried out using this vulnerability. Suppose that a specially crafted USB disk somehow ends up plugged into the laptop of a senior executive or a PC in that company’s intranet. Those systems can than be controlled by outside actors and potentially used in targeted attacks.

    Timely patching by system administrators would have reduced the risk of falling victim to this attack. Enterprise system administrators should also reconsider existing policies on the use of USB media within corporate networks.

    What and where is the vulnerability?

    As we noted earlier, the vulnerability is found in FASTFAT.SYS. Comparing the vulnerable version and the patched version, there is only one difference: the function FatCommonWrite().

    Figure 1.  Difference between original and patched FASTFAT.SYS

    The second parameter (NumberOfBytes) is multiplied by 0×18 in the patched version when the ExAllocatePoolWithTag function is called.

    The prototype of function ExAllocatePoolWithTag() is as follows

    PVOID ExAllocatePoolWithTag(
    _In_  POOL_TYPE PoolType,
    _In_  SIZE_T NumberOfBytes,
    _In_  ULONG Tag
    );

    The bug itself is very simple. The developer performed the wrong calculation on the size needed memory that is to be allocated: he forgot to multiply the number of structures by the size of a single instruction. This can lead to out-of-bounds heap write operations in the following instructions.

    The pseudocode around the vulnerability could be described as follows:

    NTSTATUS FatCommonWrite (
    IN PIRP_CONTEXT IrpContext,
    IN PIRP Irp
    )

    {
    ……
    if (TypeOfOpen == VirtualVolumeFile)
    {
    ….
    ULONG Fat;
    ULONG BytesPerFat;
    IO_RUN StackIoRuns[2];
    PIO_RUN IoRuns;
    BytesPerFat = FatBytesPerFat( &Vcb->Bpb );
    if ((ULONG)Vcb->Bpb.Fats > 2) {
    IoRuns = FsRtlAllocatePoolWithTag(
    PagedPool,
    (ULONG)(Vcb->Bpb.Fats), //Actual vulnerability, missing ×sizeof(IO_RUN)
    TAG_IO_RUNS );
    } else
    {
    IoRuns = StackIoRuns;}
    for (Fat = 0; Fat < (ULONG)Vcb->Bpb.Fats; Fat++)
    {
    IoRuns[Fat].Vbo = StartingDirtyVbo;
    IoRuns[Fat].Lbo = Fat * BytesPerFat + StartingDirtyVbo;
    IoRuns[Fat].Offset = StartingDirtyVbo – StartingVbo;
    IoRuns[Fat].ByteCount = WriteLength;
    }
    ……
    }
    ……
    }

    Obviously, when Bpb.Fats is 3 or above, the memory allocation for IoRuns by FsRtlAllocatePoolWithTag() is less than the expected size. It would typically cause a crash when IoRuns is called again – for example, when it is initiated in the “for” statement. However, hackers can use it to overwrite some kernel objects deliberately, setting the stage for arbitrary code execution.

    Triggering the vulnerability

    Since any FAT32 file write request with the VirtualVolumeFile file type could trigger FatCommonWrite, the key point is how to control Vcb->Bpb.Fats to meet the condition (Vcb ->Bpb.Fats > 2) of the vulnerability

    In the fastfat implementation, the Vcb (Volume control Block) record corresponds to every volume mounted by the file system. In FatCommonWrite, Vcb is initiated with FileObject which is the memory representation of FAT32 volume partition just before the vulnerability.

    The Vcb trace back process for detail is shown below:

    Figure 2. Vcb trace back

    _USBSTOR is the volume label of our USB drive for test with FAT32 file system.

    What is Bpb.Fats?

    Usually, the MBR (Master Boot Record) is located in cylinder 0, head 0, sector 1, while the Boot Sector of the first partition of a FAT32 volume is located in cylinder 0, head 1, sector 1.

    The first important data structure of a FAT volume is called the BPB (BIOS Parameter Block), which is located in the first sector (Boot Sector) of the volume in the Reserved Region.

    Figure 3. BPB in disk format

    The definition of a BPB’s structure can be found in Microsoft Windows Driver Kit as follows:

    typedef struct BIOS_PARAMETER_BLOCK {
    USHORT BytesPerSector;
    UCHAR  SectorsPerCluster;
    USHORT ReservedSectors;
    UCHAR  Fats; //Number of FAT tables, default 2
    USHORT RootEntries;
    USHORT Sectors;
    UCHAR  Media;
    USHORT SectorsPerFat;
    USHORT SectorsPerTrack;
    USHORT Heads;
    ULONG32  HiddenSectors;
    ULONG32  LargeSectors;
    ULONG32  LargeSectorsPerFat;
    union {
    USHORT ExtendedFlags;
    struct {
    ULONG ActiveFat:4;
    ULONG Reserved0:3;
    ULONG MirrorDisabled:1;
    ULONG Reserved1:8;
    };
    };

    USHORT FsVersion;
    ULONG32 RootDirFirstCluster;
    USHORT FsInfoSector;
    USHORT BackupBootSector;
    } BIOS_PARAMETER_BLOCK, *PBIOS_PARAMETER_BLOCK;

    How to control Bpb.Fat?

    Bpb.Fat is located in the fixed byte of the disk drive, which can be modified directly by a sector read/write tool.

    In this test, we use FAT32 template of a binary editor to find out the Bpb (i.e. BPB_FAT32 structure in Figure 4) structure and the Fat field (i.e. NumberOfFats in Figure 4).

    Figure 4  FATS in Data Structure of BPB

    Proof of Concept leading to a crash

    We made a proof of concept by simply modifying the BPB of a FAT32 USB disk. We changed BPB_FAT32.NumberOfFATs to a number greather than 2 using the sector read/write tool.

    A crash soon results after the following steps:

    1. Insert this USB disk into any PC with a vulnerable FASTFAT.SYS version.
    2. Perform any write operation on the disk (i.e. copy a file onto it.)

    Conclusions

    This vulnerability is present in older versions of Windows – Vista, Server 2003, and Server 2008. Newer versions like Windows 7, Windows 8, Server 2008 R2, and Server 2012 are not affected.

    The patch for this vulnerability makes the code for the patched platform essentially identical to newer versions. We suppose that the vulnerability was introduced by human error during coding or during code merging. This indicates that more vulnerabilities or bugs could be found out by binary comparison between Windows 7 and other platforms for FASTFAT.SYS.

    Exploits for this vulnerability has not yet been seen publicly to date. However, the appearance of exploits in the wild cannot be ruled out. Incidents like these highlight the need for improved patch management on the part of enterprises, as even vulnerabilities that do not immediately lead to the execution of code on affected systems can pose risks, as this analysis shows. In addition, network-based solutions like Deep Discovery can help reduce the risks from certain kinds of vulnerabilities.

     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  

    A new Shellshock attack targeting SMTP servers was discovered by Trend Micro.  Attackers used email to deliver the exploit. If the exploit code is executed successfully on a vulnerable SMTP server, an IRC bot known as “JST Perl IrcBot” will be downloaded and executed. It will then delete itself after execution, most likely as a way to go under the radar and remain undetected.

    The diagram below illustrates the attack cycle.


    Figure 1. Diagram of the SMTP attack

    1. The attacker creates a custom email with Shellshock malicious code inserted in the Subject, From, To and CC fields.
    2. The attacker then sends this email to any potential vulnerable SMTP server.
    3. When a vulnerable SMTP mail server receives this malicious email, the embedded Shellshock payload will be executed and an IRC bot will be downloaded and executed. A connection to IRC server will also be established.
    4. Attackers can then perform different routines with the mail server, such as launching a spam run.

     Possible Vulnerable Mail Servers

     We listed down various environments with possible vulnerable mail servers.

    1. qmail Message Transfer Agent (MTA)
      .qmail is a Unix-based configuration file that controls the delivery of email messages and is responsible for launching Bash shell commands for execution. It is possible to configure this to launch a program and once it calls Bash, the attack is successful. (The attack requires that a .qmail file exists for the valid recipient on the qmail MTA and that the .qmail file contains any delivery program.)
    2. exim MTA with versions earlier than Version 4
      Starting with Version 4 of exim, the pipe_transport  does not call a Shell for variable expansion and command line assemble.
    3. Postfix using procmail: the Postfix MTA invokes procmail, which is a Mail Delivery Agent (MDA). An MDA is used to sort and filter incoming mail.
      Postfix has no obvious Shellshock vulnerability. However, procmail (a type of message delivery agent) itself could use an environmental variable to pass message headers to subsequent deliver/filter programs, resulting in the vulnerability in Shellshock attacks.
      Note: Debian/Ubuntu Postfix distribution default sets procmail at its mailbox_command configuration in main.cf. This means the Debian/Ubuntu Postfix distribution are vulnerable to Shellshock attacks.

    Analysis of the Attack

    According to our analysis, the malicious email crafted by the attacker will connect to the following URLs and download IRC bots if the malicious script embedded in the emails were successfully executed by a vulnerable SMTP server:

      • hxxp://{BLOCKED}.{BLOCKED}.31.165/ex.txt
      • hxxp://{BLOCKED}.{BLOCKED}.251.41/legend.txt
      • hxxp://{BLOCKED}.{BLOCKED}.175.145/ex.sh

    All IRC bots discovered so far are written by Perl. The files ex.txt and ex.sh are the same file but with different names.


    Figure 2. Source code downloaded by “JST Perl IrcBot” 

    “JST Perl IrcBot” connects to a command-and-control (C&C) IRC server through Ports 6667, 3232, and 9999. The bot performs the following routines, compromising the security of the affected system:

      • Download file(s) from URLs
      • Send mail
      • Scan ports
      • Perform distributed denial-of-service (DDoS) attacks
      • Run Unix command

    This SMTP server attack has been seen in countries such as Taiwan, Germany, the U.S., and Canada.


    Figure 3. Top countries which visited the site hosting the malware

    The IRC bot discovered in this STMP attack will connect back to following IRC servers where it waits for commands from the bot master or attacker:

      • 62[.]193[.]210[.]216
      • d[.]hpb[.]bg

    There are at least 44 variants of IRC Perl bots detected by Trend Micro. The related hashes for this attack are:

      • SHA1: 23b042299a2902ddf830dfc03920b172a74d3956 (PERL_SHELLBOT.SMA)
      • SHA1: 8906df7f549b21e2d71a46b5eccdfb876ada835b (PERL_SHELLBOT.SM)

    Conclusion

    This SMTP attack highlights yet another platform for attackers to exploit the Shellshock vulnerability to launch IRC bots.

    We recommend IT administrators to block all related IPs and domains related to this attack. Although, the victim countries and impact are limited as of posting, we are continuously monitoring this threat for any new development.  Trend Micro can detect all discovered IRC bots related to this attack so all our customers are well protected. Trend Micro Deep Security prevents this kind of attack on SMTP servers via the following rule, which was released since September 30:

    • 1006259 – GNU Bash Remote Code Execution Vulnerability Over SMTP

    For more information on Shellshock vulnerability, you can read our Summary of Shellshock-Related Stories and Materials.

    Users can also get free protection from Shellshock via these tools.

     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  

    Malicious browser extensions bring about security risks as these often lead to system infection and unwanted spamming on Facebook. Based on our data, these attacks have notably affected users in Brazil.

    We have previously reported that cybercriminals are putting malicious browsers in the official Chrome Web store. We also came across malware that bypasses a Google security feature checks third party extensions.  For this blog entry, we performed an in-depth analysis of malicious Chrome browser extension and its evasion tactics, after receiving samples in from Facebook. Facebook’s Security team conducts their own malware research and they regularly collaborate with Trend Micro to keep their service safe.

    The Ins and Outs of the Browser Plugin

    The malicious Chrome plugin (detected as BREX_KILIM.LL)  is composed of two files, manifest.json and background.js. The file manifest.json will inform Chrome where to load background.js:

    malbrowser1

    Figure 1. Two files behind the malicious plugin

    The file background.js will execute the following routines:

    1. It prevents the removal of the malicious plugin. If  users open a tab to chrome://extensions to check for malicious browser extensions, the plugin will close this tab immediately.

    malbrowser2

    Figure 2. Code showing the closing of said tab

    2. It prevents access to antivirus websites. Any attempts to visit antivirus software websites will be blocked.

    malbrowser3

    Figure 3. Code showing the blocking of specific sites

    malbrowser4

    Figure 4. Notification showing access was blocked by the extension

    3. It removes the security option from HTTP response header. This security option is typically used to avoid cross site scripting attacks. The plugin removes this as it will will inject script that does not belong to Facebook.

    malbrowser5

    Figure 5. Code removing portions of the HTTP header

    4. It runs a JavaScript code when users visit Facebook. When users go on Facebook, the plugin will run a JavaScript code into the tab where the site is open. Doing so will allow the cybercriminals to control the users’ accounts; users will unwillingly follow, like, or subscribe to Facebook accounts as dictated by the cybercriminals behind this attack. These commands are performed automatically by the included JavaScript code. The affected users’ friends will also see these actions on their feed and may possibly inadvertently install the plugin as well.

    malbrowser6

    Figure 6. Screenshot of the malicious JavaScript that triggers users to follow, like, subscribe a Facebook account owned by cybercriminals

    Evasion Tactics

    To avoid having their extensions detected and removed from computers, cybercriminals are using the following evasion methods:

    1. They use malicious multi-script  files that work together.

    malbrowser7

    Figure 7. Malicious plugin using multi-script

    The malicious behavior is separated into multiple files. If each script file is analyzed independently, the overall malicious behavior may not be spotted and the files may be (mistakenly) thought to be clean.

    2. They encode the JavaScript content.

    Hackers use HEX to encode strings as seen in the screenshot below:

    malbrowser8

    Figure 8. Encoded strings via Hex

    After decoding the Hex string, they appear like in the screenshot below, showing that it’s the same as the original. This behavior helps to avoid detection by security products.

    malbrowser9

    Figure 9. Decoded string

    3. They use HTTPs and a known, good domain to host malicious JavaScript.

    malbrowser10

    Figure 10. A good domain used by the malicious plugin

    For instance, herokuapp.com is a free cloud application platform where everyone can upload APP to it, and cybercriminals can use this site to host the malicious JavaScript. This tactic is also used to prevent URL detection and blocking by security solutions.

    4. They use Twitter to hide malicious URLs.

    malbrowser11

    Figure 11. Code communicating with Twitter servers

    malbrowser12

    Figure 12. Twitter profile that houses the URL

    A malicious plugin runs a JavaScript into the user’s browser tab and downloads content from a Twitter user’s profile. The cybercriminals use the affected Twitter user’s profile content to hide the malicious URL that  the plugin connects to. Once cybercriminals change the profile content, they can change the behavior of the malicious plugin.

    5. They use fake file extensions.

    malbrowser13

    Figure 13. The plugin uses .DLL as its supposed extension

    Infections and Protection

    Based on our data starting from May 2014 onwards, Trend Micro HouseCall has helped about 1,000,000 users whose computers have been infected by malicious browser extensions. The top affected countries are mostly located in the Latin American region, such as Brazil, Mexico, Colombia, and Peru.


    Figure 14. Top affected countries

    We strongly advise users to avoid clicking links from messages, even if they appear to come from your friends. Users can also opt to use Trend Micro HouseCall to secure their systems from online threats, including those that may leverage or abuse Facebook.  Trend Micro and Facebook are working closely together to combat this threat.

    Below is the SHA1 hash of the malicious file:

    • 4733c4ea00137497daad6d2eca7aea0aaa990b46

     

     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  

    We have been continuously monitoring the FlashPack exploit, especially with the recent attack which affected Japanese users. We recently looked at our Smart Protection Network feedback and found in a new development that majority of the infected systems of FlashPack exploit came from the U.S.

    zemot1

    Figure 1. Top infected countries for the FlashPack exploit (based on feedback from September 24-October 22)

    URL Usage and Malware Payload

    We checked the details of the URLs used by the FlashPack exploit and found that the exploit uses three combinations. We broke down the combinations in the table below.

    zemot2

    Figure 2.  Format of the URLs used by the FlashPack exploit

    Based on our analysis, one significant detail is that majority of the sites are employing bulletproof hosting, though some of the said sites have been taken down already. Furthermore, the domain registrations of the discovered sites are new and have been registered only between September and October 2014.

    Given these facts, having a very strong web filter that enforces an existing IT policy of only allowing access to known sites would be ideal as it effectively filters out unknown sites.  At the onset of infection, the URLs used in this attack may not be rated immediately as these are newly created websites and as such may not have been classified or visited yet by a web filter vendor.

    In one of the URLs that was used as a distribution point, the initial file upon its discovery (sha1: 909dc6764355625cb9a98ae45f986439cf3142a6) had little behavioral characteristics as it just launches calc.exe and is generally benign.

    zemot3

    Figure 3. Behavioral characteristics of the initial benign file (sha1: 909dc6764355625cb9a98ae45f986439cf3142a6), seen through sandbox execution in Deep Discovery Analyzer

    The files downloaded from the distribution sites are named this way:   e54 + [0-9,a-f]{10} + [0-9]{10}  + .exe.  Here are other examples:

    e5444ba64330cd1413790308.exe
    e54443e078e78a1413758471.exe
    e5441bf7a34d961413595002.exe
    e54419339d4cf11413583673.exe
    e544185e1ef4571413580257.exe
    e544183b3ccb0e1413579699.exe
    e544174fb9ca431413575931.exe
    e54416fe30fc2b1413574627.exe
    e544168f59c9c51413572853.exe
    e544165de20c9e1413572062.exe
    e544163fdad9d01413571581.exe
    (and so on …)

    Note that the file name seems to be generated by the affected sites. However, after monitoring these sites for a few days, we see that the payload changes and we were lucky enough to observe several files that distributed through web sites. One such sample (sha1: 987d17220ee8936d2dfb58b35a6adc17f7141d50) is detected by Trend Micro as TROJ_DOFOIL.WYTU. This malware has characteristics like sandbox checking for its evasion tactic, and process injection:

    zemot4

    Figure 4. Behavioral characteristics of TROJ_DOFOIL.WYTU, seen through sandbox execution in Deep Discovery Analyzer

    Aside from the behaviors mentioned above, we also did code analysis for TROJ_DOFOIL.WYTU and found the following details:

    1. This malware does not perform the intended routines if the following are seen:

    zemot5

    Figure 5. Screenshot of listed software

    These refer to actual software:

    • v  sbiedll – Sandboxie, a sandbox security software for Windows
    • v  dbghelp – Debug Help Library, commonly used to for debugging when working with portable executable (PE) file format
    • v  qemu – a generic and open source machine emulator and virtualizer
    • v  virtual – commonly used to refer to VirtualBox
    • v  VMware – like VMware Workstation and other similar software from VMware
    • v  Xen – from the Xen Project, an opensource hypervisor

    2. It creates a mutex, which is a hashed computer name +  volume SN

    3. It drops/creates the following files:

    • %Appdata%\{random1}{random2}.exe
    • StartMenu\Programs\Startup\{random1}.lnk

    Where {random1} and {random2} are generated from hashed computer name

    4. Once active, it connects to the following URLs:

    • hxxp://kilopinkad[.]com/bimforum
    • hxxp://bulbushkinho[.]org/bimforum

    It also sends the following via HTTP request:

    &cmd={getload or grab or getproxy}
    &login={computer name hashed}{volume SN}
    &bits={value}
    &file={value}
    &run=ok
    &sel={malware version} –> ffbot
    &ver={malware version} –> 5.1
    &r=

    zemot6

    Figure 6. HTTP request parameters of TROJ_DOFOIL.WYTU

    After a few days, the site changed back to the original benign file (SHA1: 909dc6764355625cb9a98ae45f986439cf3142a6). Note that all file hashes with their detections are mentioned at the bottom of this article.

    As seen above, the exploit kit has the capability to load other malicious software that can be a launch pad of secondary attacks. The initial file that was used (which launched only calc.exe) can be viewed as a preliminary attempt during the first few days of this exploit kit’s discovery.

    Conclusion

    The risk of an exploit kit is that it is designed to serve as a ‘door’ opener of any malicious file: cybercriminals can change the malware payload to any that they wanted.

    We have already seen further evolution of this particular threat. Through the use of  the Trend Micro Smart Protection Network, we are able to examine files, some of which have new reference data that currently refers to an active malware. One example of is TSPY_ZEMOT.

    zemot7

    Figure 7. TSPY_ZMOT malware file

    ZEMOT is a malware family of Trojan downloaders frequently used by other malware, often to stage additional malware payload (secondary infections). It is known to be distributed via exploit kits. Based on our data (starting from October 13), the North American region is the most affected region by TSPY_ZEMOT.

    zemot8

    Figure 8. TSPY_ZMOT distribution according to region

    Trend Micro is closely monitoring this threat for any new developments. Our Smart Protection Network protects users from all threats associated with the FlashPack exploit kit.

    The following are the related hashes for this attack:

    • 987d17220ee8936d2dfb58b35a6adc17f7141d50 (TROJ_DOFOIL.WYTU)
    • 6b944b5a06e1dee2bd64d2a35d5c14b304a5eb35 (TROJ_DOFOIL.WYTU)
    • 41ff7407630e575d2b7544f79e8da3378d367470 (TROJ_DOFOIL.WYTU)
    • 2df93253f1aa7ab6e99660629ff58efeae9acbc3 (TROJ_DOFOIL.WYTU)
    • 12de009d00b5e543c9d0b6542f1b03516b076478  (TSPY_ZEMOT.SMN0)
    • 2e65dea705983a8ae2e9b4eecd42816bf4ef7a3a (TSPY_ZEMOT.SMN0)
    • 8792dc1f6351e103eac4662ad927b00b663ff08f (TROJ_FORUCON.BMC)
     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  

    Cybercriminals and attackers are leveraging Google Drive site and brand to go under the radar and avoid detection. Just last week, a targeted attack uses Google Drive as a means into getting information from its victims. This time, phishers are using a modified version of the legitimate Google Drive login page to steal email credentials. This attack can be considered an improved version of attacks seen earlier this year, which asked for multiple email addresses.

    Fake Google Drive Site

    Users may receive an email that contains links that lead to the spoofed Google Drive site.


    Figure 1. Spammed message containing links to fake site

    The phishing site allows user to log in using different email services, which is highly unusual as Google Drive only uses Google credentials. The site also has a language option that does not work.


    Figure 2. Fake Google Drive site

    To trick the user into thinking nothing suspicious is afoot, the phishing site redirects the user to a .PDF file from a legitimate site about investments. However, this redirection to a site about investments may still raise suspicions as nothing in the email indicates the specific content of the “document” is related to finances.


    Figure 3. After logging in, users are redirected to a legitimate site

    Looking at the Code

    A quick look at its source reveals that the Chrome save tag can be seen. This means the phish author may have saved the source of the legitimate Google Drive login page and added malicious code. And since this site recycled code from Google Drive, all the checkers for proper entries are still in place. The phishing site will only accept email addresses in the proper format (e.g., <accountname>@<serviceprovider>.com). This is a marked difference from the earlier phishing pages, which accepted anything, even gibberish.


    Figure 4. Code of phishing page reveals recycled code from Google Drive

    If the user clicks the Sign In button, the credentials and the mail service are sent to a specific URL.


    Figure 5. This screenshot shows all the related activity in the scheme, from the phishing page to the stolen information to the redirection

    The phishing site appears to be a Chinese sports forum, indicating it may have been compromised.


    Figure 6. Compromised Chinese site

    Propagating Through Phishing

    Judging from the screenshot below, cybercriminals are using the phished accounts to get more victims. It appears that this campaign must have been operating for at least three months now.


    Figure 7. Phishing victims discuss how their accounts were used to spread the link

    Mobile Users, Also Affected

    Based on our investigation, this attack will also work on mobile devices. When users clicked the “Sign in” button, the PDF file download is prompted and the users’ credentials are sent out to the cybercriminals.

    google_drive_fig8

    Figure 8. Screenshot of PDF prompt download in mobile devices

     

    The following URLs, which are related to this attack, lead to https://ad[.]bfopay[.]com/pdf/doc2014/action.php:

    • http://www[.]86579[.]net/pdf/doc2014/
    • http://www[.]86579[.]net/pdf/doc2014/action.php

    It should be noted that as of this writing, all these URLs are inaccessible.

    Protecting User Data

    Users should exercise caution when opening emails, even those from known contacts. Avoid clicking links that are embedded in emails. Users can also check first by hovering their mouse over the link; doing so can reveal the true URL of the link in the status bar.

    Users can also check the legitimacy of the site before sharing any personal data, be it login credentials or contact details. They can check if the site address has any discrepancy (misspellings, different domain names) from the original site (e.g., <sitename.com> versus <sitename.org>). They should also check the security of the site before sharing any information. One rule of thumb is that sites that use HTTPS are more secure than those that don’t.

    Trend Micro protects users from this threat via its Smart Protection Network that blocks this phishing page thus preventing the risk of having user information stolen. Mobile users are also protected from this threat as our mobile products also block the malicious links.

    We have notified Google about this phishing page.

     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  



     

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