INTRODUCTION AND ENVIRONMENT SETUP

Introduction
A Home lab is an environment in your home that is used to practice
and improve your skills in a specific field. This home lab has
components and tools that can be found in enterprise
infrastructures. It’s a safe environment to work with these
components and learn how they work.

The objective of this 7-part series blog is to serve as a guide leading

to the building of a digital playground to safely simulate scenarios
for cybersecurity enthusiasts.

The idea is to have an environment where one can practice the

exploitation of network and/or system vulnerabilities, penetration
testing concepts such as persistence, remote command and control,
and covering your tracks as an attacker.

Thereafter, the environment will also provide a platform to practice

incident response and threat mitigation techniques.

In this way, you can practice both sides of cybersecurity, i.e. the
penetration side and the detection and mitigation side of
cybersecurity.

High-Level Architectural Overview

The image below shows our lab network topology as will be hosted
in the Oracle VM VirtualBox on your local machine.
Home Lab Network Topology

Let’s look at the technologies used in the lab:

a) pfSense:

PfSense is an open-source firewall and network segmentation

platform. It is the backbone of our lab as it acts as the barrier
between the network segments, controlling and monitoring
incoming and outgoing traffic via the configured firewall rules.
PfSense is also the gateway router. The setup is such that it is
accessed and configured via the Kali Linux VM via the web console
since they’re on the same LAN.

NB: pfSense should always be the first VM booted in the lab as it

also acts as the DHCP and DNS server for the virtual network
machines. Without this, the machines will not access the internet.

b) Kali Linux:

The Kali Linux VM will primarily serve as the attack machine i.e. It
will act as the point where all the attacks against the victim network
will be propagated from. The Kali VM will allow us to get hands-on
practice on offensive cyber security practices and general
penetration testing. It is from these attacks that we will be able to
learn how to mitigate cyber security attacks and incident response
principles.

c) Ubuntu Linux:

The security analyst VM will be hosted on the Ubuntu Linux

operating system. As the name suggests, it is from this VM that we
will detect malicious activities and put in measures that protect the
lab network devices. The security analyst will have access to the
security onion IDS via a web page and the Splunk instance will be
downloaded here to allow network monitoring and responding to
suspected malicious activities. Thereafter, we will apply security
controls from this virtual machine.

d) Security Onion:
Security Onion is a Linux open-source all-in-one solution for
intrusion detection, security monitoring, and log management. It
also has PCAP packet capture and analysis capabilities like
Wireshark. Security Onion is instrumental in understanding our
lab’s network behavior, detecting, investigating, and responding to
potential security threats.

e) Splunk:

Splunk is a software platform that is designed for monitoring,

collecting, indexing, searching, and analyzing machine-generated
logs in real time. In our lab, it will be used by the Security Analyst
as a SIEM where malicious activities i.e. threats can be detected,
and the data collected can be visualized in reports to provide data
insights. Splunk will work in conjunction with Security Onion as the
tool used by the Security Analyst to have a general and detailed
view of the network activities.

f) Victim Network:

The victim network is a collection of deliberately configured

vulnerable machines that will be attacked in the controlled lab
setup. It consists of a Windows domain environment with an Active
Directory server and a Windows 10 client machine. The lab will also
have the vulnerable machines: Damn Vulnerable Web Application
(DVWA) from VulnHub and Metasploitable from Rapid 7 which are
secure platforms for penetration testing and security research.

g) SPAN Port:
The SPAN port (also known as a mirror port) is a dedicated network
port configured to duplicate traffic from other ports to one specific
port and send it to one specific destination. It is going to enhance
network visibility by allowing security onion to capture a copy of all
network packets from and to the victim network for analysis. It is
from this data that our IDS will begin to monitor and detect unusual
traffic i.e. the propagated attacks from the Kali attack VM.

Installation & Setup

System requirements

 64-bit Windows 10 Operating System.

 Minimum 1.4GHz Intel Pentium or equivalent (2GHz
recommended) processor.
 At least 16GB of RAM.
 At least 2.0GB of disk storage.

Prerequisite Downloads:

These are the necessary building blocks we need for the lab. Follow
the links to download as per the instructions.

a) VirtualBox:

 Download VirtualBox via the

link [Link] (Be sure to
pick the correct download for your OS).
 Run the installer to install VirtualBox to your local machine
setup (i.e. Follow the steps of the installation guide
accepting all the defaults).
b) pfSense:

 Download the latest version of pfSense from the

link [Link] and click on
Download.
 Select the correct installation image as below and click add
to cart.

 Then proceed to ‘Go to Cart’ and then ‘Checkout’.

 This will lead to a login screen. ‘Create an account’ or ‘Sign
in’ then you will proceed to the complete order page.
 Fill in the necessary details the click on ‘Complete Order’.
 You will get the download link for pfSense. Proceed to
download the disk image.
 Your download will be a compressed disk image. Use
Winrar or 7zip file archiver software to extract the
download to get the pfSense disk image.

c) Security Onion:
  Download the Security Onion iso from the
link [Link]
on/blob/master/VERIFY_ISO.md

d) Ubuntu Desktop:

 Download the latest Kali Linux iso image installer from the
link [Link]

e) Kali Linux:

 Download the latest Ubuntu Desktop iso image installer

from the link [Link]

f) Windows 10:

 Download the latest Windows 10 Installation Media Tool

from the link [Link]
download/windows10
 Once downloaded, Run the Media Creation Tool.
 Read and accept the Licensing Agreement.
 Select the ‘Create Installation Media (USB flash drive,
DVD, or ISO file) for another PC’ option and click next.
 Use the recommended options for Language, Architecture,
and Edition and click next.
 Select ‘ISO File’ as the media to use and click next to
download the ISO Image for Windows 10.

g) Windows Server 2019:

  Download the Windows Server 2019 disk image from the
link [Link]
windows-server-2019. Make sure you’ve selected the ISO
downloads option, English in this case.

h) VulnHub — DVWA:

 Download the DVWA disc image from the

link [Link]
application-dvwa-107,43/
 Be sure to use the download link highlighted below:

i) Metasploitable:

 Download the Metasploitable Linux from the

link [Link]
 Unzip the downloaded file to gain access to the virtual
machine disk format
Now that we’ve laid out all the resources we need for our lab, we
should proceed with setting up and configuring them. Let’s begin
with installing pfSsense, our firewall in the next episode here: part
two. Happy learning!

PFSENSE & NETWORK INTERFACES SETUP

Introduction
Welcome back to the blog series, ‘Cybersecurity Detection and
Monitoring Lab’. Find the link to part one of the lab where we
introduced the lab and its components.

Today, we embark on installing and setting up pfSense, our network

security guard. Specifically, we will complete the initial
configuration required of the network interfaces in pfSense to
onboard the network segments that make up our lab.

Below is an image of our lab network topology that we will as a

reference throughout this blog series.
Setting up the pfSense Virtual Machine
 Go to VirtualBox and click on ‘New’ to create a new Virtual
Machine (VM).
 For the name, type in ‘pfSense’, then for the iso image
select the downloaded pfSense iso image.
 Type will be ‘BSD’ and the version should be ‘FreeBSD(64-
bit)’. Then click on ‘Next’.
· Give the new VM 2GBs of RAM, then proceed to click on ‘Next’.

