Digital Forensics Investigations: Data Sources and Events based Analysis


Digital Forensics Investigations: Data Sources and Events based Analysis

Amy Wees

CSEC650, 9045

March 15, 2013


Data sources used to gain evidence in digital forensics investigations differ significantly depending on the case.  This paper prioritizes data sources used to gain evidence for network intrusions, malware installations, and insider file deletions.  These three events drive the prioritization of the types of data that are analyzed, what information is desired, and the usefulness of that data in regards to the event.  Primary focus is information garnered from sources such as user account audits, live data systems, Intrusion Detection Systems, Internet Service Provider’s records, virtual machines, hard drives and network drives.

Digital Forensics Investigations: Data Sources and Events based Analysis


Digital forensics investigations deal with a multitude of data sources used to preserve and capture evidence to be used in a legal platform.  The various events or crime scenes investigators encounter drive the prioritization of the types of data that are analyzed, what information is desired, and the usefulness of that data in regards to the event.  The goal of this paper is discuss three specific events; network intrusion, malware installation, and insider file deletion and then analyze and prioritize data sources that can be useful in investigating each case.

Network Intrusion

A network intrusion occurs when a computer network is accessed by an unauthorized party.  Network intrusions can have significant impacts on the victim organization as files can be stolen, altered or deleted, and hardware or software can be damaged or destroyed.  In a case study by Casey (2005) published in the Digital Investigation Journal, a network intrusion investigation is described.  The scenario presented in this case study will be the basis for analyzing data sources most crucial to the contribution of evidence.

In March of 2000 at a medical research facility, a system administrator completing routine maintenance tasks noticed an unfamiliar account with the name “omnipotent” on a server which he was solely responsible for.  The administrator immediately deleted the account and notified Information Security personnel (Casey, 2005).  The incident caused several laboratories to be shut down for days, preventing ongoing medical research resulting in severe financial losses for the company.  Luckily, after a thorough investigation the perpetrator was caught and charged in 2004 (Casey, 2005).

Prioritized data sources

Account Auditing

Many steps were taken by forensic investigators in this scenario to preserve evidence, reconstruct the crime, track the intruder and examine the data.  The aim of this paper is to prioritize the data sources used in this scenario from the most to least useful in terms of a network intrusion.  The first data source used was review of user accounts during routine maintenance.  Without routine review of user accounts and permissions, the account the intruder was using to access the server may never have been discovered (Casey, 2005).  This scenario exemplifies why account and role auditing is so vital.

The Federal Agency information technology (IT) Handbook on technical controls published by the National Institute of Standards and Technology (NIST) (2002) recommends access to any asset be controlled by combining technical and administrative controls to make sure that only approved users are given an applicable level of access and that they can be held accountable for their use of information systems.  Access should be monitored by positively identifying and authenticating users.  The handbook also makes clear that a weakness in policy at one node in the network can put other nodes at risk.  Therefore, it is essential that all agencies have a uniform access control policy (NIST, 2002).  Account and role maintenance should require users to authenticate with a strong password and to change passwords on a consistent basis.  Administrators must also ensure user names belong to currently identified users and that users are deleted and updated often.  Auditing should also be established on user accounts to ensure that accounts which haven’t been active for a period of time are deleted.  Incorrect logon attempts should also be limited and locked after multiple erroneous password entries (NIST, 2002).

If some of these policies were in place in the above scenario, the “omnipotent” user may have been discovered earlier or prevented from accessing the system in the first place. Role auditing can be challenging when dealing with multiple types of operating systems and role based user accounts.  Each operating system has different account systems and auditing procedures.  It may also be difficult for organizations with a large pool of users to weed out inactive or incorrect accounts.  Organizations may also outsource their IT services, making user role auditing a difficult process as the administrator behind the phone may not be able to positively identify a user or give the correct permissions to an account.  User account and role auditing is the most useful of the four data sources in this network intrusion scenario as it is easy to accomplish and if maintained properly can aid an administrator in identifying if an account has been misused, locked out, or doesn’t belong.

Live System Data

Next, to gain more evidence, investigators used the Encase program to capture live data from the systems and kept an audit log by utilizing the script command.  During this capture, they found that the intruder was accessing the network through a dial-up connection in Texas, had installed a sniffer, and also substituted the original Telnet for a version with a backdoor vulnerability allowing remote access.  The sniffer log contained records of the backdoor intrusions as well as root passwords for multiple computers.  They also discovered the hacker had created his own telnet password, “open_sesame” to access and compromise additional computers on the network (Casey, 2005).

