Advertisement

Most computer forensics experts are well-versed in basic computer hardware technology, operating systems, common software applications, and computer forensics tools. And while many have rudimentary knowledge about the Internet and simple network-lookup tools, they are not trained in the analysis of network communication protocols and the use of packet sniffers.Insights on the role of network forensics and how knowledge of computer communications and network protocols is emerging as a necessary skill for digital investigators.

Most computer forensics experts are well-versed in basic computer hardware technology, operating systems, common software applications, and computer forensics tools. And while many have rudimentary knowledge about the Internet and simple network-lookup tools, they are not trained in the analysis of network communication protocols and the use of packet sniffers.

 

Introduction
The bulk of the computer forensics literature demonstrates clearly that this discipline is, in many ways, a subset of computer science. Indeed, the very best computer forensics examiners know a lot about computer hardware, operating systems, and software. As a result, many educational curricula in this field are being taught under the auspices of a Computer Science or other computer technology-related department. Frequently, the emerging curricula place an emphasis on computer science and programming.

Practitioners in both the private and public sectors, however, need to possess a broad set of knowledge areas in cyberspace. In particular, analysis and interpretation of network traffic—live or otherwise—has become increasingly important to the computer forensics community in the last several years. Network data—either live traffic, stored communications, or server logs—contain information that might be of use to the forensics examiner. In fact, there is so much potential information in these log files that due diligence requires the investigator to look at as much of this information as possible and the sheer volume makes it nearly impossible to examine every source of data in every case. (The problems implied by the previous sentence are well beyond the scope of this article.)

This article will present some insights about the role of network forensics and how knowledge of computer communications and network protocols is emerging as a necessary skill for digital investigators—perhaps even more than programming itself. Indeed, many of the issues discussed here are already well-known within the information security community, but are still on the periphery of the education and training of computer forensics practitioners. The article will conclude with some network investigation case studies.

 

The Role of Network Forensics
The analysis of network data is fundamentally different than the analysis of data found on a hard drive due to the temporal nature of the network information. When a computer is shut down, the contents of the hard drive remain intact and static. In a network, everything is constantly changing. Any live network analysis, at best, captures a snap shot of the current activity. While both parties in a case can examine the same snapshot data, it is impossible to replicate the network state at a later time.1,2,3

Network-based information can be used for a variety of network management, information assurance, and criminal and civil investigation purposes. While similar tools might be used for these divergent needs, they do have some different processes and procedures, as well as potentially different legal constraints. Some data is collected for the express purpose of ensuring compliance with governmental regulations (e.g., Sarbanes-Oxley [SOX] or the Health Insurance Portability and Accountability Act [HIPAA]) or industry requirements (e.g., tracking music downloads or licensing software). If law enforcement (LE) is involved in any examination (in the U.S.), Fourth Amendment search and seizure protections are in play and a search warrant may well be needed. This may also affect non-LE personnel; if a system manager finds something that he or she believes to be evidence of a crime and turns that information over to LE, any subsequent action that the sysadmin takes on behalf of LE makes him/her an agent of the state and also subject to the search warrant requirement.4,5,3

In any case, there is a blurring between intrusion detection, network security monitoring, and collection of data for forensic analysis. The differences between them hinge on these questions:1,3

  • What is the intended purpose of the information collection?
  • What information should be collected?
  • When should the information be collected? Jones, Bejtlich, and Rose note that data collected prior to a compromise or network event is proactive, whereas data collected during or after an event is a reactive or emergency condition.6
  • How (and where) is the information stored?
  • How (when, and by whom) is the information retrieved?

