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!