· Allocate a disk size of 16GB and click ‘Next’. Then proceed

to ‘Finish’.

· Click on the pfSense VM then select ‘Settings’.

· Go to ‘Network’ to enable the 6 virtual network adapters as per

our lab requirements i.e. NICs for following the VMs:

1. Bridged Adapter to access the internet.

2. Kali Linux Attack Machine (LAN interface to access
pfSense and configure firewall rules)
3. Victim Network with the vulnerable machines
4. Security Onion
 5. Span Port
6. Ubuntu Desktop Cybersecurity Analyst VM.

· Notice that VirtualBox has 4 network adapter tabs to configure in

the GUI. However, you can add up to 8 network interfaces on any
VM. Configure the 4 network adapters as follows:

 For Adapter 1, set as the image below.

 For Adapter 2, set as the image below. Take note of
the ‘name’ value detect-and-monitor-LAN as this is what
distinguishes our vLANS. Then click ‘ok’ once done.

 For Adapter 3, set as the image below. Take note of

the ‘name’ value detect-and-monitor-lab-Analyst-
VLAN. Then click ‘ok’ once done.
 For Adapter 4, set as the image below. Take note of
the ‘name’ value detect-and-monitor-SecOnion-VLAN.
Then click ‘ok’ once done.
· Following the Oracle VM VirtualBox documentation, section
8.10 [Link]
modifyvm, we will have to use the VirtualBox CLI
— ‘[Link]’. Proceed with the following steps to add the
next two adapters to our pfSense VM:

 Navigate to where VirtualBox is installed on your

computer. In my case, it’s in the ‘C:\Program Files\Oracle\
VirtualBox’
 Right-click on the window and select ‘Open in
Terminal’. PowerShell will open which I highly recommend.
 Type the command: ‘.\[Link] to see the general
usage options for the [Link] CLI.

 We need to add the VM Name, Next Interface

ID and Network name. For my case, me details are as
follows:

1. VM-Name: pfSense
2. Next Interface ID: 5 (for Adapter 5) and 6 (for Adapter 6)
3. Network Name: detect-and-monitor-lab

 Proceed to add the interfaces by running the following

commands.

1. For Adapter 5:
2. For Adapter 6:

· Go to ‘Audio’ and disable it.

· Go to ‘USB’ and disable it.
 Select the pfSense virtual machine and click ‘Start’ to
begin the installation.
 Accept’ the Copyright and Distribution Notice.
 Click ‘ok’ to install pfSense.
 Click ‘ok’ to select the default Partitioning.
 Press ‘Select’ to continue with the default ZFS
Configuration: configure options.
 Click ‘Select’ to proceed with the partition.
 Choose Stripe — No redundancy since we are installing
pfSense on a single disk and click ‘ok’.
 Use your space bar such that an asterisk (*) denotes the
selected disk and select ‘ok’.
 Select yes on the next screen. Use arrow keys.
 The installation process will begin.
 The installation will complete and a screen requesting you
to reboot will appear.
 Remove the iso installation file from VirtualBox before you
reboot the VM otherwise, you will be led to the initial steps
of the installation. To do so:

1. Click on ‘Devices’ on your VirtualBox menu.

2. Go to ‘Optical Drives’ and select ‘pfSense iso image’.
3. Then select ‘Force Unmount’.

 Press ‘enter’ to reboot the virtual machine.

 Then type exit to complete the reboot.
 Ignore the errors below and reset the virtual machine by
clicking on Machine then Reset on the VirtualBox menu.
 Once the machine has rebooted, you’ll get a prompt that
asks ‘Do you want VLANs set up now[y|n]?’ Choose n.
 Proceed to enter the name for the WAN interface as follows
and press enter.
 Enter the LAN interface name as below, then enter the
remaining interface names following the same format.
 This should be the result. Type ‘y’ to confirm your naming
configuration.
Configuring the pfSense Interfaces
As per the image below, two interfaces will have IP addresses: the
WAN interface will pull an IP address from your network (in my
example [Link]/24) and the LAN interface will have a
Default LAN IP address space [Link]/24. The other interfaces
will not have IP addresses. We will configure IP addresses for the
other VMs in the next steps.
a) Configure the LAN interface (Kali Linux Attack VM)

 Despite the LAN interface having an IP address, we want to

set up some more settings on it such that Kali can access
the pfSense web configurator.
 Enter option ‘2’.
 Enter option ‘2’ to select the LAN interface.
 Enter ’n’ not to configure IPv4 via DHCP. This is already
taken care of by the WAN interface.

 Enter the new IP address ‘[Link]’.

 Enter the subnet mask bits ‘24’.
 Proceed to press enter. This is a LAN.
 Enter ’n’ since we will not be using IPv6.
 Press Enter for no IPv6 address.
 Enter ‘y’ to enable the DHCP server on LAN.
 Enter the start address ‘[Link]’.
 Enter the end address ‘[Link]’.
  Enter ’n’ not to revert to HTTP as the webConfigurator
protocol. We want to keep using TLS.
 As per the screenshot below, we will be able to access the
WebConfigurator via the url shown i.e. ‘[Link]

 Press <ENTER> to continue.

b) Configure the OPT1 interface (Security Analyst VM)

 Enter option ‘2’.

 Enter option ‘3’ to select the OPT1 interface.

 Enter ’n’ to configure the address statically.

 Enter the network address.
 Enter subnet mask bits.
  Proceed to press enter. This is a LAN.
 Enter ’n’ since we will not be using IPv6.
 Press Enter for no IPv6 address.
 Enter ’n’ to enable the DHCP server on LAN.
 Enter ’n’ not to revert to HTTP as the webConfigurator
protocol.

 Press <ENTER> to continue.

c) Configure the OPT2 interface (Security Onion VM)

 Enter option ‘2’.

 Enter option ‘4’ to select the OPT2 interface.

 Enter ’n’ to configure the address statically.

 Enter the network address.
 Enter subnet mask bits.

 Proceed to press enter. This is a LAN.

 Enter ’n’ since we will not be using IPv6.
 Press Enter for no IPv6 address.
 Enter ’n’ to enable the DHCP server on LAN.
 Enter ’n’ not to revert to HTTP as the webConfigurator
protocol.
  Press <ENTER> to continue.

d) Configure the OPT3 interface (Victim Network)

 Enter option ‘2’.

 Enter option ‘5’ to select the OPT2 interface.

 Enter ’n’ to configure the address statically.

 Enter the network address.
 Enter subnet mask bits.
 Proceed to press enter. This is a LAN.
 Enter ’n’ since we will not be using IPv6.
 Press Enter for no IPv6 address.
 Enter ’n’ to enable the DHCP server on LAN.
 Enter ’n’ not to revert to HTTP as the webConfigurator
protocol.
  Press <ENTER> to continue.

e) Configure the OPT4 interface (SPAN Port)

We’re going to leave OPT5 without an IP address because it’s going

to have traffic from the Victim network that Security Onion will be
monitoring.

pfSense final interface configuration

The interfaces and IP addresses should now look like this:

We’ve now successfully installed our firewall and created the

network segments within it. Next, we need to set up our ‘control’
machines i.e. the Kali Linux Attack Machine used to configure
pfSense and the Security Analyst VM. Catch this in the next episode
here: part three. Happy Learning!

