Computer Forensics Explained: A Primer for Physical Security Professionals

July 12, 2005
What you need to know when managing an investigation that involves possible network crimes

The responsibilities of security professionals have expanded well beyond the range of simple access control as you now face issues of investigations that cross the border between physical security investigations and ones that look into the investigations of IT asset usage, such as computers, email and access to company networks. This means that the scope of the security director is expanding - meaning double or even triple the work and expertise you require -- but the good news is that you will find the approach to managing your computer risk to be similar to managing your physical risk.

This article introduces computer risk and more specifically computer incident response and forensics to an audience who is traditionally accustomed to implementing physical controls such as camera surveillance, physical access, and alarm systems throughout their facility. We'll look at the methodology used during a computer incident, as well as the steps taken during a computer forensics investigation subsequent to an incident. Finally, a real case study will be introduced to fortify the points and demonstrate incident response in practice.

Why bother? How about the fact that in 2003, the Carnegie-Mellon Emergency Response Team (CERT) reported that there were 137,529 computer incidents? You may read that statistic and find it daunting. If you thought that's a daunting number, you're not alone, because even CERT reached a point in 2004 where there was such a proliferation of incidents that they stopped counting. Whether in the papers, on the television, or on the web, the public is exposed to an increasing number of headlines about computer incidents.

Take these headlines:

Even with a conscientious proactive approach towards risk, attackers will successfully penetrate an environment (albeit physical or logical) as long as there is a challenge and/or something they desire for their own gain. If a proverbial "Pandora's Box" exists, attackers will want to open it. The important factor is knowing how to react when the "box" has been opened.

Incident Response Methodology Overview

In our investigations, we approach an incident similar to the way one may approach a physical compromise. The following 11 steps provide a logical framework allowing organizations to deal with a computer incident in a calm and collected manner providing them with the necessary information to make informed decisions.

Prepare...for an incident before the incident occurs by developing an incident response plan and testing it on a frequent basis. Basically, "an ounce of prevention is worth a pound of cure."

Detect...the occurrence of an incident within your system identifying any anomalous behavior during a cursory review of event logs. the incident by performing an initial investigation allowing you to scope the magnitude of the incident. Obtain the most critical evidence and confirm whether an incident has or has not occurred.

Create...a response strategy by analyzing all of the known facts and determine the best response and then inform management as to the strategy.

Duplicate...evidence determining whether to create real physical forensic images for investigative purposes or perform online retrieval of evidence.

Investigate...the incident by taking investigative steps to determine what happened, who did it, and how it can be prevented in the future. measures by actively responding to the victim systems applying security measures to isolate and contain the incident.

Monitor...the network by reviewing network activities to both investigate and secure the victim network.

Reclaim...the environment by restoring the victim system to a secure, operational site.

Record...all evidence and conclusions in an accurate manner documenting all of the details of the investigative steps and security remedies undertaken.

Summate...the processes conducted and record the lessons learned while fixing the problem.

Computer Forensics Methodology Overview

If there is confirmation that an incident has occurred beyond a reasonable doubt, it is common practice to proceed with a computer forensics investigation on the compromised machine. The two most fundamental principles of computer forensics are 1) the preservation of evidence, and 2) the necessity of thorough and complete documentation to ensure forensic integrity.

A computer forensic site is really no different than a homicide site. For instance, the authorities take all measures to retain the integrity of the crime-scene by putting police tape up; chalking the outline of the body; placing numbered cards by evidential matter; and taking an abundance of pictures to capture the scene as of that point in time. In computer forensics, this evidence retention is accomplished by duplicating ("duping") the hard-drive(s) or other systems. This technique allows a computer investigator to capture the electronic evidence before it can be modified either intentionally or inadvertently.

The ultimate goal of computer forensics is to identify the attacker, but before doing so, there are certain objectives that need to be achieved during the investigation. First, one must determine the earliest detection of compromise (e.g. what time of day the attacker entered the building). Next, the investigator must identify the initial method of the compromise (e.g. did the attacker enter through an open window or break down the door?) Once one figures out the point of entry, they can begin examining the indicators of the compromise for instance hostile programs, malicious tools or hostile IP addresses (e.g. broken glass, a battering ram and fingerprints). Lastly, the investigator needs to examine the environment and estimate the data viewed, taken, or stolen from the system (e.g. if the family jewels were taken from the safe).

These goals are achieved by approaching computer forensics in three phases:

  • Phase 1: Evidence Preparation
  • Phase 2: Forensic Analysis
  • Phase 3: Case Documentation

