Chapter 5

“After all, we are nothing more or less than what we choose to reveal.”{99}

—Francis Underwood, House of Cards

In the previous chapters, we covered some basic forensic concepts. Now it’s time to focus on the technical aspects and engineering tasks of a forensics investigation. At this point, you should have a general understanding of how to build a team, develop a forensic lab, and create a manager’s view of a forensic investigation. This chapter focuses on what is involved with a forensics investigation from the beginning to when you hand off your results in the form of a forensic report to the party requesting your services.

In this chapter, we first look at items that should be on your pre-investigation checklist. Next, we look at the process of opening a forensic case and best practices for logging work. We cover evidence-handling topics such as search and seizure, chain of custody, and how to bag artifacts discovered during the investigation process. We also look at how to set up an investigation for capturing digital footprints left by devices. The final part of this chapter looks at how to properly close a case and develop professional forensic reports. Many topics are developed more fully in the following chapters because our focus here is on the investigation process.

The steps for a generic digital forensic investigation are as follows:

Determine whether an incident has occurred.

Identify any clues that have been left behind.

Initiate a preliminary assessment of the situation and identify potential evidence.

Search and seize artifacts with potential evidence.

Collect evidence and hand off for potential legal use.

Conclude active involvement.

Develop a forensic report.

Let’s kick things off by looking at everything to consider before starting an investigation.

What incident is being investigated?

Who is involved?

How does it impact the organization?

What artifacts are involved?

Are there any politics to be aware of?

Are there any clearance requirements?

Next, you need to understand who the first responder was; you also need to get a detailed understanding of the current state of all systems involved with the investigation. The first responder is not always the first person on the scene. It is usually the first person who realized an investigation needs to occur. Many times, when there is a failure in collecting evidence, it occurs because the first responder did not follow an acceptable procedure. That is why it is important to ensure your first responder has been trained. This is normally the minimum amount of forensics training, in our opinion, every organization needs. We look at the first responder more closely in this chapter.

A first responder must be able to scope the level of effort required for your team to achieve the goal agreed upon for the investigation. This person also needs to establish a state prior to a forensics investigation. A first responder will want a complete asset list for all devices in question and enforce a process to add or remove devices from this list. If this list hasn’t been established, you may have to become the first responder by documenting your findings using video, photography, and documentation of each artifact of interest’s current state.

Following is a list of common things you need to capture to ensure you have solid documentation of the environment you are being asked to investigate. Every entry needs a timestamp and must be signed off by the investigator.

List of first responders with contact information (if applicable; this may be your team)

Asset list for artifacts of interest

An order of volatility for artifacts of interest

The electronic serial number of the drive and other artifact-specific data

A record of any system clock drift

Video, photograph, or sketch of the scene of the incident if no other methods are available

Contact information for any witnesses

You need to specify a technical lead to represent the group during the investigation. This person should be the point of contact regarding any questions and concerns. Other roles that could be filled are photographer, evidence manager, evidence documenter, examiners, expert witnesses, attorneys, and other decision makers. It is important that anybody designated as an investigator has knowledge of standard evidence-handling procedures to avoid complications both from how he performs the investigation to challenges from opposing counsel against his qualifications. The lead may also act as the main contact for communication between the investigation team and outside parties to avoid interrupting the investigation process. This is very similar to the process of developing an incident response team described in the preceding chapter. This forensic team may also act as the incident response team or be a completely isolated group, depending on the situation.

The next step for preparing for an investigation is validating that you are authorized to access every system on the asset list. In Chapter 1, “Digital Forensics,” we described some of the US laws that protect device privacy. You need to have a formal document that assures you have clear access to every device, to protect yourself from violating some type of privacy law. You may need to obtain necessary warrants for search and seizure. Remember that warrants can be issued for very specific areas, such as a room, or can be broader, such as for an entire company. Make sure to ensure that you are working within the region specified by the warrant. We look at this process a little more later in this chapter.

If you are expected to access systems on a live network, such as a firewall or router, you should obtain a network diagram and establish what type of access you will be granted for your investigation. You may be told to request data, and another authorized person will be used to obtain it for you. There is risk of data contamination or gaps in the data chain of custody when introducing other parties to obtain data you plan to use for your investigation. You should push to have a forensically trained analyst assigned for any data abstraction and make sure the entire process is documented. You need to capture details about the process for abstracting the data, which is covered later in this book, depending on the device being investigated. Details on how to obtain data from network devices are covered in Chapter 8, “Network Forensics.”

Finally, you need to calculate the level of effort to perform the work. You should consider the tools, manpower, and skills and make sure they fit in the scope of work. Once again, you may find that you don’t have the right tools or people for the job and need to consider outsourcing some or all of the work for the case.

To summarize the pre-investigation, you should answer the following questions:

Are you going to be the first responder, or who is the first responder?

Are you qualified for this case, and do you have the right tools?

Does the level of effort make sense for you to proceed?

Are you authorized to work on this case?

Is there a better option than using your services?

Are there potential challenges or legal issues that need to be addressed before proceeding?

When the answers to these questions give you a green light for moving forward, you can open a case and start logging your work.

Date and time

Place and location of incident

Whether the evidence is on a volatile system or nonvolatile system

Details of persons present at the crime scene

Names and identification of people who can serve as witnesses

Documentation, pictures, and videos

There isn’t a wrong way to take notes while working on a case or some type of official standard. Everybody has her own way of note taking, so just make sure to document everything using the method that makes sense for you. The more notes you take, the better data you can pull from for your final forensic report. Also, limited notes may be questioned by opposing counsel, thus putting your investigation practices in question. At the very least, use some precreated templates for investigation forms using Microsoft Word or OneNote. You can find some at www.sampletemplates.com/business-templates/forensic-report.html.

We recommend using both a physical and a digital journal. A physical journal allows you to take quick notes and sketch the incident or crime scene. There are digital options for accomplishing the same goals, such as videotaping or photographing the crime scene or using drawing software. Having both digital and physical versions of your notes gives you the flexibility to be ready to take notes regardless of the situation at hand. For example, it may require more time to boot a laptop versus quickly using a voice recorder or physically jotting down some notes about a situation. A small voice recorder may also be helpful to capture quick verbal notes about what you see or are doing during the investigation.

