RSA UEBA Essentials Hunting Guide

UEBA Essentials Hunting Guide

This document contains the following sections:

• Summary
• Intrusion Behaviors

• Network Data

  • Data Gathering
  • Data Filtering

• Logs

  • Data gathering
  • Data Filtering

• Use Cases

  • Hunt Card Template
  • Hunt Card Examples (Log-based)
  • Hunt Card Examples (Packet-based)

• Appendix

  • Network Parsers
  • UEBA Essentials Content Pack
  • Related Materials

Summary

The purpose of UEBA Essentials and user-hunting is to detect or bring focus to suspicious user (and entity) behavior to find potential insider threats, lateral movement by external attackers, or general abuse or misuse of user accounts (policy). To flush out use cases and build effective detection and hunting content, we need to drill down into each of these, to determine actions and behaviors that attackers are likely to attempt.

Consider some fundamental questions to ask:

• What fundamental techniques and behaviors are common across a nearly all intrusions?
• What is the evidence that these techniques leave behind?
• What do all attackers do?
• What are "normal" behaviors that I expect from my accounts and entities?
• What does my network look like, and where are my sensitive machines located?

Once you have an idea of the questions you need to ask and the behavior on which you want to focus, it's time to hunt, and leverage that hunting across user and entity behaviors. This is the aim of the UEBA Essentials Hunting Guide and related content.

Taking what you've learned by looking through the Packets Hunting Guide, the same methodology is leveraged here. Hunt through meta data to find interesting pieces of behavior: capture that knowledge as Application Rules, so you don't have to perform the same queries and drills multiple times. Then aggregate the atomic events into behaviors and express those behaviors as an RSA Correlation Rule. This leads to higher-fidelity alerts as well as providing a way to hunt through behaviors and discover more complex activity throughout an environment.

It takes a combination of the right visibility (the right data from the right devices), context, and an understanding of what it is you're looking for to find suspicious user behavior and validate it as either malicious or benign. It's important to collect the data you need to satisfy the use cases that you're interested in. This allows you the best opportunity to get the best detection possible and not be distracted by non-essential information.

This document walks through and provides suggestions on how to frame hunts, which data to gather, and how Live Content and product Dashboards help automate the process of user behavior analysis.

Deploying the UEBA Essentials bundle downloads all of the content and content dependencies of the UEBA Essentials Pack to the service appropriate for each content type.

For details on UEBA Essentials in RSA^® NetWitness^® Platform, see the following topics:

• Context Hub Lists in ESA Rules
• UEBA Essentials Content Pack

Intrusion Behaviors

To gauge the breadth of an incident, as well as to determine its impact, you need to understand what an attacker did after gaining entrance into your organization. It is important to note that events (logs, network sessions, processes) should not be considered isolated nor independent from one another. Instead, there must be a way to associate behaviors in order to gain insight into a compromised computer system.

User and Entity behavior is one method of looking into internal breach activity. To understand the types of activity you should look for, we leverage the Mitre ATT&CK framework. This allows us to bucket individual detection methods (rules, alerts, and models) into techniques, and then roll those up into tactics. This provides the additional benefit of understanding and identifying detection gaps in your environment, and being able to have a discussion around investigation techniques related to various attacker activities.

The following Coverage & Requirements Matrix shows how the content offered by RSA NetWitness lines up with the various ATT&CK Techniques, and how various techniques can be chained together to look for interesting combinations of behavior.

Network Data

Data Gathering

While UEBA Essentials is primarily based on log visibility, you can also gain insights by analyzing network traffic. The following protocols give insight into activity centered around usernames: HTTP, FTP, SNMP, SMTP, Telnet, POP3, IMAP, SIP, Kerberos, FTP, DCERPC, LDAP, and RADIUS as well a few others. While some information is more application specific (for example, determining failed or successful logins), some interesting insights can still be gained through network traffic analysis. In RSA NetWitness, the greatest level of network user visibility involving corporate-issued usernames revolves around HTTP (proxy authentication), Email, and Kerberos traffic. However, do not ignore the other protocols.

Data Filtering

