Blog

Information and insight on today's advanced threats from the leader in advanced threat prevention.

All Posts


NGOs: Fighting Human Rights Violations and, Now, Cyber Threat Groups

With so many non-government organizations (NGOs) in operation today around the world, we asked ourselves a question here at FireEye Labs. Who would think about targeting NGOs?  Steal from a nonprofit? It would seem unthinkable to most people. But, as we can see from a few recent examples below, this is a clear reality.

As more NGOs reach out to us, it is clear that the situation for them is not a pretty one. Based on the breaches we have observed in this space, it appears there are more than 15 distinct advanced threat groups active in NGO networks. The sheer volume and variety of threat groups active in NGO environments struck us as unusually high for a single industry and indicates the incredibly difficult threat landscape NGOs face.

Hamstrung by limited budgets to establish strong network defenses and few personnel that understand how and why these threats are materializing, NGOs make a relatively easy target. Even if they aren’t profitable, NGOs use credit cards for donations, transact with cash, store personally identifiable information (PII) and, in some cases, even house intellectual property.  Many NGOs also work on political issues—an inviting target for opponents who want to monitor their communications and activities. Weak defenses and a target-rich environment make NGOs an enticing victim to maliciously motivated threat actors.

Cyber Operations at NGOs: An Intelligence Collection Pursuit?

NGOs — particularly those based in the U.S. — have long been perceived as instruments of U.S. government policy. Regimes with a less-than-favorable view of the U.S. frequently consider NGOs’ work as a rallying point for domestic unrest and political opposition. Three nations that fit this description — China, Russia and Iran — are all rumored or known to have existing and growing cyber operations to support their governments’ political agendas. Data acquired from NGOs via network compromises has the potential to grant these nation-states valuable, predictive insights on key policy topics and NGO programming, as well as intelligence on personnel and their contacts.

Over the last few years, we have observed China-based advanced persistent threat (APT) groups frequently target U.S.-based NGOs. Unsurprisingly, they were organizations with programs that touched on Chinese human rights, democratic reforms, and social issues.  In these instances, data theft was not just limited to documents about NGO programming, but also included documents on grants, legal proceedings, research programs, and even employee communications. The threat actors and recipients of the stolen data were likely able to gain significant insights into the NGOs’ operations, issues, and personnel. Not only were the threat actors better positioned to understand the NGOs’ values and plans, but, more importantly, they could potentially identify in-country contacts for the NGOs. These domestic contacts could face repercussions for their collaboration with the NGO.

NGO

Figure 1: A sample breakout of the types of documents stolen from an NGO

Sought-After Financial Data Goldmine

Because NGOs are often dependent on donations from large donors and dedicated supporters, they maintain or process financial data of potentially great value to cybercriminals who seek to steal PII. This financial information could be used to perpetrate identity theft and other types of criminal exploitation, including the theft of credit card numbers, bank account information, and other PII of wealthy individuals. There are any number of cases of non-profits who were either breached via network compromise or even experienced the physical theft of devices that gave perpetrators access to databases filled with valuable information such as names, addresses and social security numbers. In one instance, a simple website misconfiguration exposed one nonprofit’s database of donors and their personal information.

The acknowledged wealth of many NGO donors likely contributes to the motivations financial threat groups would have in targeting NGOs. FireEye tracks a number of criminal threat groups who conduct network intrusions to obtain data similar to the kind NGOs manage in large quantities. These threat actors may seek financial gain from cyber operations through direct theft of funds or the resale of data they have stolen. Because NGOs maintain valuable financial data, and perhaps other data they perceive to be valuable, criminal threat actors may target these networks with the intent to profit.

Perception of Weak Defenses

When criminals are looking for an easy target, NGOs’ networks may be perceived to be easy pickings. Just as the common thief would rather steal items of value from a house without an alarm than one with, the same is true with advanced threat actors and cybercriminals. NGOs possess information of value that a variety of threat actors desire, and their networks can sometimes be far easier targets than government institutions or large commercial organizations, due to their typically limited resources when it comes to network security and defense.

Although NGOs face a unique landscape when it comes to advanced threats in terms of the sheer number of threat groups targeting them and the widely varying possible impacts of a breach, their operations and needs share many similarities with those of our small- and medium-sized (SMB) customers. To that end, FireEye Labs recommends reviewing our latest SMB-focused white paper for more insight into what the broader threat landscape looks like for NGO-like organizations. A copy of the paper can be found here: http://www2.fireeye.com/smb_five_reasons_wp.html.

If an Android Has a Heart, Does It Bleed?

The OpenSSL Heartbleed vulnerability “allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read” [1]. Heartbleed surprised the public by allowing attackers to steal sensitive information from vulnerable websites by sending crafted SSL heartbeat messages. However, due to the fact that servers can send heartbeats to clients as well, malicious servers can, in turn, attack vulnerable clients and steal sensitive information. For the Android platform, we find that roughly 150M downloads of Android apps contain OpenSSL libraries vulnerable to Heartbleed.

Currently there are about 17 antivirus apps on Google Play branded as “Heartbleed detectors”. Six of them scan the OpenSSL library belonging to the Android platform for vulnerabilities. Unfortunately, this method isn’t sufficient for detecting the Heartbleed vulnerability on Android. Except in limited Android versions (mainly 4.1.0-4.1.1), the majority of Android platforms are not vulnerable, as most versions use OpenSSL libraries that are not vulnerable or simply have the OpenSSL heartbeat functionality disabled.

However, Android apps frequently use native libraries, which either directly or indirectly leverage vulnerable OpenSSL libraries. Therefore, even though the Android platform itself is not vulnerable, attackers can still attack those vulnerable apps. They can hijack the network traffic, redirect the app to a malicious server and then send crafted heartbeats messages to the app to steal sensitive memory contents.

We studied apps with vulnerable OpenSSL libraries and confirmed this attack. Most of the vulnerable apps are games, and some are office-based applications. Although there is not much valuable information in the game apps, attackers can steal OAuth tokens (access tokens and refresh tokens) to hijack the game accounts; as such, the information might be useful for hijacking those linked social network accounts with incorrect configurations. Office apps vulnerable to Heartbleed are much more dangerous due to further potential data leakage.

During our investigation of the office apps that contains a vulnerable version of OpenSSL, we were surprised that they were not vulnerable to the Heartbleed attack. How could it be? A deeper look shows that these apps either make a mistake in the native code linkage, or just contain dead code. Therefore, when they try to invoke SSL functions, they directly use the non-vulnerable OpenSSL library contained within the Android OS, instead of using the vulnerable library provided by the app. The linkage mistake is common for Android applications built with native code. As such, the side-effect of this mistake helps reduce the apps’ overall risk profile.

Within the 17 Heartbleed detector apps on Google play, only 6 detectors check installed apps on the device for Heartbleed vulnerability. Within the 6, 2 report all apps installed as “Safe”, including those we confirmed as vulnerable. One detector doesn’t show any app scan results and another one doesn’t scan the OpenSSL version correctly. Only 2 of them did a decent check on Heartbleed vulnerability of apps. Although they conservatively labeled some non-vulnerable apps as vulnerable, we agree it is a viable report which highlights both the vulnerabilities and the linkage mistakes. We’ve also seen several fake Heartbleed detectors in the 17 apps, which don’t perform real detections nor display detection results to users and only serve as adware.

