Forensic Workstation/Lab (pt. 1 Overview)

Jesse Spangenberger -

Part 1: Overview
Part 2: pfSense

I ran across Hacking&Coffee's post Red Team Laptop & Infrastructure (pt 1: Architecture) during research for SIFT Workstations and virtual technology. The blog post goes into great degree of explaining the overall architecture of the system which contains the following VMs:

  • pfSense
  • Windows (Corp related stuff)
  • Attack VMs (kali)
  • Untrusted VMs (basically non-related Corp stuff)

Each set of VMs is setup in different security zones connected to pfSense. pfSense provides excellent traffic segregation and enforces traffic where it needs to go. What I do enjoy about this setup is the ability to scale it up using other network, local, or cloud resources providing complete control over traffic paths.

I had been looking for a Forensic Workstation/Lab when I found the post and decided to do something similar for forensics (or even 'blue team' stuff) in relation to the same context as from this site. I decided my list of requirements would be as follows:

  • Segregated VM zones through pfSense
  • Primary VM (s) (similar to the Corp above) -- probably one Windows and one Linux
  • Ephemeral VMs:
    • SIFT Workstation VM(s)
    • REMnux VM(s)
    • BlackArch/Kali VM(s)
    • General Linux VMs
  • Ability to spin-up VMs as required
  • Some VMs should completely destroy themselves with ease
  • Local storage connected to VMs as required for evidence gathering

Why would I want 'ephemeral' VMs? I think this provides the best way to keep each different class of VM clean every time without dealing with extra cleanup states and configurations.

Currently, I am looking at a few different technologies to accomplish this task:

  • Vagrant - VM orchestration
  • Ansible - VM configuration/control
  • Docker - ephemeral VMs/light weight

In the article above, they use cloned-linked VMs to save space; however, I really want even smaller footprints which is why I want to use Docker. REMux does run some tools inside of docker already within the VM and I need to see how this will work with Docker-in-Docker problem.

More to follow as I decide my overall layout of the VMs and tools to use.