This is the eighth post from Google Cloud Principal Security Strategist John Stoner as part of his deep-dive "New to Chronicle" series, which helps propel forward security teams either new to SIEM or replacing their SIEM with Chronicle. You can view the entire series here.

Since this series started, we’ve been exploring rules in Chronicle and all of the power that YARA-L can bring us. We’ve got more to talk about with rules, but today, we are going to take a break from rules and talk about search. Dedicated readers may recall we talked about UDM in our very first post, but in case you don’t recall or are just joining us, here is a link for your reference.

Chronicle has had search capabilities for both raw logs as well as UDM for some time, but our latest update to search, announced today, provides analysts with an environment that investigators, hunters and detection engineers alike can utilize to go deeper into their data.

For those who have been working with YARA-L or reading our rule blogs, the syntax for search will be very familiar. Parenthesis as well as the operators and, or and not are all eligible for use in search as well as nocase to denote if we want to search a field for different types of capitalization. Regular expressions are also available with the use of the forward slashes enclosing the value. If you recall from our earlier blog around regular expressions in rules, we don’t need to put leading or trailing .* values.

Because the syntax is similar to YARA-L, we are going to focus on using the interface today. In this example, one of our dashboards has lit up with what appears to be a large number of logins on a user’s workstation over the past 24 hours. We’ve been asked to investigate this a bit further.

Our initial search is very straightforward. Because we are looking to understand more about the logins on a specific system, we are going to start with a single piece of criteria and go from there.

metadata.event_type = "USER_LOGIN"

Because we want to bound our search to the past 24 hours, we can click on the time in the right corner of the screen, and set the time boundary of our search. We can adjust the time window down to the sub second or we search around a specific time, plus or minus a number of minutes, hours, days or weeks.

With that basic search, we have nearly 1,200 events. We can quickly narrow our result set by filtering on the specific system of interest. Now, we could have put that field into our initial search, but then I wouldn’t have been able to show you how we can explore our data and then drill down, and what kind of fun would that have been? ¯\_(ツ)_/¯

Because we are looking for user login events that are originating from wrk-shasek, we could use the hostname or IP address that this system was assigned, but if we do that, we are overlooking a powerful feature in Chronicle. Because we loaded in our asset information and DHCP, Chronicle is taking care of associating hostnames and IP addresses for us. So rather than worrying about this, we can click on the Add Filter button on the left side of the screen to add an inline filter for src.asset_id equals WRK-SHASEK$ and click Apply.

The number on the right side of the panel represents the total events that contain a value for that field and the number in parenthesis next is the count of distinct values. We can also quickly find a field or value by typing in a string in the search bar. As we review the login events, an interesting field to observe is the security_result.action field which is an enumerated field in UDM and based on the event will be a fixed value, like ALLOW, BLOCK or QUARANTINE. Let’s go ahead and click on the three dots next to BLOCK and we can then filter down on just the block events by selecting Show only.

With these filters in place, let’s take a look at our histogram. Notice how our legend has changed showing the filtered events in one color with the queried events in another and represented on the histogram as such.

By doing so, we add a time filter to our other inline filters.

Let’s go ahead and add some additional context to our tabular output. Ohhhh…you want to examine the events you have before adding fields to the tabular view? No problem, we can click on the box with the arrow that appears on each line of the search results on the far right side of an event when hovering over it. Clicking on the box opens the event viewer.

We can add additional columns by clicking on the specific fields in the UDM event and clicking the Add As Column button in the event viewer or by clicking the Columns button on the right side of the screen in the events pane. The fields are available based on a hierarchical view and we can easily navigate up and down the tree by clicking on the headings in the pop-up box.

Pro tip: Adding fields through the event viewer will be limited to the specific fields available in that event, so if you don’t see a particular field in a specific event, use the Columns button to add the field instead!

Once we add our columns to the results, we can see that these blocked login events are network login events. We also see that while many of the users do not have a target.user.department field populated, the user frank.kolzig appears to be part of the information technology department. Because the IT department contains users with higher-level privileges, that might be another value to filter down on.

As we review the events in the tabular view, we can see that they are all associated with the same user, they are all Windows 4625 (An account failed to log on) events and the timestamp for each event appears to be one minute apart. There are additional questions to contemplate like why is this specific user attempting to login from this system and what system is he attempting to login into?

Let’s make a few changes to our current search, by broadening the time window and looking at all user login events for Frank that have a principal.hostname of the wrk-shasek, and not just the blocked attempts. Here is what we are left with.

However, there is one event without that tag. This event’s metadata.product_event_type has a value of 4624. That appears to be a successful login.

Based on our investigation, it appears that we had some sort of automated process attempting logins. That would account for the spike in the dashboard that was seen. However, we also saw that an IT user account had a successful login event in the context of that automated process.

One more thing, if we want to take the inline filters and convert them to a search, all we need to do is click Apply To Query and Run and all of our inline filters move into the search window.

Today, we learned how we can take a morsel of data, like a dashboard panel with an outlier, and start investigating in Chronicle to uncover something much larger, even with a very simple search. Clearly this is not the end of the investigation, but I hope you have a greater appreciation for how the new Chronicle search interface can be used to get closer to your data and how to investigate further!