The primary reason an incident handler would use a tool such as Encase to capture live data is to determine if an event has occurred and if a full investigation needs to be accomplished on a system.  In the above scenario, the incident handlers used Encase to capture live, volatile data and were able to determine if a network connection had been made from the intruder to that computer.  They were also able to view live system logs to see what passwords had been used to access the system.  Capturing data from live systems is also called “live forensics”.  Live forensics capture system information or volatile data that disappears after the device is powered down.  The challenges of live forensics are in preserving the state of the system and ensuring the data captured is forensically sound (McDougal, 2006).  The best way to do this is by using a forensic toolkit such as Encase which keep the process as automated as possible.   In the above scenario, a new employee who wasn’t competent in live forensic processes missed files on several machines and didn’t keep an audit log which allowed incident handlers to determine which data came from which computer, leaving all evidence captured to be inadmissible in the case.  Live system data is the second most useful data source because live data provides the most promising evidence to discover what files and systems have been compromised and gives evidence in real time as to how the intruder is accessing the system (Casey, 2005).

Intrusion Detection System

The third data source used was the intrusion detection system.  After the subnet used by the intruder in Texas was discovered from the live system analysis, investigators were able to reconfigure the intrusion detection system to monitor network traffic for these connections.  After the reconfiguration, investigators were able to monitor network traffic and watch as the hacker accessed more machines not previously found to be targeted using the telnet backdoor password.  Critical systems were able to be secured and processed for evidence as a result of these findings (Casey, 2005).

Intrusion Detection Systems (IDS) are indispensable in detecting network intrusions because they can be programmed to automatically alert administrators when abnormal network traffic occurs.  Hill & O’Boyle (2000) compare IDS to a burglar alarm as although one observes cyberspace and the other physical space–both provide alerts when the unforeseen occurs. The main difference is that in cyberspace unauthorized actions are harder to detect than those in a physical space.  The challenge for an IDS operator is sorting out the harmless activity from the anomalous and programming the IDS to capture future anomalies (Hill & O’Boyle, 2000).

Automated IDS and accompanying forensic procedures utilize “signature matching,” which searches network connections and activity alerting on specific incident patterns and means of attack. Unfortunately, automatic signature matching is not a definite process and is determinant on many factors.  Signatures often create false alarms because they are too generalized, such as alarms for port scanning.  Attack profiles can also vary considerably from well-known malware insertion attempts to customized programs created to target specific systems and not yet known to the public. The latter customized attacks are not caught by IDS because signatures do not yet exist for this situation and are not made available until after the attack.  The downside of utilizing IDS in this situation is that, without the latest updates, IDS is not nearly as effective (Hill & O’Boyle, 2000).

Forensics investigators can start by sorting through automatically generated IDS alarms and then use clues from the alarms to further analyze less developed system logs and information. In order to isolate evidence of an intrusion, the investigator needs vast knowledge of various operating systems and hacking techniques and must comprehend logs of diagnostic tools and systems. IDS is the third most useful source of evidence because after discovering the intrusion, the IDS is able to capture details about the rogue connection and help prevent or block further connections as well as pinpoint where the traffic is aimed.

Internet Service Provider Records

The last source of evidence was the Internet Service Provider (ISP) used by the hacker.  Investigators were able to call the ISP and request logs and records connected with the case be preserved (Casey, 2005).  According to Daniel (2012), after a subpoena if one is requested, there is some basic information that can be gleaned from ISP records, dependent on what the ISP collects on its account holders.  Some of the available information could be names, e-mail addresses and mailing addresses for paid account holders, to include payment information such as credit cards or bank account information, which may lead to other evidence.  IP addresses assigned to the account during the dates and times requested as well as associated activity may be available along with a MAC address for the computer making the connection (Daniel, 2012).  The challenge of collecting information from an ISP is that a subpoena may be required, information may not always be reliable, and different ISPs carry varying amounts of information regarding their customers.  For these reasons, ISP records are the least useful data source in this scenario.

Malware Installation

Malware is malicious software that can emerge from scripts or codes hidden in websites or content, embedded in web advertisements or buried in different types of software programs.  Malware can infect a system when a user visits a website, opens an email, or clicks on a hyperlink among many other normal activities.  The types of malware that exist are viruses, rootkits, spyware, and worms.  Each type infects a system in a different way (Goodrich, 2012).  Malware is dangerous because it exists in a multitude of formats, is easy to create and hard to track.  Although there are many different anti-virus, anti-spyware and anti-malware applications to detect and remove malware from a system, the programs are only as effective as the updates provided to recognize the attack.

One common scenario was presented by Martin Overton at the 2008 Virus Bulletin Conference: a user calls the helpdesk with a complaint that their computer is suddenly unusually slow to respond, and they aren’t able to bring up task manager to figure out what the problem might be.  How does the helpdesk know if the problems are caused by malware or if the user has done something wrong?  Alas, the anti-virus program shows no signs of an infection, is recently updated, and has been active throughout the reported timeframe.  What should the administrator do?  How can the machine be investigated further to determine the presence of malware (Overton, 2008)? Overton presents an all too familiar scenario which will be used as a basis for analysis of a malware installation.

