Mastering Windows Network Forensics and Investigation

Steve Anson, Steve Bunting, Ryan Johnson, Scott Pearson

• Editorial: Sybex
• Año: 2012
• ISBN:
  9781118236086
• Edición: 2
• Categoría: Ciencia de la computación
• Categoría: Ciberseguridad

An authoritative guide to investigating high-technology crimes

Internet crime is seemingly ever on the rise, making the need for a comprehensive resource on how to investigate these crimes even more dire. This professional-level book--aimed at law enforcement personnel, prosecutors, and corporate investigators--provides you with the training you need in order to acquire the sophisticated skills and software solutions to stay one step ahead of computer criminals.

• Specifies the techniques needed to investigate, analyze, and document a criminal act on a Windows computer or network
• Places a special emphasis on how to thoroughly investigate criminal activity and now just perform the initial response
• Walks you through ways to present technically complicated material in simple terms that will hold up in court
• Features content fully updated for Windows Server 2008 R2 and Windows 7
• Covers the emerging field of Windows Mobile forensics

Also included is a classroom support package to ensure academic adoption, Mastering Windows Network Forensics and Investigation, 2nd Edition offers help for investigating high-technology crimes.

Part 1

Understanding and Exploiting Windows Networks

• Chapter 1: Network Investigation Overview
• Chapter 2: The Microsoft Network Structure
• Chapter 3: Beyond the Windows GUI
• Chapter 4: Windows Password Issues
• Chapter 5: Windows Ports and Services

Chapter 1

Network Investigation Overview

As mentioned in the introduction, this chapter provides background information to those readers who do not have a great deal of experience in conducting network investigations. Since much of this book will focus on the techniques used to conduct these investigations, a basic working knowledge of the steps required to use them is essential to getting the most out of this text. Those who have an extensive amount of experience in this area will probably be able to skim this chapter and proceed to Chapter 2, “The Microsoft Network Structure.”

With that disclaimer out of the way, we’ll now cover the steps generally involved in conducting an investigation of a network intrusion or similar network-related incident. It is important to note that this section will deal with broad generalities. Every investigation is unique, and it is the responsibility of the investigator to analyze each situation to determine the appropriate investigative approach. Making these decisions and implementing the associated techniques require a great deal of subject matter expertise, and the remainder of this book is designed to provide you with the information and techniques that you will need to be an effective Windows network investigator.

In this chapter, you will learn to

• Gather important information from the victim of a network incident
• Identify potential sources of evidence in a network investigation
• Understand types of information to look for during analysis of collected evidence

Performing the Initial Vetting

The vast majority of intrusion investigations begin with a phone call. Someone, somewhere has encountered something that makes them suspect that they are the victim of a computer hacker. The first thing any investigator must learn is that many of the people who pick up a phone to report an incident are not victims. It is important to conduct an initial assessment of any report and determine its legitimacy in order to avoid unnecessary and unproductive false starts.

start feature

---

When You Are the Victim

This section largely deals with situations where you are working in the capacity of an outside consultant or law enforcement officer, but the questions and techniques discussed still apply to internal corporate security departments or similar groups. All too often, IT administrators, users, and even Security Operations Center (SOC) monitoring analysts leap too quickly to the conclusion that the sky is falling. It is the responsibility of the highly trained security professional (that would be you) to cut to the heart of the matter, provide a reasonable triage of the situation, and either begin the necessary investigation or restore peace and tranquility to the world by telling the people involved, “It will all be OK.”

---

end feature

Since most cases begin with a phone call, it makes sense to perform your initial investigation while on the phone. This saves a great deal of time by allowing you to get preliminary information to determine exactly what resources (if any) you will need to bring to bear to conduct an appropriate investigation into the incident being reported. Obviously, if the reported incident involves classified or otherwise sensitive information, you will need to factor operation-security concerns into your approach. In such cases, you may need to perform even your initial vetting in person at an appropriately secure facility. While each situation will be unique, the following list of questions will provide you with a good starting point for performing your initial inquiries:

What makes you believe that you are the victim of a computer crime? This simple, open-ended question provides you with a lot of information about both the incident and your reporting party. Allow the reporting person to provide you with the story in his own words for a while. Listen for things that indicate the experience and knowledge level of the reporting person. In addition, start assessing the likelihood that an incident has actually occurred. Responses to this question will range from “Our security team was conducting a routine audit of our IDS (intrusion detection system) logs and noticed some anomalies that we found suspicious,” a good sign, to “I received an email and my virus-scanning thing said it was infected,” a not-so-good sign. If the response has anything to do with aluminum foil and alien mind rays, simply refer the caller to the appropriate counseling service—or to your favorite rival agency (you know the drill).