On April 10th, we scanned more than 54K Google Play apps (each with over 100K downloads) and found that there were at least 220 million downloads affected by the Heartbleed vulnerability. We have notified some of the app developers and library vendors about the OpenSSL Heartbleed vulnerability found in their products. Fortunately, it seems most app developers and library vendors take Heartbleed seriously, as we have started to see apps updated with proper fixes. The total number of vulnerable apps download has since decreased to 150 million on April 17th.

[1] Vulnerability Summary for CVE-2014-0160

Dissecting Advanced Attacks: FireEye Labs and the 2014 DBIR

Each year, a number of reports are released on the changing state of the threat landscape and where cyber security is headed. Like our annual Advanced Threat Reports and M-Trends Reports, Verizon has released the “Data Breach Investigations Report” (DBIR), which is considered by many in the security industry as the most comprehensive guide to data breaches. This year, owing to the large number of and deep insights into cyber espionage and advanced persistent threat campaigns that we track, Verizon tapped the FireEye Labs team to contribute to the latest version of the report.

The 2014 DBIR takes a comprehensive look into all forms of attacks from the past year and, as we have always done with our investigations, newly examines the incident patterns of attacks. This type of analysis is what we like to call behavioral or contextual analysis of a breach lifecycle and is invaluable in understanding advanced threats that are not readily apparent in traditional detection methods.

To help with this initiative, FireEye Labs contributed information on several advanced attacks uncovered in 2013 that were likely driven by cyber espionage motives. Information on the individual attacks can be found here:

To view a full version of the Verizon DBIR, you can download a copy here: http://www.verizonenterprise.com/DBIR/. Also, be on the lookout for the release of our European Advanced Threat Report next week.

InfoSecurity Europe 2014: Cybersecurity for the Masses

InfoSecurity Europe is the biggest security event and most important date on the calendar for information security professionals across Europe. The event aims to break through the noise and provide the European audience with all the necessary information to better understand cyber threats to their networks. Join FireEye experts and learn how to prepare for a new frontier of advanced attackers:

  • Visit stand J60 and check out FireEye’s Geek Bar. A certified geek will analyze your portable device to determine if you’ve received any malware. The live demonstration can prove useful to better understand and identify potential threats to your network.
  • Join FireEye Director of Technology Strategy Jason Steer, SI Technical Lead Simon Mullis, and Greg Day, EMEA CTO among others, as they discuss the threat landscape and walk attendees through interactive, educational workshops and presentations. Join us on our stand to understand the threat landscape – presentations every 30 minutes all 3 days.
  • Senior Director of Market Research at FireEye Rob Rachwald will be speaking on Wednesday, April 30, where he’ll cover the nitty gritty of sandbox evasion. Mr. Rachwald’s presentation will help the audience gain an overview of various sandboxing techniques, understand current sandbox bypass methods, as well as identify best practices to optimize malware detection.
  • FireEye SVP and COO Kevin Mandia will make a special appearance on Wednesday, April 30 to discuss FireEye’s recent acquisition of Mandiant, as well as to discuss today’s changing threat landscape.
  • The FireEye team will also release the latest findings from Mandiant’s annual M-Trends report and European ATR research report. The results offer visibility into motives, approaches, and different skill levels of attackers both in Europe and around the globe.
  • Participate in FireEye’s photo contest and have the opportunity to win an Apple® gift card worth £250! Look around London and you will see FireEye branded taxis zipping around the city. Grab your camera or smart phone and take a picture of you and the taxi. Submit your photo to helena.brito@fireeye.com and your photo will be posted to FireEye’s Facebook page. You will also be automatically entered into the contest.

FireEye Taxi

Stop by Stand J60 to learn more about the newly expanded FireEye Security Platform, which integrates expertise from Mandiant and is designed to give customers one solution to go from threat alert to remediation. We’ll have live demonstrations of all the new FireEye products. In the mean time, be sure to follow @FireEye for the latest threat research and updates from the company.

We hope to see you in London the week of April 29 through May 1. If you are unable to attend, check back on the blog for interviews and insights from the conference. You can register for a free entry ticket by clicking HERE – your badge will arrive with “FireEye Guest” printed on the bottom.

The Economics of Security

During many of my customer meetings, I often hear security leaders ask the question: “What technology could I remove to free up budget to enable the implementation of FireEye?”

My natural response is to inquire how and when they assess the real value, not the ROI, they get from their existing solutions. Whilst every security solution provides an “ROI” – often a metric based around industry data on how many security “events” they return – this assessment should not focus on noisy “ROI,” but which solution gives your company the most valuable information. Considering the nature and pace of change when it comes to malware and advanced attacks, this is something to validate regularly and involves looking at more factors than a generic ROI tool can factor in.

In a small survey of about 30 European CxOs we ran in December 2013, I asked the question of how they validated the value of security controls, and, surprisingly, at least 36 percent still didn’t conduct any annual assessment.

doyouvalidate

Having spent quite a bit of time looking at analyst models and what exists publically today, the fact that some still don’t conduct these assessments emphasizes that there still isn’t a well-defined model to correlate business value against investment for security solutions.

Take, for example, the outsourced model where Key Performance Indicators (KPIs) are typically established. Too often I hear anecdotal examples where KPIs were based on incidents found; this simply encourages dialing-up the technologies being monitored so that every incident – malicious or not – is tracked and reported, drowning out the ability to identify real threats.

For example, companies investing in big data solutions that gather and equate the millions to billions of events delivered each week to value. However, because they are too resource-constrained to convert these into actionable data, the true value is not extracted and, because doing so in a resource-constrained environment takes so long, the return here would seem extremely poor to a sheer numbers-based evaluation.

However, if the value of said product is measured by the actions taken to mitigate a major security event, that extra time spent executing on a few major items rather than not executing on a large amount of items becomes invaluable to the business. As such, we must blend together the quantitative metrics such as the costs of a solution (capex & opex), incident levels and overlay those values with qualitative insight. These evaluation criterion would look something like the below:

opexcapex

 

  • Noise to incident ratio – What is an acceptable incident to noise (i.e., false positives or irrelevant alerts) ratio?
  • Volume versus impact - We can alert and respond to a million incidents but it’s the one outage of a critical system or breach of business IP or customer records will have a far more significant impact on the business.
  • How actionable is the solution – Critical to an alert is timeliness, how long does it take to identify an incident and what level of human skills are required to interpret the results. Spotting a breach is hard, doing the forensics is harder, and understanding the motives of the attacker is harder still.
  • Business outcome – Did a technology mitigate, reduce or simply delay the business impact. Did it tick a compliance control to avoid penalty fees or did it protect IP & customer data?

In the coming months we are going to delve into the economics of security in greater detail.  Whilst there are many tools out there discussing security process and ROI tools showing generic return, we all have limited budget and resources. With the scale and scope of security tools continues to grow we must innovate our thinking, in how we each quantify the value of our investments.

 

 

Crimeware or APT? Malware’s “Fifty Shades of Grey”

Some cybercriminals build massive botnets to use unsuspecting endpoints for spam, distributed denial-of-service (DDoS) attacks, or large-scale click fraud. With the aid of banking Trojans, other cybercriminals create smaller, specialized botnets that focus on stealing bank credentials and credit card information.