One free tool available in Kali Linux is Autopsy, which we covered in Chapter 3, “Building a Digital Forensics Lab.” Autopsy is a collection of tools that can be accessed using a simple GUI in Kali Linux. The main use of these tools is to analyze the disk images that have been collected in the investigation, but it can also be your case management tool if you are looking for something free and easy to use. To start Autopsy in Kali Linux, go under the Forensics tool section and select Autopsy. This brings up a command-line prompt stating you can now access the GUI using the address http://localhost:9999/autopsy. This means the Autopsy application is running and listening on the local computer using port 9999. Open the Iceweasel browser and go to that address to pull up the Autopsy main dashboard, as shown in Figure 5-1. Do not close the command-line terminal because it will terminate Autopsy.

Say you are starting a new case and want to use Autopsy as your case management tool. After you access the dashboard, click the New Case button. You are asked to give a case name, description, and the names of the investigators involved with the case. Fill in that information and click New Case. A new case is created, and you see where the files will be stored on your Kali Linux installation. Figure 5-2 shows what happens when you create a new case in Autopsy.

Next, you need to add a host. A host represents the device being investigated. Click Add Host and fill out the description of the host device. Some data fields are optional, but it is recommended you include as much data as you can. Next, you are asked to import an image file. Figure 5-3 shows the page you see in Autopsy when you are at this step. Click Add Image File to import your image. You need to have access to the image file to import it into Autopsy.

You can also create a timeline for the file activity. Think of this as a way to log every time the artifact is accessed during your investigation. As you investigate the file, you can add notes similar to a digital journal. This can be done using the notes for the specific image or using the event sequencer. For most of the examples in this chapter, we use the event sequencer like a digital journal. There are better programs for this purpose, but we are just using this tool to demonstrate the digital forensics journal concept. Figure 5-4 shows the event sequencer in use. Notice that two events are already logged in this example.

There is a lot more you can do with Autopsy, but this brief introduction should give you an idea how a case management package works. For professional work, we recommend other popular options such as Digital Forensic Framework (DFF), Open Computer Forensics Architecture (OCFA), X-Ways Forensics, and EnCase. You should try out a few options to see which best supports your investigation style. Any of them will likely be more effective than using a notepad and paper to manage your investigation. Autopsy can get the job done if you find you like it. Check out http://resources.infosecinstitute.com/computer-forensics-tools/#gref for a list of some popular case management software options.

The first responder for a forensics investigation should aim to accomplish the following tasks. Many of these items were mentioned in the steps for logging a case.

Block off the area involving the incident.

Document all systems involved and potential systems to be investigated.

Photograph and record all details of the system’s current state.

Gather names of any people who could be witnesses.

Assess any dangers or threats to the investigation.

Engage any required outside parties such as authorities or data owners.

Alert the incident response team.

Decide the next course of action (outsource, investigate with internal services, etc.).

Your team may become the first responder or be called in to take over the investigation, so you will need to engage with the first responder. If you are not the first responder, you need to answer the questions presented earlier in this chapter and open a case. Your logging starts with the handoff, so any case files you create include assumptions and details that were obtained from your interview of the first responder(s). It is important to capture as many details as possible and label them as data from the different people you interacted with; this information includes the first responder team and contact information for those individuals in the event you or somebody else needs to question actions that occurred before your team was involved. You should expect a different investigation team to ask you similar questions if you are the first responder who is handing off an investigation to a different forensic group. Remember, it is still considered the responsibility of all those involved to ensure the investigation is conducted properly and fairly.

Some tools you will likely need as a first responder are the following. You should include these tools in your forensic jump bag, as covered in Chapter 3.

Powerful laptop (two recommended) with Windows and Linux (ensure that it is sanitized, meaning that is clean of malware, up to date with patches, and configured with proper security settings)

Large external hard drives for duplicating lots of data

USB memory sticks for quick copies

Hard drive write blockers (for example, using a Logicube-MD5, a portable drive duplicator with write-blocker, or write-block software installed on the laptops)

Digital camera

Kali Live CD and Live USB

Four-port hub, not a switch

Chain of custody, disclosure, and permission forms

Assorted tools and hex drivers

Portable label printer, notebook, voice recorder, pens

Crime tape

You should secure the area using something that makes it obvious that the area is off-limits. Crime tape is a common tool used for this purpose, as shown in Figure 5-5. It may sound strange for you, as a network engineer, to carry around and close an area with crime tape, but it gets the message across visually to everyone: “Do not mess with this area.” You also want to monitor the area until your forensic team is able to either transport the artifact(s) to the lab for investigation or capture forensic-quality images in the event you are not permitted to remove the devices. Any gaps in monitoring could be interpreted as potential times for contamination to your investigation, which means an opportunity for an outside party to impact the evidence. You need to keep a log of the parties responsible for monitoring the contained crime scene and include their contact information in the event there are any questions about the scene being compromised. Best practice is using somebody with legal authority, such as a security guard or police officer versus a general employee of the company.

You need to have a digital camera and use it to photograph everything about the artifacts of interest. In Figure 5-5, for example, you would want a clean photograph of the monitor without the crime tape to show what programs are running. Remember from Chapter 1 that it may be illegal for you to access a system without a warrant or the system owner’s permission, but one exception is what is publically viewable. For example, that includes what can be seen on the monitor, if the officer/investigator has a legal right to be there and the discovery was done by chance. Note that this is not legal advice and applies to US-based laws. You also need to photograph the devices plugged into the computer and any network cables that plug into a network jack or networking device. Video recording and sketches are useful for this as well. Anything recorded should be included in your case journal.

Looking back at the Autopsy example, you need to include images of this asset’s state before you create a forensic copy or perform other investigation techniques. In Figure 5-6, we created a log specifying the data originally captured about the device and location of the photographs taken by the first responder. It would be ideal to include a lot more details, but we are just providing a simple example for learning purposes.

You need to repeat this process for every asset being considered for the investigation. After all devices are identified, you should have a decent idea of the potential level of effort to complete the work required for this investigation. You may be unsure about the time required to properly investigate some devices. You may also assume that a device will be simple but later run into complications, such as corrupted hard drives or encryption that can impact your timeline. Outside the many factors that can impact your investigation, you should at least be able to make an attempt at generalizing the investigation requirements and proceed with a decision on how you will work on this case. If you choose to hand off the case, the handoff shouldn’t require much effort because all your notes are stored within your case management software.