KALI LINUX ATTACK VM & UBUNTU SECURITY ANALYST VM

SETUP

Introduction
Welcome back to the blog series, ‘Cybersecurity Detection and
Monitoring Lab’. Find the link to part two of the lab where we
installed the pfSense firewall and set up the initial configuration of
our network interfaces.

Today, we embark on installing the two network controllers; the

Kali Linux Attack virtual machine (VM) and the Ubuntu Security
Analyst virtual machine (VM). We need the Kali VM initially to
access the pfSense web console and finish configuring the network
interfaces, DHCP, and DNS activation. Thereafter, we will
propagate attacks on our victim network devices from here. The
Analyst VM will be the central point at which we will be accessing
the IDS and SIEM to monitor the traffic and respond to incidents in
our lab.

Below is an image of our lab network topology that we will

reference throughout this blog series.
Setting up the Kali Linux Virtual Machine
Kali Linux will be used as the attack machine that will propagate
different forms of offensive actions against the victim network.

Configure the VM by following the steps below:

 Go to VirtualBox and click on ‘New’ to create a new Virtual

Machine (VM).
 For the name, type in ‘Kali Linux AttackVM’, then for the
iso image select the downloaded Kali Linux iso image and
click on ‘Next’.
 Give the new VM 2GBs of RAM, then proceed to click on
next using the defaults until you finally create the Kali
Linux VM by clicking on ‘Finish’.
 Click on the Kali Linux VM then select ‘Settings’.
 Go to ‘Network’. Enable Adapter 1 and set it as below to
our internal network detect-and-monitor-LAN.
 Click ‘Start’ to Power on the virtual machine.
 Select Graphical Install and click on ‘Enter’.
 Select your preferred language, country, and keyboard to
proceed.
 Enter an appropriate hostname for your case.
 Leave the domain blank and click ‘continue’.
 Enter the username and password then click
on ‘continue’ to allow login to the OS after installation.
 Continue with the entire disk partition and all files in one
partition (the recommended options).
 Finish partitioning and write changes to disk.
 Select ‘Yes’ then continue to begin OS installation.
 Continue with the default Software selection.
 Select ‘Yes’ to install the GRUB Boot Loader. Select your
drive the click ‘continue’.

 Choose ‘continue’ to reboot the machine.

 Log in with your username and password.
 Open the terminal in Kali Linux and type in the
command ‘ifconfig’ to confirm that the LAN VM has
received an IP from the pfSense DHCP server. You should
see the IP address below. We will use Kali Linux to
 configure our pfSense terminal and this should be done on
a private network.

Setting up the Security Analyst VM.

The general objective of this lab is to simulate a security analyst.
This Ubuntu VM will be used as the analyst VM where a security
analyst will be able to analyze and mitigate against the different
forms of offensive actions propagated against the victim network.
The tools in the lab e.g. Security Onion, Splunk, and Wireshark will
be accessed from this VM by the analyst.

Configure the VM by following the steps below:

 Go to VirtualBox and click on ‘New’ to create a new Virtual

Machine (VM).
 For name, type in ‘Security Analyst, then for iso image
select the downloaded Ubuntu iso image and click
on ‘Next’.
 On the Unattended Guest OS Install Setup page, type in an
appropriate username and password. Click on ‘Next’.
 Give the new VM 2GBs of RAM, then proceed to click on
next using the defaults until you finally create the Security
Analyst VM by clicking on ‘Finish’. The installation will
begin automatically.
 Choose your preferred language.
 Select ‘Install Ubuntu’.
 Choose your preferred keyboard layout and click on next.
 Select the default installation and click on ‘Next’.
 Click on ‘Next’.
 Click on install.
 Enter account details as below and click on ‘Next’.
 Choose a theme and click on ‘Next’.
 The installation will begin automatically.
 After the installation is complete, log in to the Ubuntu VM.
 Launch the terminal type the command ‘sudo apt upgrade’
and press enter. Then ‘sudo apt update’ and press Enter to
ensure you’re running the most recent version of Ubuntu
OS.
 Turn off the VM. Go to the settings tab and ensure Adapter
1 has the following configuration.
 Login to the VM. Open the terminal and type the
command ‘ifconfig’.
 Since we need to check our IP addresses for assignments,
we must install network tools. Run the command ‘sudo apt
install net-tools’ in the terminal.
 Type the command ‘ifconfig’ again. You should get a result
close to the one below. Notice the IP address from your
home DHCP. We will also add the vtnet2 adapter (detect-
and-monitor-Analyst-VLAN) as Adapter 2 that will connect
our Analyst VM to pfSense.
Note that Adapter 2 in our setup doesn’t have an IP address. This
means that pfSense which in this scenario is our DHCP server has
not assigned an IP address to our Analyst VM. We will add this
when we configure our pfSense VM.

Great work! We now have our attack and analyst machine set up.
We will now proceed to install Security Onion our IDS to monitor
our network traffic. Catch this in the next episode: part
four. Happy Learning!

SECURITY ONION

Introduction
Welcome back to the blog series, ‘Cybersecurity Detection and
Monitoring Lab’. Find the link to part three of the lab where we
installed the Kali Linux Attack Machine and the Ubuntu Linux
Security Analyst Machine.

In this episode, we proceed to install and configure our all-in-one

IDS, security monitoring, and log management solution, Security
Onion. The lab is set up in such a way that all the logs from the
victim network are duplicated via a Span Port and sent to Security
Onion, as shown in the network topology diagram below. This will
allow the investigation and analysis of all the activities that have
taken place in the victim network, allowing the Analyst to take swift
action based on the alerts generated in Security Onion.

Setting up Security Onion

Configure the VM by following the steps below:

 Go to VirtualBox and click on ‘New’ to create a new Virtual

Machine (VM).
 For the name, type in ‘Security Onion, then for the iso
image select the downloaded Security Onion iso image and
click on ‘Next’.

 On the Unattended Guest OS Install Setup page, type in an

appropriate username and password. Click on ‘Next’.
 Give the new VM at least 4GBs of RAM and 4 processors,
then proceed to click on ‘next’. (Security Onion
recommends 12GB of RAM and 4 processors. In this lab
environment, be aware of this as you also consider your
hardware capabilities).
 Select a hard disk space of at least 100GB as recommended
then click on ‘next’.
 Finally create the Security Onion VM by clicking
on ‘Finish’. Take note of the error. We will fix it in the next
few steps.
 Click on the Security Onion VM then select ‘Settings’.
 Go to ‘Network’. Select Adapter 1 and set it to Bridged
Adapter, then enable Adapter 2 and Adapter 3 setting them
both to internal network.
 Set Adapter 2 to interface with pfSense at detect-and-
monitor-SecOnion-VLAN i.e. vtnet3.
 Network Adapter 3 will be mapped to the Span Port,
detect-and-monitor-SpanPort-VLAN i.e. vtnet5. Set the
Promiscuous Mode to ‘Allow All’.

 Select ‘Storage’ and select the Security Onion iso image.

 You can disable both the USB and Audio controllers.
 Click on ‘Start’ to power on the VM.
 Enter an appropriate administrative username and
password.
 The installation will begin automatically after you
press ‘Enter’.
 Click enter to reboot the VM after installation is complete.
 After the VM has rebooted, enter the admin credentials to
