👩🏻‍⚖️ 🈚️ 👉🏾 Using SIEM to Train Ethical Hackers: Opening the Hands-On Lab 🛌 🧑🏿‍🤝‍🧑🏻 🕴🏾

How do we train ethical hackers at our universities and training centers? As a rule, we provide them with Kali Linux or Scanner-VSthat includes a set of security testing tools and a machine with many vulnerabilities. As a result, listeners can get a rather cursory understanding of how penetration testing is actually done, since in real projects, pentesters deal with infrastructures that include information security tools and information security event monitoring systems (SIEM). To remedy the situation and provide beginners with the opportunity to study security testing methods and tools for monitoring information security events in a complex, we begin with this article the publication of practical laboratory work.

Our introductory lab focuses on identifying an incident related to gaining access to the admin panel of a web server.

Case

During the ISA's vacation, third-party developers were hired to create a web application to be hosted on the Tomcat web server. For convenience, the developers made the web console for managing server applications available to the entire outside world and created a "non-trivial" admin: admin account.

The threat

An attacker, while scanning the organization's external hosts, comes across port 8080 of the web server in question, makes sure that the administrative console is available, and after a few attempts, successfully brutes the password for the administrator account.

Task

It is necessary to determine how the information security administrator could set up SIEM before his vacation in order to timely register an incident related to the threat in question. After that, you need to implement this attack scenario and make sure that the correlation directives work correctly.

Virtual infrastructure

The situation is developing in the following IT infrastructure deployed in VirtualBox:

Attacker's machine (Kali Linux, IP: 8.8.8.10, 4GB RAM, kali: kali);
Firewall with intrusion detection system (pfSense, external IP: 8.8.8.1, internal network IP: 192.168.1.1, DMZ IP: 192.168.2.1, 1GB RAM, admin: pfsense);
Web server (Ubuntu Server 18.04 with Tomcat, IP 192.168.2.15, 2GB RAM, user: user);
Server SIEM-system "KOMRAD" (Ubuntu 20.04, IP 192.168.1.99, 4GB RAM, user: user).

If you are interested in deploying this infrastructure on your own, then you can use the instructions , but if you want to save time, then we posted the configured virtual machines in the OVA format . The SIEM system will need to be obtained additionally, but this will be described below.

Solution: setting up a SIEM system

To solve the problem, we will sequentially perform the actions of the attacker, analyze how they are reflected in the firewall and web server logs, configure the collection, parsing and filtering of events, and also create the necessary correlation directives in the SIEM system.

The guide our laboratory provides detailed steps to solve this problem, in the article, we will concentrate only on the key points.

1. Sending events from the firewall

The pfSense firewall allows you to send your logs via the Syslog protocol to a remote server, for this you just need to set the IP address and port of the syslog collector SIEM "KOMRAD", and also add a rule that allows sending logs from the 192.168.2.0/24 network to the 192.168 internal network .1.0 / 24.

The SIEM system will receive events of the following type:

<134> 1 2020-10-18T02: 33: 40.684089 + 00: 00 pfSense.localdomain filterlog 9761 - - 4 ,,, 1000000103, em0, match, block , in, 4, 0x0,, 64,25904,0, DF, 6, tcp, 60, 8.8.8.10 , 8.8.8.1 , 35818,1721,0, S, 1017288379,, 64240,, mss; sackOK; TS; nop; wscale

As you can see, this entry contains such important information as the IP address of the host that initiated the connection, the IP address of the host to which the connection is being attempted, and an indication that the connection attempt was blocked.

2. Sending events from a web server

The Tomcat web server logs http requests to local logs that can be redirected via rsyslog to the SIEM system. To solve this problem, you can also use the file collector, which is part of the SIEM-system "KOMRAD". In the records, you can see that the IP address of the host from which the request was received is registered, as well as the user account in case of successful authorization:

3. Receiving a stream of events by the SIEM-system "KOMRAD"

The considered events are automatically registered by the SIEM-system "KOMRAD":

The mentioned two types of events are enough to detect the following situations:

