LinkedIn
Twitter
This is the eighth post from Google Cloud Principal Security Strategist John Stoner as part of his deep-dive "New to Google SecOps" series, which helps propel security teams either new to SIEM or replacing their SIEM with Google SecOps.
Since this series started, we’ve been exploring rules in Google SecOps 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.
Google SecOps has had search capabilities for both raw logs as well as UDM for some time, but our latest update to search 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.
When we execute our search, we get a tabular view of our UDM events, a listing of quick filters on the left side of the screen and a histogram in the middle of the screen.
With that basic search, we have over 1,900 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 Google SecOps. Because we loaded in our asset information and DHCP, Google SecOps 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.
Using the Aggregations panel on the left side of the search results, we can see UDM fields from our results set. 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.
Searching for the string action brings us quickly to this field and we can see that more than 80% of our values are BLOCK actions.
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.
The white “lollipop” sliders on either side of the histogram can be moved to narrow the time frame or we can click on one of the timeslices. By doing so, we add a time filter to our other inline filters.
At this point, we have narrowed our events from the over 1,900 user login events to 194.
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.
The event viewer contains both the raw log as well as the parsed UDM event.
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!
If the Columns button does not provide a field, that means none of the results of your search contain that particular field.
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 activedir.stackedpads.local, and not just the blocked attempts. Here is what we are left with.
Most of the events have an AUTH_VIOLATION tag (from the security_result.category field) associated with them and a metadata.product_event_type of 4625.
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.
From there, we can save our search by clicking the three dots to the right of Run Search and selecting Save Search and then providing a name for our search.
Today, we learned how we can take a morsel of data, like a dashboard panel with an outlier, and start investigating in Google SecOps 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 Google SecOps search interface can be used to get closer to your data and how to investigate further!