UEBA Essentials Hunting GuideUEBA Essentials Hunting Guide
This document contains the following sections:
SummarySummary
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:
Intrusion BehaviorsIntrusion 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.
| ATT&CK Tactics | ATT&CK Technique IDs | ATT&CK Techniques | Required Data Sources |
|---|---|---|---|
|
Defense Evasion Persistence Privilege Escalation Credential Access Lateral Movement Command and Control Collection Execution Command and Control Launch |
T1098 T1169 T1035 T1110 T1078 T1136 T1089 T1105 T1070 T1039 T1050 T1076 PRE-T1146 PRE-T1149
|
Account Manipulation sudo Service Execution Brute Force Valid Accounts Create Account Disabling Security Tools Remote File Copy Indicator Removal on Host Data from Network Shared Drive New Service Remote Desktop Protocol Spear phishing messages with malicious links Unconditional client-side exploitation/Injected Website/Driveby |
RSA NetWitness Packets (or other Packet capture) RSA NetWitness Endpoint Windows Registry File monitoring Netflow/Enclave netflow Process command-line parameters Process monitoring Anti-virus Process use of network Windows event logs API monitoring Authentication logs Process Monitoring Services Network protocol analysis Proxy logs Mailserver/mail gateway logs DNS resolution logs; Passive DNS data Bro HTTP|SSL|DNS|SMTP logs |
Network DataNetwork Data
Data Gathering 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 FilteringData 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.
LogsLogs
Data gatheringData 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 FilteringData 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 CasesUse 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 TemplateHunt Card Template
Let's take a look at a Hunt Card template, and talk a bit about the role of each section:
|
Hunt Card Title or Focus |
Card title, for example Lateral Movement: RDP |
|
Activity Profile |
One-line, executive summary of the use case |
|
Knowledge Profile |
One of:
|
|
Hypothesis or Axiom |
Attackers may be leveraging a C2 channel that utilizes custom encoding or encryption techniques over commonly used ports |
|
Data |
Datasets include:
Related NetWitness Content:
|
|
Techniques and Patterns |
ATT&CK™ Tactic(s):
ATT&CK™ Technique(s):
Look for:
|
|
Feedback |
Derivative Intelligence:
Next Steps:
|
|
Related Hunt Cards |
|
|
Related Analytic (Mitre CAR) |
Link to the Mitre Cyber Analytic Repository (CAR), if available. |
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)Hunt Card Examples (Log-based)
User Login Activity Monitoring Example
|
User Login Activity Monitoring |
|
|
Activity Profile |
Monitor user login activity for improved situational awareness. |
|
Knowledge Profile |
Known Unknown |
|
Axiom |
Enterprises should have a clear understanding of valid accounts, but do not know whether a particular login activity leveraging a valid account is legitimate, or is leveraging compromised credentials. Monitoring logon and log-off events is a critical factor in development of good situational awareness. Generated events or alerts on unusual activity can be good indicators, or may serve to corroborate related hypotheses. |
|
Data |
Datasets include:
Related NetWitness Content:
More information: |
|
Techniques and Patterns |
ATT&CK™ Tactic(s):
ATT&CK™ Technique(s):
Look for:
|
|
Feedback |
Derivative Intelligence:
Next Steps:
|
|
Related Hunt Cards |
|
|
Related Analytic (Mitre CAR) |
Simultaneous Logins on a Host Example
|
Simultaneous Logins on a Host |
|
|
Activity Profile |
Simultaneous logins may be an indicator of compromise (IOC) |
|
Knowledge Profile |
Known Unknown |
|
Axiom |
Within typical enterprise environments, it is relatively uncommon to see multiple users logged into a single system at the same time. There are exceptions to this, which should be understood and accounted for by whitelisting systems and users after sufficient vetting. Under normal circumstances, multiple users logged into a single machine at the same time, or even within the same hour, can indicate compromised credentials. |
|
Data |
Datasets include:
Related NetWitness Content:
More information: |
|
Techniques and Patterns |
ATT&CK™ Tactic(s):
ATT&CK™ Technique(s):
Look for:
Note: Certain users or classes of users may need to be whitelisted after sufficient vetting. |
|
Feedback |
Derivative Intelligence:
Next Steps:
|
|
Related Hunt Cards |
User logged in to multiple hosts |
|
Related Analytic (Mitre CAR) |
User Logins Across Multiple Hosts or Servers Example
|
User Logins Across Multiple Hosts or Servers |
|
|
Activity Profile |
Simultaneous logins may be an indicator of lateral movement. |
|
Knowledge Profile |
Known Unknown |
|
Axiom |
It is not typical to see “normal” user accounts simultaneously logged into multiple systems. While certain administrative or “power users” may exhibit this behavior, most users tend to use only one or two systems in the course of normal business. User accounts that log into multiple systems (especially within a brief span of time) may indicate compromised accounts and credentials. Related remote login sessions across multiple systems may indicate lateral movement. |
|
Data |
Datasets include:
Related NetWitness Content:
More information: |
|
Techniques and Patterns |
ATT&CK™ Tactic(s):
ATT&CK™ Technique(s):
Look for:
Note: Certain users or classes of users may need to be whitelisted after sufficient vetting. |
|
Feedback |
Derivative Intelligence:
Next Steps:
|
|
Related Hunt Cards |
Simultaneous logins on a host |
|
Related Analytic (Mitre CAR) |
Hunt Card Examples (Packet-based)Hunt Card Examples (Packet-based)
Phishing Messages with Malicious Links Example
|
Phishing Messages with Malicious Links |
|
|
Activity Profile |
Email messages that include malicious links are designed to convince users to click on links in order to deliver malware payloads. |
|
Knowledge Profile |
Known Unknown |
|
Axiom |
Email messages containing malicious links, designed to deliver malware payloads, remain one of the most significant and consistent threats faced by enterprises today. Criminal actors leverage a wide variety of email-based techniques to entice users to malicious sites and affect the establishment of initial beachheads within environments. Links to malicious sites embedded in the body of an email continue to lead to a significant number of incursions; effectively detecting these techniques is a critical capability in reducing the impact of attacker successes, reducing attacker free-time, and mitigating the impact of credential compromise and lateral movement. |
|
Data |
Datasets include:
Related NetWitness Content:
|
|
Techniques and Patterns |
ATT&CK™ Tactic(s):
ATT&CK™ Technique(s):
Look for:
More information: |
|
Feedback |
Derivative Intelligence:
Next Steps: Basic guidance/Run card or phishing playbook |
|
Related Hunt Cards |
Phishing Messages with Malicious Attachments |
|
Related Analytic (Mitre CAR) |
NA |
Client-side Exploitation: Drive-by (RIG) Example
|
Client-side Exploitation: Drive-by (RIG) |
|
|
Activity Profile |
Identify and detect RIG EK activity based on network traffic analysis. |
|
Knowledge Profile |
Known Known |
|
Axiom |
While the widespread use of Exploit Kits has been in steady decline since the demise of the Lurk Group and Angler in June of 2016, the RIG EK ascended to the throne and has managed to remain a relatively persistent threat. It has evolved rapidly, and been able to adapt to new threat trends, such as ransomware, information stealing, and most recently, coin-mining. As of January 2018, RIG remained the market leader in the EK landscape. Looking at RIG operations over time, it is easy to see that the actors behind the related campaigns are financially motivated. Effective detection of RIG can provide not only a tactical advantage against the direct threat of the EK itself, but may provide valuable insight into shifts in operational cadences and the overall threat landscape. |
|
Data |
Datasets include:
Related NetWitness Content:
|
|
Techniques and Patterns |
ATT&CK™ Tactic(s):
ATT&CK™ Technique(s):
Look for:
More information: |
|
Feedback |
Derivative Intelligence:
Next Steps:
|
|
Related Hunt Cards |
NA |
|
Related Analytic (Mitre CAR) |
NA |
Lateral Movement RDP Example
|
Lateral Movement RDP |
|
|
Activity Profile |
Detect abuse of lateral movement using RDP. |
|
Knowledge Profile |
Known Known |
|
Axiom |
Lateral movement is perhaps the keystone tactic in contemporary attacker methodologies. Following a quick entry via vectors such as phishing or web application compromise, Lateral movement is the pivotal step in reinforcing and expanding an attack. Remote Desktop Protocol (RDP) is just one technique that adversaries may employ for lateral movement. However, once they have obtained valid credentials, this is often the preferred means of establishing interactive access to assets. The clandestine use of legitimate tools (such as RDP) provides good cover for adversaries, and can often be very difficult to detect. That said, it pays to focus on these tactics, as lateral movement is where adversaries spend the majority of their time, and is coincidentally when they are most vulnerable. The ability to detect and isolate adversarial use of RDP can be particularly important, not only in detecting the presence of an adversary in your network, but also in understanding and controlling the scope of an incursion. |
|
Data |
Datasets include:
Related NetWitness Content:
|
|
Techniques and Patterns |
ATT&CK™ Tactic(s):
ATT&CK™ Technique(s):
Look for:
|
|
Feedback |
Derivative Intelligence: IOCs/IIOCs, rules, parsers, etc. Next Steps: Basic guidance/Run “card” |
|
Related Hunt Cards |
NA |
|
Related Analytic (Mitre CAR) |
AppendixAppendix
Network ParsersNetwork Parsers
These network parsers generate username or email meta.
Username
- dcerpc.lua
- ftp.lua
- http.lua
- imap.lua
- irc_verbose.lua
- kerberos.lua
- ldap.lua
- ntlmssp.lua
- pop.lua
- proxy_block.lua
- qq.lua
- radius.lua
- sip.lua
- smb.lua
- socks.lua
- fingerprint_job.lua
Email Addresses
- http.lua
- mail.lua
- sip.lua
- smtp.lua
- vcard_lua.lua
UEBA Essentials Content PackUEBA Essentials Content Pack
As part of the ongoing development of content to combat threats, RSA develops content bundles. These consist of a grouped set of content (rules, parsers, feeds) that can be deployed as a group from RSA Live. For details, see Deploying a Bundle.
Note the limitations of the UEBA Essentials content pack:
- It only works out-of-the-box with RSA NetWitness Platform versions 11.1 and later.
- Deployment of some ESA Rules to NW releases prior to v11.1 will result in a failure to deploy due to Context Hub list dependencies.
- To see the affected ESA Rules, refer to VERSIONS SUPPORTED section of the Description field for a specific rule in RSA ESA Rules.
Related MaterialsRelated Materials
- Lateral Movement details: Lateral Movement Content Pack
-
Third Party links:
- JPCert CC: Detecting Lateral Movement through Tracking Event Logs
- CERT-EU: Detecting Lateral Movements in Windows Infrastructure (PDF)
