Originally Published: December 18th, 2017
I'm super stoked about this project. It's incredibly important for an attacker to be aware of their IOCs, but there's quite a bit of knowledge required to build out security monitoring. This project handles:
Configuring PowerShell transcription logging
All of this is deployed to current best practices, allowing an attacker (or defender) to quickly have a lab where they can run through attacks and see what sort of tracks that they're leaving behind.
Playing with DetectionLab was a great excuse to mess around with some devopsy tools that I've been meaning to look at for awhile.
Vagrant was designed to simplify deploying development environments. You declare your environment in a config file, your developers download this file and then run
vagrant up, which handles building out VMs and configuring them. Vagrant is able to deploy VMs to many different providers (AWS, VMWare, Hyper-V, Virtualbox, etc), but the config file has to be written to support each provider. DetectionLab supports VMWare and Virtualbox. It's worth noting that the VMWare plugin for Vagrant costs $80 (at the time of this writing), the Virtualbox plug is free and installed automatically.
Packer compliments Vagrant by building gold images. Like Vagrant, it supports multiple providers including its own 'box' format, which is what Vagrant leverages. In DetectionLab, Packer handles downloading Windows ISOs, installing Windows, patching, and installing some custom software.
The README for DetectionLab does a good job of walking through setting all of this up. The basic process though is:
Run Packer to build the Windows images
Run Vagrant to build the lab
An interesting approach to this lab (which seems like it might be convention) is that it leverages the hypervisors port forwarding for access to resources. In labs that I build, I typically have a shared network between my host and the VMs and just access VM resources directly.
Most of the customization that you would want to do would be handled by editing the Vagrantfile, which is pretty straightforward.
In my case, I ended up customizing the Packer JSON files to point to local ISOs instead of a URL. This offered a couple of advantages for me:
It allowed me to use my MSDN ISOs
It meant that every time I built the Packer image, it didn't have to redownload the ISOs
Customizing this was just a matter of pointing the 'iso_url' attribute in each of the Windows JSON files to a local ISO and updating the hash. To get the hash, I used the magic of PowerShell.
PS> Get-FileHash -Path D:\ISOs\en_windows_10_enterprise_version_1703_updated_june_2017_x64_dvd_10720664.iso -Algorithm SHA1 | Format-ListAlgorithm : SHA1Hash : D7EF32D857D444886D941A49C39E76D60ACA4485Path : D:\ISOs\en_windows_10_enterprise_version_1703_updated_june_2017_x64_dvd_10720664.iso
I'll be honest, it took me like 3 days to get this successfully deployed. All of my issues could have been avoided had I read the README more carefully. Go read the README. Things I learned the hard way:
You can only build one Packer image at a time. It will take about an hour per image.
The README has an issues section which covered the other issues I ran into. (Namely, the port forwarding issue)
Ultimately I was able to successfully deploy the lab by running
vagrant up, which failed on the port forwarding. I then ran
vagrant reload dc --provision and then deployed the remaining machines with
vagrant up wef and
vagrant up win10
The port forwarding issue seems to be a bug with Vagrant, otherwise the lab would have deployed successfully I think.
I can't wait to spend some more time in this lab. I'll probably end up writing some more stuff as I learn how to use Fleet and Splunk a bit. Major thanks to Chris for all the effort that went into putting this together.