Falcon LogScale Documentation

First, you can start by identyfing the different types by getting the top events. This basic search can be a good way to identify the outliers in the overall event stream, for example, odd protocols, or protocols used less or more than you might expect.

The #path tag identifies the top level type:

top(#path, limit=100)

We increase the limit on the output so that we get the full set of different event types.

The output highlights some specific protocols in the output that may warrant some further investigation.

The sample data uses the service field to track specific protocols used in the events. Some attacks will use or overload a given protocol specification in order to initiate an attack, or they use invalid protocols to trigger a memory failure.

Let's see what output we get from this query:

top(service, limit=100)

The output generates a list of protocols:

The protocols in the output contain perfectly valid protocols, including http and smb. But there are also some protocols that do not look valid. For example, there is no protocol A:, or TERMSRV/bas-ad-01.lab.local.

The unique ID for each session identified by Corelight (see Session Identifier (uid)) can also be an identifier for unusual network traffic. A high number of events within a unique session ID may be suspcicious. The opposite is also true, a low number of events for a given session may indicate an attempt to attack that is merely probing for potential attack vectors.

Let's look at the top and bottom ten events by the unique session ID, starting with the bottom:

groupby(uid)| sort(order=desc,limit=10)

This generates the following summary output:

Let's take a closer look at that last UID:

uid=CBBHS11aPS4RsdHkRe| groupby([#path,service])

High transfer rates, or high amounts of data transferred for protocols or services that are normally small and discrete can be worth investigating.

DHCP requests, for example, should not normally contain excessive payloads of data, as the infomation returned. High data returns from a DHCP exchange might indicate a fake or spoof DHCP server masquerading on your network.

The response payload for requests is contained within the resp_bytes field. You can look for these by running a query looking for non-zero DHCP:

service = dhcp | top(resp_bytes)

The query returns the following data set:

We can see here that the majority of DHCP requests have a empty response, but there are some that return much larger payloads that require investigating.