Jones et al.6 suggest that there are four basic classes of network information that might be collected by the forensics examiner:

  • Full content data: Collect every bit of information, including packet headers, on the network. As an example, the contents from all network servers might be imaged and saved, whereas the actual data examined will be defined at a future date by a judge.
  • Session data: Collect only the information pertinent to a particular investigation. For example, an investigator might serve a search warrant on an Internet service provider (ISP) to turn over all data associated with a given customer at a certain date and time, analogous to the FBI's former Carnivore project, where specific e-mail messages within defined parameters—such as certain keywords or user names—would be collected.
  • Alert data: Collect only data that includes particular items of interest. This is similar to the actions of an intrusion detection system (IDS) that collects information indicating known potential attack behavior or unknown, but abnormal, behavior.
  • Statistical data: Information that individually might not be suspicious but that, taken in the context of the overall network activity, indicates something remarkable. For example, use of secure file transfers between two users might be indicative of some nefarious communication if secure file transfers are otherwise not used. Although applying statistical methods to network data analysis for forensic applications is still an emerging area, it will be an important one in the future. Much of the current research in this particular area is attempting to define what statistical models to use. An operational model merely compares observed events with expected ones, based upon some definition of normalcy. A mean and standard deviation model uses these statistical measures to determine that some event has deviated from the norm; in this model, a network has to "learn" what is normal over a period of time. The multivariate model is similar but uses multiple variables and a χ2 test to determine an abnormal event. A time series model is also similar to the mean and standard deviation model, except that it uses time between events as the key to abnormality. Finally, a Markov process model uses a state transition matrix as the indicator of the norm so that a state change that has a low probability of occurrence might stick out as a suspicious event.7

  

Sources and Types of Network Data
Part of the complexity of gathering network information is that there are a variety of sources and types of information that can be gathered. Some of the more obvious locations of network data include:8,2

  • IDS and firewall logs
  • Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), e-mail, and other server logs
  • Network application logs
  • Backtracking of network packets and Transmission Control Protocol (TCP) logical connections
  • Artifacts and remnants of network traffic on hard drives of seized systems
  • Live traffic captured by a packet sniffer or network forensic acquisition software
  • Individual systems' routing and Address Resolution Protocol (ARP) tables, and responses to port scans and Simple Network Management Protocol (SNMP) messages

There are some potential weaknesses—forensically speaking—with network-acquired data. First off, any number of activities or events might influence or affect the collected data in unknown ways, including TCP relaying, proxy servers, complex packet routing, Web and e-mail anonymizers, Internet Protocol (IP) address or e-mail spoofing, compromised third party systems, session hijacking and other person-in-the-middle attacks, and domain name system (DNS) poisoning. 8,2

A second area of vulnerability is with the tools themselves. Most real-time network analysis is accomplished with packet sniffers and protocol analyzers. Packet sniffers are devices that capture network traffic on wired or wireless networks. Although packet sniffers were, at one time, relatively complicated and expensive pieces of hardware, they are now available as free, command line or graphical interface software for a variety of platforms (e.g., Ethereal, tcpdump, and Wireshark). Although a network interface card (NIC) will typically see only packets specifically addressed to it, packet sniffers can place the NIC into a promiscuous mode, allowing the computer to listen in on all communications on a broadcast segment of the network. Special monitoring ports on some switches allow a network manager to monitor all packets even on a switched network. Packet sniffing software in combination with a protocol analysis capability makes a very powerful tool for information security professional as well as network forensic analysts. Protocol analyzers provide an interpretation of the traffic, parsing the bits and bytes into the raw messages from Ethernet, TCP/IP, FTP, HTTP, and other protocols. Packet sniffers and protocol analyzers are at the core of many types of network security and analysis products, including intrusion detection systems, security event management software, and network forensics analysis tools.9

Packet sniffing software is well-known and, by and large, accepted within the digital forensics community. Because real-time data is being collected, however, it is quite possible that some data might be missed (e.g., if the network data rate is too high for the NIC of the acquiring system) or silently lost (e.g., a misconfigured filter might drop certain packets as "uninteresting"). Some forensics tools—such as EnCase Enterprise Edition, LiveWire, and ProDiscover IR—are specifically designed to acquire information over networks but each has limitations, such as the inability to acquire process memory or mounted drives on remote systems.8,1,2

 

The Role of Protocol Analysis: Four Case Studies
Network analysis is new turf for many digital investigators. With this new type of investigation comes new tools, most notably protocol analysis software and packet sniffers. Packet sniffers are an essential tool for incident response and network forensics, generally providing the most useful real-time information about a network.9