Filtering network data is as important as filtering log data. If you are not able to decrypt encrypted traffic, consider filtering SSL, SSH, GRE, IPSEC, and ESP traffic by keeping only the associated metadata. If you want a little more visibility into SSL than just metadata, you keep the handshake part of the protocol (including the certificate exchange), and use the truncate=app option. Likewise if you'd like to keep the first X bytes of any type of a session, you can use truncate=X (where X is the number of bytes you want like to keep).

Sometimes keeping a bit of raw data in addition to the meta can help with that extra bit of context needed in an investigation. There is a line that you walk with filtering: too much and you may lose context, too little and you wind up wasting resources that could be better used. Just as in data gathering, data filtering is all about knowing your visibility points and workflow, and using those to drive filtering, just as you would use data ingest to drive use cases.

Logs

Data gathering

Perhaps the most important step of detecting any compromise or related activity is insuring you have the correct visibility and data. In this section, we examine some of the types of data that you should be collecting, and where you should be collecting it from, so as to have a greater chance of discovering an incident. Equally as important as bringing data into the system, is filtering out the data you don't need. User analysis is greatly impacted by visibility and data quality, and with any kind of analysis the motto "garbage in, garbage out" holds true.

Microsoft has several documents, from a log perspective, describing the types of data that you should consider bringing into the RSA NetWitness platform. We'll start here to make sure a baseline is established and then expand upon the other types of visibility that are beneficial when analyzing or looking for suspicious user behavior.

Data Filtering

Some events will be naturally noisy or excessive (ex.: 4688, 4689, 5156, 5158); these events need to be filtered or managed by their individual messages or field names in order to be used effectively. In some cases, this filtering can be achieved using capabilities of the RSA NetWitness platform, and in others it may need to be done using logging configurations directly on the client or server.

Additionally if you learn something from the output of any investigation, you should capture that intelligence so you (hopefully) don't have to perform the same analysis again. When you believe a username to be benign or not interested in activity from it? Add it to the User Whitelist Context Hub List. Find a suspicious username floating around and want to keep an eye on it? Add it to the User Blacklist Context Hub List. By adding usernames to various Context Hub Lists you can tune ESA rule behavior by ignoring or highlighting user behavior throughout the environment. While it requires a few more steps, the same type of workflow can be accomplished with feeds for domains, IPs, systems, and so on. An example of how feeds and content can work together as part of the analysis process (filtering and highlighting) check out the Lateral Movement Content Pack, which also intersects user behavior.

Use Cases

If you want to succeed and survive against contemporary adversaries, you're going to have to get past the traditional prevention-based models. To mount a successful defense in today's security landscape, you need to evolve beyond traditional security measures. The days of setting up shop in your SOC and getting down to the business of responding to queues of alerts are, simply put, outmoded and obsolete. Today, successful SOC teams concern themselves with hunting: stated simply, proactively seeking out the ways in which adversaries would seek to do harm, or otherwise affect their goals.

To help you understand and get started hunting, we have developed the NetWitness Hunt Card. The Hunt Card model provides a simple means of helping junior analysts to understand a particular type of threat, and a structured plan to help them go hunt against it. At the same time, Hunt Cards provide a template for senior analysts to document threats, plan hunts, and provide guidance to their junior analysts, thereby accelerating the development of their experience, effectiveness, and expertise. Each hunt card is made up of 9 sections, each with a distinct role in defining and documenting your hunts.

Hunt Card Template

Let's take a look at a Hunt Card template, and talk a bit about the role of each section:

Notes on each section:

