How to Detect a Worm with a Network Analyzer (by Nancy Liu)
Wireshark Use Case: Slow Response Times - Part 4 (by Paul Offord)

Optimizing Network Security with Packet Intelligence (by Tom Rowley)

Optimizing Network Security with Packet Intelligence !

Enterprise security teams devote an incredible amount of resources to monitoring and defending their networks. Everyone knows there are professional grade tools that can monitor networks 24x7 providing detailed information about usage as well as enabling the in-depth examination of captured traffic once an Intrusion Detection System (IDS) has identified an activity that needs to be investigated.

Given the amount of success that attackers are having in penetrating network defenses and the deluge of alerts and alarms network teams deal with from IDS on a daily basis, enterprises are in need of better tools and training to go beyond the typical prevention, detection and response security protocols to effectively deal with incident response.

In today’s world, intelligent packet capture is the answer. Most modern forensic investigation solutions (FI) enable network security teams to capture and save a historical record of network activities that occur from the moment an attack is detected. But, one common weakness in existing forensic investigation solutions is that they don’t provide critical packet-level data from the period of time immediately BEFORE attacks are detected.

Is your network locked or not

Consider this example:

A network user visits a friend’s Facebook page and clicks on something that looks interesting- an unusual webcam. The site does contain an interesting webcam image but it also has a hidden iFrame. The iFrame loads a page containing a javascript which, in turn, downloads and executes malware that opens a backdoor into the user’s system. The malware embeds itself in the user’s system while scanning for useful information to steal. Later, the malware attempts to exfiltrate some information from data protected by DLP (Data Loss Prevention) software and, finally, this activates a security alert. Many security appliances, like the DLP above, would now begin capturing and saving network and packet data when the alert triggered.

Even better, a well-designed FI solution would have been continuously buffering the network information for some period of time BEFORE the alert happened. Then, not only is the succeeding exfiltrated data captured (which is certainly valuable), but the entire history of the attack can be reconstructed.

Here’s an example of what an investigator would have been able to see if the FI tool had been buffering and capturing packets before the alert triggered. (Names have been changed to protect the innocent but this is a real iFrame attack chain) -

 Click on images to expand - 

Picture 1

First, we see the user accessing the webcam page – “”. We see that he also downloaded a webcam image – “webcam.png”, this looks OK so far but let’s look at the actual html code. We search the packet files for the HTML code that the user’s browser executed.

Picture 2

As is typical for efficient web transport, the html is Gzip encoded but we run it through a decoder and among all the legitimate HTML, there is a fragment of iFrame code that looks like below:.


<iframe src=""

       width=0 height=0 style="visibility:hidden"></iframe>


iFrames have a legitimate role in web page design, inserting ads, for example, but it’s very suspicious that this iFrame has its width and height set to zero! From the code, we see the IFrame is downloading another page from “”, so we search through the captured packets for that web page and find this:


Picture 3

Again, we decode the Gipped HTML content and we see in the HTML code this javascript:


<script src="" ></script>


The remote site – “” – is hosting a malware file – “666.js” and this script, now running on the user’s machine through the iFrame, executes the malware and penetrates the user! We have found the initial point of entry.

Because the FI solution was able to save and reconstruct the packets before the DLP’s belated alert, the security team is able to see the Facebook linked visit to the webcam site, the iFrame exploit, the downloading and execution of the malware, and follow the attack through to its completion.

Without the saved network activities before the alert occurred, the team would only have seen the attempt to access a protected data set – leaving them without a clue as to where exactly attacker was in the system or how he got there in the first place.

When all is said and done, most IDS alerts will not be triggered by the early actions of an attacker within a network. Many attackers have access to a compromised system for a significant period of time before being detected. This is why the ability to save and recover network and log data prior to an alert is critical in understanding how attackers gain access, what data they target and how to prevent the same or similar vulnerabilities weakening a network in the future.  

More great solution examples -

Tom rowleyAuthor - Tom Rowley, with over 35 years of technology experience is a Security Strategist, for Savvius Inc.   Tom was named a Technology Pioneer by the World Economic Forum in 2002. Tom holds three U.S. patents and has lectured for business schools at Stanford University, University of California at Berkeley and Santa Clara University. Among his accomplishments, Tom has been the CEO of StarVox, a public VoIP telephone company; Nuelight, an OLED controller startup; Preventsys, a supplier of enterprise security policy management software; Counterpane Internet Security, a managed security services provider; Veridicom, a spin-off of Lucent Technology’s Bell Labs providing silicon fingerprint readers; and Centigram, a leader in the voice messaging market. He also led the development of secure cryptographic semiconductors at National Semiconductor.