You are likely to have many different device types that are identified as targets for the investigation. We included chapters dedicated to some of the common device categories you are likely to see. Those topics include various forms of Windows devices, Linux systems, IoT devices, networking equipment, mobile devices, email servers, and social media. Some devices may fall outside these topics; however, we feel the tactics covered here should give you enough steps to help you proceed with investigating pretty much any digital asset you will encounter. Regardless of the nature of device, if it is a digital asset, it is likely to have some form of memory, operating system, and other technology that mimics how standard computers function. We always recommend doing research on whatever asset you plan to engage because technology will continue to change after this book is published.

It is important to know how the evidence will be perceived by the parties who will be viewing it. Digital evidence in general has challenging aspects. First, many people believe it is hard to handle and is chaotic in nature because it is constantly changing. For some artifacts, this is true, depending on how volatile it is. The volatility of an artifact makes it seem fragile and sometimes hard to trust as absolute truth. This means many legal groups view digital evidence as circumstantial or hearsay, depending on how well you can back up its authenticity. Opposing parties will likely play to this weakness by attempting to make your digital evidence seem abstract or an incomplete view of what is being proved to have it removed from the case. This is why we continue to stress the importance of logging everything during the entire investigation. Report only the facts and attempt to prove your case using as many referenceable details as possible. We look at this issue in more detail later in this chapter when we cover how to deliver a forensic report.

Our next topic focuses on the different states of the assets that you have logged in to your case management system and plan to investigate. Chapter 6, “Collecting and Preserving Evidence,” goes into detail about what you must do before you start investigating an artifact; this chapter focuses on the investigation steps only. The main rule you must always remember, which is the theme for the next chapter, is: Never investigate the original artifact. Any changes you make are likely to be considered contamination, which ruins the legal use of evidence that your team spent time to collect. Instead of investigating the original, you should always perform the following three steps on any digital artifact you collect:

Make a few forensic copies of the artifact.

Hash validate those copies.

Enable write protection before investigating the copy.

The advice to always work on a copy may seem obvious, but some of the cases we work on are thrown out because the original device was tampered with, modified, or had the potential to be tampered with or modified in some manner. If you decide you want to pursue a career as an investigator, we suggest you study a few cases where digital forensics are instrumental in a courtroom decision. We hit these topics hard in the next chapter. The process to perform these steps depends on the power state, or whether the system is powered on or off. Let’s look at this concept in more detail from an investigation standpoint.

Maintaining the power state of a device is critical for capturing all the available data on that device as well as not modifying the asset. Systems that are powered on are likely to have volatile data, which is data that would be lost if the system is powered off. Examples of volatile data include data in RAM. Capturing this data can be important because many forms of malware do not install themselves on the hard drive. Other examples are network tables in a router or running processes on a desktop. Powering down a system can not only destroy this data, but the power cycle can modify the asset; this means that you, the investigator, changed the system’s state since the party of interest used the system. For example, if you hash validate a system before and after rebooting a system, you are likely to see a change in hash, which represents contamination in most legal matters. Hashing and image validation concepts are covered in the next chapter.

Data should always be collected based on order of volatility. This means that highly volatile data should be collected first. This data can be lost when a device is powered off and is potentially valuable to the investigation. We base our volatility list on the Internet Engineering Task Force (IETF) document RFC3227 found at https://tools.ietf.org/html/rfc3227#section-2.1. According to the IETF, the following is a list of most to least volatile data artifacts. Note that the weight is based on how volatile and valuable the data on the artifact could be.

1. Registers, Cache

CPU cache and registers are considered extremely volatile because they are constantly changing.

Changes occur in nanoseconds, so you need to capture and label this data assuming another capture will be different.

2. Routing Table, ARP Cache, Process Table, Kernel Statistics, Memory

These data artifacts represent data in network devices and parts of the computer that are in constant change.

This data will be lost if power is out and likely to change even while not in use by the administrator.

3. Temporary File Systems

These files could be lost if the power goes down.

The volatility factor isn’t as high as the previous examples because the data tends to linger around and is possibly recoverable even after a loss in power.

4. Disk

Data stored on a disk is designed to be saved, so there is a low chance of that data being lost.

Hard drives can vary in nature, and there is always a possibility of failure.

Newer solid state drives include TRIM and wear algorithms that could modify data. This topic is covered in more detail in Chapter 7, “Endpoint Forensics.”

5. Remote Logging and Monitoring Data That Is Relevant to the System in Question

Data on logging and monitor systems could change, but as with hard drives, logs are typically stored.

It may be more likely log data is lost versus data on a hard drive. Log data is considered less valuable, making this lower on the volatility list regarding investigation value.

6. Physical Configuration, Network Topology

These items are not volatile and likely offer little forensic value.

7. Archival Media

This is similar to the artifacts you have already collected; however, these are older items, which makes them even less valuable.

Figure 5-7 shows the order of volatility for endpoint devices. You may adjust items based on the case you are investigating or level of effort to obtain data. For example, obtaining RAM from a system that is likely not used by the suspect may not be as important as obtaining a copy of a hard drive pulled directly from the suspect’s system that is powered off.

You need to create separate new artifact notations in your case management program for each item pulled from the laptop. Best practice is to keep everything organized, so any artifacts from the sample laptop should be maintained under a folder relating to that laptop so that data isn’t mixed with other devices being examined. If artifacts are pulled out of the RAM for the laptop you are investigating, you should create a new folder to contain those artifacts that lead back to the RAM. Think of your logging system as a parent/child relation in which any new artifacts are children of the parent item that they were pulled from. We find many investigations generate a ton of logging, and things can easily become a mess if proper organization tactics are not followed from the beginning. This is why leveraging a case management program is so critical.

Regarding use of the forensics management platform Autopsy, you can also upload captures such as a .raw RAM dump pulled from the sample laptop, as shown in Figure 5-8. Once again, we have simplified the process and details with the goal of providing a generic example of the investigation process. Also, know that other forensic packages make the documentation and logging of artifacts easier than Autopsy. We are leading with Autopsy because it’s free and available on your Kali Linux lab system. You will likely find that a commercial software package offers a lot more logging options.

We go into more detail about how to pull data off endpoints in Chapter 7. This also includes where to find data of interest and tools you can use to accomplish your investigation goals for endpoints. What is critical is that data is admissible, authentic, reliable, and complete in order to be considered legally valid under most legal systems. This includes proving you performed the proper steps to identify that evidence without introducing contamination, and you didn’t violate any laws during the process. Next, we look at the legal process of obtaining assets of interest.