Remote access tools, or RATs, are an integral part of the cybercrime toolbox. For example, a recent FireEye investigation into XtremeRAT revealed that it had been propagated by spam campaigns that typically distribute Zeus variants and other banking-focused malware. This tactic may stem in part from the realization that compromising retailers can net millions of credit card numbers in one fell swoop.

Malware designed to compromise point-of-sale (POS) systems is not a new phenomenon. But we have seen a recent surge in malware that specifically targets these systems (e.g. Chewbacca, Dexter, BlackPOS and JackPOS). Moreover, POS malware is being deployed in an increasingly targeted manner. For example, some attacks against retailers have been characterized as “APT style” attacks —  a designation traditionally reserved for malware-based espionage sponsored on some level by nation-states.

The extent to which such attacks are targeted, and not opportunistic, is unclear. The attackers could be singling out specific retailers in advance. Or they could be targeting an entire industry, simply capitalizing on opportunities that arise.

In this blog post, we examine one case that clearly illustrates the nature of this problem.

Continue reading »

Occupy Your Icons Silently on Android

FireEye mobile security researchers have discovered a new Android security issue: a malicious app with normal protection level permissions can probe icons on Android home screen and modify them to point to phishing websites or the malicious app itself without notifying the user. Google has acknowledged this issue and released the patch to its OEM partners.

Normal vs. Dangerous Permissions: A Background

Android Open Source Project (AOSP) classifies Android permissions into several protection levels: “normal”, “dangerous”, “system”, “signature” and “development” [1][2][3].

Dangerous permissions “may be displayed to the user and require confirmation before proceeding, or some other approach may be taken to avoid the user automatically allowing the use of such facilities”. In contrast, normal permissions are automatically granted at installation,  “without asking for the user's explicit approval (though the user always has the option to review these permissions before installing)” [1].

On the latest Android 4.4.2 system, if an app requests both dangerous permissions and normal permissions, Android only displays the dangerous permissions, as shown in Figure 1. If an app requests only normal permissions, Android doesn’t display them to the user, as shown in Figure 2.

Figure 1. An Android app asks for one dangerous permission (INTERNET) and some normal permissions (Launcher’s READ_SETTINGS and WRITE_SETTINGS). Android doesn’t notify the user about the normal permissions.

Figure 1. An Android app asks for one dangerous permission (INTERNET) and some normal permissions (Launcher’s READ_SETTINGS and WRITE_SETTINGS). Android doesn’t notify the user about the normal permissions.

Figure 2. An Android app asks for normal permissions (Launcher’s READ_SETTINGS and WRITE_SETTINGS) only. Android doesn’t show any permission to the user.

Figure 2. An Android app asks for normal permissions (Launcher’s READ_SETTINGS and WRITE_SETTINGS) only. Android doesn’t show any permission to the user.

Normal Permissions Can Be Dangerous

We have found that certain “normal” permissions have dangerous security impacts. Using these normal permissions, a malicious app can replace legit Android home screen icons with fake ones that point to phishing apps or websites.

The ability to manipulate Android home screen icons, when abused, can help an attacker deceive the user. There’s no surprise that the com.android.launcher.permission.INSTALL_SHORTCUT permission, which allows an app to create icons, was recategorized from “normal” to “dangerous” ever since Android 4.2. Though this is an important security improvement, an attacker can still manipulate Android home screen icons using two normal permissions: com.android.launcher.permission.READ_SETTINGS and com.android.launcher.permission.WRITE_SETTINGS. These two permissions enable an app to query, insert, delete, or modify the whole configuration settings of the Launcher, including the icon insertion or modification. Unfortunately, these two permissions have been labeled as “normal” since Android 1.x.

As a proof of concept attack scenario, a malicious app with these two permissions can query/insert/alter the system icon settings and modify legitimate icons of some security-sensitive apps, such as banking apps, to a phishing website. We tested and confirmed this attack on a Nexus 7 device with Android 4.4.2. (Note: The testing website was brought down quickly and nobody else ever connected to it.) Google Play doesn’t prevent this app from being published and there’s no warning when a user downloads and installs it. (Note: We have removed the app from Google Play quickly and nobody else downloaded this app.)

Lastly, this vulnerability is not limited to Android devices running AOSP. We have also examined devices that use non-AOSP Launchers, including Nexus 7 with CyanogenMod 4.4.2, Samsung Galaxy S4 with Android 4.3 and HTC One with Android 4.4.2. All of them have the protection levels of com.android.launcher.permission.READ_SETTINGS and WRITE_SETTINGS as “normal”.

Google acknowledged this vulnerability and has released the patch to its OEM partners. Many android vendors were slow to adapt security upgrades. We urge these vendors to patch vulnerabilities more quickly to protect their users.

References:

  1. http://developer.android.com/guide/topics/manifest/permission-element.html
  2. https://android.googlesource.com/platform/frameworks/base/+/master/core/res/AndroidManifest.xml
  3. https://android.googlesource.com/platform/packages/apps/Launcher2/+/master/AndroidManifest.xml

Annual M-Trends Report Looks Beyond the Breach

Since 2010, Mandiant’s annual threat report, “M-Trends” has provided the industry with in-depth analysis and insight based on hundreds of advanced threat investigations conducted during the previous calendar year for the U.S. government, the defense industrial base and commercial organizations. As a leader in combating advanced threats, FireEye stresses the continuous education that needs to take place in order to be one step ahead of attackers. That is why it is with great excitement that I present the fifth installment of M-Trends.

2013 was an explosive year for the cybersecurity industry; a result of Mandiant’s APT1 report, The New York Times breach, and other organizations coming to the forefront to openly discuss their own incidents. In addition, President Obama discussed concerns about cyber-attacks in his annual State of the Union address. This was a huge step for the industry in terms of bringing advanced attacks to the forefront of the nation, and the world’s, attention.

This year’s report compiles incident response trends from hundreds of clients in more than 30 industry sectors. Some highlights include:

  • The time it takes to detect a compromise continues to improve
    The median number of days it takes an organization to discover a network breach dropped to 229 days in 2013 from 243 in 2012. This improvement is incremental relative to the drop from 416 days in 2011. However, organizations can unknowingly be breached for years. The longest time an attacker operated undetected in a network before being discovered was six years and three months in 2013.
  • Organizations are yet to improve their ability to detect breaches
    In 2012, 37 percent of organizations detected breaches on their own. This number dropped only minimally, to just 33 percent in 2013.
  • Phishing emails largely look to capitalize on trust in IT departments
    44 percent of the phishing emails observed in attacks investigated by Mandiant sought to impersonate the IT departments of the target’s workplace. The vast majority of these emails were sent on Tuesday, Wednesday and Thursday.
  • Political conflicts increasingly have cyber components that impact private organizations
    In the past year, Mandiant responded to an increased number of incidents where political conflicts between nations spawned cyber-attacks that impacted the private sector. Specifically, Mandiant investigated incidents where the Syrian Electronic Army (SEA) compromised external-facing websites and social media accounts of organizations with the primary motive of raising awareness for their political cause.
  • Suspected Iran-based threat actors conduct reconnaissance on energy sector and state governments
    Multiple investigations of suspected Iran-based network reconnaissance activity indicates that threat actors are actively engaging in surveillance activities at energy sector companies and state government agencies. While these suspected Iran-based actors appear less capable than other nation-state actors, nothing stands in the way of them testing and improving their capabilities.