Network investigations can be far more difficult than a typical computer examination, even for an experienced digital forensics examiner, because there are many more events to assemble in order to understand the case and the tools do not do as much work for the examiner as traditional computer forensics tools. If an investigator is looking for chat logs, images, or e-mail messages, for example, most common computer forensics tools will specifically find those types of files. Examining live network traffic, however, requires that the examiner understand the underlying network communications protocol suite, be it TCP/IP or something else. While a packet sniffer can grab the packets, and a protocol analyzer can reassemble and interpret the traffic, it requires a human to interpret the sequence of events. 10,8,11

The remainder of this article will present four case studies in which the authors played a role, using different network analysis tools. All of these cases could apply to either network forensics examiners or information security professionals.

 

Case Study #1: Distributed Denial-of-Service Attack
Exploitation of a vulnerable system on a network—particularly prevalent on systems within the .edu domain—is a common way in which to launch other attacks. In a distributed denial-of-service (DDoS) attack, an intruder finds a site to compromise and places a DDoS master program of some sort on the victim host. The DDoS master system runs code—often worms—that automatically and systematically finds other systems to exploit by searching for open ports or services, particularly those that are not secured and/or are being used by application software with known vulnerabilities. The DDoS master places zombie programs on those machines; zombies merely sit and wait for instructions from the master. When the Bad Guy wants to launch an attack, an instruction is sent to the DDoS master system which, in turn, sends messages to all of the zombies in order to coordinate the attack.

After an attack is initiated, the victim site is inundated with network traffic—from hundreds, possibly thousands, of sources. Analysis of this traffic might lead the examiner to some of the zombies. Analysis of those machines might—but not necessarily—lead to the DDoS master system. Even if the DDoS master can be found, the examiner would still have to back track to the original intruder. Each of these steps becomes increasingly difficult.

Packet sniffers and IDS are an important tool in the fight against these types of attacks. In the following case, the system administrator of a server in a college environment was advised by the Information Technology Department that the server (doggie.example.edu) was suddenly generating an enormous amount of network traffic, consuming considerable bandwidth. As a result, the college isolated the server's portion of the network until the situation could be resolved.

The first author was asked to investigate and immediately put tcpdump, a command line Linux packet sniffer, on the network to look at all traffic coming from or going to the suspect machine. The results are shown below:

[root@altamont gck]# tcpdump host doggie.example.edu
12:03:36.016502 doggie.example.edu > 192.0.2.7: icmp: echo reply (DF)
12:03:46.016502 doggie.example.edu > 192.0.2.7: icmp: echo reply (DF)
12:04:37.016502 doggie.example.edu > 192.0.2.7: icmp: echo reply (DF)
12:04:47.006502 doggie.example.edu > 192.0.2.7: icmp: echo reply (DF)
12:05:38.016502 doggie.example.edu > 192.0.2.7: icmp: echo reply (DF)
12:05:48.016502 doggie.example.edu > 192.0.2.7: icmp: echo reply (DF)
12:06:39.006502 doggie.example.edu > 192.0.2.7: icmp: echo reply (DF)
12:06:49.006502 doggie.example.edu > 192.0.2.7: icmp: echo reply (DF)
12:07:40.006502 doggie.example.edu > 192.0.2.7: icmp: echo reply (DF)
12:07:50.006502 doggie.example.edu > 192.0.2.7: icmp: echo reply (DF)
12:08:41.006502 doggie.example.edu > 192.0.2.7: icmp: echo reply (DF)
12:08:51.006502 doggie.example.edu > 192.0.2.7: icmp: echo reply (DF)
12:09:42.016502 doggie.example.edu > 192.0.2.7: icmp: echo reply (DF)
12:09:52.016502 doggie.example.edu > 192.0.2.7: icmp: echo reply (DF)

The output shows that the server, doggie.example.edu, was sending packets to the IP address 192.0.2.7.12 The first thing that leaps out here is the rate at which these packets were being generated; one packet followed by another 10 seconds later, followed by another 51 seconds later, in a repeating pattern. This was, of course, much too regular for a person at a keyboard and was undoubtedly generated by software.