Prioritized data sources

Live System Data

Similar to the network intrusion scenario and most useful to the malware installation scenario is the collection of live system data.  Overton (2008) recommends that after a suspect system is identified, all traffic coming to and leaving the system should be captured to include searching for hidden files inserted by malware, most likely located in alternate data streams.  Nmap, Nessus, and various other vulnerability assessment tools can be used on the suspect workstation as well as the network to analyze anomalies (Overton, 2008).   Programs such as Helix3 and Windows Forensics Tool-chest can examine volatile system data for valuable clues such as network routing tables, system drivers and applications, and analysis of running processes and services, all without alerting the attacker an investigation is taking place (Aquilina, Malin & Casey, 2010).  The challenge in determining if malware is installed on a live system is that tools may not be available to conduct a thorough analysis and anti-malware tools may give a high amount of false-positives or the malware may be so stealthy it goes unnoticed until the damage caused is irreparable.

Intrusion Detection System

An IDS is the second most useful tool for malware installation.  After the initial investigation is complete and the analyst has deemed an infection is probable but wasn’t caught by the anti-malware program; the workstation should be removed from the network to prevent the spread of malware to other systems and the ports and protocols collected should be analyzed further using IDS or other network analysis tools such as Wireshark or Snort (Overton, 2008).  The second step in discovering malware is analysis and IDS can assist in malware detection by creation of signatures created based on the information captured from the previous inspection.  These signatures can then be implemented to block future attacks until anti-virus programs are updated.  There are many reasons IDS can be used to both detect and prevent malware that comes in through the network boundary.  In a second conference presentation written by Overton (2005), he explains that malware is quickly evolving and requires faster detection methods.  IDS can also be part of a defense-in-depth strategy that uses IDS in combination with anti-malware scanning tools to provide improved protection.  Finally, using an IDS for malware detection uses the IP from the source and this data can quickly eliminate the spread of threats across the network (Overton, 2005).  The challenges with an IDS is that signatures can be difficult to create and maintain, they require training to understand and utilize for malware detection, and the amount of information left for an investigator to comb through may be overwhelming.

Virtual Machine

            The third most useful data source for malware installation and analysis is the use of a virtual machine.  As suggested by Overton (2008), a private or closed network or lab environment should be used to analyze malware if available.  Virtual machines can make this possible by allowing for multiple systems to be running from the same hardware allowing the observer to watch how a string of malware behaves inside various systems, also called “behavioral malware analysis” (Zeltser, 2007).  Virtual machines can take on the forms of many different types of systems or platforms, without requiring an entire lab of expensive equipment.  Virtual machine program vendors such as VMWare allow the administrator to take multiple snapshots of the systems settings, performance and volatile data throughout the observation process so that if further study is needed it is possible to go back to a previous snapshot.  VMWare can also create a simulated network so that it is not necessary to connect the infected machine to a live network allowing for analysis in a protected environment while still having the ability to analyze network traffic (Zeltser, 2007).  In a virtual environment, threats can be detected and mitigations tested and proven.

The use of virtual machines (VM) also presents challenges in that a virtual environment cannot always fake the characteristics of an operating system on a physical platform, allowing attackers to possibly discover the VM.  In certain cases, a virtual environment may not meet the need because of the type of system being imitated or the response of the malware, requiring the analyst to utilize a complicated and expensive laboratory environment (Brand, Valli & Woodward, 2010).

Insider File Deletion

Inside threats to an organization can come from employees, contractors, vendors, visitors, and   anyone else with reasonable access to company assets.  What makes insiders threatening is their familiarity with systems, databases, and processes as well as their permitted position inside of security barriers (Cappelli, Keeney, Kowalski, Moore & Randazzo, 2005).  Accidentally or not, files that are crucial to an organization can be deleted and information security personnel need to have the skills and tools to be able to recover data for various reasons.

In a scenario from March 2002 offered by Cappelli, Keeney, Kowalski, Moore & Randazzo (2005), a resentful employee of a finance company planted a logic bomb that erased 10 billion files prior to quitting over an annual bonus disagreement.  A logic bomb can be inserted into a computer system and set to activate at a later time or upon a specified action.  The deleted files in this case impacted servers across the country and cost over $3 million dollars in damages and file reconstruction.  Were the company able to recover the deleted files, what data sources would be useful to the investigation?  This query will be the basis for this analysis.

Prioritized data sources