Click here to request a copy of the report.

Let us know your thoughts by leaving a comment below.

DLL Side-Loading: Another Blind-Spot for Anti-Virus

Last month, I presented a talk at the RSA USA Conference on an increasingly popular threat vector called “Dynamic-Link Library Side-Loading” (DLL Side-Loading). As with many vulnerabilities, this exploit has existed for a rather long time and is the result of Microsoft looking to make binary updates easier for Windows developers through the Windows side-by-side (WinSxS) assembly feature.

Now, though, advanced persistent threat (APT) developers are using the innocuous DLL Side-Loading method to sneak malware past anti-virus (AV) scanners as the infected files run in-memory. In doing-so, the malicious payload is using a benign application to be built in memory, meaning that the malware does not sit running in the file system where AV scans take place. In the figure below, you can see an example of how this all plays out:

DLLpic

For a real-life example: in 2013, attackers exploited the executable originally developed by Fortune 50 company using this technique in a highly targeted attack. In such an attacks, the malware places a spoofed, malicious DLL file in a Windows’ WinSxS directory so that the operating system loaded the spoofed DLL instead of the legitimate file. Furthermore, because the file in-question was white-listed by hash in a public database, AV simply ignores it altogether.

In response to the growing use of DLL Side-Loading in APTs, we have developed a full paper that describes the history of DLL Side-Loading and its role in the malware and software engineering arenas which you can review here: http://www.fireeye.com/resources/pdfs/fireeye-dll-sideloading.pdf

 

 

Real World vs Lab Testing: The FireEye Response to NSS Labs Breach Detection Systems Report

Today, NSS Labs released a report detailing the performance of several vendors’ ability to detect advanced attacks.  We declined to participate in this test because we believe the NSS methodology is severely flawed. In fact, the FireEye product they used was not even fully functional, leveraged an old version of our software and didn’t have access to our threat intelligence (unlike our customers).  We did participate in the BDS test in 2013 and at that time we also commented on the flaws of the testing methodology.  In fact, we insisted that the only way to properly test was to run in a REAL environment.  NSS declined to change their testing methodology so we declined to participate in the most recent test, results of which have been published today. When NSS tested our product a year ago, they used a sample set that included 348 total samples.  FireEye detected 201 of 348 total samples.  Of the 147 “missed” samples:

  • 11 were non-malicious.
  • 19 were corrupted (as to why other vendors detected these because some vendors scored higher – close to 100% – means that their detection engines are based on hashes which will match regardless of whether the sample is malicious).
  • 117 were duplicates (as to why FireEye didn’t receive credit for detecting these, we never received a response from NSS).

Clearly, nobody could take this approach seriously—it was a major mismatch versus what we see in the wild.

Understanding advanced threats still represents a black hole for many in today’s security industry. The test unfortunately perpetuates a general failure by many to fully understand and appreciate the inner workings of advanced threats that continue to plague organizations despite millions invested in legacy security technologies. In this case, the test contained a number of flaws that security professionals should thoroughly understand before taking these results at face value. 

Issue #1:  Poor sample selection.   Specifically:

  • NSS mostly relied on VirusTotal to download payloads (clear text executable files).  The NSS sample set doesn’t include Unknowns, Complex Malware (Encoded/Encrypted Exploit Code & Payload), and APTs.   Almost by definition, APTs use new or updated code to bypass detection, which is standard procedure.  However, NSS used a known corpus of malware.  Advanced threats are in, out, and cleaned-up in minutes.  In the past, the malware samples used in the NSS tests were available on VirusTotal (an aside: the oldest sample on VirusTotal is from 2006 and the median sample age is 17.2 months).  By contrast, when tests specifically leverage malware samples that are new and unknown, antivirus detection rates fall dramatically.  For example, the Imperva study found that antivirus detected only 5% of malware.  The other vendors in the NSS report are built for detecting known malware.  By relying on VirusTotal, NSS missed out on AK-47s and spent time analyzing pea shooters.
  • Even for Payloads, NSS doesn’t perform Forensics Analysis to understand if the sample is malicious, goodware or corrupt (can’t execute).  NSS gives a positive score as long as a vendor sees the sample on the wire, even if the sample is not actually malicious.

 

Issue #2:  Differing definitions of advanced malware: Vendors and test agencies differ in how they define advanced malware. The NSS test confused Adware, Spyware, & APTs and accounted for Adware and Spyware as APTs.  For instance, some of the NSS tests expected Adware to be classified as malware.  In this series of tests, Adware that changes the home page of the browser, but does not infect the system in any other way, must be flagged as malware by a product in order to receive a positive score. FireEye solutions wait for true malicious behavior to avoid false alerts.  In the aforementioned case, the page load of the new home page would be analyzed to identify if the change was truly malicious or not.

Issue #3:  Poor test methodology. Specifically, the NSS test:

  • Doesn’t account for the use of zero day exploits.  There were no zero day exploits in the test sample. This is difficult to do.  Testing for zero days requires having a zero day on hand or developing one yourself, which is expensive.  Finding new malware that utilizes zero day exploits is where FireEye thrives.  In 2013, we found 11 exploitable zero days as well as countless malware campaigns used in cyber espionage, warfare or crime.  This year, we have already uncovered two zero days.
  • Did not have access to our security intelligence in the cloud.  Unlike our customers, the FireEye appliances were NOT connected to our Dynamic Threat Intelligence cloud to get latest content updates, virtual machines and detection capabilities.

We respect NSS and the work they do—especially for IPS – and their testing methodology for BDS is also more suited to testing IPS products. However, we believe the issues we identified with their evaluation of advanced threats are indicative of the security industry’s broader lack of knowledge regarding sophisticated attacks. FireEye is designed to supplement legacy signature and reputation based technologies to protect against advanced threats—and the NSS tests didn’t properly gauge our capabilities.  Our product’s efficacy is proven by how well we protect customers in real-world deployments. Consider that in 2013, FireEye:

  • Found 11 exploitable zero day vulnerabilities, with two uncovered so far in 2014.  (By comparison, among the top 10 cyber security companies ranked by security-related revenue, only 2 other zero-day vulnerability were reported in 2013.)
  • Tracked more than 40 million callbacks.
  • Tracked more than 300 separate APT campaigns.
  • Deployed more than 2 million virtual machines globally.

Any lab test is fundamentally unable to replicate the targeted, advanced attacks launched by sophisticated criminal networks and nation-states. The best way to evaluate FireEye is for organizations to deploy our technology in their own environment and they will understand why we are the market leader in stopping advanced attacks.  We believe it is erroneous for NSS to compare security efficacy, performance, and cost in the same graphic, because doing so assumes that all three buying criteria are all equally important.  In our experience, security efficacy is much more important than the others.  In fact, most users and vendors are moving toward a malware prevention, detection, and response architecture.

In August 2013, IDC issued a report, Worldwide Specialized Threat Analysis and Protection 2013–2017 Forecast and 2012 Vendor Shares.  This report identified and ranked vendors claiming to stop advanced malware attacks.  FireEye was listed as the top vendor based on market share (38%) compared to the nearest competitor with 14% market share.  The market is voting with dollars based on their real-world experience while under real-world attacks from advanced threats.