The Evidence Preparation phase is essential, because if you do not properly manage the digital evidence, the remainder of the forensics process will be disparaged and lack integrity. The first step is to maintain a catalogue of notes for each system reviewed populating your significant findings throughout the process. Next, the files should be extracted into a notes catalogue segregated into certain categories. The suggested categories include web logs, registries, event logs, and attacker tools. In addition, all well-known files and applications resident on the system can be identified based on a known hash-value for each of them. This provides one with the ability to minimize the scope of our analysis by eliminating these known non-malicious files. The filtering is performed based on the hash values and not the filenames as it is trivial for an attacker to modify the latter in an attempt to masquerade a malicious program as a well-known application.

Now that we have separated the information between what does and does not need to be analyzed, it is time to conduct the Forensic Analysis phase of the engagement. This phase commences with the review of the file system for hostile programs (e.g. Trojan horses, backdoor keystroke loggers) and performing a detailed time/date stamp analysis on those hostile files. By looking for anomalies in web and event logs, it will be possible to see questionable activity and hone in on the hostile files. At this point, the relevant timeframes should be noted to focus one's attention at performing a manual review of the contents of all directories housing hostile programs. Among the logs and directories to be reviewed are: system logs, security logs, application logs, Dr. Watson logs, Windows registry, the quarantine directory and the IIS web logs.

Once the preparation of evidential matter and forensic analysis has been completed, it is time to perform the Case Documentation phase of the investigation. This phase begins with recording the earliest evidence of a compromise. Next, it is necessary to list all the files placed on the system by the attacker, as well as the files that were used by the attacker, but no longer reside on the file system. Subsequently, it is necessary to compile all of the IP addresses that initiated the attacks against the system and perform both "WHOIS" and "DNS Lookups" on those IP addresses. The WHOIS and DNS Lookups are online tools used to identify the owner of an IP address (very similar to looking in a phone book to associate a person, to a home address, to a phone number). At this point, a list of investigative questions should be accumulated for the line-of-questioning process. Case documentation should be completed and organized at this point in the event litigation support is requested.

An Incident Response Case Study

An employee of a consulting firm noticed that $20,000 had been transferred from her on-line banking account that she usually accessed from her office computer. She notified the financial institution, initiating a password change to protect her assets. An additional $20,000 was transferred out of the victim's account by the next day. She and the financial institution made another change to her account credentials and yet a third transfer of $10,000 was made after this second change. The financial institution had responded by reviewing their system security data, but did not note a compromise to their systems. They did note that the connection data lead back to a geographically dispersed point.

The victim initiated litigation against the financial institution to recover her $50,000 in funds and began the process of an investigation to review her system for electronic evidence. A forensic image duplication of the victim's hard drive was made and upon further review, we noted that several time/date stamps resulted in initial clues. Within five minutes of review, we noted a suspicious file in the form of a keystroke capture log file that had been backed up by Microsoft XP's built-in System Restore capability. Further analysis resulted in identifying that an additional 25 similar files contained keystroke logs. What had occurred was a "Trojan" was installed on her machine (without her knowledge, of course) specifically targeting financial data to capture the victim's keystrokes and periodically sending them to an email server in Europe. The Trojan would then automatically uninstall itself after two-week's time, thus removing its executable, registry entries and the keystroke capture log files. However, residues from the Trojan still existed in the system's slack space allowing us to perform a limited analysis of its capabilities.

Such an attack is not uncommon today. Attackers have come to realize that it is much easier to exploit 10 unaware end users than it is to exploit a highly protected and monitored e-commerce server for the same monetary gains.

Computer Security Going Forward

This article set out to explain, at a high-level, the steps taken during the incident response process and the computer forensic process drawing parallels to physical security. Hopefully, you were able to decipher the similarities and differences between the two disciplines and bring those into practice at your organization. Again, the good thing is now you are better versed on computer security, the bad thing is that computer incidents continue to occur at an alarming rate.

Market indications and our own fieldwork support the facts that due to the complexity of attacks, the frequency of attacks, and the enhanced visibility of these matters in regulatory requirements, that incident response and computer forensics is a burgeoning market. From executives, risk managers, security directors, and system administrators, all facets of an organization will most likely be involved in handling an incident and will be required to make informed decisions. Those organizations that have taken the proper steps to prepare for a computer incident will be better poised to make timely decisions and will mitigate their risk; thus, reducing the overall impact to their business.

Today, anyone who manages risk at an organization needs to accept that bad things will happen, and they need to take a long, hard look at their computer security program to determine if they have been diligent in addressing the question "What if a compromise occurs?" A security professional needs to be just as diligent in trying to thwart a compromise as they are in responding to a compromise. You need to be able to walk into an executive's office and say with confidence, "Yes, we have just experienced a computer incident We have an incident response plan in place. We are taking action. We know what was compromised, and we know what was taken."

About the author: Michael Malin is an executive vice president at Red Cliff Consulting and has over 14 years of risk management experience with PwC, Foundstone and Red Cliff. Red Cliff specializes in computer forensics, incident response, network & application security and education.