Hard Drive (Non-volatile system data)

            In the previous subjects of network intrusion and malware installation, live system data has been the highest priority data source because of the indications given by volatile data.  However in the case of insider file deletion; the first goal is to make a forensic copy of the hard drive in an attempt to recover data that hasn’t been overwritten on the hard drive.  Even the least savvy computer user will know to delete files from the recycle bin so volatile data is not as much of a concern as the non-volatile data that resides in the master file table which can be recovered with the assistance of various third-party applications.

For example, when a file is removed from the recycle bin in Windows, only the file information such as the path, sector, and additional identifying information such as create and modify dates have been erased.  Windows is simply notified by the file system that new space is available for use where the deleted file used to be and any newly saved files will overwrite information deleted long ago.  In spite of this if a newly saved file is not as large as or does not take up all of the space of a previously deleted file (hence the old information is not completely overwritten), the file is still recoverable with the use of forensic software.  If only a short time has passed since the file deletion, tools such as WinUndelete for windows can easily recover the file (Landry & Nabity, n.d.).  The challenges of recovery from a computer hard drive are that after a period of time, the desired files may be entirely overwritten.  A smart criminal may also use freeware such as “Eraser” to overwrite erased data immediately making it unrecoverable by forensic toolkits (Capshaw, 2011).

Network Storage

            Of equal worth to a forensic investigation in the insider file deletion scenario, is the recovery of deleted files from a network storage device.  In most cases, files of considerable importance to an organization must be shared with a group of people and are therefore located on a network storage device such as a Network Attached Storage (NAS), Windows File Server, or a Storage Area Network (SAN).  After a file is deleted from a folder on the network, the easiest way to recover it is through previous versions.  Microsoft TechNet (2005) explains that on most Windows Server versions, there is a previous versions tab that when selected, will bring up any files that have been deleted from that location and can then be copied and pasted to the newly desired location.  Similarly, NAS and SAN file systems offer recovery of recent snapshot from the administrative user interfaces.  The challenge with recovering files from a network storage device is that a copy of a RAID or other file system disk may be large and difficult to analyze.  Insiders with administrative access may also know how to permanently delete files or destroy network storage volumes.


Digital forensics investigations deal with a multitude of data sources.  This paper has covered three events which drive the prioritization of the types of data that are analyzed, what information is desired, and the usefulness of that data in regards to the event.  Important data sources for network intrusions are account audits, live system data, Intrusion Detection Systems, and Internet Service Provider records.  Malware installation requires examination of live system data, Intrusion Detection Systems and Virtual Machines.  Recovery of deleted files relies mostly on hard drives and non-volatile data.  Each data source has tools, advantages, and challenges for an investigator to consider dependent on the situation at hand.




Aquilina, J. M., Malin, C. H., & Casey, E. (2010). Malware forensic field guide for windows systems, digital forensics field guides. New York: Syngress. Retrieved from

Brand, M., Valli, C., & Woodward, A. (2010, November). Malware forensics: Discovery of the intent of deception. Originally published in the proceedings 8th Australian digital forensics conference, Perth, Australia. Retrieved from

Cappelli, D., Keeney, M., Kowalski, E., Moore, A., & Randazzo, M. (2005). Insider threat study: Illicit cyber activity in the banking and finance sector. (Technical Report, Carnegie Mellon Software Engineering Institute). Retrieved from

Capshaw, J. (2011, April 01). Computer forensics: Why your erased data is at risk. Retrieved from

Casey, E. (2005). Case study: Network intrusion investigation e lessons in forensic preparation. Digital Investigation, 2005(2), 254-260. Doi: 10.1016. Retrieved from

Daniel, L. (2012). Digital Forensics for Legal Professionals. Waltham, MA: Elsevier Inc. Retrieved from

Goodrich, R. (2012, Nov 21). What is Malware? How malicious software can affect your computer. Retrieved from

Hill, B., & O’Boyle, T. (2000, August). (2000, August). Cyber Detectives employ Intrusion Detection Systems and Forensics. Retrieved from

Landry, B., & Nabity, P. (n.d.). Recovering deleted and wiped files: A digital forensic comparison of FAT32 and NTFS file systems using evidence eliminator. Retrieved from

McDougal, M. (2006). Live forensics on a windows system: Using windows forensic toolchest. Retrieved from

Microsoft. (2005, January 21). Recover a file that was accidentally deleted. Retrieved from

National Institute of Standards and Technology. (2002). Agency IT Security Handbook: Technical controls. In Federal Agency Security Practices (2 Ed.). Retrieved from

Overton, M. (2005, May). Anti-malware tools: Intrusion Detection Systems. Paper presented at conference 2005 EICAR Conference, Malta. Retrieved from

Overton, M. (2008, October). Malware forensics: Detecting the unknown . Conference Presentation Paper 2008 Virus Bulletin Conference, Ottawa, Canada. Retrieved from

Zeltser, L. (2007, May 1). Using VMware for malware analysis. Retrieved from



  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: