Attack Simulation (Why it is Important!) Part 2 — Get one’s ducks in a row

Now, following steps through part 1, we have lab setup and running. It is essential to understand how things are working in the background. You have noticed two main directories when installation is complete: Ansible and Vagrant.

Ansible, which uses playbook for automatic provisioning of Splunk attack range components, there are specific roles that have been defined for each instance (*.nix, windows) for example, windows_workstation.yml, which has assigned five roles

Each role consists of a specific set of configurations needed on the Windows workstation, which were then defined in the tasks below.

Vagrant which handles building up the complete environment of virtual machines.

To see what machines (boxes) have been added to vagrant profile use

sudo vagrant box list

If you would like to see status of each of machine, then use

sudo vagrant global-status

And if you need to bring up the specific machine, in my case, windows 10 then use

sudo vagrant up [machine id]

vagrant file can be found under the vagrant directory, which is the main file responsible for provision lab basis on what you have to enable/define in attack_range_local.conf file such as CPU, memory, IP addresses, password etc.

Below is the location to find actual boxes.

cd ~/.vagrant.d/

Now that we have developed some basic understanding of how mechanics work in the background let’s explore Splunk.

Out of the box, once lab is built, it provides perfect coverage of logs sources getting ingested, particularly those related to windows.

But what is missing is kali-Linux telemetry, which we will be adding in so that we can examine what is happening at the attacker machine (kali linux) when performing some tests on the Windows machine.

Note: if you use cloud deployment, you don’t have to worry about it as osquery on ubuntu is already in a package. It’s just not come as part of local build option.

· Installing osquery and Splunk Universal forwarder on Kali Instance

We will be modifying a few things to make osquery and Splunk UF installation automated by changing ansible playbook for kali Linux

But before that, we need to download a few files into roles/kali_linux/files directory.

osquery.config and flags file

wget https://raw.githubusercontent.com/casimkhan/splunkattackrange/main/osquery.conf

wget https://raw.githubusercontent.com/casimkhan/splunkattackrange/main/osquery.flags

https://raw.githubusercontent.com/casimkhan/splunkattackrange/main/inputs.conf

splunk universal forwarder .deb package from splunk website

Once all files are downloaded, your file directory should look like below

As mentioned above, we will be modifying kali_linux.yml file to install/configure osquery and splunk forwarder on kali box

Download and replace with an updated version of yml file in attack_range_local/ansible directory

wget https://raw.githubusercontent.com/casimkhan/splunkattackrange/main/kali_linux.yml

We need to modify the indexes config file by adding the osquery index

cd attack_range_local/ansible/roles/search_head/files

add below three lines in indexes.conf

Lastly, we need to download splunk addon for osquery

We are all set to spin up the lab again.

Once finished we will install osquery addon app in splunk server

And now we can start seeing events coming in osquery index

Now we run a simple port scan with nmap using Metasploit v5 through kali machine and then verify logs in splunk

From the above subnet nmap identified 2 hosts are up which is true as we are running only 2 machines in lab at the moment (kali linux 10.0.1.16 and splunk server 10.0.1.12)

Let’s see what logs we have available in splunk for test we have just completed.

Above is the telemetry generated by osquery when scan started. Interestingly we have executed nmap via msf, osquery does how the command which was executed. We need to ignore splunkforwarder events, which are not event of interest for us in our scenario. We have started our scan at 20:35:47; that’s what splunk show in logs I need to verify that nmap is actually executed via msfconsole so I will grab parent process id “columns.parent” which Is “6048”.

Indeed, it was from msf console:

Now the real fun begins, In part 3 — Time to fly! I will execute more standard TTPs against windows OS and analyze telemetry. Stay Tuned!