Here’s a true story about how network forensics helped an enterprise IT team discover the scope and modus operandi of a security attack.
A security tool installed on the network raised an alert about unusual activity on a server. When the IT team investigated, they discovered that the server had been compromised by a security attack. Unfortunately, the security tool provided no further information about the attack, such as who the culprit was and which other systems might also have been compromised. This vague nature of this alert is quite common. Security tools might detect an anomaly, but to thoroughly understand the nature and scope of an attack, IT engineers need to investigate matters themselves.
To start their investigation, the team turned to their network forensics system, which had recorded network traffic before, during, and after the attack. Using a dashboard (in this case, WildPackets Compass), the team discovered that the compromised system had initiated a spike in Common Internet File System (CIFS) traffic shortly after the attack had begun. (CIFS is an network protocol used by Windows computers to manage access to files and printers.)
To learn more about the systems involved in the CIFS spike, the team opened a Peer Map, showing a visual record of all the network communications that took place during the period in question.
The Peer Map confirmed that the compromised server had communicated with several other systems.
Next the team filtered traffic to show communications only from the compromised server. This made it easy to identify the three other systems that the compromised server had communicated with after the attack.
Figure 2. Filtering on the Peer Map made it easy to identify the addresses of the systems with which the compromised server had been communicating. Network forensics provided critical information that security tools overlooked.
Now the IT team knew which servers to focus their attention on in their efforts to contain the attack and reverse its effects. In addition to quarantining and repairing the server that was initially attacked, the IT team quarantined the three other infected servers, as well.
Working from a vague security alert, the team was able to use network forensics to identify specific systems to quarantine and where to focus attention on cleaning up the attack. Network forensics enabled the team to find proof of the attack and trace its effects.
To read other network forensics case studies, see the WildPackets white paper Real-World Security Investigations with Network Forensics, which is available on www.wildpackets.com.