Threat Research


Filter by Category:


NGOs: Fighting Human Rights Violations and, Now, Cyber Threat Groups

With so many non-government organizations (NGOs) in operation today around the world, we asked ourselves a question here at FireEye Labs. Who would think about targeting NGOs?  Steal from a nonprofit? It would seem unthinkable to most people. But, as we can see from a few recent examples below, this is a clear reality.

As more NGOs reach out to us, it is clear that the situation for them is not a pretty one. Based on the breaches we have observed in this space, it appears there are more than 15 distinct advanced threat groups active in NGO networks. The sheer volume and variety of threat groups active in NGO environments struck us as unusually high for a single industry and indicates the incredibly difficult threat landscape NGOs face.

Hamstrung by limited budgets to establish strong network defenses and few personnel that understand how and why these threats are materializing, NGOs make a relatively easy target. Even if they aren’t profitable, NGOs use credit cards for donations, transact with cash, store personally identifiable information (PII) and, in some cases, even house intellectual property.  Many NGOs also work on political issues—an inviting target for opponents who want to monitor their communications and activities. Weak defenses and a target-rich environment make NGOs an enticing victim to maliciously motivated threat actors.

Cyber Operations at NGOs: An Intelligence Collection Pursuit?

NGOs — particularly those based in the U.S. — have long been perceived as instruments of U.S. government policy. Regimes with a less-than-favorable view of the U.S. frequently consider NGOs’ work as a rallying point for domestic unrest and political opposition. Three nations that fit this description — China, Russia and Iran — are all rumored or known to have existing and growing cyber operations to support their governments’ political agendas. Data acquired from NGOs via network compromises has the potential to grant these nation-states valuable, predictive insights on key policy topics and NGO programming, as well as intelligence on personnel and their contacts.

Over the last few years, we have observed China-based advanced persistent threat (APT) groups frequently target U.S.-based NGOs. Unsurprisingly, they were organizations with programs that touched on Chinese human rights, democratic reforms, and social issues.  In these instances, data theft was not just limited to documents about NGO programming, but also included documents on grants, legal proceedings, research programs, and even employee communications. The threat actors and recipients of the stolen data were likely able to gain significant insights into the NGOs’ operations, issues, and personnel. Not only were the threat actors better positioned to understand the NGOs’ values and plans, but, more importantly, they could potentially identify in-country contacts for the NGOs. These domestic contacts could face repercussions for their collaboration with the NGO.

NGO

Figure 1: A sample breakout of the types of documents stolen from an NGO

Sought-After Financial Data Goldmine

Because NGOs are often dependent on donations from large donors and dedicated supporters, they maintain or process financial data of potentially great value to cybercriminals who seek to steal PII. This financial information could be used to perpetrate identity theft and other types of criminal exploitation, including the theft of credit card numbers, bank account information, and other PII of wealthy individuals. There are any number of cases of non-profits who were either breached via network compromise or even experienced the physical theft of devices that gave perpetrators access to databases filled with valuable information such as names, addresses and social security numbers. In one instance, a simple website misconfiguration exposed one nonprofit’s database of donors and their personal information.

The acknowledged wealth of many NGO donors likely contributes to the motivations financial threat groups would have in targeting NGOs. FireEye tracks a number of criminal threat groups who conduct network intrusions to obtain data similar to the kind NGOs manage in large quantities. These threat actors may seek financial gain from cyber operations through direct theft of funds or the resale of data they have stolen. Because NGOs maintain valuable financial data, and perhaps other data they perceive to be valuable, criminal threat actors may target these networks with the intent to profit.

Perception of Weak Defenses

When criminals are looking for an easy target, NGOs’ networks may be perceived to be easy pickings. Just as the common thief would rather steal items of value from a house without an alarm than one with, the same is true with advanced threat actors and cybercriminals. NGOs possess information of value that a variety of threat actors desire, and their networks can sometimes be far easier targets than government institutions or large commercial organizations, due to their typically limited resources when it comes to network security and defense.

Although NGOs face a unique landscape when it comes to advanced threats in terms of the sheer number of threat groups targeting them and the widely varying possible impacts of a breach, their operations and needs share many similarities with those of our small- and medium-sized (SMB) customers. To that end, FireEye Labs recommends reviewing our latest SMB-focused white paper for more insight into what the broader threat landscape looks like for NGO-like organizations. A copy of the paper can be found here: http://www2.fireeye.com/smb_five_reasons_wp.html.

If an Android Has a Heart, Does It Bleed?

The OpenSSL Heartbleed vulnerability “allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read” [1]. Heartbleed surprised the public by allowing attackers to steal sensitive information from vulnerable websites by sending crafted SSL heartbeat messages. However, due to the fact that servers can send heartbeats to clients as well, malicious servers can, in turn, attack vulnerable clients and steal sensitive information. For the Android platform, we find that roughly 150M downloads of Android apps contain OpenSSL libraries vulnerable to Heartbleed.

Currently there are about 17 antivirus apps on Google Play branded as “Heartbleed detectors”. Six of them scan the OpenSSL library belonging to the Android platform for vulnerabilities. Unfortunately, this method isn’t sufficient for detecting the Heartbleed vulnerability on Android. Except in limited Android versions (mainly 4.1.0-4.1.1), the majority of Android platforms are not vulnerable, as most versions use OpenSSL libraries that are not vulnerable or simply have the OpenSSL heartbeat functionality disabled.

However, Android apps frequently use native libraries, which either directly or indirectly leverage vulnerable OpenSSL libraries. Therefore, even though the Android platform itself is not vulnerable, attackers can still attack those vulnerable apps. They can hijack the network traffic, redirect the app to a malicious server and then send crafted heartbeats messages to the app to steal sensitive memory contents.

We studied apps with vulnerable OpenSSL libraries and confirmed this attack. Most of the vulnerable apps are games, and some are office-based applications. Although there is not much valuable information in the game apps, attackers can steal OAuth tokens (access tokens and refresh tokens) to hijack the game accounts; as such, the information might be useful for hijacking those linked social network accounts with incorrect configurations. Office apps vulnerable to Heartbleed are much more dangerous due to further potential data leakage.

During our investigation of the office apps that contains a vulnerable version of OpenSSL, we were surprised that they were not vulnerable to the Heartbleed attack. How could it be? A deeper look shows that these apps either make a mistake in the native code linkage, or just contain dead code. Therefore, when they try to invoke SSL functions, they directly use the non-vulnerable OpenSSL library contained within the Android OS, instead of using the vulnerable library provided by the app. The linkage mistake is common for Android applications built with native code. As such, the side-effect of this mistake helps reduce the apps’ overall risk profile.

Within the 17 Heartbleed detector apps on Google play, only 6 detectors check installed apps on the device for Heartbleed vulnerability. Within the 6, 2 report all apps installed as “Safe”, including those we confirmed as vulnerable. One detector doesn’t show any app scan results and another one doesn’t scan the OpenSSL version correctly. Only 2 of them did a decent check on Heartbleed vulnerability of apps. Although they conservatively labeled some non-vulnerable apps as vulnerable, we agree it is a viable report which highlights both the vulnerabilities and the linkage mistakes. We’ve also seen several fake Heartbleed detectors in the 17 apps, which don’t perform real detections nor display detection results to users and only serve as adware.

On April 10th, we scanned more than 54K Google Play apps (each with over 100K downloads) and found that there were at least 220 million downloads affected by the Heartbleed vulnerability. We have notified some of the app developers and library vendors about the OpenSSL Heartbleed vulnerability found in their products. Fortunately, it seems most app developers and library vendors take Heartbleed seriously, as we have started to see apps updated with proper fixes. The total number of vulnerable apps download has since decreased to 150 million on April 17th.

[1] Vulnerability Summary for CVE-2014-0160

Crimeware or APT? Malware’s “Fifty Shades of Grey”

Some cybercriminals build massive botnets to use unsuspecting endpoints for spam, distributed denial-of-service (DDoS) attacks, or large-scale click fraud. With the aid of banking Trojans, other cybercriminals create smaller, specialized botnets that focus on stealing bank credentials and credit card information.

Remote access tools, or RATs, are an integral part of the cybercrime toolbox. For example, a recent FireEye investigation into XtremeRAT revealed that it had been propagated by spam campaigns that typically distribute Zeus variants and other banking-focused malware. This tactic may stem in part from the realization that compromising retailers can net millions of credit card numbers in one fell swoop.

Malware designed to compromise point-of-sale (POS) systems is not a new phenomenon. But we have seen a recent surge in malware that specifically targets these systems (e.g. Chewbacca, Dexter, BlackPOS and JackPOS). Moreover, POS malware is being deployed in an increasingly targeted manner. For example, some attacks against retailers have been characterized as “APT style” attacks —  a designation traditionally reserved for malware-based espionage sponsored on some level by nation-states.

The extent to which such attacks are targeted, and not opportunistic, is unclear. The attackers could be singling out specific retailers in advance. Or they could be targeting an entire industry, simply capitalizing on opportunities that arise.

In this blog post, we examine one case that clearly illustrates the nature of this problem.

Continue reading »

Occupy Your Icons Silently on Android

FireEye mobile security researchers have discovered a new Android security issue: a malicious app with normal protection level permissions can probe icons on Android home screen and modify them to point to phishing websites or the malicious app itself without notifying the user. Google has acknowledged this issue and released the patch to its OEM partners.

Normal vs. Dangerous Permissions: A Background

Android Open Source Project (AOSP) classifies Android permissions into several protection levels: “normal”, “dangerous”, “system”, “signature” and “development” [1][2][3].

Dangerous permissions “may be displayed to the user and require confirmation before proceeding, or some other approach may be taken to avoid the user automatically allowing the use of such facilities”. In contrast, normal permissions are automatically granted at installation,  “without asking for the user's explicit approval (though the user always has the option to review these permissions before installing)” [1].

On the latest Android 4.4.2 system, if an app requests both dangerous permissions and normal permissions, Android only displays the dangerous permissions, as shown in Figure 1. If an app requests only normal permissions, Android doesn’t display them to the user, as shown in Figure 2.

Figure 1. An Android app asks for one dangerous permission (INTERNET) and some normal permissions (Launcher’s READ_SETTINGS and WRITE_SETTINGS). Android doesn’t notify the user about the normal permissions.

Figure 1. An Android app asks for one dangerous permission (INTERNET) and some normal permissions (Launcher’s READ_SETTINGS and WRITE_SETTINGS). Android doesn’t notify the user about the normal permissions.

Figure 2. An Android app asks for normal permissions (Launcher’s READ_SETTINGS and WRITE_SETTINGS) only. Android doesn’t show any permission to the user.

Figure 2. An Android app asks for normal permissions (Launcher’s READ_SETTINGS and WRITE_SETTINGS) only. Android doesn’t show any permission to the user.

Normal Permissions Can Be Dangerous

We have found that certain “normal” permissions have dangerous security impacts. Using these normal permissions, a malicious app can replace legit Android home screen icons with fake ones that point to phishing apps or websites.

The ability to manipulate Android home screen icons, when abused, can help an attacker deceive the user. There’s no surprise that the com.android.launcher.permission.INSTALL_SHORTCUT permission, which allows an app to create icons, was recategorized from “normal” to “dangerous” ever since Android 4.2. Though this is an important security improvement, an attacker can still manipulate Android home screen icons using two normal permissions: com.android.launcher.permission.READ_SETTINGS and com.android.launcher.permission.WRITE_SETTINGS. These two permissions enable an app to query, insert, delete, or modify the whole configuration settings of the Launcher, including the icon insertion or modification. Unfortunately, these two permissions have been labeled as “normal” since Android 1.x.

As a proof of concept attack scenario, a malicious app with these two permissions can query/insert/alter the system icon settings and modify legitimate icons of some security-sensitive apps, such as banking apps, to a phishing website. We tested and confirmed this attack on a Nexus 7 device with Android 4.4.2. (Note: The testing website was brought down quickly and nobody else ever connected to it.) Google Play doesn’t prevent this app from being published and there’s no warning when a user downloads and installs it. (Note: We have removed the app from Google Play quickly and nobody else downloaded this app.)

Lastly, this vulnerability is not limited to Android devices running AOSP. We have also examined devices that use non-AOSP Launchers, including Nexus 7 with CyanogenMod 4.4.2, Samsung Galaxy S4 with Android 4.3 and HTC One with Android 4.4.2. All of them have the protection levels of com.android.launcher.permission.READ_SETTINGS and WRITE_SETTINGS as “normal”.

Google acknowledged this vulnerability and has released the patch to its OEM partners. Many android vendors were slow to adapt security upgrades. We urge these vendors to patch vulnerabilities more quickly to protect their users.

References:

  1. http://developer.android.com/guide/topics/manifest/permission-element.html
  2. https://android.googlesource.com/platform/frameworks/base/+/master/core/res/AndroidManifest.xml
  3. https://android.googlesource.com/platform/packages/apps/Launcher2/+/master/AndroidManifest.xml

DLL Side-Loading: Another Blind-Spot for Anti-Virus

Last month, I presented a talk at the RSA USA Conference on an increasingly popular threat vector called “Dynamic-Link Library Side-Loading” (DLL Side-Loading). As with many vulnerabilities, this exploit has existed for a rather long time and is the result of Microsoft looking to make binary updates easier for Windows developers through the Windows side-by-side (WinSxS) assembly feature.

Now, though, advanced persistent threat (APT) developers are using the innocuous DLL Side-Loading method to sneak malware past anti-virus (AV) scanners as the infected files run in-memory. In doing-so, the malicious payload is using a benign application to be built in memory, meaning that the malware does not sit running in the file system where AV scans take place. In the figure below, you can see an example of how this all plays out:

DLLpic

For a real-life example: in 2013, attackers exploited the executable originally developed by Fortune 50 company using this technique in a highly targeted attack. In such an attacks, the malware places a spoofed, malicious DLL file in a Windows’ WinSxS directory so that the operating system loaded the spoofed DLL instead of the legitimate file. Furthermore, because the file in-question was white-listed by hash in a public database, AV simply ignores it altogether.

In response to the growing use of DLL Side-Loading in APTs, we have developed a full paper that describes the history of DLL Side-Loading and its role in the malware and software engineering arenas which you can review here: http://www.fireeye.com/resources/pdfs/fireeye-dll-sideloading.pdf

 

 

Security Perspective


Filter by Category:


Dissecting Advanced Attacks: FireEye Labs and the 2014 DBIR

Each year, a number of reports are released on the changing state of the threat landscape and where cyber security is headed. Like our annual Advanced Threat Reports and M-Trends Reports, Verizon has released the “Data Breach Investigations Report” (DBIR), which is considered by many in the security industry as the most comprehensive guide to data breaches. This year, owing to the large number of and deep insights into cyber espionage and advanced persistent threat campaigns that we track, Verizon tapped the FireEye Labs team to contribute to the latest version of the report.

The 2014 DBIR takes a comprehensive look into all forms of attacks from the past year and, as we have always done with our investigations, newly examines the incident patterns of attacks. This type of analysis is what we like to call behavioral or contextual analysis of a breach lifecycle and is invaluable in understanding advanced threats that are not readily apparent in traditional detection methods.

To help with this initiative, FireEye Labs contributed information on several advanced attacks uncovered in 2013 that were likely driven by cyber espionage motives. Information on the individual attacks can be found here:

To view a full version of the Verizon DBIR, you can download a copy here: http://www.verizonenterprise.com/DBIR/. Also, be on the lookout for the release of our European Advanced Threat Report next week.

InfoSecurity Europe 2014: Cybersecurity for the Masses

InfoSecurity Europe is the biggest security event and most important date on the calendar for information security professionals across Europe. The event aims to break through the noise and provide the European audience with all the necessary information to better understand cyber threats to their networks. Join FireEye experts and learn how to prepare for a new frontier of advanced attackers:

  • Visit stand J60 and check out FireEye’s Geek Bar. A certified geek will analyze your portable device to determine if you’ve received any malware. The live demonstration can prove useful to better understand and identify potential threats to your network.
  • Join FireEye Director of Technology Strategy Jason Steer, SI Technical Lead Simon Mullis, and Greg Day, EMEA CTO among others, as they discuss the threat landscape and walk attendees through interactive, educational workshops and presentations. Join us on our stand to understand the threat landscape – presentations every 30 minutes all 3 days.
  • Senior Director of Market Research at FireEye Rob Rachwald will be speaking on Wednesday, April 30, where he’ll cover the nitty gritty of sandbox evasion. Mr. Rachwald’s presentation will help the audience gain an overview of various sandboxing techniques, understand current sandbox bypass methods, as well as identify best practices to optimize malware detection.
  • FireEye SVP and COO Kevin Mandia will make a special appearance on Wednesday, April 30 to discuss FireEye’s recent acquisition of Mandiant, as well as to discuss today’s changing threat landscape.
  • The FireEye team will also release the latest findings from Mandiant’s annual M-Trends report and European ATR research report. The results offer visibility into motives, approaches, and different skill levels of attackers both in Europe and around the globe.
  • Participate in FireEye’s photo contest and have the opportunity to win an Apple® gift card worth £250! Look around London and you will see FireEye branded taxis zipping around the city. Grab your camera or smart phone and take a picture of you and the taxi. Submit your photo to helena.brito@fireeye.com and your photo will be posted to FireEye’s Facebook page. You will also be automatically entered into the contest.

FireEye Taxi

Stop by Stand J60 to learn more about the newly expanded FireEye Security Platform, which integrates expertise from Mandiant and is designed to give customers one solution to go from threat alert to remediation. We’ll have live demonstrations of all the new FireEye products. In the mean time, be sure to follow @FireEye for the latest threat research and updates from the company.

We hope to see you in London the week of April 29 through May 1. If you are unable to attend, check back on the blog for interviews and insights from the conference. You can register for a free entry ticket by clicking HERE – your badge will arrive with “FireEye Guest” printed on the bottom.

The Economics of Security

During many of my customer meetings, I often hear security leaders ask the question: “What technology could I remove to free up budget to enable the implementation of FireEye?”

My natural response is to inquire how and when they assess the real value, not the ROI, they get from their existing solutions. Whilst every security solution provides an “ROI” – often a metric based around industry data on how many security “events” they return – this assessment should not focus on noisy “ROI,” but which solution gives your company the most valuable information. Considering the nature and pace of change when it comes to malware and advanced attacks, this is something to validate regularly and involves looking at more factors than a generic ROI tool can factor in.

In a small survey of about 30 European CxOs we ran in December 2013, I asked the question of how they validated the value of security controls, and, surprisingly, at least 36 percent still didn’t conduct any annual assessment.

doyouvalidate

Having spent quite a bit of time looking at analyst models and what exists publically today, the fact that some still don’t conduct these assessments emphasizes that there still isn’t a well-defined model to correlate business value against investment for security solutions.

Take, for example, the outsourced model where Key Performance Indicators (KPIs) are typically established. Too often I hear anecdotal examples where KPIs were based on incidents found; this simply encourages dialing-up the technologies being monitored so that every incident – malicious or not – is tracked and reported, drowning out the ability to identify real threats.

For example, companies investing in big data solutions that gather and equate the millions to billions of events delivered each week to value. However, because they are too resource-constrained to convert these into actionable data, the true value is not extracted and, because doing so in a resource-constrained environment takes so long, the return here would seem extremely poor to a sheer numbers-based evaluation.

However, if the value of said product is measured by the actions taken to mitigate a major security event, that extra time spent executing on a few major items rather than not executing on a large amount of items becomes invaluable to the business. As such, we must blend together the quantitative metrics such as the costs of a solution (capex & opex), incident levels and overlay those values with qualitative insight. These evaluation criterion would look something like the below:

opexcapex

 

  • Noise to incident ratio – What is an acceptable incident to noise (i.e., false positives or irrelevant alerts) ratio?
  • Volume versus impact - We can alert and respond to a million incidents but it’s the one outage of a critical system or breach of business IP or customer records will have a far more significant impact on the business.
  • How actionable is the solution – Critical to an alert is timeliness, how long does it take to identify an incident and what level of human skills are required to interpret the results. Spotting a breach is hard, doing the forensics is harder, and understanding the motives of the attacker is harder still.
  • Business outcome – Did a technology mitigate, reduce or simply delay the business impact. Did it tick a compliance control to avoid penalty fees or did it protect IP & customer data?

In the coming months we are going to delve into the economics of security in greater detail.  Whilst there are many tools out there discussing security process and ROI tools showing generic return, we all have limited budget and resources. With the scale and scope of security tools continues to grow we must innovate our thinking, in how we each quantify the value of our investments.

 

 

Annual M-Trends Report Looks Beyond the Breach

Since 2010, Mandiant’s annual threat report, “M-Trends” has provided the industry with in-depth analysis and insight based on hundreds of advanced threat investigations conducted during the previous calendar year for the U.S. government, the defense industrial base and commercial organizations. As a leader in combating advanced threats, FireEye stresses the continuous education that needs to take place in order to be one step ahead of attackers. That is why it is with great excitement that I present the fifth installment of M-Trends.

2013 was an explosive year for the cybersecurity industry; a result of Mandiant’s APT1 report, The New York Times breach, and other organizations coming to the forefront to openly discuss their own incidents. In addition, President Obama discussed concerns about cyber-attacks in his annual State of the Union address. This was a huge step for the industry in terms of bringing advanced attacks to the forefront of the nation, and the world’s, attention.

