Setting up a Pentesting... I mean, a Threat Hunting Lab

I see a lot of articles out there showing you how to use specific tools to steal credentials, move laterally, bypass security controls and even own an entire domain. However, only a few articles share how to detect or hunt for those attacks. One of the things I feel helps me a lot to stay up to date and to learn new offensive and defensive skills, besides reading books, is having my own personal lab at home. This allows me to test or validate new attacks while at the same time learning and developing new techniques to detect and hunt for them in the real world. 

Recently I had a few friends ask me to walk them through the basics of building a threat hunting lab. Therefore, I decided to start a series of posts with the title "Setting up a Pentesting... I mean, a Threat Hunting lab" to show you how you can also start setting up your environment to not just play red team but to hunt at the same time. 

This series will cover the basic configurations for the following:

Virtual network (WAN & LAN) (Part 1)

On this first post, I will show you how to set up a virtual WAN and LAN (NAT) with the help of ESXI 6.5 and PfSense. We will have our default original VM management network act as our virtual WAN and a new virtual switch and port group as our virtual LAN with PfSense as our router/Firewall. That way we can simulate real world attacks where inbound connections to non-public systems are not allowed unless there is a reverse connection initiated by a user or an infected host. Eventually we will add a Kali system to our virtual WAN to perform attacks.

Windows Server 2012 R2 build (Part 2)

In order to understand how adversaries compromise an entire domain and to learn what you have to hunt for, you have to create your own at home. In this post we will go over setting up a basic Windows Server 2012 and enabling the following server roles: DHCP, AD and DNS.

Promote your server to a domain controller and set up your own DHCP Server (Part 3)

Our server has AD domain services, DHCP and DNS roles enabled, now what? Time to promote our server to a domain controller (adding a new forest with its respective root domain, selecting functional levels for the forest and domain, specifying domain controller capabilities and setting the location of the AD DS database, log files and SYSVOL ) and to set up our own DHCP server.

Configure your Active Directory environment (Part 4)

It is time to create new Organizational Units (OUs), Users, Groups, GPOs, and join computers to our domain. Also, since we are going to learn how to create a GPO, I will show you how you can increase the visibility on your endpoints from a logging perspective by creating a more robust Audit Policy. Quoting Sean Metcalf "Securing Domain Controllers is only one part of Active Directory Security. Another is being able to detect anomalous activity which starts with logging." [source]

Hunting Platforms - ELK Stack (Part 5)

Up to this point, this setup might look familiar. However, what I believe takes any lab set up to the next level is having a central repository where logs generated during an attack can be stored, parsed and analyzed. This is how you learn the real skills because it allows you to see exactly what you need to look for when hunting for adversaries attacking your network.

For the purpose of my next threat hunting series, I will be using an ELK stack to store native Windows and Sysmon logs from my compromised systems and Winlogbeat to forward those logs to my basic stack. Later on, I will add other open-source projects such as Security Onion , Rock NSM, or even AlienVault's OSSIM  and implement other applications to make my ingestion and distribution of data more robust such as Kafka.

Sysmon and Winlogbeat on your endpoints (Part 6)

I wish I had an EDR vendor send me a dev agent [hint! hint!] to test how much event data I can capture from an endpoint, but for now I love to use Sysmon when it comes down to endpoint visibility. In this post I will show you how to install sysmon and use custom configurations to filter noise and still get the visibility you need to hunt for advanced adversaries. Additionally, as you might already know, we need some type of log forwarder to send logs to our ELK stack. In case you didn't know, Elastic provides several products besides Elasticsearch, Logstash and Kibana, and the one that will help us live stream Windows event logs to our ELK stack is named Winlogbeat. In this post, I will also show you how to set it up and integrate it with our ELK stack configurations.



Remember that these are just simple configurations I put together to fulfill most of my basic needs and what I wanted to accomplish with my own lab. These are by no means the MUST HAVE for your own lab environment, but I wanted to share it with the community and hopefully inspire others to also build their own #SharingisCaring. After this series, I will start another one where I will show you how you can use your custom environment to hunt for the hunter.

I hope these posts help you to start building your own environment and encourage you to do more research to fix or to improve what I present to you.

Feedback is greatly appreciated!  Thank you.