Digital Forensics Lab Setup

This page introduces computer forensics lab setup and network forensics lap setup. Notes are given for students interested in setting up their own lab environment at home. The pdf version of the environment is here.

1. Computer Forensics Lab Setup

The machines in Olsen 310 have three virtual machines on them in the folder called c:\virtualmachines. Use the free VMware Player program on each lab machine to start a vmware station. Do not install any vmware tools if not instructed.

Virtual Machine 1 - UMLSEEDUbuntu: Account setup is the same as the original SEEDUbuntu by Prof. Wenliang Du at Syracuse University. Click here to download the manual.

Virtual Machine 2 - Unpatched Windows XP SP3: The administrator password for the xp machine is umlcs. DO NOT patch this system since the unpatched version has vulnerabilities we will exploit in labs.

Virtual Machine 3 - Metasploitable2 (Linux): "Metasploitable is an intentionally vulnerable Linux virtual machine. This VM can be used to conduct security training, test security tools, and practice common penetration testing techniques. The default login and password is msfadmin:msfadmin. Never expose this VM to an untrusted network (use NAT or Host-only mode if you have any questions what that means). To contact the developers, please send email to For more information please see the following URL:" - from Metasploitable2 README

Students can also use this setup to run related network forensics labs.

2. Network Forensics Lab Setup

There are 6 virtual machines in our vmware cluster that have the Metasploitable2 vm on them - they are on an isolated network. The setup is illustrated in the following figure.

To get to the isolated network,

Step 1. Login the Linux server on our public network with an ip address of via ssh program such as putty. Please contact Harry Lee ( for username and password.

Step 2. Get to a team machine with IPs of
Team 1 IP:
Team 2 IP:
Team 3 IP:
Team 4 IP:
Team 5 IP:
Team 6 IP:

At this time, the user account, which is a sudo account, on those machines is given below. Change the password immediately.

Username: msfadmin
Password: msfadmin

From the public server, you can login the team machine, for example,, using the following command

ssh msfadmin@

3. Notes for setting up their own environment at home


Download the Metasploitable2 and files, and uncompress them to a directory of your choice. (See top menu for the VM download page)


Next, start vmware (make sure the vmware agent is running, on most Linux distributions, run "service vmware start" as root) and press Ctrl+O to open an existing VM. Browse to the extracted VMs, and add both.

You should now have the Metasploitable and SEEDUbuntu VMs in your list of virtual machines. On each, in turn, right click that menu entry, select "Settings", click the "Network Adapter" entry, and select the radio dial for "Host-only".

Host-only allows the host computer, the virtual machines, and vmware (which provides a dhcp server) to talk to each other. For an explanation of the other options, please see


You'll also need to install a Windows XP SP3 machine (We used a Windows Professional disc). A license key is not necessary for the labs as long as you're within the first thirty days from installation, so acquire a disc or disc image and install according to these instructions:

4. Virtual Machine Environment Setup for Detection and Traceback lab

By Ken Kleiner

To provide secure and reliable resources for the lab it was decided that the existing VMware infrastructure being used in the CS department would be leveraged. The lab environment partially exists of:

  1. 1 HP AMD based blade server running the VMware ESXi Advanced 4.0 hypervisor with 4 ethernet NICs.
  2. iSCSI based SAN
  3. HP c3000 blade enclosure
  4. Virtual Connect network switch in blade enclosure.
  5. 6 virtual servers running the msploit virtual machine, each with one virtual NIC (the virtual exploitable servers)
  6. 1 virtual server running Ubuntu-based linux, with latest security patches, configured with 2 virtual NICS (the primary virtual server)

The switch in the blade enclosure has at least one of its uplinks connected to the public network. Another port on the blade switch is configured as a VLAN which is non routable and inaccessible from the public network. A third port must be configured with the same VLAN that the iSCSI storage SAN is configured for.

The physical blade running the VMware ESXi Advanced 4.0 hypervisor is configured wherein one NIC is mapped to the switch port that is configured for the public network. Another NIC is mapped to the switch port that is configured for the private VLAN. A virtual ‘VMware network’ needs to be created for each of these 2 connections.

The primary virtual server is configured with 2 virtual NICS. One NIC is mapped to the public virtual network and is assigned with a publicly routable ip address. The 2nd NIC is mapped to the private virtual network and is assigned a private non-routable ip address. The linux OS on the primary server is configured to allow inbound SSH connections from the public network and has a routing table capable of allowing users to ssh to hosts on the private network it is connected to. Users must first connect to this host before they can ‘ssh’ to the private servers.

The virtual exploitable servers are each configured with 1 virtual NIC. Each NIC is mapped to the private virtual network and is assigned a unique ip address in that VLAN range.

Local linux accounts are created on the primary virtual server. The virtual machine for the exploitable machines comes preconfigured with an account of ‘msfadmin’ with the same password.

The virtual machines (primary and exploitable) are created using the VMware Virtual Center tools and their files are located on the Vmware filesystem located on the iSCSI SAN. An assumption is being made that the iSCSI san has been preconfigured and the VMware ESXi hypervisor has been configured to use the SAN for virtual machine storage. The iSCSI san should be on a separate VLAN than the virtual machines and should be connected to the network switch located in the blade enclosure. This requires that the network switch must also be configured with at least one port utilizing the network VLAN that the iSCSI SAN is configured for. Setting up the iSCSI SAN and VMware connectivity to it is out of the scope of this document.

It should be noted that the virtual machines could instead be located directly on the blade assuming it has its own storage.