This year’s report compiles incident response trends from hundreds of clients in more than 30 industry sectors. Some highlights include:

  • The time it takes to detect a compromise continues to improve
    The median number of days it takes an organization to discover a network breach dropped to 229 days in 2013 from 243 in 2012. This improvement is incremental relative to the drop from 416 days in 2011. However, organizations can unknowingly be breached for years. The longest time an attacker operated undetected in a network before being discovered was six years and three months in 2013.
  • Organizations are yet to improve their ability to detect breaches
    In 2012, 37 percent of organizations detected breaches on their own. This number dropped only minimally, to just 33 percent in 2013.
  • Phishing emails largely look to capitalize on trust in IT departments
    44 percent of the phishing emails observed in attacks investigated by Mandiant sought to impersonate the IT departments of the target’s workplace. The vast majority of these emails were sent on Tuesday, Wednesday and Thursday.
  • Political conflicts increasingly have cyber components that impact private organizations
    In the past year, Mandiant responded to an increased number of incidents where political conflicts between nations spawned cyber-attacks that impacted the private sector. Specifically, Mandiant investigated incidents where the Syrian Electronic Army (SEA) compromised external-facing websites and social media accounts of organizations with the primary motive of raising awareness for their political cause.
  • Suspected Iran-based threat actors conduct reconnaissance on energy sector and state governments
    Multiple investigations of suspected Iran-based network reconnaissance activity indicates that threat actors are actively engaging in surveillance activities at energy sector companies and state government agencies. While these suspected Iran-based actors appear less capable than other nation-state actors, nothing stands in the way of them testing and improving their capabilities.

Click here to request a copy of the report.

Let us know your thoughts by leaving a comment below.

Real World vs Lab Testing: The FireEye Response to NSS Labs Breach Detection Systems Report

Today, NSS Labs released a report detailing the performance of several vendors’ ability to detect advanced attacks.  We declined to participate in this test because we believe the NSS methodology is severely flawed. In fact, the FireEye product they used was not even fully functional, leveraged an old version of our software and didn’t have access to our threat intelligence (unlike our customers).  We did participate in the BDS test in 2013 and at that time we also commented on the flaws of the testing methodology.  In fact, we insisted that the only way to properly test was to run in a REAL environment.  NSS declined to change their testing methodology so we declined to participate in the most recent test, results of which have been published today. When NSS tested our product a year ago, they used a sample set that included 348 total samples.  FireEye detected 201 of 348 total samples.  Of the 147 “missed” samples:

  • 11 were non-malicious.
  • 19 were corrupted (as to why other vendors detected these because some vendors scored higher – close to 100% – means that their detection engines are based on hashes which will match regardless of whether the sample is malicious).
  • 117 were duplicates (as to why FireEye didn’t receive credit for detecting these, we never received a response from NSS).

Clearly, nobody could take this approach seriously—it was a major mismatch versus what we see in the wild.

Understanding advanced threats still represents a black hole for many in today’s security industry. The test unfortunately perpetuates a general failure by many to fully understand and appreciate the inner workings of advanced threats that continue to plague organizations despite millions invested in legacy security technologies. In this case, the test contained a number of flaws that security professionals should thoroughly understand before taking these results at face value. 

Issue #1:  Poor sample selection.   Specifically:

  • NSS mostly relied on VirusTotal to download payloads (clear text executable files).  The NSS sample set doesn’t include Unknowns, Complex Malware (Encoded/Encrypted Exploit Code & Payload), and APTs.   Almost by definition, APTs use new or updated code to bypass detection, which is standard procedure.  However, NSS used a known corpus of malware.  Advanced threats are in, out, and cleaned-up in minutes.  In the past, the malware samples used in the NSS tests were available on VirusTotal (an aside: the oldest sample on VirusTotal is from 2006 and the median sample age is 17.2 months).  By contrast, when tests specifically leverage malware samples that are new and unknown, antivirus detection rates fall dramatically.  For example, the Imperva study found that antivirus detected only 5% of malware.  The other vendors in the NSS report are built for detecting known malware.  By relying on VirusTotal, NSS missed out on AK-47s and spent time analyzing pea shooters.
  • Even for Payloads, NSS doesn’t perform Forensics Analysis to understand if the sample is malicious, goodware or corrupt (can’t execute).  NSS gives a positive score as long as a vendor sees the sample on the wire, even if the sample is not actually malicious.

 

Issue #2:  Differing definitions of advanced malware: Vendors and test agencies differ in how they define advanced malware. The NSS test confused Adware, Spyware, & APTs and accounted for Adware and Spyware as APTs.  For instance, some of the NSS tests expected Adware to be classified as malware.  In this series of tests, Adware that changes the home page of the browser, but does not infect the system in any other way, must be flagged as malware by a product in order to receive a positive score. FireEye solutions wait for true malicious behavior to avoid false alerts.  In the aforementioned case, the page load of the new home page would be analyzed to identify if the change was truly malicious or not.

Issue #3:  Poor test methodology. Specifically, the NSS test:

  • Doesn’t account for the use of zero day exploits.  There were no zero day exploits in the test sample. This is difficult to do.  Testing for zero days requires having a zero day on hand or developing one yourself, which is expensive.  Finding new malware that utilizes zero day exploits is where FireEye thrives.  In 2013, we found 11 exploitable zero days as well as countless malware campaigns used in cyber espionage, warfare or crime.  This year, we have already uncovered two zero days.
  • Did not have access to our security intelligence in the cloud.  Unlike our customers, the FireEye appliances were NOT connected to our Dynamic Threat Intelligence cloud to get latest content updates, virtual machines and detection capabilities.

We respect NSS and the work they do—especially for IPS – and their testing methodology for BDS is also more suited to testing IPS products. However, we believe the issues we identified with their evaluation of advanced threats are indicative of the security industry’s broader lack of knowledge regarding sophisticated attacks. FireEye is designed to supplement legacy signature and reputation based technologies to protect against advanced threats—and the NSS tests didn’t properly gauge our capabilities.  Our product’s efficacy is proven by how well we protect customers in real-world deployments. Consider that in 2013, FireEye:

  • Found 11 exploitable zero day vulnerabilities, with two uncovered so far in 2014.  (By comparison, among the top 10 cyber security companies ranked by security-related revenue, only 2 other zero-day vulnerability were reported in 2013.)
  • Tracked more than 40 million callbacks.
  • Tracked more than 300 separate APT campaigns.
  • Deployed more than 2 million virtual machines globally.

Any lab test is fundamentally unable to replicate the targeted, advanced attacks launched by sophisticated criminal networks and nation-states. The best way to evaluate FireEye is for organizations to deploy our technology in their own environment and they will understand why we are the market leader in stopping advanced attacks.  We believe it is erroneous for NSS to compare security efficacy, performance, and cost in the same graphic, because doing so assumes that all three buying criteria are all equally important.  In our experience, security efficacy is much more important than the others.  In fact, most users and vendors are moving toward a malware prevention, detection, and response architecture.

In August 2013, IDC issued a report, Worldwide Specialized Threat Analysis and Protection 2013–2017 Forecast and 2012 Vendor Shares.  This report identified and ranked vendors claiming to stop advanced malware attacks.  FireEye was listed as the top vendor based on market share (38%) compared to the nearest competitor with 14% market share.  The market is voting with dollars based on their real-world experience while under real-world attacks from advanced threats.