You can't see some malware until it's too late. Sophisticated attacks arrive in pieces, each seemingly benign. Once these advanced attacks reassemble, the target is already compromised.
FireEye takes a new approach to malware detection with its NX appliances. As this Clear Choice test shows, the FireEye device allows advanced malware to proceed – but only onto virtual machines running inside the appliance.
In our tests, the FireEye appliance performed flawlessly. It detected all the multi-stage malware samples we threw at it, including some involving recent zero-day exploits. The top-of-the-line NX 10000 ran at speeds beyond 4Gbps in inline mode, and at better than 9Gbps in tap mode, both with and without attack traffic present.
The NX line fills a specialized niche, and complements rather than replaces existing security gear. It’s not an IDS on its own, though the company is working on an IDS module. Even then, the NX 10000 won’t be an all-in-one security device. Instead, it does one thing really well: It stops the most advanced forms of malware from passing into the enterprise.
This comprehensive protection doesn’t come cheap. The high-end system we tested has a list price of around $420,000, plus service contract. But that’s intended for 10G Internet links (which themselves are rather pricy), and it’s aimed at enterprises protecting assets worth far more than a half-million dollars. For comparison, FireEye’s entry-level NX 900 appliance works on 10-Mbit/s links and has a list price of $9,600.
+ ALSO ON NETWORK WORLD Free antivirus you can trust +
Anatomy of a threat
While automated attacks from script kiddies remain a nuisance, a far more serious threat comes from sophisticated multi-stage malware. Some of these so-called advanced persistent threats (APT) are state-sponsored; in other cases organized crime is involved.
New attacks, especially zero-day vulnerabilities, are often seen during this stage.
Second, the exploit on the infected client then downloads the actual malware, though not necessarily in one piece. The “dropper” might come in multiple pieces from multiple sources, each obscured to hide its nature.
Third, the compromised system phones home to a command-and-control network that executes the malware. By now, the attackers control the target system; they have its data and a pathway to the rest of the internal network.
Conventional approaches to fighting malware have limitations in combating multi-stage malware threats. A signature-based system might detect the existence of a malware binary file, but only once it’s been reassembled on the target – and by then the target is already compromised. Newer sandbox systems stop traffic before it reaches target machines, but they may not be able to assemble and analyze all the constituent parts of a multi-stage attack. Indeed, a key step in some exploit kits is to “fingerprint” versions of the hypervisor, OS, browser, and plug-ins before deciding whether to proceed.
The FireEye difference
Virtualization is FireEye’s key differentiator. Its appliances run multiple versions of Windows OSs, browsers, and plug-ins, each in its own virtual machine. Malware actually compromises a target (virtual) machine – and then and only then does the FireEye software record a successful attack. Network managers can configure the FireEye appliance to block such attacks, preventing their spread into the enterprise.
We tested the NX 10000 appliance, FireEye’s highest-speed device with two 10G Ethernet interfaces. It focuses specifically on Web-based attacks. The company has other product lines for email, mobile, and forensic analysis, but we did not test those.
The NX 10000 operates in tap or inline mode, with the latter optionally able to block attacks. Its content library is updated daily to include new exploits, something we verified in testing with recent zero-day vulnerabilities.
FireEye’s technology complements rather than replaces an intrusion detection system (IDS). Unlike an IDS or IPS, it doesn’t have a library of thousands of attack signatures. Instead, it looks for actual compromises on its virtual machines. The company says an IDS module is in beta testing, and is slated for general release by the end of the second quarter.
Once the appliance identifies multi-stage malware, it triggers an alert. With a conventional IDS/IPS, a malware alert might say something like “file trojan.exe was detected.” In contrast, an NX 10000 alert shows each component of the malware, including callback URLs used to contact command-and-control networks, as seen below.
FireEye's NX 10000 offers detailed reporting on multi-stage malware, showing each component of an attack, including callback URLs used to contact command-and-control networks.
The appliance’s virtual machines represent various service pack levels of Windows 7 and Windows XP, along with many combinations of browser and Adobe Flash and Microsoft Silverlight versions. FireEye wrote its own hypervisor that makes virtual machines appear to run on bare metal. That’s useful to thwart exploit kits that skip execution on machines if they detect VMware hypervisors.
The version we tested doesn’t yet support Mac OS X virtual machines, though FireEye says Mac support will be available in the third quarter.
Like all security devices, the NX 10000 only detects attacks it can see, and that has network design implications. Placing the appliance at the network perimeter makes sense. So does a hub-and-spoke design that aggregates Internet traffic from branch offices and telecommuters. Enterprises with more decentralized designs might instead consider smaller appliances for each site.
One drawback to having a large appliance at a central site: The NX 10000 lacks built-in high-availability support, instead relying on external systems such as load balancers to avoid a single point of failure.
We tested the NX 10000 in terms of multi-stage malware coverage and performance. We ran coverage and performance tests in both tap and inline modes, and conducted performance tests both with and without attack traffic present.
For the coverage tests, we replayed a collection of 60 multi-stage malware samples seen in the wild between January and April 2014. These samples, used with permission of malware-traffic-analysis.net, represent many aspects of multi-stage malware. They involve different kinds of exploit kits; zero-day exploits; dropper executable files; and callbacks to command-and-control networks. We did not tell FireEye which samples we’d use in testing.
In all 60 cases, the FireEye appliance correctly identified the individual components of each malware sample, both in inline and tap modes.
The FireEye device updates its library of multi-stage malware examples at least once every 24 hours. It’s possible the system would not detect a brand-new exploit, but we did not see that in testing. Indeed, the most recent of our samples was first posted on malware less than 24 hours before we used it in testing, and the updated FireEye device correctly identified it.
FireEye says its customers typically see one attempted malware exploit every three minutes; our tests were far more stressful than that. We replayed all malware samples consecutively at rates approaching 10G Ethernet wire speed. In contrast, each malware sample originally took seconds or even minutes to run from start to finish. Also, there was no gap between the end of one malware sample and the start of another.
The FireEye appliance also met its stated limits in performance tests. FireEye claims the NX 10000 can forward traffic at around 4Gbps in inline mode and at nearly 10Gbps in tap mode.
We evaluated these claims using Spirent Avalanche, a Layer 4-7 traffic generator analyzer. We configured Avalanche HTTP traffic from up to 40,000 clients, as in a large enterprise network. We measured performance in both inline and tap modes, and we also measured performance while the system was under attack.
With only benign web traffic, the FireEye device forwarded traffic at 4.224G and 9.259Gbps in inline and tap modes, respectively. Both results are in line with FireEye’s performance claims.
We then repeated these tests while concurrently offering the multi-stage malware samples (again, we offered these consecutively, at the maximum possible rate). This time, the NX 10000 forwarded traffic at 4.207G and 9.298Gbps in inline and tap modes, respectively. Those numbers are virtually identical to the tests with benign traffic only, with the minor differences most likely explained by bandwidth contention among many TCP flows.
The FireEye appliance again identified all components of all 60 malware samples offered in the inline tests. Some malware samples were not identified in the tap-mode tests, but we believe this was due to an overloaded CPU in the switch mirroring traffic to the FireEye device. The switch reported CPU utilization of 100 percent and became unresponsive during multiple iterations of the tap-mode tests. While the missed reports should not be “charged” to the FireEye device, this does point up the importance of using tap infrastructure capable of forwarding all traffic at 10G Ethernet wire speed.
Advanced attacks require advanced defenses. The NX 10000 represents an innovative and effective approach to combating multi-stage malware. Combined with a conventional IPS (or using its own IPS module, available soon), the FireEye appliance should help large enterprises keep malware off their networks.
Network World gratefully acknowledges the assistance of Spirent Communications, which supplied its Spirent Avalanche C100MP traffic appliance. Spirent’s Michelle Rhines, Ankur Chadda, Angus Robertson, and Chris Chapman also supported for this project. Thanks, too, to malware-traffic-analysis.net, which provided permission to use its packet captures of recent multi-stage malware firstname.lastname@example.org.
Newman is a member of the Network World Lab Alliance and president of Network Test, an independent test lab and engineering services consultancy. He can be reached at
How We Did It
We assessed FireEye’s NX 10000 in terms of features, attack coverage, and performance. Features testing required no separate methodology. Instead, we discovered functions supported by the device in the course of security and performance testing.
For attack coverage, we obtained 60 multi-stage malware packet captures from the website malware-traffic-analysis.net. These captures had been seen in the wild between January and April 2014. Captures included examples of exploit kits, dropper (infected) files, and callbacks to command-and-control servers.
We used the open-source tcpprep and tcprewrite tools to prepare these packet captures for use on our test bed, rewriting MAC and IP addresses. We then used the open-source tcpreplay tool to generate the multi-stage malware attacks. We generated these attacks using a single FreeBSD 10.0 server equipped with a multiport NIC.
For performance testing, we used Spirent Avalanche, a layer 4-7 traffic generation tool to offer Web traffic from up to 40,000 users. In this case, Avalanche ran on Spirent’s C100MP appliance equipped with 10G Ethernet interfaces.
For security and performance tests, we constructed a routed test bed with three IP subnets. When tested in inline mode, the FireEye NX 10000 appliance resided in the middle segment, and bridged traffic between two layer-3 switches. When tested in tap mode, the layer-3 switches were directly connected to each other, and the NX 10000 listened to traffic using a mirror port configured on one switch. The Spirent and FreeBSD traffic generators resided in the outer subnets in this test bed, with one interface from each device connected to each outer subnet.
For the coverage tests, we configured tcpreplay to offer all 60 malware samples at the maximum rate possible. We monitored the NX 10000 continuously during and after the test, and verified that it correctly identified each attempted exploit. The success metrics in this case included the ability to identify source and destination IP addresses and name the various exploit kits, droppers, and command-and-control callbacks used by each malware sample.
For the performance tests, we configured Spirent Avalanche to emulate up to 40,000 clients requesting 64-kbyte Web objects as quickly as possible. We ran four permutations of performance tests: With benign traffic only, both in inline and tap modes; and with benign and malware traffic offered concurrently, again in inline and tap modes.