Connection blocking - based on block;
Port scanning - in case of multiple blocking of connection attempts initiated by the same host;
Suspected unauthorized access - port scanning and then gaining administrative access.

All three situations can be information security incidents, but of course with different levels of severity.

Before registering incidents, we need to learn how to extract the above useful information from events.

4. Analysis of events by the SIEM-system "KOMRAD" (parsing)

To parse source events in a SIEM system, you need to create a plugin that includes a set of regular expressions. For the most popular sources, COMRAD already has ready-made plugins. In the absence of a plug-in, the user can create one.

Below is an example of designing a regular expression to extract fields from the above firewall event. As a debugging tool, we used the portal https://regex101.com/

After creating the plug-in, data from events is extracted into separate fields, as you can see from the following event card:

5. Configuring filters to extract information security events of interest from the stream

In order to identify the events of interest to us in the stream of events entering the SIEM system, we need to set up filters. In the SIEM-system "KOMRAD" filters are formed using the popular scripting language Lua (information security specialists are already familiar with it from Nmap and Suricata).

To select firewall events related to blocking the connection, we will create the following filter:

--  filter  
function filter(event)
--    ,     IP- ,  
    action = event:getString ('Action')
    ip = event:getString ('IpSrc')
--     IP-,      
    if action == 'block' then
        return {IP=ip}
    end
end

The filter for the Tomcat event looks a little more complicated, in which we check if the account retrieved from the event matches the value "admin". In this case, we also return the IP address.

function filter(event)
    journal = event:getString ('Journal')
    login = event:getString ('Username')
    ip = event:getString ('IpSrc')
    
    if journal == 'tomcat-access' and login == 'admin' then
        return {IP=ip}
    end
end

When used in a production environment, to improve system performance, you might need to check a specific collector ID at the start of each filter to limit the scope of the filter.

6. Creating correlation directives

Let's create correlation directives for the considered situations with the following severity levels:

Connection blocking - "insignificant";
Port Scan - Low;
Sending http requests using the admin account is "high".

To create an incident if a connection is blocked, it is enough to indicate in the correlation directive the only applied filter:

filter 5

The second directive, which should create an incident in case of three times blocking of a connection initiated by the same host, will look like this:

/*  ip,   ,        .*/
var ip
filter 5 export ip = ep.IP
/*         IP.
    notforking,       .*/
filter 5 +1m where ep.IP==ip notforking
//   .
filter 5 +1m where ep.IP==ip notforking

In the third directive, we add another line, in which we use the filter with ID 6, created to select requests to the web server with the admin account.


var ip
filter 5 export ip = ep.IP
filter 5 +1m where ep.IP==ip notforking
filter 5 +1m where ep.IP==ip notforking
filter 6 +1m where ep.IP==ip notforking

In the tutorial example, the time window was left equal to 1 minute; in real life, it makes sense to increase it to several minutes.

Solution: carrying out an attack and identifying it

After configuring the event sources and the SIEM system, it's time to conduct a mock attack. First, let's scan the ports:

Then we go to port 8080 and go through the authorization with the admin: admin account:

These actions are recorded by the SIEM-system "KOMRAD": all three correlation directives are triggered:

Conclusion

Thus, in this laboratory work, we saw the sequence of actions for collecting and analyzing information security events in case of gaining administrative access to the web server. In the next lab, the attacker will develop the attack and use the gained administrative access to collect information about the target infrastructure.

How to get a demo version of the SIEM-system "KOMRAD"

We are currently in beta testing of our product, in which anyone can take part. To do this, we provide the current version of the SIEM system in the form of a Docker container. There are only two limitations in the demo version: the event processing rate is cut down to 1000 EPS and there is no authorization and access control system.

To receive an archive with a demo version, write to us at the e-mail address getkomrad@npo-echelon.ru from your organization's mailbox (we are interested in who will participate). We also invite you to our Telegram group, where you can get help in case of any difficulties: https://t.me/komrad4

Using SIEM to Train Ethical Hackers: Opening the Hands-On Lab