The second thing to observe is that this was a stream of Internet Control Message Protocol (ICMP) Echo Reply messages. Echo Reply messages are a basic part of ICMP and are normally sent only in response to Echo Request messages.13 Note, however, the absence of incoming Echo Requests in this packet stream.

A more detailed look at the contents of the packets showed the following:

[root@altamont gck]# tcpdump -x host doggie.example.edu
12:12:45.016502 doggie.example.edu > 192.0.2.7: icmp: echo reply (DF)

                   4500 0414 0000 4000 4001 cdf9 c0a8 abcd
                   c000 0207 0000 9ca3 1a0a 0000 0000 0000
                   0000 0000 0000 0000 0000 0000 0000 0000
                   736b 696c 6c7a 0000 0000 0000 0000 0000
                   0000 0000 0000 0000 0000 0000 0000 0000
                   0000

12:12:55.016502 doggie.example.edu > 192.0.2.7: icmp: echo reply (DF)

                   4500 0414 0000 4000 4001 cdf9 c0a8 abcd
                   c000 0207 0000 9ca3 1a0a 0000 0000 0000
                   0000 0000 0000 0000 0000 0000 0000 0000
                   736b 696c 6c7a 0000 0000 0000 0000 0000
                   0000 0000 0000 0000 0000 0000 0000 0000
                   0000

12:13:46.016502 doggie.example.edu > 192.0.2.7: icmp: echo reply (DF)

                   4500 0414 0000 4000 4001 cdf9 c0a8 abcd
                   c000 0207 0000 9ca3 1a0a 0000 0000 0000
                   0000 0000 0000 0000 0000 0000 0000 0000
                   736b 696c 6c7a 0000 0000 0000 0000 0000
                   0000 0000 0000 0000 0000 0000 0000 0000
                   0000

 

Breaking down the packets show that these are valid IP packets, each containing a valid ICMP Echo Reply message. But inside the long string of zeroes is the hexadecimal string, 0x73-6b-69-6c-6c-7a. Interpreting these as ASCII14 characters reveals the string "skillz" which, taken together with the Echo Reply messages, is a known signature for the Stacheldraht DDoS zombie. The Echo Reply messages are the mechanism by which the exploited system will communicate with the DDoS master system.15

With this hint, subsequent examination of the server using the netstat command showed that it was listening on TCP port 65000, the avenue by which a Stacheldraht master communicates with its zombies.15 The case for this type of DDoS software was complete and the only thing to do was to totally rebuild the server from scratch.

If these packets show communication between a DDoS zombie and master, what role does IP host 192.0.2.7 play in all of this? That step also required some careful investigation because it was unknown whether that system was, itself, a victim or a perpetrator. The sysadmin and first author looked up the address using simple tools such as whois and dig. That information, plus some calls to the domain registrar and foreign host's ISP, suggested that this was a legitimate user—and, most likely, an upstream victim. The technical contact for this domain was contacted and he stated that his server had been compromised some weeks earlier but that the attacker's rootkit had been removed—or so he thought. The remote sysadmin had, apparently, merely cleaned the server of the known rootkit rather than rebuild the system but had been infected with more malware than just this one piece of software.

The lesson, of course, is that if a system has been exploited, there is no way to know how badly it has been compromised. Upon discovery of the exploit, assume that the system cannot be cleaned but has to be rebuilt. One also has to take care in contacting apparent attackers.

While many in the field recommend that computer forensics examiners take more and more programming courses, most practitioners do not, in fact, write programs; most of the tools available today get the job done and are accepted in courts of law whereas homegrown tools will face the uphill battle of validation. On the other hand, knowledge of network analysis and protocols, and the tools with which to support that activity, are possibly even more important skills for the computer forensics examiner. While there are tools that will capture and display network data, the practitioner needs to know how to properly interpret what they are seeing in the context of their investigation.

Read part 2 of this article in the Fall issue of DFI News. From: Kessler, G.C., & Fasulo, M. (2007). The Case for Teaching Network Protocols to Computer Forensics Examiners. In Proceedings of the Conference on Digital Forensics, Security and Law, April 18-20, 2007, Arlington, VA, pp. 115-137.

 