In general, courts see digital data as a tangible object you are requesting access to. Digital evidence is different from physical evidence because it can be changed more easily. Also, most courts consider computer records as hearsay evidence, meaning it is secondhand or indirect evidence. There are exceptions that vary depending on the court, such as a business record that directly demonstrates a violation of law could be considered admissible as more than hearsay. Challenges against this evidence could be based on how authentic and trustworthy the evidence is, including the chain of custody that is documented when the evidence was evaluated. The legal right to assess the data is also likely to come up, which brings up the topic of warrants. Once again, we are not lawyers, and this is simply our opinion and advice. You are responsible for seeking out the information that may be applicable to your situation.

The steps for requesting a warrant depend on the legal system you are interacting with. For our first example, say our investigation is happening in Philadelphia, Pennsylvania. In this case, we base our decisions on the laws posted at www.rcfl.gov/philadelphia/request-assistance. Know that it is best to include a legal authority versus just trusting a website, but we will skip running our case by a legal professional for this example. According to this website, we can’t submit more than five evidence items per request without prior approval from the Philadelphia Regional Computer Forensics Laboratory (PHRCFL) director. For this example, we would look at what the first responder discovered and attempt to prioritize and group devices in order of need for our warrant(s). The website also lists the following warnings that should be considered from nonparticipating agencies:

Cellular phones: All nonparticipating agencies must process their cell phone requests through the Cell Phone Kiosk before making a request to the PHRCFL for a laboratory examination of a cell phone.

Loose media: All loose media (DVDs, CDs, floppy disks) must be processed using the Loose Media Kiosk.

Audio/Visual Enhancements: No requests will be accepted for any audio/visual enhancement work.

Locked Devices: No requests will be accepted for any locked devices including JTAG services.

We are not legal specialists, so we would require a legal team to make this request on our behalf and assume such a team would fall under a nonparticipating agency. Because we are not lawyers, we would let the legal team handle this part of the warrant request process. What is important to you, as a network engineer, is what the legal group informs you that you can and cannot submit for a warrant to gain access to. What you need to know from the legal team is how many artifacts you can submit, what types of artifacts would be considered acceptable versus not acceptable to request access to, how long you have access to those artifacts, and what the warrant would grant you access to if it is successfully created. We recommend hosting a meeting between your forensic team and the legal team to confirm these details so that the right information is processed for the warrant request. Many forensic teams include legal specialists within the teams for this purpose.

The person filling out the request should be prepared to answer some common warrant form questions. The actual questions you see when you go through this process will vary based on the court system you are interacting with. Most warrants require some form of probable cause. This could be based on many factors, and it is recommended to leverage facts that are crystal clear versus reasons that could be easily challenged. For example, basing your probable cause on an IP address traced to a residence would probably be considered weak because that IP address could have come from an unsecured residence that anybody could have accessed to commit the crime. You should be prepared to have an opposing legal team and judge question any probable cause you included as a reason for the warrant by having hard evidence that is explained with details in the warrant request form.

Here are questions to be ready to answer when filling out a warrant:

Who are you investigating?

What are the artifacts of interest?

Can they be removed without harming people or the business?

What is the location of the artifacts?

Is there any offsite storage of data or cloud usage?

Who is your employer, and what is your experience in forensics and legal matters?

Are there any badge numbers or requirements to be authorized to fill out this form?

What are the case facts?

Are there other warrants related to this case?

What do you expect to find?

Is there evidence of probable cause?

For our second example, we look at the state of Kansas. You can find an example of a warrant form for the Kansas District Counter at www.rcfl.gov/heart-of-america/documents-forms/searchwarrant_computer.doc. Figure 5-9 shows one of the pages from a warrant request form. You should spend time searching online for warrant forms in your area of work to become more familiar with what you need to properly request a warrant.

Many courts define certain types of content and sometimes assign weight to that content; for example, calling out “child pornography” would probably receive more of a push for a warrant than “sexually explicit conduct.” The reason is that child pornography is likely to have laws with steep penalties versus sexually explicit conduct, which could possibly be legal by state rules but a violation of corporate policy. Figure 5-10 shows how this language could be included in the warrant process to define different types of crimes and terms. Keep in mind that if you are using language incorrectly in a legal manner, your entire investigation can be considered to have no grounds or merits. For example, I was involved in a case (I have changed many of the details here) in which a forensics investigator launched a lawsuit that suggested my client copied the product it was building, which meant my client was infringing on existing patents. The digital evidence and the investigator’s own case stated my client created an inferior copy to a much superior original product. The nature of the lawsuit stating that my client created an inferior copy was the start of some legal Olympics the lawyers used to prove that all the digital evidence presented proved my client was not in violation because an inferior copy is very different from an exact copy.

If the warrant is successfully created, you should see the rules clearly stated regarding what has been granted. It is common in the United States for a court system to issue a limited phrase to the warrant, which allows the police or investigator to separate innocent information from evidence. It is also common that new evidence is discovered during the investigation, which could require a new warrant and case against the party being investigated. For example, you could be investigating a system with the understanding that there is illegal drug content but later discover child pornography images. In this situation, you are likely going to need a new warrant to expand the existing warrant, thus giving you more room to search for the new evidence. We once again repeat that this is not legal advice, and the situation is different based on the location of the crime. Figure 5-11 shows a warrant granted in the state of Pennsylvania.

After you identify and obtain the artifacts of interest, you need to make sure they are transported properly. This takes us into our next topic: chain of custody.

The first step for starting the chain of custody process is establishing a log of how the system is before you interact with it. This is the precustody state. Just as with the first responder, you need to document everything about the device using video, photography, and a journal. There is not a standard for documentation, so you really can’t do it wrong regarding the style you use to document the artifact. It is import that you include enough details to determine what the system was like before the investigation, be able to clearly identify it from similar artifacts, and be able to recognize various features and settings, such as what it was plugged into. NIST offers a sample chain of custody document you could use, as shown as Figure 5-12.