• Hunt Card Title and Focus. This is fairly straightforward. It is just a unique name assigned to each of your hunt cards, so that everyone can easily understand what we're hunting.
• Activity Profile. The activity profile is nothing more than a very high-level description of the intended purpose of the hunt card.
• Knowledge Profile. See Knowledge Profile below.
• Hypothesis or Axiom. See Hypothesis or Axiom below.
• Data. The Data block in your hunt card lays out an inventory of the data sources required to support your axiom or hypothesis, and enumerates any related content that may contribute to the hunt.
• Techniques and Patterns. The Techniques and Patterns block begins with a mapping to Mitre's ATT&CK™ Tactics and Techniques. The ATT&CK model is extremely beneficial as a means for thinking about how threats manifest, particularly against behaviors of known adversaries. Additionally, this block provides general guidance, as well as specific examples, of how to conduct your hunt using the RSA NetWitness platform.
• Feedback. Successful hunts produce derivative intelligence that should be fed back into systems and processes for continuous improvement of an organization's operational security mission. The Feedback block outlines the derivative intelligence most likely to be produced, and goes on to provide general guidance on how to incorporate the intelligence, as well as next steps based on the results of the hunt.
• Related Hunt Cards. As indicated with the ATT&CK mappings earlier in the hunt card, every hunt happens within the scope of a phase in the attack lifecycle. As such, there are always related events, and related hunts. These hunts may be related within a stack, such as a number of different techniques within the lateral movement tactic, or they may be related to phases left and right of the current hunt. The Related Hunt Cards block outlines those related cards to help establish where a hunt exists within the attack lifecycle, and where to look next.
• Related Analytic (Mitre CAR). In addition to the ATT&CK™ mappings already mentioned, we map the related Cyber Analytics Repository (CAR) analytic where one exists. The CAR is a knowledge base of analytics developed by Mitre based on the ATT&CK™ model.

Knowledge Profile

The Knowledge Profile is useful in helping to think about how you can approach threats, and how to structure your hunts.

"There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we now know we donʼt know. But there are also unknown unknowns. These are things we do not know we donʼt know." Donald Rumsfeld

While the comment is infamous, and has been widely debated, the fact remains that with a single addition it outlines a matrix that provides us with an infinitely useful state table for knowledge upon which action can be based. That addition is the 'Unknown Known—the things that we don't know we know, and it gets added to the other three outlined states. Let's examine each of these states of knowledge in a little more detail:

• Known Known

  No real rocket science here; this is the realm of things where we have a good understanding of the elements required for detection. We understand the TTPs, the signatures of the related activity, and the required data. In short, we know everything that we need to know in order to build detection capabilities for threats that have a KK knowledge profile.

• Known Unknown

  With a KU knowledge profile, we get into prime hunting territory. Known Unknown means that there's something we know that we don't know. In other words, a Question exists. We provide a good example of a KU knowledge profile below in the User Login Activity Monitoring Hunt Card: We know the body of valid accounts, but we don't always know when a particular login is legitimate or compromised.

• Unknown Known

  Use cases or hunts with a UK profile characterize the latent or tacit knowledge in your enterprise–the information that's there, but that has yet to be understood and integrated as intelligence. Gaining command of your UK domain will make an adversary’s job much more difficult, as it will become much more difficult for them to hide and move about within your environment.

• Unknown Unknown

  Use cases with a UU profile are not typically best for hunting, at least not before some analytical groundwork has been done. By definition, threats profiled UU are those threats that we don't even know exist. Because we don't know that they exist, it is very difficult to define and start asking questions. While senior analysts are often capable of finding these sorts of threats using structured analytic techniques, these are the types of problem that are perhaps best served by data science and machine learning models.

The four knowledge profiles outlined above give us a fairly complete set of ways that we can categorize what we do and do not know about our environment, the security landscape, and the threats that populate it. Conveniently, these profiles can be grouped as K-vectored (the Knowns) and U-vectored (the Unknowns).

Hypothesis or Axiom

Every hunt starts with a proposal regarding some sort of activity that may or may not be discoverable in your environment. Building upon the foundation we laid with Knowledge Profiles, we subdivide hunts and their associated proposals as K-vectored and U-vectored.

• K-vectored hunts are based on one of the Known knowledge profiles, and thus have an associated Axiom. Within formal systems, Axioms are propositions that are assumed to be self-evidently true. Axioms are well suited to automation within a rules-based system.
• U-vectored hunts are based on the Unknown knowledge profiles, and thus have an associated Hypothesis. Hypotheses are propositions based upon speculation or conjecture, typically requiring deductive or inductive proof. U-vectored hunts benefit greatly from the involvement of a senior analyst with an analytical mindset. However, they can often be refined to a point of being operationalized and run by mid-tier or junior analysts.

Hunt Card Examples (Log-based)

User Login Activity Monitoring Example