Simple correlation scenario for Splunk using lookup tables

Events correlation plays an important role in the incident detection and allows us to focus on the events that really matter to the business services or IT/security processes.Splunk software supports a lot of ways to correlate events, such as:
• event correlations using time and geographic location;
• transactions;
• subsearches;
• field lookups;
• joins.
In this article, we will consider the use of event correlation based on field lookups and joins. In my opinion, this is one of the lightweight ways to correlate events unlike the use of subsearches or joins in one search query. In most cases, we need to compare one field from an event with the appropriate field from another event to search for matches. For example, we try to detect suspicious activity in our network and to learn who performs the scan for TCP 445 in our network and tries to connect to C&C servers.
Let’s start with search, which will help us to detect scan for TCP 445 in our network.
Find all events with connections to the 445 port:

Criteria for detecting scan is: one host scans 30 hosts in 1 minute, so using bucket and eventstats it is not hard to group events and find count greater than 30:

As a result, we detect that host 10.10.10.3 performed scan for 763 hosts per 1 minute in our network:

The host should be added to the list of suspicious hosts. To do this, we need to run search and put results in a lookup table:

Result:

This search automatically creates lookup suspicious_hosts.csv with fields src_ip, HostsScanned,_time.
Now we need to find out who in our network tried to connect to Ransomware C&C:

Note. IP Addresses used in the article are not necessarily Ransomware C&C at the time of writing the article.
Consolidation of results from both searches in one:

Result:

We used correlation scenario to detect an infected host in our network. For full automation, you can put these requests into Alerts. Using lookup significantly increases the efficiency because it is much easier to compare events with a static table than to make subsearch again and again.

Thank you for your attention,
Alex Verbniak