Detection Lab, designed and maintained by Chris Long, is a collection of Vagrant and Packer scripts. These scripts allow users to quickly spin up a fully configured and monitored Windows Active Directory environment. Once the setup is complete, we will have a fully functional lab designed with defenders and security researchers in mind. Detection Lab can easily be modified to fit most needs or expanded to include additional hosts.  This blog will demonstrate how to install and use Detection Lab with penetration testers in mind.

Detection Lab consists of 4 total hosts:

• DC: A Windows 2016 Domain Controller
• WEF: A Windows 2016 server that manages Windows Event Collection
• Win10: A Windows 10 host simulating a non-server endpoint
• Logger: An Ubuntu 16.04 host that runs Splunk and a Fleet server

Baseline installation

Before attempting to build the lab, one will need to make sure to meet the following prerequisites:

• 55GB+ of free disk space
• 16GB+ of RAM ( 32GB recommended)
• Packer 1.3.2 or newer
• Vagrant 2.2.2 or newer
• Oracle Virtualbox 6.0 (at the time of writing the Vagrant plugin did not support 6.1) or VMWare Fusion/Workstation (users will need to buy a separate license to interact with VMWare based hypervisors from Vagrant). In our case, we went with Oracle VirtualBox.

Once meeting the requirements, the next step is to clone or download Chris Long’s repository to your local machine. Downloading Chris Long's repository will ensure all the required definition files are present on the computer that will be hosting the lab. The next step is to build or download the lab machines.

Next, to begin downloading the lab, there is a single build script. The script supports three different options. For simplicity's sake, the easiest and recommended option is to download the pre-built Packer boxes from Vagrant Cloud. The more complex approach would be to build the boxes by leaving out the --vagrant-only option on the command line below. In a terminal window, the command to do this is the following:

The above process may take some time, but once completed, there will be four VirtualBox lab machines up and running on the 192.168.38.0/24 network range.

Custom additions

As pentesters, we have an arsenal of tools and methods that we use to test out vulnerabilities and/or gain access to vulnerable machines. Our goal when performing a red teaming or a penetration testing engagement is to mimic as much as possible the targeted infrastructure. So we are using the above baseline installation and we expand on it with any potential antivirus, intrusion detection/prevention systems, EDR solutions we may be encountering in that specific engagement. Once all the machines are up and running and configured to simulate the IDS and AV solutions in play, we can begin launching simulated attacks against the network. By doing this, we will be able to see which attacks are  discoverable and which cannot be detected and tune accordingly.

For our tests, we placed a Kali Linux pentesting machine on the same network as Detection Lab to simulate an attacker on an internal network.

Sample tests

We used Empire, to begin with, and ran a few commands such as sysinfo, ipconfig, ps and mimikatz. We did this to see what kind of information the logger and wef virtual machines would detect. After some time enumerating the system, we logged into the logger machine’s Splunk Web UI at https://192.168.38.105:8000/ to see what kind of data is captured and logged.

From the above screenshot, we can see several discovered simulated attacks; including Command-Line Interface in the category of Execution, Process Hollowing, PowerShell attacks and Credentials Dumping.

Hovering over the Hunting Indicators, it is noticeable that more detailed information about Sysmon Events, Lateral Movement Indicators, PowerShell Events and Newly observed hashes.

Before getting an initial agent on the target machine, we ran several PowerShell stagers against the Windows 10 non-server endpoint. The Logger did a great job detecting the base64 encoded payloads as seen in the image below:

Going back to the main page and clicking on the individual machine we were testing brings up a Computer Drilldown. Here we can find all the events that were logged and processed. Clicking on each event will then go into more detail for that event.

The ParentProcess GUID Drilldown has an excellent visual representation of the process execution. This representation includes the created process time, the Mitre Attack ID, the user under which the event/process was started by, and also the process paths for both PPID and PID.

We also see the raw sysmon event logs. Looking carefully, it is noticeable the use of the Empire PowerShell stager at the beginning of the test.

Going back to the main menu and this time selecting the Mitre Category Credential_Access, we can filter all the credential access related events that occurred during testing.

By clicking on the "Technique" field, it redirects to https://attack.mitre.org/ to the appropriate attacking technique. Here we can read up on the attack technique with detailed information about how it occurs. It also displays the tools commonly used to exploit this technique and mitigation that organisations should implement to stop the technique.

https://attack.mitre.org/techniques/T100/

For the next test, we wanted to see how well Detection Lab would perform against legitimate remote administration tools such as PsExec.

“PsExec is a light-weight telnet-replacement that lets you execute processes on other systems, complete with full interactivity for console applications, without having to manually install client software manually.”

 https://docs.microsoft.com/

PsExec is used by system administrators to remotely administer systems easily and quickly via SMB. However, although it is used legitimately most of the time, it can also be leveraged by potential attackers to execute and gain administrator access to other machines with breached credentials.

We used impacket’s python script PsExec.py to run ipconfig remotely on the Domain Controller.

We went back to the Logger UI and took a look in the Newly Discovered hashes menu. Here we could quickly identify that a newly observed ipconfig.exe hash had been logged; this also includes the timestamp of when it was identified.

We performed the same task in Metasploit using the PsExec module to gain a meterpreter shell. This process was performed 5 times to see if all 5 shells would be detected.

Under Drilldowns - Network connections, we can see that a TCP reverse connection was initiated from the DC to our Kali attacking machine.

All in all we were very impressed with Detection Lab. It offers a quick and easy way to spin up an environment that can be used to:

1. Simulate a customer’s Microsoft Active Directory environment without going through all the pains of setting it up from scratch;
2. Hone one’s skills specifically in Red Teaming by proving a fully monitored and configured environment with a single pane of log collection;
3. Test exploits.

We recommend all red teamers and penetration testers to try Detection Lab, as it provides a valuable insight into the offensive actions themselves and the kind of artefacts they generate.