Insight into User Behavior Using LogRhythm CloudAI: Part I

As Chief Scientist and de facto Technical Product Manager for LogRhythm’s Data Science team, I continuously evaluate the effectiveness of LogRhythm’s user and entity behavior analytics (UEBA) functionality to surface user activity that may be of interest to a security analyst. On most mornings, I log into LogRhythm’s internal deployment and — much as our customers would — try to understand the user activity that LogRhythm UEBA (formally known as CloudAI) is surfacing for me. From a security point of view, this exercise amounts to an evaluation of how quickly I can arrive at a reasonably comprehensive understanding of a user’s behavior that would help me decide if the activity required deeper investigation.

This blog is the first in a series that will walk you through the process by which I leverage LogRhythm’s core SIEM Platform along with CloudAI to characterize user behaviors. I utilize the same tools that are available to any of our customers and will share some of my customization to the Web Console that I believe helps distill user activity information for easy consumption and understanding.

UEBA Threat Hunting

We start with what might be considered the traditional threat hunting scenario with CloudAI. In this case, we want to leverage CloudAI to guide us toward users (more precisely identities) that deserve some level of examination due to deviations from past behavior. When I say “guide us toward users,” what I mean is that there are several contexts under which we can leverage CloudAI data that will guide us to different users. Once we identify a user through one or more of these contexts, we can then perform an initial examination of the user’s activity to determine if a deeper investigation is warranted.

Most Anomalous User

In this blog, the context under which I will identify a user of interest is to examine the most anomalous user as determined by the aggregate anomaly score in the Top Anomalous Users Web Console widget. The magnitude of the score is not important — I am simply interested in the most anomalous user. In the image below, I see that the most anomalous user has a score of 54 and is well above the rest of the users in the User Distribution.

Figure 1. The Top Anomalous User Web Console Widget identifies the most anomalous user identity

A quick look at the user’s timeline reveals two things:

1. The observed values for the timeline cards are very low (ranging from approximately 1 to 13 or so) indicating that the volume of activity is low. This can sometimes be helpful in differentiating identities that are actual people from users that are service accounts (service accounts will tend to have a higher magnitude of activity).
2. The expected values for the timeline cards are also very low (0 or 1). In some cases, many zero values in the expected baseline can indicate new users that have not been observed before or for some time.

Figure 2. Examination of the user’s behavior timeline

In order to perform an initial investigation into this user’s behavior, I click on the search control, which will launch a Data Indexer search over the previous 24-hour scoring period. Keep in mind that this search is simply filtered by time and the identity I am investigating, so it will pull back any data tagged with this identity in the scoring period.

Figure 3. Clicking the search control from the Top Anomalous User Web Console widget launches an investigation against the selected user identity

Once this search completes, I can open it in an analyzer by clicking on the search results in the Web Console tasks bar. At this point, I want to leverage a custom analyzer layout that assists in summarizing and drilling down on the search results. I have included an importable layout called UEBAAnalyzer that you will want to apply to this search result. Simply import UEBAAnalyzer.wdlt (after unzipping the attached file) and ensure you set it as the layout for this drilldown search. The widgets included in this analyzer layout are set up to summarize the search results for two purposes:

1. Summarizing general metadata fields for understanding how the data was classified/identified and what types of log sources the data came from, including:
   1. Top Classifications
   2. Top Common Events
   3. Top MPE Rules
   4. Top Log Source Types
2. Summarize metadata fields that are relevant to the UEBA analysis performed by CloudAI, including:
   1. Top Origin Identity
   2. Top Origin Host
   3. Top Impacted Host
   4. Top Origin Location
   5. Top Impacted Location

The full layout is shown over the next three screenshots:

Figure 4. Widgets included in the analyzer layout show top Classifications, top Common Events, and top MPE Rule Names

Figure 5. Widgets included in the analyzer layout show top Log Source Types, top Origin Identity, and top Origin Hosts

Figure 6. Widgets included in the analyzer layout show top Impacted hosts, top Origin Locations, and top Impacted Locations

One of the first things I do from this point is start to leverage the Web Console analyzer filtering in order to slice and dice the data into views that draw out different features of the data that CloudAI deemed anomalous. I first focus on the Authentication Success/Fail data by double clicking a Classification in the Top Classification widget.