What systems are involved, what data do they store, and were they damaged? Here you are looking to determine whether or not any alleged incident falls within your territorial and subject-matter jurisdictions or your assigned area of responsibility. If all of the computers are located in Spokane and you are a local police officer in Denver, you probably need to end this call with a referral to another agency. Likewise, if you are assigned to a Computer Emergency Response Team (CERT) for a large company and the caller is asking about their mother’s home PC, not their company computer, then perhaps you should provide them with a number for a local IT security firm. Check to ensure that you are the appropriate person to address the alleged incident.

When did the attack occur? While this seems like a fairly simple question, you may be surprised at some of the answers it can generate. It is not at all uncommon for an organization to wait many weeks or months before notifying law enforcement of an incident. Internal politics involving Legal, Public Relations, and other departments can stretch out for long periods of time while the pros and cons of reporting the incident to outside people are debated. This question will give you an idea of how stale the case may be and how long the victim organization has had to unintentionally lose and delete important evidence.

How was the attack discovered, and who knows about the discovery? This question gives you an idea of how likely it is that the offender knows that his activities have been detected. If the victim organization detected a few anomalies that suggest an attack and immediately called you, then you may have the advantage of catching the attacker unaware. If, on the other hand, the attack was discovered because all systems reported U h4v3 b33n H4x0red at bootup, it is a fair guess that the attacker already knows that the victim is aware of the incident. An additional consideration here is that a large percentage of computer incidents are perpetrated by inside users of the impacted systems. Thus, if the victim organization has already circulated emails announcing that they have detected an attack, it is a fair guess that your as-of-yet-unidentified suspect has also been made aware of the discovery.

Did the attacker seem to have familiarity with the network or systems impacted? This question can be used to begin gauging the competency of the attacker, as well as to try to determine whether you are dealing with a rogue insider or an outside attacker. If the attacker gained access to the system using an old administrator account and in one command line copied a file from C:\files\secret stuff\my special projects\stuff I never told anyone else about\project X\plans.doc, then you can bet that either the attacker had inside information or the attacker has been to this system before and this is simply the first time that the victim has noticed.

After you have an idea of what has transpired, you will be in a position to make suggestions to the caller to help preserve any evidence that may exist. The instructions that you give in this regard will depend on the specifics of the case, and by the end of this book you will have the knowledge necessary to make that determination. In many cases, the best advice is simply to suggest that the computer be left powered on and that only the network cable be disconnected if necessary to prevent further damage. Again, there will be situations where this is not the best idea, but each case must be analyzed independently.

Meeting with the Victim Organization

Once you have gathered enough information to determine that some type of incident occurred and that you are the appropriate person or agency to respond to that incident, it is time to get your investigation under way. At this stage, it is best to arrange a meeting with the reporting person and anyone else who has relevant information about the incident.

start feature

---

Meetings about Meetings

It may be in your best interest to also schedule a one-on-one meeting with the reporting person prior to including anyone else in the conversation. This gives you an opportunity to question that person in a little more detail before moving into a setting where his peers and bosses will be watching. If at this private meeting he realizes that a mistake has been made (such as, “Oops, we weren’t hacked; I accidentally deleted those files”), then he can get out and call the whole thing off. If such a realization is made in front of a roomful of people assembled to discuss the big incident that has been discovered, the reporting person’s fight-or-flight instincts may kick in and lead him to provide you (and everyone else) with false or misleading information to save face.

---

end feature

If possible, the first face-to-face meeting with the victim organization should take place in a quiet meeting room with at least one whiteboard available. After the initial introductions, have the reporting person explain what is known about the incident in very broad terms. During this meeting, there are some very specific pieces of information that you will need to obtain, so don’t let the initial overview get into too much detail. After everyone agrees on a very general view of what you are all gathered to discuss, take control of the meeting and begin to gather information in a systematic manner. The following sections will give you some ideas on information that you need to ascertain, but keep in mind that no two investigations will be exactly alike.

start feature

---

The Big Meeting

Once word gets out that law enforcement or security consultants are coming to interview staff about a possible computer crime incident, things can spiral out of control within the victim organization very quickly. Everyone who thinks they are important will insist on attending, and the initial introductions will sound like a job fair as everyone explains what their unit does and how important they are to the overall mission of the organization. You will likely encounter representatives from the Human Resources department, senior managers, chief information officers, company lawyers, computer incident response teams, outside consultants, and all other imaginable players. Just take it all in and note who the key players really are. This is your opportunity to once again size up the people with whom you are dealing. Also, never forget that many computer crimes are committed by people within the victim organization. Don’t reveal too much about your thoughts, techniques, or plans in these types of meetings, because the perpetrator may be sitting in th...