login.
 Click ‘Yes’.
 Select the standard installation.
 Select the EVAL option.
 Type ‘AGREE’.
 Select the Standard option.
 Select an appropriate name.
 Select the first NIC as it’s the one that can access the
internet.
 Choose DHCP for the management interface.
 Select ‘Yes’.
 Select ‘direct’ internet connection.
 The monitoring interface NIC will be enp0s9. This will be
the NIC for the Victim Network (in our case the Span port).
Use the space bar to select it.
 Enter an email address. Note that it doesn’t have to be an
actual email address. Then enter a password for the email
address. These will be the credentials we use to access the
Security Onion web portal.
 Select to access the web interface via an IP address.
 Allow access to Security Onion installation via the web
interface.
 Type in the IP address range as below. This will be the IP
address range that will be allowed to access the Security
Onion web interface. Click ‘ok’.
 Take note of the management IP below. It will be the IP
address we use to access the Security Onion web interface
via the Analyst VM. Press the tab key to select ‘yes’. This
will begin installation.
 The installation will be complete, and you should
see yourusername@localhost on your Security Onion
terminal.
 The next step is to allow access to the Security Onion web
interface via the Security Analyst VM. Type the
command ‘sudo so-firewall includehost analyst
[Link]’ in the Security Onion console.
 Then type the command ‘sudo so-firewall apply’ to apply
the changes.
 Go to the browser on your analyst VM and search
for [Link] to access the Security Onion
web interface.
 Click on ‘Advanced’.

 Accept the risk and continue.

 Enter the login credentials you input during the setup i.e.
in my case admin@[Link] and the
accompanying password.

 Log in to see the following welcome page.

  Given the number of services offered on Security Onion, I
will explore its components and write an article on the
same.

Note: The management IP address is not static. It depends on the

home router that your machine connects. If you need to effect a
change in the management IP, type the command ‘sudo so-ip-
update’ on your Security Onion terminal.

Excellent stuff! We’ve finally completed setting up Security Onion,

which come to think of it, is the engine that will keep our lab
moving and make it worthwhile, despite how long the installation
takes. Thank you for persevering through it. Next, we have to now
configure firewall rules in pfSense so that our lab devices can
communicate and access the internet. Catch this in the next episode
here: part five. Happy Learning!

PFSENSE NETWORK INTERFACE & FIREWALL RULES

CONFIGURATION

Introduction
Welcome back to the blog series, ‘Cybersecurity Detection and
Monitoring Lab’. Find the link to part four of the lab where we
installed Security Onion to act as the engine of our lab that will sniff
network packets and assist in generating alerts when malicious
activities are suspected in our victim network.

Today, we continue with the work done in part two of our blog
series and finish up configuring pfSense. We will define the
interfaces for easier reference, then enable and configure the DNS
and DHCP capabilities such that all our connected subnets can get
IP addresses and access the internet. Finally, we will also define
Firewall rules for the subnets we defined in our home lab. We will
use the pfSense WebConfigurator to perform all the tasks in this
lab, accessed via the Kali Linux machine because pfSense and the
Kali VM are on the same LAN.

It is very critical to follow our guide here, the network topology

diagram, as it will allow us to use the pre-defined IP address ranges
and allow consistency throughout the series.
Configure pfSense interfaces
Let’s begin with the interfaces by following the steps below:

 On the Kali VM, navigate to the web browser and search

for [Link].
 Click on ‘Advanced’.

 Accept the risk and continue.

 Sign in to pfSense using the default
credentials: admin & pfSense.

 The next page will be the pfSense ‘wizard/pfSense

setup’ page.

 Click on next till you get to the ‘General information’ page.

Here input your Primary DNS server as ‘[Link]’ (Google
 DNS server) and your Secondary DNS server as ‘[Link]’.
Click on ‘next’.

 Select your timezone then click on ‘next’.

 Unblock the RFC1918 Networks and Block bogon networks
checkboxes and click on ‘next’ until you get to the Admin
password page.

 Change the default admin password. Click on ‘next’.

  Click on ‘reload’.
 Click on ‘finish’. Accept the Copyright and Trademark
notices.
 Go to ‘System’, then ‘General Setup’. Change the theme to
dark in the webConfigurator module.

The next step is to configure the interfaces as we had initially

defined and named them. Go to ‘Interfaces’ to begin.

 LAN (vtnet1): Change description value to ‘Kali’,

click ‘save’ then ‘Apply Changes’.
 OPT1 (vtnet2): Change description value
to ‘SecurityAnalyst’, click ‘save’ then ‘Apply Changes’
 OPT2 (vtnet3): Change description value
to ‘SecurityOnion’, click ‘save’ then ‘Apply Changes’.
 OPT3 (vtnet4): Change description value
to ‘VictimNetwork’, click ‘save’ then ‘Apply Changes’.
 OPT4 (vtnet5): Change the description value
to ‘SpanPort’ then click the checkbox to enable the
interface. (The interface is not enabled because we didn’t
give it an IP address during the initial pfSense setup).
Click ‘save’ then ‘Apply Changes’.
 OPT5 (vtnet6): Change description value to ‘Splunk’,
click ‘save’ then ‘Apply Changes’.
 Click on ‘Assignments’ to see the following setup.
  Click on ‘Bridges’ and click ‘Add’. (See highlighted area in
preceding photo).
 For member interfaces, click on ‘VictimNetwork’ then
click on ‘Display advanced’.
 For the Span Port, click on ‘SpanPort’. Scroll to the
bottom of the page and click on ‘Save’.

By the above two steps, we have effectively configured our Span

Port to copy and direct all traffic in and out of our Victim network to
Security Onion.
Enable and Assign DHCP Ranges
 Go to ‘Services’, then click on DHCP server.
 Notice the Kali interface loads and it has the ‘Enable DHCP
server on Kali Interface’ checkbox marked and
the ‘Address Pool Range’ fields with IP addresses from the
subnet range specified above the fields.

 Now, following the above convention, proceed to apply

changes to the rest of the four interfaces. For example, the
SecurityOnion interface would look like this.
DNS Resolver Service Optimization
 Go to ‘Services’, then select ‘DNS Resolver’.
 Scroll to the bottom of the page and enable the two
following options.

 Scroll to the top and click on ‘Advanced Settings’.

 Enable the following options as well.
  Scroll to be bottom of the page and click
on ‘Save’. Then ‘Apply changes’.

Configure the Firewall Rules

i. WAN Interface:

 Go to the ‘Firewall’ dropdown and click on ‘Rules’.

 Click on ‘Add a rule to the bottom of the list’.
 Amend the Protocol value to ‘Any’ and click ‘save’. The
firewall rule allows all traffic through our pfSense firewall.
This is certainly never going to be implemented in an
enterprise environment. However, it does serve the
purpose of allowing us to gather as much information as
possible in Security Onion for our future exploitation
activities. Click on ‘Apply Changes’.

ii. LAN Interface:

 Click on ‘Add a rule to the bottom of the list’.

 Set the same rule as above.
NB: Proceed to set the same rule for all the other network
interfaces. Remember, we want our internal network as open as
possible for initial exploitation before we begin to harden it.

Good job! We have completed the configuration of pfSense required

to start the lab. It is important to note that whenever we start the
lab, pfSense should always be the first VM booted because it also
serves as our DHCP server. Next, we need to have our victim
network set up. Catch this in the next episode here: part six. Happy
Learning!

