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

  • Recent Posts

  • Calendar

    December 2014
    S M T W T F S
    « Nov    
  • Email Subscription

  • About Us

    Email authentication and validation is one method that is used to help bring down the levels of spam and phishing by identifying senders so that malicious emails can be identified and discarded. Two frameworks are in common usage today; these are SPF and DKIM.

    1. SPF (Sender Policy Framework): Defined in RFC 7208, SPF provides a mechanism to allow receivers to check that incoming mail from a domain is being sent from a host authorized by that domain’s owner. The list of authorized IP addresses for a domain is published in the domain’s DNS records.
    2. DKIM (DomainKeys Identified Mail): Defined in RFC 6376, DKIM allows mail recipients to check that incoming mail from a domain is authorized by that domain’s owner. A digital signature included with the message can be validated by the recipient using the signer’s public key published in the DNS.

    Recently, DMARC (Domain-based Message Authentication, Reporting and Conformance) has also been used by some sites. This provides extra report mechanisms to domain owners and uses existing SPF and DKIM authentication results. Data from Google indicates that as of last year, half a million domains implement DKIM, 3.5 million domains implement SPF and 80,000 domains implement DMARC.

    Attackers are well aware of these techniques, and are already circumventing these in their email attacks. We will show three cases where attackers were able to bypass these checks and make their emails appear to be legitimate.

    Apple Phishing
    Method: Use a fake user-friendly display name and random email address to bypass email authentication.

    When we check who sent us an email, we actually see two different things: the email address that (supposedly) sent the email (in the form, and a display name that is meant to be read by humans (i.e., the name of the person sending the email). However, the two are set independently of each other and don’t have to be related at all. This is frequently seen in spam and phishing emails.

    For example, we observed two types of phishing emails that both pretend to be from Apple. In the first type, the display name is iTunes, with the sending address being an address.

    Figure 1. Phishing message with forged sender address

    These emails will fail authentication if an SPF check is performed (as it was not actually sent from an email server).  However, if the situation is slightly different – the sending address is not modified, but the display name is still fake, some email clients will display the (fake) phishing address instead, as seen below:

    Figure 2. Mail client showing only the display name

    Other clients will show the email address correctly.

    Figure 3. Mail client displaying sending address

    We have blurred out the name of the ISP in question, but it is clear that it is not It is a large ISP, which we’ll call

    This email would pass email authentication. The email could be sent by the ISP’s mail servers, so it would pass SPF. DKIM would also pass, as the e-mail would appear to be from a address. Due to above, it may also pass DMARC checks.

    While we used an (obsolete) mail client to demonstrate the flaw, it is worth noting that mobile email clients generally do not show the actual sending address, only the display name.

    Australia Post
    Method: Use a similar domain to the target domain and set up their own SPF/DKIM authentication. Passing these will make the email more credible, increasing the chance of delivery.

    Fundamentally, email authentication merely assures that the email came from the domain that it says it came from. It does not say anything about the reputation of the organization that sent it.

    Attackers are currently creating domains that appear to be from the target organizations and set up their own email authentication. Organizations that increase the chance of delivery for email that merely pass an email authentication check are making a dangerous choice, as this can lead to serious security problems. A reputation check must also be made.

    Consider the email below:

    Figure 4. Email supposedly from Australia Post

    The email is supposedly from the Australian email provider Australia Post. The domain name used sounds like a plausible domain for the company, and is slightly similar to its actual domain A user may believe that this email is real and click on the phishing link.

    The attacker set up SPF and DKIM policies on the domain they created. If an organization automatically lets through email that has passed SPF and DKIM checks, users within that organization would be able to see this email and be led to the malicious sites.

    The SPF record of is below:

    ;; ANSWER SECTION:            3600    IN      TXT     "v=spf1 ip4: a mx ~all"

    ;; AUTHORITY SECTION:            3373    IN      NS            3373    IN      NS

    The DKIM record of is below:


    Fake speeding camera notice
    Method: Use a domain similar to the legitimate government domain and a modified display name to fool users. Set up an SPF policy to ensure phishing emails pass authentication and increase mail credibility.

    This particular case involved phishers sending users a fake speeding camera notice, saying they had exceeded the speed limit and they had to “act now” to avoid costs.

    Like the previous case, the supposed sender and address are both designed to plausibly sound legitimate. The sender is supposedly the “Office of State Revenue”, with the email addresses’s domain ( also sounds plausible when first seen. However, this is actually a domain under the control of the phishers.

    Figure 5. Fake penalty notice email

    Like the previous case, this domain is set to have its own SPF policy. They also wanted to increase the email’s credibility through the email authentication. The email’s headers note that it passed SPF (as expected, since the whole domain is under the control of attackers):

    Received-SPF: Pass ({recipient mail server}: domain of designates as
    permitted sender) identity=mailfrom;
    receiver={recipient mail server};
    x-conformance=sidf_compatible; x-record-type=”v=spf1″


    Email authentication is already a part of email server best practices, and properly implemented it represents a valuable solution to some phishing attacks. However, it is not a universal solution to email phishing; as this post demonstrates it can be bypassed.

    Authentication solves several specific issues related to email, but other problems are completely out of scope. Attackers know this, and have designed some of their attacks accordingly. Perversely, they are actually using authentication to improve the quality of their campaigns.

    E-mail providers (such as ISPs) and organizations that run their own e-mail servers (like large companies) need to understand that other e-mail solutions – particularly those based on content filtering – are still a necessary part of email solutions.

    End users need to keep in mind two things:

    • The display name and address in an email can be easily forged by a phisher. If an email’s content is already suspicious, just looking at the “From” field will not be conclusive, as this field can be modified too.
    • Links in email are frequently suspicious. Unless you are certain that the links in question are from really do go to an organization’s legitimate site (and not a plausible-sounding but fake one), as much as possible, you should not click on these sites.

    We will continue to monitor these new email threats in order to protect our users as they appear.

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

    Security researchers have announced a new “vulnerability” in Linux dubbed “Grinch“, which allows for escalation-of-privilege attacks in versions of Linux that use the polkit toolkit for privilege authorization. However, the true threat of this vulnerability is much more limited.

    The bug was named after the holiday season and the Dr. Seuss character, as some would say that this would have the potential to ruin the season of network administrators. An independent researcher first posted about this vulnerability – which he called PackageKit Privilege Escalation – almost a month ago.

    Whether or not this flaw is actually a real vulnerability is debatable. SANS, in a blog post discussing this flaw, described it as more a “common overly permissive configuration of many Linux systems.” Red Hat even goes further and describes it as “expected behavior“.

    The scope of this vulnerability is very limited. Grinch is not remotely exploitable; it requires that an attacker have physical access the server they want to attack. In addition, the attacker must already have access to an account in the wheels group (i.e., already have elevated privileges as local administrators), polkit must be installed, and the PackageKit package management system must be in use. The barriers to exploitation are significant; in a very real way to exploit this flaw you must already have very high levels of access, making exploiting this “vulnerability” unnecessary.

    While attacks that exploit Grinch directly are unlikely, it does serve as a useful reminder to double-check membership in administrator groups to ensure that only necessary users have this access, as well as cleaning up unsecured polkit configurations.

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

    Around this time in 2013, the most commonly used exploit kit – the Blackhole Exploit Kit – was shut down after its creator, Paunch, was arrested by law enforcement. Since then, a variety of exploit kits has emerged and have been used by cybercriminals.

    The emergence of so many replacements has also meant that there are now some key technical differences between these various exploit kits. In this post, we shall go over some of these differences.

    Exploits used

    Exploits targeting Internet Explorer, Silverlight, and Adobe Flash vulnerabilities were frequently used by exploit kits in the past year. The four vulnerabilities below were some of the most frequently targeted by exploit kits:

    1. CVE-2013-0074 (Silverlight)
    2. CVE-2014-0515 (Adobe Flash)
    3. CVE-2014-0569 (Adobe Flash)
    4. CVE-2014-2551 (Internet Explorer)

    The most notable change in this list is the relative absence of Java vulnerabilities. Exploit kits have been removing Java because of the increasing use of click-to-play for Java applets, rendering Java a far less attractive target for exploits.

    The tables below shows which exploits are in use by exploit kits:

    Table 1. Exploits used by various exploit kits
    (Click thumbnail to enlarge)

    Plugin Detection

    Almost all exploit kits run some sort of software that detect the browser platform a would-be victim is running in order to determine which exploit to send to the user.

    The code necessary to do this varies from one exploit kit to another, and is actually fairly complex due to the number of permutations of browsers and plugins that are possible.

    Two exploit kits – Nuclear and FlashPack – use a legitimate JavaScript library, PluginDetect. This minimizes the work the creators of the exploit kit need to do, as well as providing a complete set of features. However, this also means that this library has known characteristics: this makes it more visible to security vendors looking for sites used by exploit kits.

    By contrast, most exploit kits write their own library to perform this task. This makes detection harder, but it also reduces the capabilities of the libraries. Many of these libraries, for example, will only function under Internet Explorer. The Magnitude exploit kit uses a third method – server-side code – to detect plugins.

    The following table summarizes which libraries are used.

    Table 2. Plug-in detection methods used

    The following screenshot shows the PluginDetect library as used in exploit kits:

    Figure 1. PluginDetect library in use

    The following screenshot shows one of the custom libraries in use:

    Figure 2. Custom library in use

    Antivirus Detection

    A new feature that has been added to exploit kits is the ability to detect installed security software. If certain specific security products are installed, the exploit kit will stop itself from running. Both antivirus products and virtual machine software can be targeted in this manner.

    This behavior is possible due to a vulnerability in Internet Explorer (CVE-2013-7331). This vulnerability allows an attacker to check for the presence of files and folders on an affected system. It was first reported to Microsoft in February 2014, but was only patched in September of the same year as part of MS14-052.

    The following table summarizes the products that each exploit kit detects:

    Table 3. Software products detected by exploit kits

    Obfuscation Techniques

    Exploit kits regularly use various techniques to obfuscate their activity, but some exploit kits have added new techniques. In both of these cases, the attackers are using legitimate tools to obfuscate their files.

    The Angler exploit kit now uses the Pack200 format to help avoid detection. Pack200 is a compactive archive format that was developed by Sun (Java’s original developers) to compress .JAR files significantly. Tools to uncompress these files are provided as part of the Java development kit, but many security products don’t support these formats (so they are unable to scan the said malicious file).

    Figure 3. HTTP request and reply headers

    When compressed, one can see that we do not encounter the “PK” header expected of standard Java files:

    Figure 4. Binary examination of Java file

    Meanwhile, Flash files are also being protected by the FlashPack and Magnitude exploit kits. These use a commercially available tool called DoSWF to hide their files. This tool was meant to allows developers to hide the ActionScript contents of their Flash file from people who would copy or pirate the contents. Unfortunately, this also works against security software, which are unable to decrypt the DoSWF encryption.

    Figure 5. Code calling DoSWF in ActionScript


    The chart below shows the monthly traffic (as measured in number of hits) we detected each month for various exploit kits. No one exploit kit dominated the market, with fierce competition leading to changes in the landscape. Magnitude, Angler, and Sweet Orange were the most frequently encountered kits throughout the entire year.

    Figure 6. Traffic seen to various exploit kits
    (Click thumbnail to enlarge)


    Exploit kit developers have not been idle in the year since the collapse of the Blackhole exploit kit. They have made various improvements that help improve the capabilities of these tools.

    The defenses against these tools on the part of users remains the same. We highly recommend that users implement all updates to their software as is practical, since many of the vulnerabilities targeted by attackers have long been fixed by software vendors.

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

    When I am in the United States I tend to overwork, especially up in the air as many planes today are WiFi-enabled. I just got back from New Orleans, a city with a vibrant atmosphere that I found musically and culturally rich.

    New Orleans was the venue of this year’s Annual Computer Security Applications Conference (ACSAC), which celebrated its 30th anniversary this year. An outstanding program of 47 selected papers (out of 237 submissions) were presented during the three-day conference.

    One of these was our work titled A Security Evaluation of AIS: Automated Identification System. AIS is a cyber-physical system (CPS) commonly used in the marine industry for vessels traffic monitoring and assistance. Given its importance in collision detection, search and rescue operations and piracy prevention, we conducted a unique security evaluation. Our findings show that both the implementation of AIS, as well as the protocol specification, are affected by several threats including spoofing, hijacking and availability disruption.

    More broadly, we expect to see a rise in the number of attacks against cyber-physical systems in the near future. Recent attacks on SCADA systems highlight the importance – and vulnerability – of these important systems.

    This publication concludes our investigation of AIS, as well as our multiple presentations at leading industrial and academic conferences all over the world.

    In addition to the paper which we linked to earlier, we are also making available our presentation slides, as well as the source code of the AIS transmitter we used in this research project. We would like to give special thanks to the forward-looking research team who supported the research in different forms.

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

    We recently found a new banking Trojan which targeted several banks in South Korea. This isn’t the first, though: in June last year, we saw that several online banking threats widened their range and targeted South Korean banks using various techniques.

    Throughout the course of monitoring similar threats, we noticed a new wave of banking Trojans targeting South Korean banks that show unusual behavior, including the use of Pinterest as their command and control (C&C) channel.

    Infection Via Malicious Iframe Injection

    This threat is currently affecting users in South Korea via compromised sites leading to exploit kits. In mid-November, we found an infection chain that involved multiple malicious websites in a single infection.

    To deliver this threat to the user, legitimate sites are first compromised and an iframe tag is injected. This tag redirects users to a second compromised site which hosts an exploit kit, which delivers the banking Trojan to the user. We detect this as TSPY_BANKER.YYSI.

    Once this malware is present on an affected system, users who access certain banking websites using Internet Explorer are automatically redirected to a malicious site. The site contains a phishing page that asks users to input their banking credentials. Users who access the website with other browsers are not affected. (Due to South Korean regulations, users in South Korea generally use Internet Explorer to access local banking sites.)

    Figure 1. Comparison between legitimate banking site and fake banking site

    Below is a list of targeted banking websites that are targeted for information theft:

    • hxxp://
    • hxxp://
    • hxxp://
    • hxxp://
    • hxxp://
    • hxxp://
    • hxxp://
    • hxxp://
    • hxxp://

    How is this redirection done? If the user visits one of the above sites, the malware will instead cause Internet Explorer to load an iframe that loads various phishing pages. The URL of this banking site will vary, depending on the URL of the original site.

    The malware will also spoof the URL in the address bar to make the user believe they are at the legitimate banking site. Upon entering their personal information, they will then be redirected to the fake banking site. In addition to the listed banks, the website of a popular South Korean search engine is similarly modified to open a pop-up window with links to the monitored banks.

    The command-and-control (C&C) routines of this malware are interesting. How does it know which fake site to redirect users to?


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


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