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


  • Recent Posts

  • Calendar

    April 2015
    S M T W T F S
    « Mar    
     1234
    567891011
    12131415161718
    19202122232425
    2627282930  
  • Email Subscription

  • About Us

    The URSNIF malware family is primarily known for being a data-stealing  malware, but it’s also known for acquiring a wide variety of behavior. Known URSNIF variants include backdoors (BKDR_URSNIF.SM), spyware (TSPY_URSNIF.YNJ), and file infectors (PE_URSNIF.A-O).

    December 2014: Rise in URSNIF infections brought about by file infection routines

    In December 2014 we discussed a rise in URSNIF infections, primarily in North America,  which were due to the addition of file infection to URSNIF’s routines.

    The virus inserts the host file into its resource section, instead carrying out typical file infection routines like patching host files (via inserting malicious code). These variants targeted the following files:

    February 2015: Another URSNIF outbreak seen

    The February outbreak showed that the malware widened its scope and improved its stealth mechanism. The URSNIF variants are detected as PE_URSNIF.B-O and PE_URSNIF.B.

    It uses strings already found in legitimate system files for its properties such as its file name, folder name, and registry entries. This is done to hide itself alongside other legitimate system files. The file names it uses are a combination of legitimate system file names; for example, the malware will name itself cmdlnsta.exe, a combination of legitimate file names cmdl32.exe and rwinsta.exe. URSNIF was known to exhibit this behavior before it became a file infector.

    It also injects its code separately into each target process, perhaps to avoid memory scanners. We also noted that the hardcoded strings in this URSNIF wave are the same ones found in the December variants.

    March 2015: URSNIF variants seen infecting more file types

    URSNIF variants seen this month (PE_URSNIF.E-O and PE_URSNIF.E) have further widened their scope. This new wave now infects more file types, including Microsoft Office documents, spreadsheets, and presentation files. It uses strings from system files (as the earlier variants did), and uses existing folder names to name the dropped files in order to trick fool users into running them. This technique was not particularly effective, as it did not hide the original folder.

    The table below compares the recent URSNIF variants:

    Pre-file infector December 2014 February 2015 March 2015
    Infected files None *.PDT, *.MSI, *SETUP*.EXE *.PDF, *.MSI, *.EXE *.PDF, *.MSI, *.EXE, *.PPT, *.PPTX, *.DOC, *.DOCX, *.XLS, *.XLSX
    Name used in removable drive propagation None Temp.exe Temp.exe {Folder Name}.exe
    Use random strings for file names? Yes No Yes Yes
    Inject routines separately? No No Yes No
    Polymorphic? No Yes Yes Yes

    URSNIF’s known hooking functions

    URSNIF is traditionally also known for hooking various executable files in order to monitor browsers. It hooks WS2_32.DLL and KERNEL32.DLL or CHROME.DLL to monitor Google Chrome, NSS3.DLL and NSPR4.DLL to monitor Mozilla Firefox, and WININET.DLL to monitor Internet Explorer. It also monitors other browsers like Opera and Safari.

    Recent URSNIF variants have significantly modified the exact system APIs that it’s been hooking for years. Hooking these APIs allows the malware to perform a wide variety of information theft, such as taking screenshots, by intercepting the data contained in various normal commands. Together with the hooked APIs, this allows for powerful information theft capabilities. The list of hooked APIs is below.

    2012-2013 2013-2014 2014-2015
    InternetReadFile InternetReadFile HttpOpenRequestA
    InternetReadFileExA InternetReadFileExA HttpOpenRequestW
    InternetReadFileExW InternetReadFileExW HttpSendRequestA
    HttpSendRequestA HttpSendRequestA HttpSendRequestW
    HttpSendRequestW HttpSendRequestW HttpQueryInfoA
    HttpOpenRequestA HttpQueryInfoA HttpQueryInfoW
    HttpOpenRequestW HttpQueryInfoW InternetReadFile
    InternetConnectA HttpAddRequestHeadersA InternetReadFileExA
    InternetConnectW HttpAddRequestHeadersW InternetReadFileExW
    InternetQueryDataAvailable InternetConnectA InternetQueryDataAvailable
    InternetConnectW PR_Read
    InternetQueryDataAvailable PR_Write
    PR_Read PR_Close
    PR_Write PR_Poll
    PR_Close PR_Available
    WSARecv LoadLibraryA
    WSASend LoadLibraryW
    Closesocket LoadLibraryExA
    LoadLibraryExW LoadLibraryExW
    ssl_write
    ssl_read
    ssl_close

    URSNIF has been constantly evolving in recent months, showing multiple faces of itself and displaying a wide variety of behavior. It shows no clear signs of dying down, which means that the malware will continue to pose risks to users across various segments.

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

    Early this year Microsoft reported an increase in macro-related threats being used to spread malware via spam. Similarly, we’ve been seeing a drastic increase in spammed emails with attached Microsoft Word documents and Microsoft Excel spreadsheets that come with embedded macros.

    Macros are a set of commands or code that are meant to help automate certain tasks, but recently the bad guys have yet again been utilizing this heavily to automate their malware-related tasks as well. Here are some recent blog posts in which we tackled various macro-based malware:

    Recent spammed emails now spread BARTALEX malware

    A recent sample email pictured below shows a fake Air Canada e-ticket with faulty airline information attached in the form of a .DOC file. Opening the .DOC file leads to a document with a malicious macro. We detect this as W2KM_BARTALEX.EU.

    Figure 1. Fake e-ticket from Air Canada carries a .DOC file with a malicious macro

    Figure 2. Macro warning when opened in Microsoft Word 2010

    W2KM_BARTALEX is the most recent addition to the roster of macro-based malware we wrote about in the past. It serves as a downloader for info-stealing malware like UPATRE and drops files depending on the OS version of the system it affects. Other macro-based malware utilize the macro itself to download other malware while W2KM_BARTALEX drops .bat, .vbs, and .ps1 files to download more malicious files.

    For Windows OSs Vista and later, W2KM_BARTALEX drops a file named adobeacd-update.bat, which executes adobeacd-update.ps1 using the Windows PowerShell® command shell. The PowerShell command was previously abused in another macro-related attack in February this year that involved the malware VAWTRAK.

    Recent wave of macro-related malware—just the tip of the iceberg?

    Common file extensions for macro-related spam we’ve noted in the past include .DOC, .DOCM, and .XLS. Another wave seen in February includes .XLSM (pictured below).

    Figure 3. Latest wave of macro-related spam now include .XLSM file attachments

    Spam with macro-based malware typically make use of social engineering lures like remittance and invoice notifications, emails related to tax and payment slips, payment confirmation, purchase orders, etc. Most of the spammed emails even contain so-called shipping codes in the email subject to appear authentic.

    We may be seeing more things to come for the spam landscape for the rest of the year along with the newest wave of spammed emails that carry W2KM_BARTALEX. While it serves as the latest malware addition, other detections for macro-based malware include X2KM_DLOARDR, W97M_MDROP, X2KM_DRILOD, and W97M_SHELLHIDE. These malware lead to their final malware payloads, which include banking malware ROVNIX, VAWTRAK, DRIDEX, and NEUREVT aka Beta Bot.

    Number of macro-based malware slowly increasing

    The bar graph below offers a quick look into the total spam volume compared against spammed emails that carry malicious macros and UPATRE-related spam. Though we are mostly seeing UPATRE malware attached to spam, macro-based malware in spam have slowly been gaining traction since December 2014 and may continue to do so in the next months.

    Figure 4. Volume of macro-based malware in spam compared against UPATRE malware and the total spam volume

    Best practices

    As always we recommend that users exercise caution when opening email attachments, even those from familiar or known senders. Ignore emails sent from unknown email addresses and especially avoid opening any type of attachments they may have. As an added measure, make sure to enable the macro security features in applications.

    Users are protected from this threat via Trend Micro™ Security software, which safeguards against viruses, phishing, and other Internet threats. Businesses are also protected with Endpoint Security in Trend Micro™ Smart Protection Suite as it offers multiple layers of protection.

    Related hashes:

    • c8683031e76cfbb4aba2aea27b8a77833642ea7d – W97M_MDROP

    With additional input and analysis by Ryan Gardo

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

    Today, personal communication is greatly enabled and enhanced by various messaging apps that provide text messaging, voice calls, photo sharing, and even video chat. These apps are often found in smartphones—devices that have all the features of a desktop computer, plus Wi-Fi, cellular, GPS, and data connectivity.

    Cybercriminals have taken advantage of the convergence of the power of the smartphone and the features of chat apps to lure victims into compromising situations and blackmail them. Our latest paper, Sextortion in the Far East, talks at length about the latest developments concerning online blackmail.

    Sextortion, Old and New

    Sextortion is a form of online blackmail involving persuading a victim into performing sexual acts that are secretly recorded. The attacker then forces the victim to give in to the attacker’s demands by threatening to release the previously recorded acts publicly.

    Previous sextortion incidents had demands that were sexual in nature. Perpetrators would use chat programs to record their victims’ activities and ask for more sexual material as “hush money.” Should victims comply, attackers would often demand more from the victim.

    Our researchers have found that certain gangs in East Asia have improved on the sextortion modus operandi, creating a far more damaging effect on the victims. The new modus operandi involves Android malware that can steal the victims’ contact list and send them to the attackers. Attackers are then able to contact the victims’ families and friends directly—making for a more intimidating threat.

    comparison-of-the-old-and-new-sextortion-modi-operandi

    Figure 1. Comparison of old sextortion scheme to the new one

    (Click to enlarge)

    The techniques aren’t the only things that have changed in the modus operandi. Cybercriminals are now asking for money as payment in lieu of sexual favors. Monetization might seem like a more attractive motive for cybercrooks looking to make bank with this type of blackmail.

    Using Data Stealers

    The Android data stealer’s primary purpose is to retrieve and send victims’ contact lists to the cybercriminals, allowing them to make more effective threats.

    Our investigation revealed the use of four Android data stealer families for sextortion. The malware were classified according to package name. Differences in code and functionality were seen from variant to variant, which suggests ongoing malware development.

    The four variants all contained aggressive techniques. For example, they can intercept and log the victims’ incoming text messages. They can also monitor changes in the infected device’s SMS inbox and prevent victims from receiving new text messages unless they pay up.  They can also prevent victims from receiving calls.

    Sextortion in the Far East and Beyond

    In-depth investigation on various sextortion scams led us to developers in China tasked to create malicious apps and sites using Chinese and Korean. But the incidents weren’t limited to these countries. Our investigation also led us to Japan, where we found victims and bank accounts associated with sextortion scams.

    While our investigation focused on the East Asian region, sextortion cases have also been spotted in other parts of the world. There have been reports in Canada, the UK, and the US.

    The sextortion schemes we uncovered are complex operations that involve people across cultures and nations working together to effectively run a very lucrative business. These once again prove that cybercriminals are not just becoming more technologically advanced— creating stealthier mobile data stealers, using complex stolen data drop zone infrastructures, and outsmarting banks to better evade detection—they are also improving their social engineering tactics, specifically targeting those who would be most vulnerable because of their culture.

    For an in-depth look at our investigations in sextortion, you may read our paper, Sextortion in the Far East.

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

    Mar23
    11:19 am (UTC-7)   |    by

    Recently I discussed how TorrentLocker spam was using email authentication for its spam runs. At the time, I suggested that these spam runs were using email authentication to gather information about victim networks and potentially improve the ability to evade spam filters. DomainKeys Identified Mail’s (DKIM) own specification mentions the possibility of messages with from “trusted sources” and with a valid signature being whitelisted.

    Since then, we’ve received several replies that differ with our findings. One of these was Martijn Grooten at Virus Bulletin, who argued that the use of these techniques was “unlikely to bring any advantage”, and speculated that domain-based message authentication, reporting and conformance (DMARC) may have been used because of pre-configured rented infrastructure.

    While it is possible that this could be the case, we would like to explore the possibility that the usage of email authentication was deliberate.

    Grooten notes that it would be unusual for spammers to use Sender Policy Framework (SPF), and DKIM, as it would only allow spam filters “to be more confident that they are blocking the correct emails.” However, he cited one exception: low-volume spam runs that are trying to look legitimate. TorrentLocker spam runs meet this description. TorrentLocker spam is sent in smaller numbers compared to other threats, and it has a strong interest in trying to look legitimate; it meets the criteria for spam that would use SPF and DKIM. Anecdotal evidence suggests that the delivery rates of TorrentLocker spam are high – it appears to be successfully evading spam filters.

    From the point of view of a spammer, using SPF and DKIM makes perfect sense if it would increase the chances of email delivery. An automated filter based on statistics or Bayesian rules may “learn” that spam with SPF and DKIM is less likely to be spam, and thus increase the chance of delivery. [Footnote: we note that we consider a Bayesian or statistical filter that increases the chance of email delivery based on passing a SPF or DKIM check is a misapplication of email authentication technologies].

    The next issue raised is that DMARC is of little benefit, as spam campaigns will have relatively little time to fix mistakes (as the campaign will soon be over).

    However, TorrentLocker campaigns are ongoing and long-lasting. While specific spam runs may be more limited in duration, overall there is plenty of time for an attacker to learn from any DMARC feedback. A recent joint report by Deakin University and Trend Micro had looked into the ongoing nature of TorrentLocker spam runs for November and December 2014. We found that these spam runs were repetitive in nature, providing plenty of opportunities for the attackers to learn how to improve their attacks.

    In addition, the best-case scenario (from an attacker’s perspective) is that SPF/DKIM feedback can be used to determine the number of recipients of a spam message for certain ISPs. For attacks explicitly designed with heavy social engineering in mind, this information is invaluable. It provided direct feedback into the effectiveness of spam campaigns, which an attacker can then use to improve as necessary. DMARC failure reports can also be useful – for example, uncovering undisclosed list recipients. DMARC can be used to both uncover relationships and security weaknesses. (One example of feedback being sent to attackers: if an email is forwarded by a recipient to a third party, the email address of that party is sent back to the attacker.)

    One issue that is raised is that perhaps the attackers merely used infrastructure that was already set up for SPF/DKIM. However, we noticed that the DMARC policy for multiple IP addresses across different ISPs was changed at approximately the same time. This strikes us as highly unusual, and does not match the expected behavior for rented infrastructure.

    Finally, the following portion of the DMARC specification is pointed out:

    Mail Receivers are only obligated to report reject or quarantine policy actions in aggregate feedback reports that are due to DMARC policy. ... If local policy information is exposed, abusers can gain insight into the effectiveness and delivery rates of spam campaigns.

    We suspect that some local policy information is being exposed, and this is why DMARC has been enabled for these outbreaks. It’s worth noting that DMARC does have a mechanism that includes detailed feedback reports; this was intended for debugging purposes. ISPs and other organizations that implement email authentication should check that information disclosure is only to the extent needed to implement email authentication.

    In conclusion, we believe that there are potential advantages that an attacker stands to gain from using email authentication. In addition, the pattern of behavior suggests that these actions were deliberate on the part of spammers.

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

    Mar22
    9:22 pm (UTC-7)   |    by

    Analysis by Marshall Chen, Yi Lee, and Joe Wu

    Brand owners frequently use SPF and DKIM to protect their brands from email forgery. For example, a brand owner could register the same domain name under multiple top-level domains (TLDs) (such as .com.net.org, etcetera) and announce SPF/DKIM records for all of these domains (even if they were not actively being used). While generally effective, there is one loophole: what about the .gov TLD?

    This loophole was recently exploited in a massive phishing attack against American Express, which started on March 4. The attackers sent out emails that imitated American Express notifications, which contained a link to a phishing site. We identified more than 50 distinct phishing sites used in this spam run. These were hosted on various compromised domains, and all had the format of hxxp://{compromised website}/amerrricaneaxpress/security.html.

    Figure 1. Phishing email (address and phishing URL highlighted)

    So far, this has been a fairly ordinary attack. What we found unusual was one of the supposed email addresses used by the attacker. Three addresses were frequently used in this attack:

    • AmericanExpress@welcome.aexp.com
    • fraud@americanexpress.com
    • noreplay@Americanexpress.gov

    The first two domain names (aexp.com and americanexpress.com) are both registered by American Express, and have SPF/DKIM records published. Emails with these addresses would fail SPF verification, as their IP address would be inconsistent with the authentic ones in the SPF record.

    In the third case, however, no SPF records would be published at all. Only US government bodies can register .gov domains. An SPF verification attempt would return none instead of fail, as there is no SPF record to authenticate at all (the domain is not even registered). Therefore, an email system checking for SPF records would not rule this message to be spam on those grounds alone. This may increase the risk that users would receive these spammed messages.

    Our own sources identified more than 430,000 phishing mails sent from more than 4,600 IP addresses as part of this spam run. These IP addresses were located in more than 120 countries. This spam run took place from March 4 to March 11, with most of the senders located in the United States.

    Figure 2. Distribution of spam-sending IPs by country

    (more…)

     
    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