VICTIM NETWORK SETUP & CONFIGURATION

Introduction
Welcome back to the blog series, ‘Cybersecurity Detection and
Monitoring Lab’. Find the link to part five of the lab where we set
up firewall rules for our lab in pfSense to allow our devices to
exchange network traffic.

In today’s episode, we set up our victim network, where all the dirty
work will be done. The subnet will be comprised of a Windows
Active Directory Domain Server with a Windows 10 client (a
simulation of an enterprise environment) and two deliberately set
servers DVWA and Metasploitable 2 that will allow us to practice a
wide range of penetration techniques.

Below is our standard reference point, the network topology

diagram, that we will use here when assigning IP address ranges to
our Domain Controller.

Active Directory Environment

For a quick introduction and setup guide on Active Directory, visit
my article, Windows Active Directory Home Lab simulating an
Enterprise environment. (A little confession, I cloned the VMs
from the Active Directory Lab)
Take note of the following as you’re walking through the
configuration process as described in the article linked above:

 Set all the Active Directory Virtual Machine network

adapters as follows: Adapter 1 to detect and monitor-
Victim-VLAN.

 The IP addresses should match the IP addresses of the

current architecture i.e. [Link]/24 for the internal
network. Make pfSense the default gateway [Link]
 and make the IP address for the domain controller
[Link] then follow through subsequently.

Domain Controller IP address,

Windows Client IP address

 One key thing missing in the Active Directory Lab

walkthrough is adding Active Directory Certificate
Services to the server roles and subsequently
adding Certification Authority to the Role services.
Ensure that you add these services since some exploits can
be tested.
 After installation is complete, the server has to be
restarted.
 After restart, you should a prompt from the notification
icon. Click on the link.

 Click on ‘Next’.
 Select the ‘Certificate Authority’ checkbox and click
on ‘Next’.
 Click on ‘Next’ until you reach the ‘Confirmation Page’.
Click on ‘Configure’ to save the changes.

 Finally, make sure you disable the Windows Defender

Firewall in your domain controller. Remember, we want to
make the most out of our lab by having the weakest
configuration settings. Type ‘Windows Defender
Firewall’ on your start menu then click on ‘Turn Windows
Defender Firewall on or off’. Proceed to turn off all the
customized settings for each type of network. You can also
 disable Windows Defender Firewall by using Group Policy
Management.

Optional vulnerable machines.

i. Vulhub’s DVWA (Damn Vulnerable Web Application)

 Go to VirtualBox and click on ‘New’.
 For the name, type in ‘DVWA’, then for the iso image select
the downloaded DVWA iso image and click on ‘Next’.
 Give the new VM 1GBs of RAM, then proceed to click
on ‘Next’.
 Allocate a disk size of 20GB and click ‘Next’. Then proceed
to ‘Finish’.
 Go to ‘Settings’ then ‘Network’. Set the VM to the internal
Victim VLAN. Click ‘ok’.
 Click ‘Start’. DVWA should boot as follows to the start
page.
 Confirm the IP address by typing the
command ‘ipconfig’. See from the image below that it
does belong to the Victim Network subnet [Link]/24.
ii. Metasploitable 2
 Go to VirtualBox and click on ‘New’.
 For the name, type in ‘Metasploitable’. Note that I have not
selected an ISO image. Select the OS type and version as
shown below and click on ‘Next’.
 Click on ‘Next’ until you get to the Virtual Hard disk page.
Here, select ‘Use an Existing Virtual Hard Disk File’. Then
select the file explorer icon highlighted below.
 Click on ‘Add’ and navigate to the extracted virtual
machine disk image. Click on ‘open’.
 With the virtual machine disk image selected, click
on ‘Choose’.
 Click on ‘Next’ and then ‘Finish’ the installation.
 Go to settings then select ‘Network’. Set it to the Victim
LAN as shown below and click ‘ok’.
 Click on ‘Start’ to boot the machine. The default username
and password both are ‘msfadmin’.
 Confirm the IP address by typing the
command ‘ipconfig’. See from the image below that it
does belong to the Victim Network subnet [Link]/24.
Nice work! We have now successfully set up our victim network and
it is ready for all the exploits we can come up with as we endeavor
to sharpen our cybersecurity skills. We are almost completing our
lab setup. Next, we need to set up our environment to allow
practice with another SIEM, Splunk. Catch Splunk’s installation and
configuration in the next episode here: part seven. Happy
Learning!
SPLUNK CONFIGURATION

Introduction
Welcome back to the blog series, ‘Cybersecurity Detection and
Monitoring Lab’. Find the link to part six of the lab where we set
up our victim network with vulnerabilities that we can exploit.

In this episode, we set up Splunk, a Security Information and Event

Management (SIEM) service that we will use to primarily receive
logs from the Domain Environment via a Universal Forwarder.
Splunk is currently one of the most popular SIEMs used in
enterprise environments globally. Splunk aggregates logs and data
(of security interest) from various devices in a network. It then
correlates all that information for searching, parsing, and indexing,
making it easy for security professionals to keep a close eye on the
infrastructure and investigate suspicious activity.

Below is the network topology diagram to give you a clear picture of

our desired result.
Splunk Installation and Configuration
The Splunk instance will be hosted in the Analyst VM. Let’s
download and install the instance by following the steps:

 Log in to your Security Analyst VM. Go to the following

URL

[Link]
 While on the page, click on ‘Get Started’. This will direct
you to either Log In if you have an account or Create an
Account. Proceed as necessary.
 Go to the Linux section and click on ‘Download Now’ on the
.deb version.

 After the installation is complete, open the terminal and

navigate to the Downloads folder.

 Run the following command sudo apt install curl to

install the curl command. This Linux command is used to
fetch data from URLs, handle HTTP requests, and
download and upload files on the web. In our use case, it is
 a dependency for Splunk. Enter your password when
prompted.

 Run the following command to install Splunk: sudo dpkg -

i splunk-9.2.1–78803f08aabb-linux-2.6-
[Link]. Note that the name of the file may defer if
you download a newer version of Splunk. Use the filename
that you downloaded in the command above.
 After the installation is complete, run the
command ‘sudo /opt/splunk/bin/splunk start –accept-
license –answer-yes.
 Provide credentials i.e. username and password, that will
be used to log into Splunk when prompted.

 Once the setup is complete, we will see Splunk running

on [Link] which can be accessed
at [Link]
  If you’d like Splunk to run automatically on system boot,
run the following command: sudo /opt/splunk/bin/splunk
enable boot-start. Alternatively, if you’d like to start the
Splunk instance, run the command: sudo
/opt/splunk/bin/splunk start.

Splunk and Splunk Universal Forwarder Configuration.

 Open Splunk by going to [Link]

 You should log in to the following Admin Dashboard.

The Splunk Universal Forwarder is a mechanism that logs the
activities on endpoints. It is used to send logs from different sources
to the Splunk instance. We will download and configure it so that it
sends logs from our Domain Controller to our Splunk instance.

First thing we have to do is set up the ability for logs to be

received by our Splunk instance. To do this, proceed with the
following steps:

 Go to ‘Settings’. Then go to ‘Forwarding and Receiving’.

 Click on ‘Add New’ in the Receive data section.
  Enter 9997 as the port to listen for incoming data. This is