You will find yourself in different situations as you are involved with investigations. Sometimes, artifacts are easy to transport, such as a laptop or mobile phone. For those situations, you need to use a hazmat bag and make sure it is labeled properly. Why not a regular bag? You ideally want a hazmat bag that can prevent charges from static build-up to prevent damaging the artifacts. You also want to validate what temperatures are expected if the artifact is bagged; if it’s powered on, could it generate heat if contained in a tight bag or storage container? You may need to use a cooler in those situations to avoid heat damage. If you’re looking for official standards around the proper hazmat bag, you could consider bags that are MIL-STD-3010 4046, EIA 541, EIA 625, or ANSI/ESD S20.20 certified. Figure 5-13 shows a common hazmat bag for a computer hard drive.

The process for bagging and tagging should be pretty straightforward. You should consider collecting anything that could store data as well as documents or manuals for those devices. This means anything such as a GPS, backup system, software, and IoT devices. We recommend assigning one person for collecting and logging assets to simplify the chain of custody documentation process. That person should make sure to include the current date, time, any serial numbers, unique features of the asset, and his name on each bag containing an artifact. If the artifact is believed to have wireless or cellular services enabled, you likely need to use some form of Faraday cage designed to block these types of communications. Some hazmat bags can provide Faraday cage functionality. If they don’t, you may need to move the bagged artifact into a storage container that prevents these communications. The hazmat bag shown in Figure 5-13 is priced around $70 US because it has Faraday capabilities.

Tracking who has access to the bagged artifact is critical. You need to maintain a digital log similar to what we have shown with Autopsy. Any time an artifact is accessed or moved, there should be a log of the event. You may have a dedicated log for chain of custody or include it with your forensics management software. When the asset is not being used, it must be contained in a secured storage facility typically called an evidence room. We discussed the evidence room in Chapter 3. Your chain of custody journey should be directly linked and enforced as a requirement before accessing an evidence room storing any artifacts being investigated.

In some cases, you likely can’t bag and tag an artifact. For example, removing the device would impact the company in a negative way, the device is unable to be moved, there is data on the device not related to the case that can’t leave the location, and so on. Examples include network devices such as routers that may have evidence of the crime but also are currently routing live traffic on the customer’s network. In these situations, your approach to investigate these devices will likely be different. Let’s look more closely at this type of situation next.

In Chapter 8, we dive deeper into investigating networks, including tools used to detect threats within live traffic as well as historical captures of security events. An example of a historical capture is replaying a packet capture that recorded an event triggered by a security tool. For this section, we focus on the investigation process you should consider as you plan your approach to abstract evidence from these types of network-based devices. Think of this as obtaining records and data about what is happening between devices versus evidence pulled from end-user systems.

Before diving into a network, you should first understand the scope of what is considered in play. This means obtaining a network diagram, understanding how data flows from system to system, recognizing the types of data being processed, and highlighting which networks are to be considered for investigation, along with any devices found on those network segments that should be listed on your asset sheet. Devices that are not on the asset sheet but are going to be considered for the investigation should be evaluated using the preinvestment procedures covered earlier in this chapter. You may not be authorized to evaluate devices on the network for privacy or other reasons; however, you may have the green light to evaluate their network footprint. You still need to log any device on your asset list, regardless if you plan to access it and comment about its role for the investigation. This way, if you later discover one or more of these devices needs to be investigated due to recently discovered evidence, you can quickly identify what you currently know about the device.

You can use various tools to discover and validate devices on a network. The most common tool available on Kali Linux is Nmap, which is short for Network Mapper. The simplest use of Nmap is typing nmap <scan type> <options> <target(s)>. For example, you might type nmap 192.168.1.0/24 to scan the entire 192.168.1.0 class C network. Another use could be typing nmap -A thesecurityblogger.com to enable OS and version detection for scanning thesecurityblogger.com website. Figure 5-14 shows a scan of a simple class C subnet with Nmap.

There are many ways to use Nmap, which you can find at https://nmap.org. In Chapter 8, we look deeper at using Nmap with Wireshark and SNORT to detect various forms of network attacks. From an investigation viewpoint, it is important to know that performing Nmap scans could trigger existing security solutions as well as add your digital footprint to the security logs you want to investigate. Mapping a network is a common step that attackers use after they breach a network; therefore, you need to make sure you are authorized to perform scans so that you don’t upset the security group monitoring the network you are investigating. You also should document your device’s network settings to ensure you do not impact the investigation in a negative way. You could use filters to weed out your device while searching logs and make notes about the IP address you used in the case file so that other investigators know what impact you had on the network during your investigation.

You can also run Nmap by downloading the Windows version of the software. There are also many other scanner tools available, such as Angry IP Scanner located at angryip.org. Whichever tool you decide to use, make sure to log your results in your case management tool. For our example, we use Angry IP Mapper and upload the results, as shown in Figure 5-15, to our forensic case file. We make comments on the case file about any device found and label that device with relevant information regarding our investigation. For example, we may find that the device at 192.168.40.5 is a server that is currently being investigated, and the device at 192.168.40.10 is a laptop owned by an employee who is not part of the investigation. We want to make a note of the device so that later if we find evidence of this device during our network investigation, we could correlate any time the device was seen to see whether it needs to be evaluated based on probable cause found during the investigation.

You will likely want to diagram the network you are investigating based on what you find as you perform your investigation, regardless of whether a diagram is provided by the customer. Many times, people don’t know what is on their network because networks constantly change after a diagram is developed. Many investigators use Microsoft tools like Visio, PowerPoint, or Adobe products to develop diagrams. One free version you could use is SolarWind’s Draw.io at www.solarwindsmsp.com. This simple tool is cloud based, so you don’t install software. It is effective at accomplishing your diagram needs. Other options are LucidChart and Dia Diagram. Figure 5-16 shows how to use the Draw.io software for building a basic diagram.

You will likely identify many security and network tools that contain logs. You need to collect logs, routing tables, application data, and any records from these tools that could be relevant to your case. Records need to be time stamped, labeled according to where they appear on your network diagram, and indicate who collected the data. Sometimes you are provided the data by an outside party, such as the asset owner, but best practice is to have somebody from your investigation team involved with the data collection so that it can be logged and validated properly. If you need to use another party to pull the data you are requesting, make sure to label that data with that person’s contact information, time of work, and where it came from. We describe how to collect the various types of network data in Chapter 8.