When filtering by the Authentication Success classification in this example, I make note of a few things that will begin to paint a picture of this user’s anomalous behavior. At any time, you can double-click an additional metadata value to continue to drill down into the results.

1. From the MPE Rule summary, I see that the Authentication Success data contains both network-based logins (EVID 4624 and EVID 4634), as well as explicit logins (EVID 4648).
2. The Authentication Success data originates from both the Windows Security Event Log as well as O365 Management Activity.
3. The largest portion of this Authentication Success data originates from an external IPv4 address, which I can perform a Contextualize Whois lookup on which reveals that this origin IPv4 address is associated with a German internet provider M-net Telekommunikations GmbH.
4. The Authentication Success data is also originating from a variety of internal IPv4 addresses and two public IPv4 addresses (including the one cited in point 3 above).
5. The Authentication Success data has primarily originated from Munich, Germany.

Figure 7. Double clicking the Authentication Success classification filters the layout in order to focus the analysis on successful authentication activity and the associated Common Events and MPE Rule Names

Figure 8. Double clicking the Authentication Success classification filters the layout in order to focus the analysis on successful authentication activity and the associated Log Source Types, Origin Identity and Origin Hosts

Figure 9. Double clicking the Authentication Success classification filters the layout in order to focus the analysis on successful authentication activity and the associated Impacted Hosts, Origin Location and Impacted Locations

When filtering by the Authentication Failure classification, I observe that there is a relatively continuous background of Authentication Failures with a spike towards the end of the scoring period. Examining the filtered widgets reveals:

1. The MPE Rule summary and Log Source summary tell me these are Windows Security Events of types EVID 4768 and EVID 4771 indicating this user is continuously failing pre-authentication. A quick look at the logs in the log viewer also indicates the Result code for these failures is type 0x18 usually indicating a bad password.
2. The Origin and Impacted Hosts are all internal to the enterprise with the Impacted hosts all being domain controllers.
3. The Origin Locations are all known LogRhythm business locations (Boulder, Maidenhead, Reading).

Figure 10. Filtering the layout by Authentication Failure classification shows a continuous background of authentication failures with associated Common Events and MPE Rule Names

Figure 11. Filtering the layout by Authentication Failure classification shows a continuous background of authentication failures with associated Log Source Types, Origin Identity, and Origin Hosts

Figure 12. Filtering the layout by Authentication Failure classification shows a continuous background of authentication failures with associated Impacted Hosts and Origin Locations

Finally, a couple of other angles of examination include:

The Network Allow classification accounts for most of the data in this drilldown and is temporally associated with the Authentication activity in this scoring period. Filtering on Network Allow shows me that this data originates solely from Palo Alto Firewall sources and completely from LogRhythm’s configured German Entity with an Origin Location of Munich, Germany. Do not forget the log viewer. I used it here in order to get a quick summary of the Impacted TCP/UDP ports which turn out to be mostly DNS traffic bound for a UK-based domain controller.

Figure 13. Filtering on Network Allow and leveraging the log viewer shows this data originates from Palo Alto Firewalls and is primarily DNS activity

Filtering by the top Origin Host (an internal IPv4 address) shows that this address is only associated with Network Allow and Authentication Success classified data.

Figure 14. Filtering on the first top Origin Host shows that this activity is associated with Network Allow and Authentication Success classified activity

Filtering by the second top Origin Host (another internal IPv4 address) shows that this address is primarily associated with the Authentication Failures.

Figure 15. Filtering on the second top Origin Host shows this activity is associated with the observed Authentication Failures

The top two Origin Host IPv4 addresses appear to be in internal DHCP address spaces, likely indicating a laptop user and that the laptop IP address has changed during the scoring period. The change in IPv4 address seemed to coincide with the shift from Authentication Failures to Authentication Success.

CloudAI Reduces the Time to Qualify a Potential Threat

These are just a few examples of the analysis paths that can be taken all within the single analyzer view, starting from the CloudAI interface. The data, environment, and domain knowledge will naturally lead a security analyst down various paths that will build insights into the user’s behavior. I’m not a security analyst, but from my point of view this activity does not appear to be all that alarming — anomalous yes, but concerning, no. All of the activity is consistent with an employee interacting with internal systems with expected network traffic and expected locations. Without counting the time to take screenshots for this post, this analysis probably took about 20 minutes.