the default port that the Universal Forwarder listens on.
Click on ‘Save’.

Now, we create an Index. Splunk indexes are repositories where

our logs are stored that thereafter allow us to use Search Heads to
search for data from these indexes.

 Go to ‘settings’ and click on ‘Indexes’.

 Click on ‘New Index’.
 Type the Index Name ‘wineventlog’ and click on ‘Save’.
 The index should appear as below.
Next, we need to download and install the Universal Forwarder in
the Windows Domain Controller so that we can ingest the log data
that is generated by our domain environment.

 Login to the Domain Controller and proceed to the

following link to download the Universal
Forwarder [Link]
[Link]
 Login to your Splunk account to complete the download.
Click on the ‘Download Now’ button.
 Click on ‘Access program’ to begin the download.
 After the download is complete, click on it i.e.
the ‘.msi’ file, to begin the installation.
 Check the box to accept the license agreement. Click
on ‘Next’.

 Enter a Username and Password.

 For the IP address, we need the IP address of the Security
analyst VM. Open the Analyst VM terminal and type the
command ‘ifconfig’ to get the IP address.
 Use the enp0s3 address and enter the default port as
directed.
 Enter the Analyst VM IP again and the default port as
directed.
 Click on ‘Install’.

 Click on ‘Finish’.
Now that we have both Splunk and the Universal Forwarder
configured, we need to link both pieces together so that Splunk can
collect data i.e. The Data Ingestion Configuration.

 Go to Splunk, ‘Settings’, and click on ‘Add Data’.

 Click on ‘Forward’.
 The Windows DC should automatically appear under
Available Hosts. Click on ‘Add all’ and input the
name ‘Domain Controller’ in the ‘New Source Class
Name’ field to provide a name for our source. Click ‘Next’
to continue.
 Select ‘Local Event Logs’. Select ‘Add all’. Click on ‘Next’.
 Click on the ‘Default’ dropdown and select the previously
created ‘windowseventlog’. Then click on ‘Review’.
 Confirm all the options are correct and click on ‘Submit’.
 At this point, the lab is set up. You can click on ‘Start
Searching’.

 The following page will load, showing the queried data. You
can also get to this page by going to ‘Apps’, then ‘Search &
Reporting’. Be sure to match the index
i.e. index=’windowseventlog’ as highlighted below.
CONCLUSION & RECOMMENDATIONS
Finally, our home lab is up and running. The immediate next steps
should now focus on looking at each of the technologies used in
detail.

· We’ll start with pfSense specifically looking to understand firewall

rules and how they affect the network.

· Then proceed to tighten our knowledge of Active Directory, how to

set policy rules, and how they can make or break our network
security.

· Then proceed to do a walkthrough of Security Onion, exploring the

inner workings of the Security Information and Event Management
(SIEM) system and gaining a better understanding of SIEM
thereafter SOC operations.

· Finally, we’ll review Splunk, and explore the services and use
cases it can and is applied to in enterprise environments.
The most important thing is to have fun while learning. The lab is
set up in such a way that we can engineer attacks, see their effects,
collect the logs, and mitigate against them. I can safely say, that the
Cybersecurity world is both your and my oyster.

Thanks alot for following the walkthrough and to all the creators
who have published the free resources I have used in this lab. Good
luck to all of us! Happy Learning!

RESOURCES.
Below are the resources I used throughout the lab.

 Gained insights on the general lab architecture and a brief

security onion introduction watch, Cyberwox’s YouTube
series: [Link]
v=0BVtSRhjViQ&list=PLDqMNdDvMsRkmtiKcZwbhOz7Me
LQE0r3G&index=1
 To learn how to configure VirtualBox for the lab
environment, read the 0xBEN’s
blog: [Link]
virtualbox/
 For another resource for the lab architecture, see
@TheCyberChef’s blog series: Monitoring and Detection
Lab Part One —
Five: [Link]
detection-lab-part-one-cd1c6df25228
 For additional information on Splunk and its setup, see
David Varghese’s blog, Building a Virtual Security Home
Lab: Part 10 — Splunk Setup &
Configuration [Link]
-home-lab-part-10/
Write

Sign in

Sysmon: How To Setup, Configure, and Analyze the

System Monitor’s Events

Syed Hasan

Follow
6 min read

Oct 22, 2020

Sysmon, short for System Monitor, is a utility tool

developed by Mark Russinovich, as part of the
Sysinternals suite. The utility is registered in a Windows
box as a system service and a device driver, which in
sync, help log activities across the environment to the
Windows Event log. Just a quick analysis of the logs
generated by Sysmon can help identify malware,
intrusions, and breaches within the network.
What Does Sysmon Do?

Due to active development of the project, newer artifacts

and evidence sources are constantly being added to
Sysmon’s capabilities. However, you can get a quick idea
on how Sysmon can aid you in identifying anomalous
activities by checking this short list of features:

 Log process creation — command line, basic

process information, parent process information, etc.

 Network communications — connection’s source

processes, IPs, ports, hostnames, etc.

 Hashing process images — a hash of process

image files is available in SHA1, MD5, SHA-256, or
the IMPHASH format

 DLL loading — identify the loading of DLLs along

with their hashes

 File modification — Identify changes in file

creation times, a technique most commonly utilized
by attackers to avoid detection

 Kernel-mode malware, rule filtering based on

False Positives, session identification,
correlations, and much more!

How to Install Sysmon

Installing and configuring Sysmon is fairly easy. After

acquiring the binaries from Microsoft’s own website —
head towards the console in the same directory. First, let’s
take a look at the options provided by the binary:

[Link] -h
So, the installation of Sysmon as a service/driver required
a configuration file. Though there’s a default setting in
place, you can also pass your own configuration file to
over-ride the default settings. We’ll get back to
configuring the service later. For now, let’s install Sysmon
with the defaults (from an administrative console):

[Link] -i

The default configurations include:

 Process images are hashed with SHA-1

 Network connections are not monitored

If you don’t wish to configure the service, this was it.

Sysmon’s service has already started logging events to its
own channel and the driver will now be a boot-start
driver. This helps the driver to capture events well before
the actual boot-up of Windows or the event logging
service.

Where are Sysmon’s Logs?

Sysmon creates its own event log channel under

“Applications and Services Logs”. To open the channel and
view the logs, you can:

 Open “[Link]”

 On the left panel, open up “Applications and

Services”

 Open “Microsoft”

 Open “Windows”
  Head to “Sysmon” and under that — the Operational
log

If you’ve installed Sysmon’s service successfully, all logs

should be updated there. For my own system, I see Event
ID’s 1 and 5 for Process Creation and Process Termination
the most. We’ll explore a few other Event ID’s later.

How to Configure Sysmon

Let’s start off by dumping the current configuration:

[Link] -c

Here’s the output from the default configuration:

Current configuration:
— Service name: Sysmon64
— Driver name: SysmonDrv- HashingAlgorithms: SHA1
— Network connection: disabled
— Archive Directory: -
— Image loading: disabled
— CRL checking: disabled
— DNS lookup: enabledNo rules installed

Now, let’s start building up a configuration file which we

can use to modify our Sysmon installation.

First, let’s understand the dynamics of a configuration file.

The file is supposed to start off with the Sysmon tag
which has the schemaversion attribute in itself — this
helps parse same versioned or older configuration files.