Each piece of data should be organized in a separate folder pertaining to the device it was pulled from and filed in your case management program. One method we use is to create a folder representing the network and place any documentation used to validate the entire network, including scans and diagrams. Within that folder, we create folders for each device tagged and store any logs, packet captures, IP tables, and so on we have obtained for the device in that folder. This approach keeps our findings organized, simplifying linking data to where it was obtained. There is no wrong way to organize your findings outside of doing something that causes you to lose files. Looking back at our Autopsy example, we would create events within the software and label the folders storing each data artifact being captured.

One challenge you are likely to run into is data that is not local. This could be artifacts that are in a remote data center or cloud service. Today, many companies utilize the cloud for data storage and applications. Almost everybody is using some form of cloud service. Services range from cloud email like Gmail to cloud storage such as Dropbox. The problem with cloud technologies is that most were developed well after digital forensic frameworks and practices, so most current forensic frameworks assume you have access to the artifact. This same concept applies to legal requirements because they are currently uncertain on how cloud forensic rules are defined in most legal systems. In particular, the question of how much access a cloud provider should provision continues to come up because hardware being used tends to host multiple customers who have nothing to do with the investigation at hand. To summarize the cloud investigation challenge, it comes down to the fact that the decentralized nature of data processing causes enormous technical and legal challenges.

There has been work in the field of cloud forensics, such as the NIST NISTIR 8006 report. This report highlights 65 challenges and 9 major groups that forensics investigators face in gathering and analyzing digital information stored in the cloud. Figure 5-17 illustrates the various challenges NIST pointed out in this report.

The first challenge you should expect to face when investigating cloud services is the inability to preserve the potential crime scene because it’s in the cloud. The second challenge is a pushback and unwillingness from the cloud service provider to provide data you are seeking, such as application or network logs. This includes challenges to be granted a warrant to access data within a cloud environment. Due to the lack of data received, your results are likely to be incomplete, so all evidence may fall under a hearsay view if you are lucky. Fragmented data can also mean a lack of data or altered metadata, which once again causes the evidence to be incomplete. Any of these issues are likely to be brought up by opposing counsel if digital evidence is used from a cloud resource. From a legal view, expect challenges such as multijurisdiction, chain of custody, and privacy issues to come up. Obtaining warrants to investigate large cloud environments is challenging.

With all these challenges in mind regarding cloud, our recommendation is to first disable or cut off service immediately to any asset you want to investigate. This way, you ideally prevent changes to local systems that are cloud connected, permitting you to pull the last connected state off that system. Basically, you should attempt to remove cloud technology from the equation and log the current state after the cloud access is disabled. This process may include disabling wireless using a Faraday cage for mobile devices. Once this is achieved, you can proceed with the steps we cover in Chapter 6 regarding investigating a local asset. Make sure you clearly mark the cloud usage of the asset in your chain of custody and forensic log management tools before proceeding with the forensic process.

You are likely not going to be able to scan a cloud service with identification tools, but you may get lucky. You could deploy cloud security technologies that generate data you could use for an investigation. The first technology to consider is virtualized firewall or IPS technology that is deployed within the cloud. These tools can be investigated just like physical or virtual security tools providing logs and other visible data based on the east-west data visibility concepts. The same may apply to agents deployed within a cloud environment that report back what is seen. Agents could collect NetFlow, files of interest, and so on. We cover how these technologies work and how to collect data from firewalls and IP technology in Chapter 8. Make sure to ask your customer if any security technologies exist in the cloud environment because many vendors are providing cloud options as the market increases in demand.

Another cloud security technology that is growing in popularity is a cloud access security broker (CASB). A CASB is software or a tool that sits between an organization’s local infrastructure and a cloud provider’s infrastructure. Think of a CASB as a gatekeeper, permitting the corporation to extend its reach and visibility into cloud provider environments it is leveraging. The focus of CASB is enforcing policy, such as discovering high-risk applications, unwanted user behavior, and compromise of user passwords to cloud services. The risk of being identified and addressed by CASB has been coined shadow IT in the industry, meaning end users acting without corporate policies being enforced. The value of CASB technologies is that they could provide what users accessed, similar to the way access control and data loss technologies function. CASB solutions can also include threat data, such as compromised accounts, antimalware detection, and general unusual behavior. It all depends on the type of CASB being leveraged because some use available APIs, whereas others use some form of agents deployed within the cloud environment. Figure 5-18 shows the Cisco CloudLock dashboard showcasing many security events that took place in different cloud environments.

There is a lot of focus on cloud security, so things are likely to improve for digital forensics as security technology, law, and investigation practices adapt to the rapid growth in cloud services. At the time of this publication, your best bet is to remove the cloud from the equation if possible and leverage what security technologies exist within the environment.

People who read any type of report usually assume the results are accurate and come from an expert. The only parties who tend to challenge results are the ones who have negative information posted about them. Nobody likes having their “baby called ugly,” so be prepared for the parties being called out to challenge any negative data. The opposite situation tends to be different. It’s rare that people challenge positive information and may even not point out when you are wrong because it would void their appraisal. Remember this concept as you collect positive and negative evidence for whatever you are looking to prove. It will help you craft the right tone as you write your report. Honestly, the same can be said for your tone in any relationship.

Another important concept in regards to developing reports is that people are lazy in nature and tend to focus on the opening and closing of a report. It is your job to summarize everything that was performed and deliver that information in a clear and unbiased format. You cannot assume the readers of your forensic report will invest effort in filling in areas of data that are missing or require background knowledge to understand concepts from your report. People will not go to some link you reference to learn more about a topic. Not everyone knows the billion acronyms used in the IT industry. It is best you assume the readers have a limited understanding of the situation, so you need to spend the effort to explain everything. This means you need to spell out every acronym or include an appendix that explains what they are. This also means you need to provide background information on technical terms being covered. For example, if you mention the attack was delivered through an exploit kit, you should include a section that explains what an exploit is. More data is always better. If the report seems as if it’s too long, leverage the appendix and other reference documentation after your closing page to help the readers who need it. A good rule of thumb is thinking about how a judge would interpret your report. Most judges specialize in law but not IT.

As a digital forensic investigator, you must develop reports in a technical manner yet simplistic enough for different types of parties to understand. You should expect readers to include managers, legal representatives, human resource representatives, or a judge during a trial. In our experience, judges tend to not be IT savvy. You must not only present your findings but also explain the steps used to develop your findings and be ready to stand by them when they are challenged. You need to include enough details that you can put down the report for a year and later be able to recall everything if you are brought in a trial to explain your work.