References

  1. Casey, E., & Stanley, A. (2004), "Tool Review—Remote Forensics Preservation and Examination Tools," Digital Investigation, 1(4): 284-297.
  2. Nikkel, B.J. (2005), "Generalizing Sources of Live Network Evidence," Digital Investigation, 2(3): 193-200.
  3. Shanmugasundaram, K., Brönnimann, H., & Memon, N. (2006), "Integrating Digital Forensics in Network Infrastructures," in Advances in Digital Forensics, Proceedings of the IFIP International Conference on Digital Forensics, eds. M. Pollitt & S. Shenoi, Springer, New York.
  4. Carrier, B. (2003), "Open Source Digital Forensics Tools: The Legal Argument," http://homes.cerias.purdue.edu/~carrier/forensics/docs/opensrc_legal.pdf, April 15, 2006.
  5. Kenneally, E.E. (2001), "Gatekeeping Out of the Box: Open Source Software as a Mechanism to Assess Reliability for Digital Evidence," Virginia Journal of Law and Technology, 6(3). http://www.vjolt.net/vol6/issue3/v6i3-a13-Kenneally.html, April 14, 2006.
  6. Jones, K.J., Bejtlich, R., & Rose, C.W. (2006), Real Digital Forensics: Computer Security and Incident Response, Addison-Wesley, Upper Saddle River, NJ.
  7. Redding, S. (2006), "Using Peer-to-Peer Technology for Network Forensics," in Advances in Digital Forensics, Proceedings of the IFIP International Conference on Digital Forensics, eds. M. Pollitt & S. Shenoi, Springer, New York.
  8. Casey, E. (2004b), "Network Traffic as a Source of Evidence: Tool Strengths, Weaknesses, and Future Needs," Digital Investigation, 1(1): 28-43.
  9. Kent, K., Chevalier, S., Grance, T., & Dang, H. (2006), Guide to Integrating Forensics Techniques into Incident Response, National Institute of Standards and Technology (NIST) Special Publication (SP) 800-86, NIST, Computer Security Division, Information Technology Laboratory, Gaithersburg, MD. http://csrc.nist.gov/publications/nistpubs/800-86/SP800-86.pdf, December 4, 2006.
  10. Casey, E. (2004a), Digital Evidence and Computer Crime, 2nd ed., Elsevier Academic Press, Amsterdam.
  11. Owen, S., Budgen, D., & Brereton, P. (2006), "Protocol Analysis: A Neglected Practice," Communications of the ACM, 49(2): 117-122.
  12. To protect the true recipient of these packets—and another victim of the attack—the actual host address is obscured. IP addresses in the 192.0.2.0 block are reserved for example purposes, per Request for Comments (RFC) 3330 (IANA, 2002). This form of IP address is used in this paper when obscuring the true IP address.
  13. Postel, J. (1981), Internet Control Message Protocol (ICMP). Request for Comments (RFC) 792, http://www.rfc-editor.org/rfc/rfc792.txt, December 15, 2006.
  14. American Standard Code for Information Interchange; see http://www.garykessler.net/library/ascii.html.
  15. Dittrich, D. (1999), "The 'stacheldraht' Distributed Denial of Service Attack Tool," http://staff.washington.edu/dittrich/misc/stacheldraht.analysis, December 14, 2006.

 

Gary C. Kessler, Ph.D., CCE, CISSP, is an Associate Professor of Homeland Security at Embry-Riddle Aeronautical University, a member of the North Florida ICAC (Volusia County Sheriff's Department), and president and janitor of Gary Kessler Associates, a training and consulting company specializing in computer and network security and digital forensics. Gary is also a part-time member of the Vermont ICAC (Burlington Police Department). He is the co-author of two professional texts and over 70 articles, a frequent speaker at regional, national, and international conferences, and past editor-in-chief of the Journal of Digital Forensics, Security and Law. www.garykessler.net

Matt Fasulo is a Special Agent with the U.S. Secret Service currently stationed in Portland, Maine. SA Fasulo has been with the Secret Service since 1998 and a member of the Electronic Crimes Special Agent Program since 1999. During that time, SA Fasulo has investigated numerous network intrusion incidents.

Advertisement
Advertisement