<Sysmon schemaversion="4.22">
...
</Sysmon>

You can retrieve the current version using the command:

[Link] -? config

Next, under the Sysmon tag, we have Configuration

Entries. These entries act like parameters which we
normally provide to executables for add-on functionality.
For example,

<HashAlgorithms>md5,sha256,IMPHASH</
HashAlgorithms>

HashAlgorithms specify the hashing algorithms to be used

for detection. Though there’s a larger list on Sysmon’s
own documentation — you get the gist of it. This is the
current structure of our configuration file:

<Sysmon schemaversion="4.22">

<HashAlgorithms>md5,sha256,IMPHASH</HashAlgorith
ms>
</Sysmon>

Next, we have the EventFiltering tag which is where

event filters go. For example, you want specific process
creations to be included and the rest to be dropped at the
collection point.

The Filter rules are written under the RuleGroup tag.

They can contain the relation between the sub-nested
tags and an optional name field. For example, for the File
creation time event, we can filter for files which are in C:\
Users or are an executable. Here’s how we’d write this
filter:

<RuleGroup name=”” groupRelation=”or”>

<FileCreateTime onmatch=”include”>
<Image name=”T1099" condition=”begin with”>C:\
Users</Image>
<TargetFilename name=”T1099" condition=”end
with”>.exe</TargetFilename>
</FileCreateTime>
</RuleGroup>

Just as we’ve used include to include such events, we

can use the exclude value under the onmatch attribute
to specify events which should be dropped.

Example — you wish to monitor registry events for

changes to the CurrentVersion\Run registry key. You can
do so using the RegistryEvent ID under your RuleGroup.
Here’s how:

<RuleGroup name="" groupRelation="or">

<RegistryEvent onmatch="include">
<TargetObject name="T160, RunKey"
condition="contains">CurrentVersion\Run</TargetObject
>
</RegistryEvent>
</RuleGroup>

This is how our sample configuration file looks like:

<Sysmon schemaversion="4.22">
<HashAlgorithms>md5,sha256,IMPHASH</HashAlgorith
ms>
<RuleGroup name="" groupRelation="or">
<RegistryEvent onmatch="include">
<TargetObject name="T160, RunKey"
condition="contains">CurrentVersion\Run</TargetObject
>
</RegistryEvent>
</RuleGroup>
<RuleGroup name=”” groupRelation=”or”>
<FileCreateTime onmatch=”include”>
<Image name=”T1099" condition=”begin with”>C:\
Users</Image>
<TargetFilename name=”T1099" condition=”end
with”>.exe</TargetFilename>
</FileCreateTime>
</RuleGroup>
</Sysmon>

Once done writing, let’s update our configuration using:

(replace [Link] with your own file)

[Link] -c [Link]

Pretty simple right? This is how you can manually

construct a powerful configuration file based on your
analysis and execution policies. Mind you, Sysmon isn’t
a whitelisting tool or a HIDS agent — it’s simply an
advanced logging service with built-in filtering.
Your analysis is what’s going to matter after you’ve
acquired Sysmon logs from an endpoint.

More detailed documentation is available at:

[Link]
Sysmon#introduction

Pre-build Sysmon Configurations

Luckily, defenders have done a tremendous job of

keeping sysmon configurations up to date. One such
amazing example is the [Link] from
SwiftOnSecurity.

It is highly customizable and supports updates from the

latest version of Sysmon. Simply download and update
your existing configurations to follow the template laid
down by the person. That’s all.

Here’s the link:

[Link]

If you’d like to contribute to the community with your own

rules or files, you can easily do so by making a similar
open-sourced configuration file.
Sysmon Event IDs

Here’s a list of event IDs corresponding to the logs

generated by Sysmon’s service:

 Event ID 1: Process creation

 Event ID 2: Process changed a file creation time

 Event ID 3: Network connection

 Event ID 4: Sysmon service state changed

 Event ID 5: Process terminated

 Event ID 6: Driver loaded

 Event ID 7: Image loaded

 Event ID 8: CreateRemoteThread

 Event ID 9: RawAccessRead

 Event ID 10: ProcessAccess

 Event ID 11: FileCreate

 Event ID 12: RegistryEvent (Creation and Deletion)

 Event ID 13: RegistryEvent (Value set)

 Event ID 14: Registry Event (Key and Value rename)

 Event ID 15: FileCreateStreamHash

 Event ID 16: ServiceConfigurationChange

  Event ID 17: PipeEvent (Creation)

 Event ID 18: PipeEvent (Connected)

 Event ID 19: WmiEvent (WmiEventFilter activity)

 Event ID 20: WmiEvent (WmiEventConsumer

activity)

 Event ID 21: WmiEvent (WmiEventConsumerToFilter

activity)

 Event ID 22: DNSEvent (DNS Query)

 Event ID 23: FileDelete

 Event ID 255: Error

Analysis of Sysmon Logs

Let’s take a look at one of the logs from the Sysmon log
source. Here’s a sample one with my configuration
updated as per SwiftOnSecurity’s config file:
Sysmon Event ID 3: Network Connection Detected

Review the information available with a single log in the

bottom pane. This is great stuff! Default logging from
Windows isn’t that advanced and Sysmon can easily fill
those gaps.

If you can forward these logs to a SIEM or a centralized

logging solution, that’d be even better.

Conclusion

That’s it for my article on setting up Sysmon. Feel free to

play around with the configuration files and see what it
does to your system’s logging capabilities. Perfecting the
config file might require you to get a broad know-how of
how your enterprise works. The lesser the noise, the more
productive time your analysts spend hunting for threats.

Windows

Logging

Sysmon

System Monitor

Configure Sysmon
Written by Syed Hasan

273 Followers

Hi, I’m Syed. Explore my articles as I embark on this

journey of learning more about Forensics and Cloud! 🚀

More from Syed Hasan

Syed Hasan

Splunking with Sysmon Series Part 1: The

Setup

By Hurricane Labs|Published On: August 3rd, 2020

Sysmon (System Monitor) is a system monitoring

and logging tool that is a part of the Windows
Sysinternals Suite. It generates much more detailed
and expansive logs than the default Windows logs,
and it provides a great, free alternative to many of
the Endpoint Detection and Response (EDR)
solutions available. If you are curious about the
potential of Sysmon, I did a short talk showing some
of its capabilities.
This blog series will help prepare you to get Sysmon
up and running, deploy it in your environment, and
forward the event logs to your Splunk indexers.

Configuration and installation

Sysmon has a simple installation, although there are

a few decisions you will need to make before you
prepare to install it in your environment. You’ll need
to decide on an initial configuration, deployment
method, and forwarding mechanism.

The first major choice is the initial configuration of

your Sysmon build. It is possible to make your own
configuration, but it takes a good understanding of
what logs you want to generate and can create a
decent amount of unpredictable logs.

There are two popular configurations that are easy

to deploy and have done a lot of the initial legwork,
and both are great choices to start with.

SwiftOnSecurity

SwiftOnSecurity has a simplified one file

configuration that is great to start out with to see
what is possible with Sysmon. You can download it
on GitHub and easily install Sysmon with it to be up
and running in a few minutes.

The advantages of this configuration are that it is