The best preparation for developing a solid forensic report is taking lots of notes during the investigation process. This is why it is mission critical to log everything using cameras and other documentation methods we covered in this chapter. You will likely not need to include every detail, but you can summarize what was done and include references to the case file, which contains more detail about the event being addressed. For example, you could have your case notes in Autopsy open and pull screenshots, notes, or other details you used to develop your conclusion about what happened. This is why we keep pointing out how important it is to have a case management program because you are likely not to remember every detail of what you did during a long investigation life cycle. It is much easier to just attach existing documentation from that software.

There are different styles of forensic reports you could use. Regardless of the template you use, you should include particular sections when developing your own reports. We believe every forensic report should at a minimum contain the topic areas in the following sections.

7/14/2017: Analyst Steve Stasiukiewicz prepared to create three (3) forensic copies of the system of interest using the Digital Forensic Framework (DFF) installed on investigation system (Name and Serial). Articles found at Appendix 9524.

7/16/2017: Analyst Steve Stasiukiewicz enabled write blocking and connected to the laptop using a USB 2.0 cable to the examination machine. Once the hard drive from the laptop of interest was recognized, analyst Steve Stasiukiewicz proceeded with developing three forensic copies of the laptop of interest. The hash values of the copies are listed and stored on an isolated investigation system previously mentioned. Articles found at Appendix 9524.

Example

Lead investigator: Joseph Muniz, [email protected]. 1.800.123.4567

First Responder: Aamir Lakhani, [email protected]. 1.800.321.7654

The language used for the title or order of these items may be different based on your writing style. You may also include other sections, such as a dedicated section for evidence, title page, table of contents, executive summary, legal details around the case, definitions for terms used within the report, and timeline for the investigation. There isn’t a mandatory way to report data, but sources like NIST offer templates and training providers like SANS give their view on how a professional report should look. In our experience, we tend to develop a report template based on the topics we covered in this section and save it to fill in versus creating a new document every time we need to create a report. We also export details from our logging tools and attach that as evidence of our process that is referenced within the report. Figure 5-19 shows an exported Autopsy report with the various artifacts that are stored. We believe Autopsy lacks some features in exporting data, so you may want to consider an enterprise forensics case management program for this purpose.

How should you formally become inactive for a specific case? The recommended method is to leverage a case tracking application, which becomes part of your logging process as covered earlier in this chapter. This way, you can log hours and the time you are claiming you closed your involvement in the case. If somebody questions when you stopped being active, you can simply pull up the case file and show your activity timeline. You can also use your log book or whatever system you used to log your involvement in the case. This feature in case management software is very useful if you bill for your time. Autopsy doesn’t include tracking billing, but many tools that can accomplish this are available, such as TimeLive. Figure 5-20 shows an example using TimeLive for tracking work hours. Again, this software doesn’t have to be used only for billing purposes. You may find this application is important for generally tracking who worked on what and being able to print out a tracking report of who accessed an artifact, which is what we showed earlier in this chapter using Autopsy. That timeline report is essentially the time frame the case was opened in regard to your involvement.

There may be questions around your involvement with the chain of custody for any evidence associated with the case. You either need to return the artifacts before closing the case before the warrant expires, or specify those artifacts are stored in a secure manner and document the last party involved with accessing those artifacts. If your company is responsible for securing any stored artifacts, you need to specify your intentions for storing, returning, or destroying what is being stored. This information is important to avoid being accused of mishandling artifacts you are not the owners of, violating a warrant’s time frame for holding the devices, or causing gaps in the chain of custody process that could be abused by opposing parties in a potential future legal matter. It is best practice to agree upon data and artifact retention policies prior to launching an investigation so that you are not forced into spending additional money and time enforcing proper containment and storing of post-investigation artifacts. This must include who the asset owner is, the owner’s contact information, and a backup in the event that person is not available. People can leave a company, so you don’t want to hear, “We don’t know about that artifact and the person responsible is no longer with the company.”

In some situations, you may have data that is classified or sensitive. If you are tasked with discarding this data, you need to include your destruction process in your forensic report as well as case records. Proper destruction of data depends on the artifact and data it contains. You may want to leverage a reputable external party for this service if you have concerns of being fined for not performing proper destruction procedures. Companies such as Securis provide various data destruction options, as shown in Figure 5-21.

Following are proper destruction tactics for common items you are likely to encounter and may need to destroy:

Destroying Documents: Shred any documents. This includes what is being recycled. If data is confidential, distribute shredding in different bins to reduce the risk of reconstructing the documents. Regarding shredding policies, we recommend enforcing a shred-all policy to ensure everything is covered. Also, use a reliable shredder.

Deleting Data: We briefly address data deletion in Chapter 7; the concept is that many hard drives treat deleting data as “allocating that space as free.” This does not mean actually removing the data, so it is easy to use a tool like Foremost to recover this data. Best practice is using a forensic-level deleting tool that replaces all data with 0s to truly remove the data.

For example, you can replace all data on a USB drive with 0s by using a command like dd if=/dev/zero of=/devsdb bs=1m. Dedicated free tools such as Darik’s Boot and Nuke (DBAN) can obliterate data on a drive. This program is command line based and found at https://dban.org/. You may also want a referenceable enterprise data deletion program that includes a fancy GUI, such as Eraser, found at https://eraser.heidi.ie/. These programs offer professional-level forensic deletion of data. Figure 5-22 shows the Eraser dashboard.

Destroying Hard Drives: Our recommendation is to destroy any hard drive versus just forensically deleting the data. The reason is that hard drives are pretty cheap, and you ensure the data can’t be recovered if the hard drive is destroyed. For spinning drives, drilling into the platter accomplishes this goal. You could use magnetic technology, but we feel drilling into a platter is more absolute. Sometimes, magnetic technology can fail, and other methods like burning or drowning the device are also hit or miss. Shattering the platter makes it pretty much impossible to recover. Why take a risk with using other methods? If you feel you need more security than drilling into a platter, you should use a professional service that will apply more absolute destruction tactics, such as chemical and physical destructive tools.

Destroying Networking Equipment: The same tactics should apply to network devices as hard drives. Anything with memory should either be forensically deleted, or destroyed, which is our recommendation. This means drilling into the memory or other methods to ensure the memory is destroyed.