simple to modify, roll out changes, and keep up to
date. The main disadvantage is that, as you tune
your configuration to your environment, the one file
deployment makes it difficult to keep track of those
changes. So for a very simple, one-shot
configuration it works great, but the second popular
configuration is much better suited to a well-tuned
environment.
 If you decide to use SwiftOnSecurity’s configuration,
I would recommend the following configuration
additions, as the default configuration will not
exclude Splunk processes and can create a large
amount of events:

To the section titled: <ProcessCreate

onmatch="exclude">.

Copy to Clipboard

plunk\ bin\ </ Image>

unk\ bin\ [Link]</ ParentImage>
unk\ bin\ [Link]</ ParentImage>
plunkUniversalForwarder\ bin\ </ Image>

<Image condition="begin with">C:\Program

Files\Splunk\bin\</Image>

<ParentImage condition="is">C:\Program Files\

Splunk\bin\[Link]</ParentImage>

<ParentImage condition="is">C:\Program Files\

Splunk\bin\[Link]</ParentImage>
 4

<Image condition="begin with">C:\Program

Files\SplunkUniversalForwarder\bin\</Image>

<Image condition="begin with">C:\Program

Files\SplunkUniversalForwarder\bin\</Image>

<ParentImage condition="is">C:\Program Files\

SplunkUniversalForwarder\bin\[Link]</Pa
rentImage>

<ParentImage condition="is">C:\Program Files\

SplunkUniversalForwarder\bin\[Link]</Par
entImage>

Modular Sysmon

Modular Sysmon, by Olaf Hartong, is more complex

than Swift’s, but is not overwhelming. An important
aspect of Modular Sysmon is that many of the rules
are mapped to the Mitre ATT&CK framework. So
each event will have a RuleName field showing the
ATT&CK mapping like below:
What it does well is that all of the configurations are
based in folders for each Event Id with separate files
based on including or excluding events from the
configuration. The configuration is available
on GitHub and requires a few more steps to install.

Since it is not based on a single XML file, there are a

couple of PowerShell scripts required to build the
configuration file each time you update the
configuration. From inside the Modular Sysmon
directory, run the following commands to build the
xml configuration:

Copy to Clipboard
 1

. .\Merge-SysmonXml.ps1

Merge-AllSysmonXml -Path ( Get-ChildItem '[0-

9]*\*.xml') -AsString | Out-File
[Link]

The advantages to Modular Sysmon is that you can

create a file for each Event ID you want to modify
the configuration file and have a copy of it outside
the main location. That way, when the base
configuration is updated, it is easy to put those files
back in after the upgrade. Also, since all the
changes you make are in their own files, it is easy to
keep track of what modifications were in the default
configuration and what were created by you.

The Splunk changes I recommend for

SwiftOnSecurity’s configuration are included by
default in Modular Sysmon.

Installation

After choosing your Sysmon configuration, the

installation on a single machine is easy.

Download Sysmon from Sysinternals, unzip the

folder, and copy the configuration file into the folder.
As an administrator, open up a command prompt or
PowerShell window, change into the Sysmon
directory, and execute the following command:

Copy to Clipboard
 1

[Link] -i <name of config file>.xml -

accepteula.

Deployment

The next choice is how you intend to deploy Sysmon

to the endpoints in your environment.

When using Splunk, I highly recommend having a

test bed of select, in-use computers in a variety of
departments. Deploy Sysmon to that test group first
for a week or two in order to generate a good
amount of logs and create an initial tuning
configuration to deploy company wide. Sysmon can
generate a large amount of events when not tuned,
and it could overwhelm a license that is too small. I
will discuss how I approach tuning in Part 2 of this
blog.

The simplest way to deploy Sysmon is with a Group

Policy enforced Scheduled Task to run a PowerShell
or Batch script. There are a few considerations to
take into account with this approach, as if it is done
poorly it can result in information disclosure that can
potentially allow a malicious actor to circumvent
your Sysmon logging.

I have a PowerShell script on GitHub that can serve

as an example deployment script. The script will
check to see if Sysmon is installed and which version
is running on the endpoint. If the version matches
what is expected in the script, it will update the
configuration on the system. If not, it will uninstall
the current version and install the new version with
the current configuration file provided.

One way to deploy the script and configuration file is

to have a scheduled task run the script from a
shared folder with the configuration file in that same
folder. Have the task run as the Builtin System
account (NT Authority\System) or another user
created for this purpose and limit the shared folder
access to only computer accounts (or said user), and
the privileged users that will be modifying the script
and configuration. This will prevent users from being
able to see and circumvent the Sysmon logs and will
maintain security on the configuration files. Running
this as a regularly scheduled task (as often as you
would make changes to the configuration) will allow
the endpoints to maintain the updated version
without much maintenance. An example of this is
below:
Splunk Configuration

There are two main ways to get your Sysmon logs to

your Splunk indexers. I would recommend using the
Splunk Universal Forwarder, but if your environment
is unsuitable for it, Windows Event Forwarding also
works.

Deploying Splunk Universal Forwarders (UF) to all

endpoints and using that to ingest Sysmon logs to
your Splunk Indexers is the preferred method. This
option allows for Splunk to ingest more than just
Windows Logs from the endpoints and offers more
control over what is sent. To send your Sysmon logs
to the Forwarder configuration, simply add the below
configuration, plus any modifications you may want
to make, to your [Link] file:

Copy to Clipboard

[WinEventLog://Microsoft-Windows-Sysmon/
Operational]

disabled = false

renderXml = true

4W

source = XmlWinEventLog:Microsoft-Windows-
Sysmon/Operational
If the Splunk UF does not work well in your
environment, Windows Event Forwarding (WEF) can
also be used to send the Symon logs from endpoints
to a centralized server for collecting logs. This can
be used for just Sysmon logs or for all Windows logs,
if you prefer. This is set up through Group Policy and
allows you to specify which Event IDs you want to
send. You can find the Microsoft documentation for
Windows Event Forwarding here.

Once WEF is set up, you would have to use a Splunk

Universal Forwarder on the WEF collectors to send
the Forwarded logs to Splunk.

Lastly, add the Splunk Add-On for Microsoft Sysmon

to your Splunk
deployment: [Link]
4/. By default, the events will have a sourcetype of
xmlwineventlog and source of
WinEventLog:Microsoft-Windows-Sysmon/Operationa
l. Below is a list of EventCodes and their meanings:

ID Event

1 Process Create

2 File creation time

3 Network connection detected

4 Sysmon service state change (cannot be filtered)

5 Process terminated

6 Driver Loaded

7 Image loaded
8 CreateRemoteThread detected

9 RawAccessRead detected

10 Process accessed

11 File created

12 Registry object added or deleted

13 Registry value set

14 Registry object renamed

15 File stream created

16 Sysmon configuration change (cannot be filtered)

17 Named pipe created

18 Named pipe connected

19 WMI filter

20 WMI consumer

21 WMI consumer filter

22 DNS query

23 File Delete

Conclusion

Hopefully, this blog post helped you learn a little

about Sysmon and settle any fears you may have
with deploying it. It is an incredibly powerful tool,
but one that requires some work to get ready for a
full production deployment.

If you have any more questions feel free to reach out

to me on Twitter at @DustyMMiller. Stay tuned for
part 2 of my Sysmon blog where I will go through my
process of tuning a Sysmon configuration with
Splunk.