By searching online, you can find many models to grade your practice. We are not going to say one way is the best way to grade your practice. What we are saying is that you should pick one that makes sense for your business model. If you are concerned about compliance, you may want to first see if a maturity model is tied to mandated compliance that you need to meet before going with another model. For our example, we use the IEEE digital forensics maturity documentation. In that document, maturity is broken down into the following categories:

Level 0: Personal-Depend Practices: All forensics practices are performed but not documented. There is no formal plan in place, and capabilities vary depending on who is available and what is required to be performed. There is no method for grading capabilities or checks and balances put in place to ensure the quality of the work. If a specialist leaves the organization, so do the forensics capabilities.

Level 1: Documented Process: Documentation has been developed and approved that outlines the digital forensic process. This is good, but the document explaining the policies for the practice isn’t adjusted often, which means it does not accurately match what services are really being delivered. This is termed process drift, which describes how the forensic team adapted its services that are different from the original documentation. Also at this level, there is very limited validation to what is documented versus what is being delivered, so there are limited checks and balances.

Level 2: Partial Deployment: At this level, the activities that are documented are being deployed. The challenge is that the activities may not be deployed as stated, so some steps may not be documented or all steps may not always be executed. There are also challenges identifying who delivered the steps in the process, fluctuation of what is delivered depending on time of day, location of work, and so on.

Level 3: Full Deployment: This level demonstrates consistency between what is deployed and what is documented. The processes that are being delivered are repeatable and provide the same value regardless of location, time of day, and so on. Interaction between teams is seamless, and there is linkage between functions and processes.

Level 4: Measured and Automated: It is great to run an effective forensic practice, but we opened this section by stating how important it is to improve. This level of maturity means you set goals with timelines, grade yourself with customer satisfaction, measure costs to accomplish goals, and so on. Many times, goals at this level are created though resource management software.

Level 5: Continuously Improving: The most mature level is going beyond measuring your maturity against a static goal. This means ensuring the grading process is also improving. You can accomplish this by viewing the results of surveys and applying changes to the goal as the results show methods to improve. For example, if you find a certain tool has saved operation cost, then maybe you need to change a goal to leverage the tool more as a means to show maturity. If the tool is causing issues, part of a new goal could be to replace or reduce the need for the tool that is negatively impacting your forensic service. Think of this as a more customized and constantly changing grading scale versus the last level that is more static in goal setting.

There are tools you can use to assess your capabilities according to models such as this. The IEEE looks at things like assessing and measuring digital forensic capabilities, people, processes, tools, knowledge base, repository of procedures, skill profiles, training, and so on. You can learn more about the IEEE model at www.ieee-security.org/TC/SPW2014/papers/5103a057.PDF. For this example, grading can look like Figure 5-23 using an assessment and evaluation tool offered at this site. Once again, we are not saying that this is the best model but just one example of the many models available. We recommend that you pick a model that makes sense for your organization and check to see whether you can quickly generate scoring like that shown in Figure 5-23 to judge your maturity.

Grading a practice can improve your digital forensic business. You can set goals with rewards, such as bonuses for improving a forensic service. This also helps you justify budget and enables your executive support representative to explain how the forensic group is providing value and improving. We talked about how important it is to have executive sponsorship for a forensic practice earlier in this book and how forensic goals should lead to a business goal to have the most impact. Providing forensic service maturity ranking is critical data to deliver to your executive sponsors to keep them involved with how the practice is being managed. It is very likely your sponsors will not be technical, so leveraging a generic model is your way to speak in a method they understand. Having this model can also explain when expensive technologies or people are needed to improve the quality of service. For example, you could say that you need a software package to move the practice to a level 4 based on the need to automate monitoring service goals.

Where do you get the feedback to grade your practice? You are going to want to get feedback from customers and internal team members to fully understand how the investigation went. We recommend surveying customers and other groups you have worked with using survey technology that keeps the responder anonymous. This way, the person filling out the report doesn’t feel he could get in trouble by providing honest feedback. Many services are available for this purpose, such as SurveyMonkey. Your goal is to answer the following questions:

How could you improve your performance in the case you were involved in?

Did you receive the results that you expected to be found?

How was the quality of the forensics report that was delivered?

Were any new problems discovered during the investigation process?

What techniques or steps during the forensic process did you have concerns about?

What techniques or steps during the forensic process did you feel were very effective?

There may be other questions to ask, or you may want to fine-tune these questions depending on the maturity model you have selected to grade your practice. Our recommendation is to align questions with the tools that generate maturity scoring so that you can simply import results into the tool to quickly generate report cards. Software may be available to help with this process as well.

You also should hold debriefing meetings with your customers and internal team to talk about how the investigation went. We recommend including a “project closeout” meeting with all parties involved, including the legal department, analysts, and other leadership to get all points of view captured and clearly state objectives for improving the forensic practice. Make sure to also evaluate the associated forensic reports because they will be the footprint representing the work that was performed.

We started this chapter by explaining what questions and practices you should perform before you start an investigation. These details will help you decide if it makes sense for you or your team to handle the case. Next, we looked at how to properly open a case and how important it is to leverage forensic case management technology. From there, we covered the steps during an investigation such as first responder, data collection, search and seizure, chain of custody, and reporting. We concluded this chapter with steps for closing a case and how to evaluate your performance to improve your digital forensic practices.

In the next chapter, we start to break down the investigation process into focus topics. The first focus topic is what should be performed anytime you investigate an artifact. Failing at the concepts in the next chapter will likely ruin the evidence you have captured for legal use.

https://www.rcfl.gov/philadelphia/request-assistance

https://tools.ietf.org/html/rfc3227#section-2.1

https://www.shredit.com/en-us/information-security-guide-data-protection-guide

https://www.cnet.com/news/the-right-way-to-destroy-an-old-hard-drive/

http://www.ieee-security.org/TC/SPW2014/papers/5103a057.PDF

https://www.sleuthkit.org/autopsy/

https://www.rcfl.gov/heart-of-america/documents-forms/searchwarrant_computer.doc

https://nmap.org

https://csrc.nist.gov/csrc/media/publications/nistir/8006/draft/documents/draft_nistir_8006.pdf

http://searchcloudsecurity.techtarget.com/definition/cloud-access-security-brokers-CABs

https://hal.inria.fr/hal-01460613/document